Разработчикам о предстоящем обновлении Shop-Script 6.3
Сегодня на github в ветку dev была выложена часть предстоящего обновления.
Ниже я кратко напишу о некоторых новых возможностях Shop-Script 6.3, релиз которого состоится на следующей неделе (точной даты пока нет).
1. Новый хук frontend_products, который вызывается перед любым выводом товаров на витрину (будь то категория, списки на главной, карточка товара, корзина).
В $params передаётся массив array('products' => &$products). Обратите внимание, что массив товаров передаётся по ссылке — это даёт возможность плагинам менять информацию о товаре, например, изменять цены на витрине.
Также в некоторых местах передаётся, помимо 'products', ещё и массив артикулов 'skus' => &skus (например, в карточке товара, и в корзине).
В плагине debug мы сделали пример заглушку, как, например, уменьшить все цены на 10%.
public function frontendProducts(&$params)
{
// YOUR CONDITION
if (0) {
foreach ($params['products'] as &$p) {
$p['price'] = $p['price'] * 0.9;
// or
// $p['price'] = $p['original_price'] * 0.9;
}
unset($p);
if (isset($params['skus'])) {
foreach ($params['skus'] as &$s) {
$s['price'] = $s['price'] * 0.9;
// or
// $s['price'] = $s['original_price'] * 0.9;
}
unset($s);
}
}
}
Обратите внимание на original_price (есть еще original_compare_price). Что это и зачем?
Дело в том, что плагинов, которые захотят менять цены через этот хук, может быть несколько.
В original_price сохраняется оригинальная цена, которая задана для товара.
В price же уже может оказаться цена, изменённая плагином, который отработал раньше.
Вариантов для применения нового хука очень много. Если кто-то из разработчиков успеет к официальному релизу сделать хорошие плагины, то мы с большой долей вероятности упомянем о них в блог-посте в качестве примера реализации. Например, плагины оптовые цены, наценка для витрин и т. п.
2. Новый хук product_custom_fields, который позволяет плагину объявить свои собственные поля для товара или для артикула, которые в частности используются при импорте из CSV.
Проще говоря, теперь появилась возможность плагину сделать поддержку импорта из CSV своих полей.
Если успеем, то экспорт тоже сделаем, но пока только импорт.
В плагине debug есть пример объявления таких полей.
public function productCustomFieldsHandler()
{
return array(
'product' => array(
'field1' => 'Custom field#1',
'field2' => 'Custom field#2',
),
'sku' => array(
'field1' => 'Custom SKU field#1',
'field2' => 'Custom SKU field#2',
),
);
}
В чём разница между 'product' и 'sku'? В том к чему это поле у вас привязано, оно может быть общее для всего товара, тогда product, например наценка в % общая, а может быть для каждого артикула своё (например оптовая цена), тогда sku.
Эти поля можно обрабатывать в хуке 'product_save'
if (isset($params['data']['debug_plugin']['field1'])) {//'Custom field#1'
//TODO update field at plugin table/run some code/etc
}
Они попадают в ключ {PLUGIN_ID}_plugin массива с данными. Для артикула соответственно в данные артикула.
3. Как выяснилось, на некоторых MySQL-серверах возникают проблемы с фильтрацией товаров, а именно некоторые SQL-запросы сильно нагружают сервера.
Мы сделали две реализации: через exists и через join (по умолчанию и это то, что работает сейчас).
Реализация через exists в общем случае чуть хуже, однако на некоторых проблемных MySQL-серверах, она работает лучше.
Какую из реализаций использовать можно указать в файле-конфиге (wa-config/apps/shop/config.php).
'filters_features' => 'exists'
По умолчанию используетс join, поэтому, если у вас возникли проблемы, то попробуйте указать exists. Практика показала, что это помогает.
4. В настройках уведомлений появилась возможность указать, какое название использовать в качестве имени отправителя.
Настройка решает проблему, если используется в одном аккаунте совсем разные магазины. Раньше всегда использовалось название магазина из общих настроек, сейчас в качестве имени можно использовать название поселения.
5. В бекенде в списке товаров теперь можно вывести колонку с кодом основного артикула.
Если у товара несколько артикулов и коды у них разные, то выводится будет только один код основного артикула!
6. Добавлена новая настройка для бонусной программы, позволяющая ограничить использование бонусов при оплате заказа.
Для корректной работы этой настройки нужно обновить тему.
Вот изменения для темы Default: https://github.com/webasyst/shop-script/commit/a80...
Если есть вопросы или замечания, задавайте их в комментариях.
Респект и уважуха! Будем тестировать.
когда обновление уже?
В планах был хук для локализации - это имелось frontend_products или будет дополнительный?
Alex Kurd, в хуке frontend_products можно и название товаров менять.
В темы дизайна нужно какие-то хуки встраивать?
На github в теме default ничего подобного не нашёл.
В темах ничего менять не нужно.
Ура! Новость номер 5 ждал очень долго. Ещё не хватает в списке заказов в админке поиска заказа по трек-коду.
Дмитрий, не могли бы вы рассказать зачем вам нужен поиск по трек-коду?
Просто интересно в какой такой ситуации у вас есть трек-код, но нет номера заказа?
А что если я в хуке frontend_products в поле price запишу ''?
Андрей, это будет на вашей совести :)
Формально через этот хук можно довольно легко сломать внешний вид магазина, но без него невозможно сделать очень многие вещи, в том числе оптовые цены.
Ну а если серьёзно, то зачем? Мы за этим будем следить на этапе модерации.
Такое писать туда нельзя, т.к. эти цены используется и в корзине, где это преобразуется в 0 и можно будет оформить заказ с ценой 0.
Я спросил потому, что у меня есть плагин "скрытые цены" и думал, что можно через этот хук цены спрятать. Но раз нельзя, так нельзя.
Александр, а можно меня как-то из бана до нг освободить, чтобы я мог отправить исправленный оптовый плагин на модерацию?
Отправляйте на модерацию, но помните про наши прошлые замечания и постарайтесь сделать так, чтобы в этом хуке было минимум SQL-запросов.
В идеале 1-2 запроса, максимум. Можно использовать SELECT * FROM {TABLE} WHERE product_id IN (...)
И держите в голове, что хук этот может вызываться по нескольку раз на одной странице (для разных наборов товаров), то есть часть информации (ту же категорию покупателя) можно кэшировать в runtime в static переменной плагина, например.
По админ части претензий насколько я помню не было, хотя сейчас там тоже можно упростить, в прошлом обновлении появился хук backend_product_sku_settings, скорее всего он будет вам полезен.
Ну и не забудьте в requirements.php указать требование версии 6.3
Ага. 6.3. Как раз хотел про это спросить. Спасибо.
Любопытно. Это очень нужный хук.
Александр, очень часто встречается ситуация, что нужно найти по треку, так как на чеке фамилия перековеркана и по ней нельзя найти заказ
Ух, ты какая интересная настройка бонусов ожидается:
<div class="name">[`Usage % limit`]</div> <div class="value"> <input type="text" class="short numerical" name="conf[affiliate_usage_percent]" value="{ifset($conf.affiliate_usage_percent)}" placeholder="100">% <p class="hint">[`Limits the maximum % of order amount that can be paid with bonus (i.e. maximum discount a customer can get by applying the bonus).`]</p> </div>Залез в плагин дебага на предмет вот этого:
Не вижу полей
Как вообще предполагается использовать этот хук? Я декларирую эти поля, они появляются при сохранении, а я их пишу куда-то в свою таблицу? Потом беру их при показе хуком frontend_products?
При сохранении нам не страшна запись в базу перебором запросов?
Андей, прямо в посте есть пример для поля field1 которое объявлено для товара (product), для sku аналогично, только оно уже будет в ['skus'][SKU_ID]['debug_plugin']
if (isset($params['data']['debug_plugin']['field1'])) {//'Custom field#1' //TODO update field at plugin table/run some code/etc }Сохранять куда-то в свои таблицы.
Насчёт записи перебором я не совмем понял о чём вы. В большинстве случаев это будет UPDATE, а UPDATE это всё равно отдельный запрос для каждой строчки в любом случае. По другому никак.
Александр, пример из поста содержится в плагине debug. Я как раз его и ковыряю. Т.е. здесь я ошибиться никак не могу.
Я поставил точку остановки при помощи xdebug на
там, где происходит запись в лог, и ожидаю в $params дополнительные поля, которые объявлены в плигине в
Там эти поля у меня не появляются почему-то. Вот поэтому я и задаю вопросы.
Андрей, вы делаете импорт из CSV?
При этом вы сопоставляете колонки плагина колонкам в файле? Но ничего не приходит?
Хук product_custom_fields сделан именно для импорта в данный момент.
Больше он нигде пока не вызывается.
Пункт №4 ликвидирует пару костылей, что очень хорошо, в анансе не увидел ничего про локализацию. Как обстоят дела с ней? Ждать?
Ну кагбэ возможность подменять информацию о товаре намкает на то, что можно сделать l10n плагин для товара
Сергей, скорее i18n =)
Я уже представляю сколько придётся инструментов делать для этого перевода.
Становится понятнее.
Михаил, я тут переделываю оптовый плагин под новый движок, костыли разлетаются в разные стороны.
На одном только backend_product_sku_settings тонну кода сократил.
Александр, прошу пояснить вот это:
Я правильно понимаю, что product_save срабатывает как из сохранения продуктов в бэкенде, так и при импорте?
Т.е. нужно так подогнать массив, чтобы и там и там в точности совпало?
думаю, там идентификаторы полей совпадать должны
С идентификаторами вроде разобрался.
Александр, заметил один недостаток.
В связи с тем, что у нас появился хук backend_product_sku_settings и мы можем вводить новые поля, нам обязательно нужен хук product_sku_delete, чтобы плагины не оставляли за собой кучу мусора в таблицах.