Разработчикам: как увеличить продажи приложений, плагинов, тем дизайна и уменьшить время модерации в магазине Webasyst
Владимир Тупоршин-мл.
28 марта 2014
Сегодня в магазине Webasyst появилось выделение популярных и рекомендованных продуктов с помощью разноцветных наклеек (бейджиков).
Наклейка «Рекомендуется» (зеленая) вручную устанавливается модераторами после проверки продуктов. Мы выделяем наклейками качественные и действительно полезные продукты, которые помогают пользователям Webasyst и Shop-Script 5 решать поставленные задачи, больше зарабатывать, выполнять работу быстро и удобно.
Наклейкой «Новинка» автоматически маркируются новые продукты, недавно опубликованные в магазине Webasyst. Отдельные выбранные модераторами «Новинки» (наиболее интересные и новаторские продукты) автоматически попадают на некоторое время в топ всех списков. Если продукт не интересен (например, если это клон уже опубликованного ранее продукта), то он, хоть и обозначенный «Новинкой», будет помещен в конец списка.
Наклейка «Новая версия» назначается вручную при значимых обновлениях продуктов.
Отображение плагинов и тем дизайна на главной странице магазина Webasyst теперь тоже работает на основе наклеек и внутреннего рейтинга продуктов.
Также сегодня был добавлен поиск плагинов. Поиск работает по названию продукта и ключевым словам, которые каждый разработчик может редактировать в описании продукта в Центре заказчика (до 10 ключевых слов на продукт).
Как увеличить продажи ваших продуктов в магазине Webasyst?
- Делайте уникальные продукты, которые реализуют полезный новый функционал и добавляют ценность всей экосистеме Webasyst, а не копируют уже опубликованные продукты. Для всех продуктов, опубликованных в магазине Webasyst, справедлив проверенный временем принцип: 80% продаж обеспечивают только 20% продуктов (цифры могут отличаться для тем дизайна и плагинов, но порядок именно такой). Лучшие продукты продаются в несколько раз лучше прочих. Плагины-клоны практически не продаются и не скачиваются.
- Мы принимаем к публикации продукты вне зависимости от того, повторяют они функционал других уже опубликованных продуктов или нет. Другими словами, в магазине Webasyst нет возможности «занять» какую-то нишу, просто первым создав приложение или плагин для нее. Несмотря на это, мы не поощраем откровенное клонирование и копирование функционала уже разработанных продуктов. Продукты-клоны, которые бы по качеству превосходили оригинал, на модерацию мы пока не получали.
- Если приложение, плагин или тема дизайна выполнена качественно, проходит проверку с первого раза, решает поставленную задачу хорошо, действительно помогает пользователям, мы с удовольствием отмечаем такой продукт в магазине значком «Рекомендуется». У новаторских продуктов есть все шансы быть выделенными в списках, у продуктов-клонов — практически никаких шансов на выделение.
- Плагины можно делать не только для Shop-Script 5. Есть еще, например, приложения «Блог», «Фото», которые не уступают Shop-Script 5 по количеству установок. Скоро мы добавим возможность публиковать плагины также и для приложения «Сайт».
- Разрабатывайте новые приложения для Webasyst. Существует множество задач, которые еще не решены продуктами Webasyst: управление заданиями, временем, проектами, взаимоотношениями с клиентами и коллегами, рекламой, продвижением сайтов, чтением новостей и фидов, почты, работы с картами, документами, совместное редактирование страниц и многое многое другие.
- Сортировка плагинов и тем дизайна в магазине Webasyst обновляется автоматически раз в несколько часов и рассчитывается на основе данных о продажах, количестве скачиваний продукта, оценкам пользователей. Чем больше людей вы приводите на страницы ваших продуктов в магазин Webasyst и чем больше они покупают ваш продукт, тем выше позиция продукта в обших списках.
- О наиболее интересных продуктах мы рассказываем в Твиттере и в Фейсбуке Вебасиста, а иногда и в блоге и на сайтах.
- По мере появления новых тем дизайна мы будем добавлять фильтрацию по категориям (отраслям, специфике) для тем дизайна: темы дизайна для магазинов автозапчастей, одежды, подарков, детских товаров, для фотогалерей, персональных блогов и сайтов и т.д. Со временем категоризация будет внедрена также для плагинов и приложений.
- Делайте продукты с базовой локализацией на английском языке и переводом на русский и публикуйте их в англоязычном магазине Webasyst (для примера таких продуктов можно посмотреть любое из бесплатных приложений, плагинов и тем дизайна разработки Вебасиста).
- Делайте меньше, но качественно. Лучше (выгоднее) разработать один хороший продукт, чем десять посредственных.
Несколько идей для новых плагинов были предложены в недавнем посте.
Как сократить время модерации?
- Делайте уникальные продукты. На модерацию каждый день поступают десятки плагинов, тем дизайна и приложений. Естественно, что новым продуктам модераторы уделяют больше внимания, чем очередным вариациям плагинов на тему «кнопка прокрутки страницы вверх».
- Мы проверяем каждый продукт на общее соответствие функционала описанию, но не производим тестирование каждой отдельной фичи продукта. Тестирование не является задачей модераторов. Задача модерации — это проверка безопасности продукта, его работоспособности, возможности простой установки и удаления, запуска на типовых серверных конфигурациях, на которых работает фреймворк Webasyst. На основе этих параметров и новизны продукта модераторы определяют достоин ли продукт выделения в списках магазина Webasyst или нет. Ответственность за функциональность, работоспособность и качество продукта несет непосредственно разработчик.
- Тестируйте ваши продукты, прежде чем отправлять их на модерацию.
Многие продукты добросовестных разработчиков проходят модерацию с первого раза. Прочие разработчики, безответственно относящиеся к тестированию, получают отказы по банальным причинам: продукт не запускается, сыпятся нотисы и варнинги и т.д.
При тестировании плагина включите в настройках PHP
error_reporting=E_ALLи в настройках MySQLsql_mode=TRADITIONAL. Перед отправкой на публикацию попробуйте установить ваш продукт в новую установку фреймворка Webasyst, где он еще не был установлен до этого (скопируйте файлы продукта в новую установку фреймворка и подключите его в конфигурационном файле). Попробуйте сделать то же самое, только во фреймворке, установленному не в корне домена, а в подпапке, например,localhost/subfolder/. - Проверка модераторами происходит до первой найденной ошибки. Если разработчик получает отказ в публикации, то это значит, что нужно исправить не только указанные ошибки — лучше еще раз все тщательно проверить и убедиться, что нет других ошибок. Учитывая замечания и исправляя ошибки по одной, можно проходить модерацию несколько недель или даже месяцев в течение многих итераций и ожиданий. А можно просто один раз внимательно посмотреть написанный код, выполнить больше тестов, попробовать установить продукт еще на один сервер или хостинг, и получить опубликованный плагин уже через 3—4 дня (это среднее время проверки и публикации в магазине Webasyst).
- Если разработчик, получив замечание, игнорирует его и повторно отправляет плагин на модерацию (удивительно, но такие случаи действительно встречаются часто), это сказывается на времени модерации. Приоритет отдается новым и интересным продуктам добросовестных разработчиков, которые заинтересованы в создании качественного продукта больше, чем в желании поспорить. Отказ формируется не с целью споров, а с целью указать на проблемные места, подсказать как сделать продукт лучше, чтобы в результате конечный пользователь был доволен покупкой, оставил более высокую оценку продукту. Мы не ставим ни малейшей задачи поучать разработчиков модерируемых продуктов, и нам совершенно не нужно держать очередь неопубликованных продуктов. Все обозначенные выше практики нацелены только на то, чтобы обеспечить конечному покупателю приятный опыт покупок в магазине Webasyst: возможность легко найти стоящий продукт, быть уверенным в его работоспособности, установить и сразу приступить к работе.
23 комментария
Касаемо сокращения времени модерации:
ответить1. Ну сделал вроде как уникальный и востребованный. И вы о нем писали, и на реформале много лайков собрал. И толку? 10 календарный дней уходит на каждую проверку.
3. Жаль, что этого пункта я раньше не увидел. Вопрос, а нафига нужна галочка "Режим разработки" или как там её в настройках инсталлера? Согласно логике она должна включать подробный вывод ошибок. И помоему это настолько очевидно, что я не додумался ручками включить error_reporting=E_ALL. Фраза "добросовестные разработчики" спорна. Правильно будет "менее везучие". Т.к. при отсутствии документации зачастую приходится писать методом тыка. И тут повезет или нет. Туда ткнул или нет. Кстати часть кода я брал из плагина, который продается в магазине. Удивительно, но именно заимствованная оттуда часть кода не устроила при модерации.
4. А вот это крайне глупо. Ладно, если речь идет о больших плагинах и приложениях. Но в случае с мелкими плагинами это плохой подход. Расскажу свой опыт. Отправил плагин на проверку. Спустя 10 календарных дней мне дали отказ по 3м причинам, относящимся к 1 строке кода. Причем существенной была только 1 причина(да и то спорно). Вторая носила более рекомендательный характер, а третья и вовсе ввела в ступор меня и всех знакомых кодеров. Нелепая и откровенно некорректная она была. Ну да ладно, исправил и повторно выложил. И снова 10 календарных дней ждал проверки на новый, оригинальный и востребованный плагин. И получил отказ из-за того, что в plugin.php у меня не указан параметр 'description'. Поясню сразу, я специально его не указываю, т.к. вся суть ясна из названия плагина. А лично меня бесят, когда в списке плагинов я вижу плагин "Вывод кнопки на странице" и тут же описание "Выводит кнопку на страницу". Ощущение, что меня считают идиотом. В общем к чему я клоню то. Теперь мне еще 10 дней ждать придется. А если бы модератор изначально досмотрел последние 3 строки, не останавливаясь на первой ошибке, то сразу сказал бы мне об этом "косяке" и уже давно плагин был бы в продаже и были бы выпущены новые версии с улучшением функционала. Кстати могли бы и предусмотреть отсутствие описания плагина.
У меня дико чешутся руки по модернизации плагина, но... но я реально боюсь уже) Вы сами поймите тот факт, что документации НЕТ. Я сейчас допишу 2 строки кода и получу отказ по причине "В этом месте лучше использовать другой метод этого класса. Вы могли бы это узнать, если бы сходили к гадалке. А вот всё остальное гут". И снова 10 дней буду ждать одобрения на изменение 1 строки. Бесплатно.
Это ведь вроде как и Вебасисту выгодно, чтобы оригинальные плагины быстрее поступили в продажу и, как следствие, быстрее разбогател их функционал.
В общем политика "Проверяем до первой найденной ошибки" для небольших плагинов - плохая политика. К тому же это нерациональный расход трудочасов модератора.
Если бы вы сразу почитали документацию (ту самую которой нет) и сразу бы сами протестировали свой плагин в самых разных ситуациях прежде чем отправлять на модерацию, то ждать бы столько не пришлось, но вы отнеслись "а сделаю как-нибудь, проверят, если будут ошибки, то сообщат же". Ну при таком подходе, что вы от нас хотите? Мы не учим программировать и разрабатывать хорошие плагины, в которых всё продумано. Об этом всём должен думать сам разработчик.
ответитьПро то как можно вообще разрабатывать что-то с выключенным error_reporting=E_ALL я просто промолчу...
По поводу проверки до первой ошибки. А какой смысл дальше проверять плагин, если найдена вообще нелепая ошибка или плагин сразу не работает? Это означает лишь одно, что разработчик очень плохо тестировал свой плагин (или вообще не тестировал), вот и мы возвращаем его, чтобы разработчик более добросовестно всё проверил, протестировал, еще раз посмотрел свой код и т.д.
К следующей проверке у хороших разработчиков как правило все ошибки и недочёты (даже те о которых не писали в отказе) исправлены и плагин спокойно проходит модерацию.
Но есть и уникальные "разработчики", которые делают в 10 местах одну и ту же ошибку, получают отказ, а на следующую проверку отправляют код, в котором ошибки исправлена только в одном месте из 10...
Да, в текущей документации есть инфа по построению запросов.. Мой косяк был в том, что я использовать $model->query("SELECT blablabla FROM shopTable WHERE ololo && tratata");
ответитьНу а была, например, и не особо понятная просьба использовать не NOW() для указания даты datetime полю, а date("Y-m-d H:i:s"), так как, цитирую "Время в MySQL может отличаться". Отличаться от чего? Долго думал от чего, ничего не придумал. Но таки исправил. Правда на gmdate(), дабы избежать 1 возвожной неточности, несмотря на то, что модератор сказал "Правильно использовать date()".
И это было единственное, что было в документации(той самой, которой нет). Давайте-ка посмотрим там инфу про написание плагинов. Да, там есть в plugin.php description. Но в этом же примере есть и handlers. Разве последнее обязательно? Нет и его можно вовсе не упоминать. Следовательно с description логика такая же, т.к. не в документации не сказано обратного.
Мультивитринность изначально я тоже не хотел поддерживать намеренно. Во-первых, по личным убеждениям. Я не признаю этот функционал. И вот тут странно то, что вы точно так же не признаете мультиленг, т.к. "это мало кому нужно, но геморно", а вот с витринами суть та же, но ваше решение другое. Во-вторых, без документации хрен знает, как её правильно поддерживать. Там описан лишь 1 массив. Мол этого хватит. Можно было бы предположить, что это я дурак, на что вы и откровенно(даже слишком) намекаете в своем посте, но ведь и опытные и хорошие разработчики(топовые в данный момент) тоже со скрежетом на зубах вспоминают те времена, когда им методом тыка приходилось изучать работу с роутингом. В-третьих, я не раз видел плагины без первоночальной поддержки подобного функционала, а значит на первое время такое допускается, что я и хотел сделать. Но сейчас, пока ждал очередной проверки, перелопатив тонну кода кое-как нашел способ, который вроде поддерживает мультивитринность и работает правильно. Проверял все возможные варианты. Но вот терзают сомнения, что могу получить отказ, т.к. надо было делать как-то иначе.
Про error_reporting я уже сказал. Зачем тогда вообще нужна галочка "Режим отладки"? Ну-ка, найдите-ка мне это в документации(той, которая есть). Если вы знаете, что она не включает вывод всех нотисов, т.к. вы являетесь внутренним разработчиком и знаете всё, то это не значит, что это должен знать я. А согласно логике она должна включать включать это. Кстати прошу пояснение, что она делает? Если бы я знал, что она бутафорская, то заметил бы ошибку, которая послужила причиной второго отказа(ну вернее нет, т.к. по ошибке я не тот архив загрузил, ну да ладно).
Но это я уже отошел от темы "Проверка до первой ошибки". Помоему я в первом посте ясно указал причины и недостатки такой проверки. Давайте на примере задачки. Дано - 10 строк кода, в каждой из которых есть ошибка. На проверку 1 строки модератор тратит минуту рабочего времени. Вопрос. Сколько времени модератор потратит на проверку способами "После найденной ошибки всё сначала" и "До конца за 1 раз"? Ответ: первым способом "1 час 05 минут"; вторым "10 минут". В Германии, например, за подобное решение начальник, принявшие решение работать таким способом, был бы уволен. Компания несет лишние расходы. К тому же это задерживает выпуск продукта, а значит и отсутствие дохода. А кто выигрывает то? Да никто. И какой смысл? Это я попытался объяснить минусы для Вебасиста. Разумеется когда речь идет о больших плагинах или приложениях, такая схема не особо работает. А вот в случае с мелким плагином, как у меня, проверять нужно до конца. Если бы было так, то плагин уже продавался бы потихоньку. Второй отказ я получил по причине, которую знать не мог. И нет причин тянуть лишние 10 дней.
Если вы что-то не хотите специально поддерживать, то об этом нужно писать жирными буквами в описании плагина, чтобы не вводить покупателей в заблуждение.
ответитьВ противном случае, плагин не пройдет модерацию по очевидным причинам.
По поводу date, допустим у вас сервер в америке, с помощью функции date_default_timezone_set в SystemConfig.class.php вы можете спокойно выставить нужную вам зону, например, Europe/Moscow и в php у вас будет время московское, а вот NOW() останется серверным временем, в данном примере американским. Вот чтобы не было разных дат, а везде было единое время и рекомендуется использовать везде date.
Почти все ваши ошибки вы бы легко обнаружили сами включив error_reporting=E_ALL, в том числе то, что description обязательное поле в plugin.php
Для нас единственный плюс может быть если разработчик отвественно подходит к созданию плагинов и тем дизайна, и делает качественный продукт и умеет самостоятельно его тестировать. В любом другом случае страдают клиенты и у клиентов ухудшается в целом отношение ко всем плагинам сторонних разработчиков и вообще к магазину вебасист. Так что наша политика более чем понятная.
Галочка режим разработчика нужна чтобы многие данные брались не из кэша, чтобы сразу находились новые классы и т.д. и т.п.
В описании этой галочки ясно написано "включает подробный вывод сообщений об ошибках".
ответитьА теперь по поводу date. Ну и что? Эта дата нужна только для внутренних целей и нигде не выводится. Да хоть 1990 год в мускуле стоит. Просто при выборке плагин и запросит записи с 1990 годом. Ну и о том, как правильно ставить время, можно спорить бесконечно. Могу 2 тома написать о минусах подобного способа датирования. А если еще учесть ваши планы с реализацией возможности смены таймзон у юзера(судя по таблице юзеров, есть такие планы), то томов прибавится.
PS в мускуле тоже можно зону выставить через "SET @@session.time_zone". Суть та же и проблемы те же.
PPS сделайте уже поддержку куков в блоге. Каждый раз нужно заново логиниться(это хорошо еще, что я себе ручками сделал "Запомнить меня" и в ЛК уже не надо логин/пасс вводить постоянно) и комменты не отправляются, т.к. сессия заканчивается, пока я за чаем хожу.
Подробный вывод ошибок тоже включает, например, если кидается Exception, то покажется конкретное место и весь стек.
ответитьПо поводу дат вам всё равно, а клиентам некоторым нет. Иногда удобно залезть в phpmyadmin и посмотреть, если там будут нормальные даты, то будет намного удобнее.
Спорить действительно можно бесконечно и смысла в этом никакого нет. От того что вы еще напишите 100500 комментариев ничего не поменяется.
Цитирую: Все текстовые файлы (PHP, HTML, JavaScript, CSS, SQL и т. д.) должны быть сохранены в кодировке UTF-8. Другие кодировки символов в Webasyst не поддерживаются.
ответитьПруфлинк: http://www.webasyst.ru/developers/docs/basics/webasyst-store-requirements/
А теперь открываем например "wa-apps/shop/plugins/cml1c/lib/shopCml1c.plugin.php", опа, а кодировка-то ANSI, just for loolz))))
Открываем actions/backend/shopCml1cPluginBackendRun.controller.php, и что же мы видим?
<pre>
$this->xml = new XMLReader();
$this->xml->open($this->data['filename']);
return;
$node_map = array(
"Классификатор" => self::STAGE_CATEGORY,
</pre>
неожиданно... там есть перлы и похлеше, код писал явно фанат switch\case)))
В итоге модуль о котором так гордо заявлено аж на первой странице не работает, но это не важно главное свистелок и перделок добавить)))
Разрабы, блин, вас что ничему не научил предыдущий плачевный опыт? Вы хреначите по нему же и восьмимильными шагами..
Хотите чтобы с вашей системой работали? Приведите её в надлежащий вид, @Leman уже упомянул отстуствие документации, я хочу упомянуть отсуствие нормальных способов расширения (о том как это поправить я написал https://github.com/webasyst/webasyst-framework/issues/31 но в ответ тишина) и модульного тестирования (например PHPUnit): если бы плагины отправлялись вместе с тестами их было бы легче проверять, отстуствует bug tracker и roadmap и вообще какое-то комьюнити для разработчиков, вы все делаете в каком-то сферическом вакууме, не понятно зачем было проект переводить в опенсорс статус...
https://github.com/webasyst/shop-script/blob/master/plugins/cml1c/lib/config/plugin.php
ответитьРусские символы не означает ANSI, кодировка файла UTF-8.
Документация есть, да она не очень хороша, но мы постоянно её улучшаем. Уже довольно много разработчиков делают плагины и как минимум у половины вопросов что-то не возникает, а остальные предпочитают удалять скобочки в коде, кричать что нет документации, создавать нелепые задачи на гитхабе не разобравшись и т.д.
Если разработчик пишет код, не включив error_reporting=E_ALL, и потом в его плагине 100500 варнингов, то я боюсь что тут документация никак не поможет...
PHPUnit используется внутри, возможно когда-нибудь сделаем общедоступными. Модерацию тесты никак не упростят, поскольку очень много ошибок находится только просматриванием исходников, да и не всё можно покрыть тестами, по крайней мере PHPUnit.
О багах можно писать в техподдержку либо на гитхаб (чем вам не открытый bug tracker?).
Notepad++\PHPStorm определяют кодировку как ANSI, можете обсудить это с разработчиками данных продуктов.
ответить"Уже довольно много разработчиков делают плагины и как минимум у половины вопросов что-то не возникает" - а у второй половины значит возникает и поэтому они "плохие"? На данный момент подавляющее подавляющее большинство плагинов для SS это плагины доставки\оплаты для которых имеется описание или плагины аля "промотать страницу вверх" которые отношения к коду вообще не имеют.
По поводу моих предложений по улучшению кода, даже если отбросить упрощение кода (то что вы называете "скобочками"), то поправлено несколько очевидных ошибок и при этом исправления до сих пор не приняты.
Почему исправления не приняты я написал на гитхабе. Замечания по существу будут сделаны в следующем обновлении.
ответитьНу так задавайте конкретные вопросы, если они возникают. Пока я лично вижу в 99% случаев что разработчики не могут внимательно прочитать даже две статьи документации, которые нужно обязательно изучить перед тем как писать плагины. Вопросов по существу я что-то особо не вижу.
По поводу большинства плагинов вы не правы, есть уже достаточно очень хороших и качественных плагинов.
Я добавил на github 3 PR, а комментарии только к одному. Версия давно не обновлялась (alexmuz authored 2 months ago), это опять же к вопросу о "чем вам не открытый bug tracker?".
ответитьВообще хотелось бы описание наподобие kohanaframework.org/3.3/guide-api/Request / github.com/kohana/core/blob/3.3/master/classes/Kohana/Request.php т.е. хотя бы минимальное описание методов (@param, @return), сейчас в большинстве случаев даже оно отсутствует.
Сейчас приходится копаться в готовых плагинах\хуках чтобы понять как работает и невсегда находится готовое решение.
Статьи тоже полезны, но они не могут охватить все аспекты, кроме того каждое приложение имеет свои особенности о которых в статьях практически ничего не сказано.
Я не ставлю перед собой цели "опустить" разработчиков WA, цель у нас в общем-то одна - рубить капусту :) просто не понятно почему:
ответить1. Вместо исправления багов, добавляется второстепенный функционал (вышло не 1 обновление, а 2-3, но старые баги остались).
2. Зачастую код расширяется не через добавление хуков\плагинов, это создает проблемы при его модернизации. Ставят в тупик ответы "мы это потом сделаем сами", но клиенту то оно нужно не потом, а сейчас и не прямой правкой кода, чтобы при обновлении дополнения не затирались.
3. Почему не пытаетесь развить комьюнити и вести коллективную разработку (хотя бы ядра). Публикуйте список задач\багов (@todo) до которых не доходят руки, возможно они будут решены сторонними разработчиками.
"Вопросов по существу я что-то особо не вижу":
1. Как добавить поля на страницу редактирования заказа на уровне плагинов\хуков?
2. Как сделать инсталятор к теме дизайна как у плагинов? Хотелось бы чтобы тема создавала несколько блоков + хелпер с несколькими функциями (как я понимаю вы не разрешите загразить в waStore отдельный плагин для темы).
3. Вопросы по директориям: могут ли плагины добавлять контент в './wa-content/'? есть ли какая-то переменная\константа содержащая этот путь? аналогичный вопрос по './wa-data' + есть ли спец. методы для этого?
1. Баги тоже исправляются.
ответить2. Ну поставьте плагин конкретному клиенту которому это нужно сейчас и который не может подождать. Но принимать плагины в магазин, которые через будут не нужны, причём осознавая это мы никогда не будем. Причины очевидны.
3. Код на гитхабе, любой может отправить пулл-реквест. Другое дело, что больше половины исправлений, которые я лично видел, я не могу принять, потому что либо в них самих что-то сделано криво, либо нарушена логика, либо еще что-то не так...
Далее:
1. Добавим.
2. Не совсем понятен вопрос, что за инсталлятор? Тему как и плагин можно в легко установить через инсталлер, так же архив с темой можно загрузить в разделе дизайн конкретного приложения. Непонятно о каких блоках идёт речь и что мешает вам это сделать сейчас. Зачем свой хелпер, если чего-то не хватает, то просто напишите об этом. Мы же не раз уже спрашивали каких функций в хелперах не хватает.
3. В wa-content плагин ничего писать не может, так же как и в wa-apps. Плагин может писать только в wa-data и wa-log.
По методам: http://www.webasyst.ru/developers/docs/classes/waSystem/#method-getDataPath
1.2 Речь не о каком-то конкретном случае\плагине (хотя у меня есть проблемы и с реальными доработками), а о том, что нужны механизмы расширения конечных сайтов без "затирания" этих расширений при обновлении wa.
ответить1.3. "любой может отправить пулл-реквест" - версия не актуальна - изменения могут оказаться бессмысленными, "я не могу принять" - опять возвращаемся к документации.
2.2. "что за инсталлятор?" install.php скрипт установки плагина.
"о каких блоках идёт речь" - Общие блоки — это фрагменты HTML/Smarty-кода, которые можно подключать внутри содержимого страниц сайта и в шаблонов дизайна, как «подшаблоны»
Методы могут быть специфическими и использоваться только в данном шаблоне ( например, формирование спец.меню), вывод каких-то спец.блоков (например, комменты disqus.com).
Сейчас темы могут использовать только функционал wa и плагинов из магазина, а хотелось бы иметь возможность создать тему "all in" со своим набором доп.функционала.
А зачем для темы install.php? Приведите пример, а лучше сразу несколько.
ответитьПо поводу блоков, ну можете создать у себя в теме сколько угодно дополнительных шаблонов и потом подключать их в нужных местах через {include file="..." inline}
В smarty 3 можно сделать очень многое и не вижу проблемы реализовать дополнительные методы прямо в smarty в вашей теме. Ну или опять же приводите пример того, что реально нужно, но нельзя сделать на уровне smarty.
Кстати если вам для конкретного сайта не хватает каких-то методов, то можно сделать свой хелпер: http://www.webasyst.ru/developers/docs/helpers/custom-helpers/
ответить"Приведите пример": добавить нестандартные настройки темы (загрузка лого, выбор значения из не статичного списка), визуальный конфигуратор меню, автоматическое добавление блоков при установке.
ответитьКстати попутно вопрос по настройкам отображения тем: можно ли сделать так, чтобы какие-то настройки были только у темы блога, а какие-то у только темы магазина? т.е. общие + настройки под конкретное приложение.
"подключать их в нужных местах через {include file="..." inline}", а работает ли это также как и блоки? можно ли добавить прямо визуальном редакторе?
"методы прямо в smarty в вашей теме" - но работает намного медленнее нативного варианта.
"можно сделать свой хелпер" Проблем с подключением хэлперов (классы со статическими методами) нет, в крайнем случае можно обойтись даже без мануала.
Я так и не понял что вы хотите делать в install.php темы, настройки темы описываются в theme.xml в секции <settings></settings> и там же можно указать значения по умолчанию.
ответитьНастройки описаные для темы приложения блог будут доступны только в приложении блог.
Если у вас семейство тем, то настройки главной темы (как правило приложение сайт), будут доступны как для самой темы, так и всех для которых она является родительской.
Конструкции smarty можно добавлять и визуальном редакторе тоже, правда если вы говорите о страницах, т.к. для редактирования дизайна есть только подсветка, а визуальный редактор есть только при редактировании страниц, то там нужно использовать $wa->shop->themePath('THEME_ID') чтобы указать путь до темы.
По поводу работает медленнее, вы замеряли? Сколько наносекунд разница? Учитывая что Smarty компилирует шаблоны "преобразуя" их в php-файлы, разницу можно заметить только в момент компиляции шаблонов (да и то очень маленькую), а дальше будет работать тот самый нативный php и никакой разницы нет.
Да, уже есть. Но их не так много. В своей родной сфере(разработка "под ключ") мне приходилось иметь дело с десятком плагинов с магазина. После их установки и разбора их работы, 80% улетало сразу в мусорку. Они либо не соответствовали описанию(моему плагину вы это особо не простили), либо попросту не работали(например последним был куплен плагин "recent" и там не редактировался шаблон вывода). Имена вслух говорить не буду, вы их и так знаете. Но по сути всего 3 разработчика у вас нормальные и рабочие плагины делают. Правда в сумме их продукты составляют 50% всего магазина. Видимо это вы и имели в виду?) Есессно теперь и я многое знаю. И с каждым отказом я знаю всё больше и в последующих плагинах уже таких ошибок не будет. И с теми разработчиками, как я уже говорил, общался не мало. И у них тоже далеко не сразу всё сложилось. Они тоже методом тыка всё делали в большинстве случаев, в надежде, что угадал и это прокатит. Так что делить на хороших/плохих не надо. Изначально всё "плохие".
ответитьРаз уж переходим на личности, о которых Вы и так знаете, в описании "recent" не было и слова о редактировании шаблона.
ответитьНо самое интересное, что после того как мне пришёл запрос на то, что этого не хватает, я таки добавил эту фичу :)
Могу сказать, что как минимум у трех разработчиков плагинов отказы бывают крайне редко и многие плагины вообще были опубликованы с первой попытки.
ответитьНу а то, что вы делаете ошибки, многие из которых никак не связаны вообще с фреймворком и шоп скриптом, ну это конкрентно ваша проблема и вам нужно её решать. Всё приходит с опытом, просто у кого-то его изначально достаточно, а у кого-то нет.
Никаких изначально "все плохие" нет.
Просто последнее время есть неприятная тенденция, появляется новый разработчик и первое что он делает, это клон какого-то уже существующего плагина, причём делает хуже чем оригинал и при этом еще делает кучу нелепых ошибок... Вот так делать не надо, это действительно пример "плохого" разработчика.
Вот только клеветы не надо :) А то люди слишком плохо обо мне подумают. Я клон не делал и тоже против подобного. В магазине такого плагина не продается. Лишь спустя 2 недели после написания, я заметил похожий плагин, который уже был до этого. Но он лишь очень отдаленно похож и практически ничего общего с ним нет. Подобный плагин на форуме продавал знакомый, который отошел от дел. Я даже у него разрешения спросил(вдруг он хочет свой допилить и в магазин поставить). Еще использовал внешнее оформление во фронтенде от другого популярного плагина. Но и это сделано не от лени или собственных кривых рук(ибо фронтендом мне приходится заниматься гораздо больше по жизни и для меня не составит проблем слепить оформление), а для некой стандартизации вида всплывающих окон. Т.к. мне приходилось иной раз покупать для клиентов несколько плагинов со всплывающими окнами, я не по наслышке знаю о такой проблеме. Когда каждое окно имеет полностью свой дизайн... это ппц. И на использование стилей того популярного плагина я тоже спрашивал разрешения.
ответитьЯ про вас ничего и не говорил, я в общем и целом написал как лучше не делать. К вам это не относится.
ответить