Как в плагине доставки реализовать доступ к БД
Про то, что в силу идеологических соображений и не желания всерьёз думать о своём продукте разработчиками движка, которые не дали штатного механизма для плагинов оплаты и доставки доступа к SQL серверу - в курсе. Но что тогда делать? использование умопомрачительного механизма хранения настроек в виде текста в поле длиной в 65535 байт порождает тупик. Ну не лезет туда информация о 109 пунктах самовывоза с адресами и параметрами для расчёта. В БД бы чудно хранилось и искалось - НО НЕЛЬЗЯ! Как выйти из такого тупика? Тупо переписывать метод плагина доступа к настройкам, чтобы конкатенировать куски по 65535? Или нарушать инструкцию по разработке и нагло создавать таблицы в обход моделей коих просто нет в плагинах? Подскажите...
p.s. Это просто плач ярославны, которую гнобят при публикации продукта, что используются неидексированные элементы массива в языке, который по определнию не является строгим и в котором даже в учебниках и примерах считается нормальным конструкция $var++; над не инициализированной переменной, а здесь отвергается.
34 ответа
самое печальное, что движок чудно принимает в методе saveSettings значение, которое не в силах сохранить, делает вид что записывает его, но потом, при обращении к такому параметру, всё рушится, поскольку массив json , сохранённый в БД обрезан с "хвоста". Никакого анализа на размер и возможность сохранения нет. Так и хочется сказать
"И эти люди не разрешают мне ковырять в носу"
Если есть желание, то можно и доработать. Плагины доставки относятся к фреймворку, код открыт, доработайте и предложите изменения. Я делал такую доработку, но не закончил. Необходимость отпала.
Гораздо неприятнее, что вы можете столкнуться с ограничением на количество POST-переменных в настройках сервера при сохранении настроек. На многих хостингах их количество ограничено 1000 или даже меньшим числом и при 100+ пвз с настройками вы легко вылезаете за лимит. Обойти это ограничение можно, но придется довольно развесистый js вешать или вклинивать свой обработчик сохранения формы, причем не совсем честным путем, чтобы он стал первым. :-/
Это попробуем решить переносом _csrf в конец списка переменных формы и сравнениями числа переменных с допустимым на стороне сервера (если это значение доступно)
В коде js-контроллера, который выполняет сабмит формы хотелось бы какой-нибудь js-хук. Я еще не придумал, как это реализовать :) Я бы часть настроек тогда смог сериализовать в json а в методе saveSettings() десериализовать.
У меня многие плагины получают списки городов/пунктов/регионов и т.п. с сервера перевозчика. И условия доставки считают автоматом (правда с наложением всяких там наценок). Но иногда пользователи просят сделать для какого-нибудь объекта или некоторых объектов спец. условия (например "запрет доставки по Москве" -- есть свой курьер, курьерская служба не нужна или "эта 2 ПВЗ находятся радом и срок доставки в них день в день, а остальные +1 день").
Можно было бы такое сделать, но 100% упрусь в ограничение ибо количество этих "спецусловий" может быть большим.
Пока думал о том, чтобы в какой-нибудь скрытой textarea хранить сериализованный json и сделать 2-way js-конроллер конторых синхронизировал бы данные из этой скрытой textarea. Но что-то реализация уж больно тяжелая получается.
С этим я уже давно столкнулся, но это решается организационно с помощью requirements.php и требованием к нужному значению max_input_vars. Так что это как раз менее значимо
Код в гитхаб открыт для подобных изменений — прототипы для реализации есть, если сможете корректно реализовать - многие будут благодарны. И пока случаев, требующих обязательного наличия собственных таблиц у плагина была крайне мало, поэтому реализация этого механизма была отложена.
Про обрезку данных с хвоста - это определяется режимом работы MySQL (и настройками хостинга отчасти). Проверять все данные перед сохранением - не лучшая идея, но в каких то случаях может чуть раньше сообщить об ошибке (хотя тут спорно, что хуже: работа с устаревшими данными и ошибкой при попытке обновить их или вывод ошибки при расчетах в случае если новые данные не сохранились корректно).
Про p.s.: ошибки вида undefined index лично я считаю критичными (про нестрогость языка - разговор отдельный и холиварный) и схожими с ошибками обращения не по адресу переменной, а рядом.
По сути: если не лезет, то не надо пытаться впихнуть всё в одну настройку. Разделите на список пунктов/условия доставок/адреса/тарифные сетки, используйте короткие ключи. (про 64/128КБ и 4/8МГц доступные "раньше" я уж промолчу). Это не лучшее решение, но отодвигает границы проблемы.
В отличии от разработчиков webasyst я не получаю за это зарплату. Я с удовольствием участвую в некоммерческих проектах как тестер и аналитик последние лет 30. Это не Best Practical и я не бездельник, который от скуки помжет тем, кто за исправление ошибок в существующем движке снимает с пользователей новый платёж под маркой смены версии.
Похоливарю про индекс. Вы считаете что конструкция вида $a['b']++; критичнее чем $a['b']=isset($a['b'])?$a['b']++:1; ? Потому потом и получается что сервак просто умирает на переизбытке проверок.
Ну и как закатывать солнце вручную - понятно. Вариантов много. Геммор себе придумать всегда можно, опять же сильно утяжеляя код вместо того, чтобы пользовать готовые и заточенные под это решения в виде SQL
Фреймворк бесплатен и денег за него никто не берет.
Плагины доставки являются частью фреймворка, а не Магазина.
Таки деньги за продажу вы получаете. Почему бы не потратить часть этих средств в виде своих усилий на улучшение?
Инициализируйте переменные заранее и не придется проверять.
если поглядите, то мы плагины продаём за смешные деньги. И их цена даже не отбивает то время, что потрачено на их написание и сопровождение. (из-за полное наличие отсутствия документации и не возможности, как и здесь, получить консультацию по возможностям, а только умные советы как надо жить). Просто магазин из коробки пользовать не возможно, а допиливание хоть как-то хочется скомпенсировать. Мы вынуждены писать под этот движок, и лишнего времени на трату нет.
Про инициализацию. А если цель не величина значения а лишь наличие самой переменной. А его величина - вторичный параметр. Если на 500-стах элементах массива только у одного понадобится эавести этото параметр, то конечно оптимально инициализировать все 500, а не только один нужный. Это опять же вопрос к скорости обработки и оптимизации исполнения, хотя зачем ставить палки в колёса гонке производителей процессоров и их покупателей
И в чем тогда проблема заменить
на
У меня тут вопрос возник...
Плагины как-бы бесплатные, но используются они только в платном Магазине и больше нигде.
Поэтому вопрос не однозначный бесплатные они или нет.
А хороший пятничный тредик получается. Давайте его в форум для разработчиков перенесем?
Готово.
Вообще я эту тему с Александром Музыченко еще обсуждал года полтора назад :)
Ответ такой, что можно сделать и предложить, а Вебассист добавит поддержку install/uninstall этой БД. Там собстенно весь затык в том, что может быть насколько методов доставки (скорее всго в БД нужно отличать настройки одного метода от другого, но не всегда). Плюс при создании/удалении метода не вызывается install/uninstall плагина. Создать таблицу БД при ее отсутствии можно в saveSettings, но вот удалить ее уже не получится, даже если пользователь вообще удалит плагин, а это плохо.
Правда с того момента я нашел более другие способы хранить большое количество данных и вопрос для меня стал неактуален :)
Интересненько, что за способы?
Я общие параметры плагина вынес в wa-config (где им и место) :) Правда мне много полей не надо было.
Ну, мы с Павлом это сам_знаешь_где обсуждали. Я в xml это храню.
О, пошёл накат. Нельзя покушаться на святое и писать претензии? После данной темы в очередной раз отказали в публикации плагина за неинициализацю не нужных переменных при генерации страницы настроек и заблокировали последующую отправку на проверку.
Как-то мелочно. При условии что наш предыдущий плагин использует точно такой же алгоритм и даже сам код не чисто написан мной, а построен по примеру чужих плагинов.
нельзя критиковать и тут....
в смысле "заблокировали последующую отправку"? Это как?
сколько раз отправлял на првореку - всегда принималось, проверялось с большой задержкой только. А в этот раз нарисовало на экране отлуп с текстом что за многочисленные ошибки приёмка отложена до 20.05.2016. То, что раньше по две недели проверяли - это нормально, а теперь ещё и не принимать стали :)
Смешно на самом деле. Кого наказывают? Только покупателей магазина. Я то, что мы получаем с плагинов, деньгами не считаю. Это даже мои временные затраты на сопровождение и вычитывание чужого кода, чтобы найти ответ на очевидный вопрос, не освещённый в документации, не возмещает.
Простите, просто наболело. Нет у этой компании уважения к тем, с кого они деньги работают.
С целью мотивации разработчиков более тщательно самостоятельно проверять собственные скрипты введен таймаут для повторной отправки на модерацию в случае если число отказов подряд превышает пороговое значение.
Раньше этот таймаут задавался инструкциями разработчику, и запрос висел во внутренней очереди, то теперь запрос на модерацию просто отклоняется с соответствующим сообщением и предложением отправить в назначенную дату, в ожидании которой можно еще раз просмотреть собственный код.
Разработчиков с хроническими отказами не много и они сами знают свои проблемы (кто-то исправляется, а кто-то из раза в раз допускает одни и те же ошибки)
повторюсь. Если использование в шаблоне не инициализированной пустотой переменной, которая даёт ожидаемое false в проверке - ошибка, то почему опубликованы все остальные плагины с таким кодом?
Модерация не всегда выявляет все ошибки. Примеры, пожалуйста, если конечно вы хотите назвать те источники, откуда был скопирован код.
Настройка автоматических таймаутов не зависит от содержания записей в хабе, это общее решение чтобы разработчики проверяли свой код тщательнее перед отправкой на модерацию.
<sarcasm>Гм, наверное вы считаете что для вас undefined index: amount денег лишние</sarcasm>
Отказ дан за те ошибки, которые обозначены в списке обязательных к исправлению ошибок, если вы не желаете их исправлять — это отдельный разговор. И отказ никак не коррелирует с вашими сообщениями здесь — проблема, обозначенная вами действительно существует, у неё есть ряд решений (разной степени неудобства).
о сколько набежало попинать и похвастаться как нас ещё наказывать будут. Лучше бы это время на написание документации хотя бы по workflow потратили
Аркадий, стыдно так делать.
Модератор этого, конечно, не увидит потому, что у него ключа нет. Но все равно стыдно.
Извините. сто не сразу отвечаю - на срубленных лёгких бесстыдных деньгах с 10 продаж этого плагина в Норвегии зависал в отпуске.
Стыдиться лично мне тут нечего. Во всех языках нормальная практика использовать инкремент над не инициализированной переменной (типа $array[$index]++; Извините, что у вас это вызывает чувство нескромности. Разрисовал конструкцию на длинную цепочку по проверке если пусто, то присвоить 1, а иначе инкримировать.
Все языки - это basic и php?
В JavaScript как будете undefined инкриментировать?
я птичьи языки плохо знаю. Я на C и Perl пишу. А что такое basic?
Я просто оставлю эту ссылку на зеркальную ситуацию здесь.
Спасибо. Хороший пример. Требовать от клиента отсутствия варнингов, при этом имея у себя ошибки не то чтобы посмотреть хотя бы и исправить, когда о них сообщают, а даже нахамить в ответ. Комплекс Юпитера?
Хамство у них бывает прорывается, но это вам не google с тысячей индийских модераторов с заготовленными алгоритмами на все случаи жизни, а небольшая компания с живыми людьми, и мы вполне можем вызвать у них личную неприязнь своим поведением и претензиями.
По поводу варнингов, Ваше поведение напоминает ролики из стопхама. Человеку говорят чтоб не нарушал правила и убрал машину, а он начинает демагогию о том, что сначала уберите вон те машины, идите лучше работать, напишите мэру итд...
Хз как Вам, а мне стыдно бывает, если какой-нибудь юзер пишет на форуме, что поймал нотисы в логах от моего плагина. Тут я уж, как ошпаренный, все бросаю и бегу исправлять. Спасибо модераторам, что они 90% таких случаев пресекают накорню.
О, кого-то вместо меня теперь ругают за плохое тестирование :)