Скрость проверки плагинов специалистами WebAsist
Форум »
К сожалению, ваш продукт Дополнительные изображения для артикула товара для Shop-Script 7 не может быть опубликован в магазине Webasyst. Причина отказа в публикации: Не используйте в data_thumb.txt короткий тэг <? , указывайте полностью с <?php , короткие теги по умолчанию отключены на серверах.
За несоблюдение требований, которые предъявляются к разработке программных продуктов, публикуемых в магазине Webasyst, дата очередной отправки вашего продукта на проверку перенесена на 19.02.2018.
Т.е. для исправления элементарной ошибки мне потребуется ждать чуть более недели.
При этом первую ошибку, возникшую с плагином, специалисты WA так и не смогли повторить\прокомментировать:
Не удаётся зайти даже в настройки плагина [20-Jan-2018 20:23:19 Europe/Moscow] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 8388608 bytes) in /var/www/sub/wa-system/plugin/waPlugin.class.php on line 60 [20-Jan-2018 20:24:01 Europe/Moscow] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 8388608 bytes) in /var/www/sub/wa-system/waSystem.class.php on line 1322
Также содрудник поддержки WA мне завуалировано угрожает:
Вы и правда считаете, что споры с модераторами по поводу первого и еще не опубликованного продукта - это лучший способ наладить сотрудничество?
Это ответ тех.поддержки WA на вопрос:
"По поводу Fatal error - ищите решение в тексте ошибки." Как я уже писал данную проблему мне воспроизвести не удалось, если она возникает у Вас, то сообщите при каких условиях. Сложно исправлять баги которые возникают только у Вас причем без каких-либо видимых причин.
И далее:
"споры с модераторами по поводу первого и еще не опубликованного продукта"
Я пытаюсь разобраться. Когда проблемы возникли по моей вине, я это честно признал и принес извинения за лишнюю нагрузку. Хотелось бы надеятся на аналогичные действия со стороны вашей компании.
"Вторая ошибка говорит о плохой оптимизации кода"
Как он может быть плохо оптимизирован если основной код класса настроек состоит из 1 строки?
class shopEnsoskuimagesPluginSettingsAction extends waViewAction
{
public function execute()
{
$this->view->assign('plugin', wa('shop')->getPlugin('ensoskuimages'));
}
}
Тестовые замеры также подтверждают что проблем нет:
$start = memory_get_usage();
$a = wa('shop')->getPlugin('ensoskuimages');
$middle = memory_get_usage();
$b = wa('shop')->getPlugin('ensoskuimages');
$end = memory_get_usage();
echo round(($middle - $start) / 1024) . 'kb - ' . round(($end - $middle) / 1024) . 'kb'; // Результат: 597kb - 4kb
Следовательно либо у Вас был какой-то сбой, либо Вы при тестировании используете какие-то настройки которые я не могу воспроизвести, именно поэтому я и уточняю детали.
.
Максимальное кол-во используемой памяти не фигурирует в https://developers.webasyst.ru/store/check-list/, т.ч. даже если проблема возникла, то я не мог её устранить на этапе разработки ввиду отсутствия у меня полной информации об условиях тестирования. Ответ:
Тогда вы честно можете поправить абсолютные УРЛы и отправить вашу работу через неделю снова на проверку - наши модераторы посмотрят еще раз и дадут свои комментарии, либо же опубликуют плагин, если не найдут каких-либо ошибок.
Т.е. по сути поддержка WA игнорирует вопросы и завуалировано угорожает, хотя как я понимаю изначальная проблема произошла на их стороне.
Хотелось бы уточнить у всех коллег возникают аналогичные проблемы?
Я пол года один плагин уже на модерацию посылаю, это как информация на заметку. Благодаря их внимательности в магазине не появляется кривых продуктов, не считая древних
Вроде всё норм. Рабочие моменты
Да. Правила одинаковы для всех. Да, после второго отклонения у всех включается таймер. Неважно из-за ошибки, опечатки или еще из-за чего.
Нет, проверяющие не обязаны разбираться в причинах возникновения ошибки, консультировать о способах их устранения. Они удостоверяются, что продукт соответствует требованиям и работает.
Ну вот так. Может не оч. справедливо, ну как есть.
Где указано о том что при тестировании мин. число оперативки 512мб?
По умолчанию вообще 128, ну и кому в радость будет использовать программу, которая потребляет столько памяти? Смотрите, что с загрузкой файлов у Вас, делайте проверки на максимальный вес файла и тому подобное.
Собственно как написано в первом посте мои тесты показывают что используется:
Про память: очень желательно, чтобы код мог работать при ограниченных ресурсах (32-64Мб памяти). Но если не хватает 512Мб памяти, то это однозначный признак того, что "кажется, что-то пошло не так". А именно ради одной строки данных вы из БД запросили все записи. У вас "всё работает" но во вполне реальных случаях, где категорий/товаров/типов/характеристик/значений/заказов/покупателей/позиций в заказе счет идет на сотни тысяч будут наблюдаться ненужные замедления работы (выделение памяти и её наполнение из БД/файлов/кешей занимает время).
Если нет понимания этого момента, то просто необходимо в этом разобраться.
Владислав,
где именно?
Каким образом размер каталога может как-то ощутимо повлиять на работу плагина? данные в отдельной таблице снабженной индексами.
Давайте поконкретнее\поконструктивнее - где по Вашему в плагине подобные проблемные места?
Ищите, где делаете SELECT без LIMIT
У меня последний плагин вообще целый месяц проверяли. Видимо не особо интересный был.
Биткоин упал, путина снова выберут, Маск промахнулся теслой по Марсу и она улетела в поле астероидов.
Что-то в этом мире не так...
Виктор, размер каталога не должен влиять ощутимо при правильном проектировании кода плагина. Пример с запросом всех строк был приведен как пример, причем достаточно типовой (что не очевидно), указать где именно у вас ошибка проблематично, поскольку вы уже несколько раз загружали обновленный код и я лично его не видел.
И если грубо говорить, то модерация — возможность услышать разработчику об ошибках не от клиента (А, всё пропало! У меня ничего не работает, срочно исправляйте!!!111), а от модераторов (без обязанности последних по исправлению и детальному анализу ошибки) с некоторыми минимальными техническими комментариями. Какие-либо рекомендации по исправлению с примерами кода и/или отсылками к аналогичным по функционалу решениям — это лишь добрая воля модераторов.
Но если вы настаиваете, могу потратить 5 минут и назвать плохие куски кода.
Да выкладывайте уже сюда плагин ... вместе разберем :)))
shopEnsoskuimagesPlugin::productDeleteHandler — SQL запросы в цикле, чтобы после во внутреннем цикле по одной удалять записи из БД и заодно по одному удалять файлы... В стандартном интерфейсе можно удалить пачку категорий со всеми товарами из этих категорий (коих может быть тысячи, не говоря уже об артикулах). "Ничего не смущает?" (с). Следует оптимизировать получение данных, а так же структуру директорий, так чтобы, удаление одного товара требовала удаления записей из БД одним запросом, а так же удаление одной директории. А не извращаться с циклами внутри циклов. В догонку: скидывать все 100500 файлов в одну директорию — плохо, используйте разряжение директорий (причины, надеюсь, сумеете найти самостоятельно).
shopEnsoskuimagesPluginBackendActions::uploadAction — оставлена возможность загрузки php файлов в директорию, открытую всем (нету проверки расширения, опираться на type некорректно)
Первое - существенный момент в производительности (на мой личный взгляд - фатальный, требующий переделки). Второе - показатель недостаточной безопасности кода (попытки фильтрации по типу есть, но её недостаточно).
Так что "Ничего не работает!!! срочно исправляйте!!!111 Галактеко Опасносте!"
J. B. diGriz
Вопрос был адресован Владиславу. Моя IDE профилирует в том числе и запросы, т.ч. можно обойтись без банальностей.
Владислав Горлов
Код shopEnsoskuimagesPluginSettingsAction изменениям не подвергался, там и изменять то толком нечего. Вообще после первоначальной отправки php код существенных изменений не претерпел - правки мелких багов и косметика.
Хотелось бы узнать в первую очередь о том, что у Вас вызывало:
То что часть функционала нужно из класса плагина перенести в модель я и сам знаю.
BNP (Дмитрий)
Если дело застопорится, то вполне возможно.
Вы не используете возможности IDE (судя по phpDoc). Не я занимался проверкой плагина, могу лишь предполагать, что могло иметь место интерференция от двух проверяемых плагинов, а тонкий анализ явно за пределами моих личных 5 минут.
Отпрофилируйте меня полностью.
$product_model->getByField('status', 1, true); тоже отпрофилирует?
Научите! А то у меня в списке товаров 1.5 млн записей.
Владислав,
Visual Studio Code из коробки не поддерживает phpDoc, да и ставить расширение смысла особого не вижу - все равно половину описания придется вручную задавать.
да, это есть в планах.
Мне почему-то казалость что type формируется у Вас с помощью waFiles::getMimeType(), ок поправлю.
ITFrogs,
Цель профилирования в том, чтобы найти подобные места и устранить. В случае нехватки памяти IDE сообщит в каком месте возникла данная проблема т.ч. не вижу проблем в локализации таких запросов.
Хорошая у Вас IDE. Всем бы такую...
Я б уже 80 плагинов на такой бы наклепал.
Т.е. глюкануло у Вас и не разобравшись, не перепроверив свалили вину на плагин.
Понятно что плагин не идеален, но вполе работоспособен.
Владислав не модератор и не проверяет плагины. Он ничем Вам не обязан и просто глянул на плагин, потратив 5 минут времени, дал совет.
Как же достали эти нытики... «У меня всё в порядке, это у Вебасист глючит», «Это не ошибка, я так вижу», «Меня забанили, мне угрожают, я такой бедненький», «Вебасист не хочет меня носом ткнуть, где я ошибся»...
Твою ж мать! Владислав за 5 минут нашел 2 серьёзные ошибки!Вместо того, чтобы писать на форум, нужно заняться исправлением и доведением продукта до ума!
Все разработчики с подобными проблемами при модерации сталкивались. Все разработчики хотя бы раз получали бан. Но когда разработчик несколько лет «поработает» с Вебасист, он уже понимает, что комментарии модератора реально ценны, а если модератор ошибается, то это решается через личный кабинет, а не на форуме (не считая одного случая с ITFrogs).
— Соберись, тряпка! (с)
Ответы модераторов иногда надо переводить с языка магистра Йоды, это бесит, на это уходит время, но потом все становится на свои места.
ITFrogs,
Иерархия WA мне не известна - он отвечал, я спрашивал.
собственно для этого и ide даже не нужна https://dev.mysql.com/doc/refman/5.7/en/show-profile.html
Злой тролль,
Это не ошибки, а советы по оптимизации.
ага, особенно когда выясняется что они не достоверны:
в итоге выяснилось что все загружается куда нужно и требовалось сделать ссылки абсолютными (чем это обусловлено мне до сих пор честно говоря не ясно).
Если ваш плагин будет вешать весь wa, то винить будут wa, что для них не хорошо. Так что оптимизация это правильно и хорошо.
Господи! Адекватный! Не начал кидаться в ответ говном ))
Тогда адекватный ответ:
Я бы не назвал это проблемами. Это скорее «рабочие моменты». Да, порой модераторы делают замечания, которые кажутся придирками. Да, часто дают баны на какое-то время. Совет один: всегда слушать модераторов и стиснув зубы выполнять их требования.
Да, иногда модераторы ошибаются. Не стоит выносить сор из избы и писать на форуме. Через личный кабинет можно вести диалог, и часто модераторы идут на встречу и признают свою неправоту
Ну зато весело же было с Андреем!
А вот Федор все через ЛК. И чисто поржать можно только когда он избранные места из переписки публикует :-)
А чего весело? Я быстро меняюсь и подстраиваюсь. Да и пошуметь люблю. Если не шуметь, в этой стране ничего не делается.
km,
кто же с этим спорит? я за конструктивную критику) но изначальный пост совсем о другом.
Хотелось бы получать список притензий целиком, а не по 1 раз в неделю. А то по сути я уже доделываю описанное Владиславом, а проверка возможна только 19ого.
Ну и чтобы проверка проводилась повнимательнее + приводились условия при которых ошибка возникла.
Модераторы могут с первой ошибки сразу отлуп дать.
Можете еще пару фич прикрутит и проверить зато )
Enso studio, вы случаем модерацию с тестированием не попутали? =)