Разработчикам о предстоящем обновлении 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...

Если есть вопросы или замечания, задавайте их в комментариях.

22 декабря 2015
  • ITFrogs 18 декабря 2015 07:42

    Респект и уважуха! Будем тестировать.

  • когда обновление уже?

  • DemoLLC 18 декабря 2015 08:48

    В планах был хук для локализации - это имелось frontend_products или будет дополнительный?

  • Alex Kurd, в хуке frontend_products можно и название товаров менять.

  • Владимир Сергеев 18 декабря 2015 08:50

    В темы дизайна нужно какие-то хуки встраивать?
    На github в теме default ничего подобного не нашёл.

  • В темах ничего менять не нужно.

  • Злой Димон 18 декабря 2015 08:54

    Ура! Новость номер 5 ждал очень долго. Ещё не хватает в списке заказов в админке поиска заказа по трек-коду.

  • Дмитрий, не могли бы вы рассказать зачем вам нужен поиск по трек-коду?
    Просто интересно в какой такой ситуации у вас есть трек-код, но нет номера заказа?

  • ITFrogs 18 декабря 2015 09:00

    А что если я в хуке frontend_products в поле price запишу ''?

  • Андрей, это будет на вашей совести :)
    Формально через этот хук можно довольно легко сломать внешний вид магазина, но без него невозможно сделать очень многие вещи, в том числе оптовые цены.
    Ну а если серьёзно, то зачем? Мы за этим будем следить на этапе модерации.
    Такое писать туда нельзя, т.к. эти цены используется и в корзине, где это преобразуется в 0 и можно будет оформить заказ с ценой 0.


  • ITFrogs 18 декабря 2015 09:15

    Я спросил потому, что у меня есть плагин "скрытые цены" и думал, что можно через этот хук цены спрятать. Но раз нельзя, так нельзя.

  • ITFrogs 18 декабря 2015 09:58

    Александр, а можно меня как-то из бана до нг освободить, чтобы я мог отправить исправленный оптовый плагин на модерацию?

  • Отправляйте на модерацию, но помните про наши прошлые замечания и постарайтесь сделать так, чтобы в этом хуке было минимум SQL-запросов.
    В идеале 1-2 запроса, максимум. Можно использовать SELECT * FROM {TABLE} WHERE product_id IN (...)
    И держите в голове, что хук этот может вызываться по нескольку раз на одной странице (для разных наборов товаров), то есть часть информации (ту же категорию покупателя) можно кэшировать в runtime в static переменной плагина, например.

    По админ части претензий насколько я помню не было, хотя сейчас там тоже можно упростить, в прошлом обновлении появился хук backend_product_sku_settings, скорее всего он будет вам полезен.

    Ну и не забудьте в requirements.php указать требование версии 6.3



  • ITFrogs 18 декабря 2015 10:13

    Ага. 6.3. Как раз хотел про это спросить. Спасибо.

  • Николай Иванов 18 декабря 2015 10:28

    Любопытно. Это очень нужный хук.

  • Злой Димон 18 декабря 2015 13:22

    Александр, очень часто встречается ситуация, что нужно найти по треку, так как на чеке фамилия перековеркана и по ней нельзя найти заказ

  • Syrnik.com 18 декабря 2015 17:52

    Ух, ты какая интересная настройка бонусов ожидается:

    <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>
  • ITFrogs 18 декабря 2015 19:32

    Залез в плагин дебага на предмет вот этого:

    public function productSaveHandler($params)

    Не вижу полей

    field1, field2

    Как вообще предполагается использовать этот хук? Я декларирую эти поля, они появляются при сохранении, а я их пишу куда-то в свою таблицу? Потом беру их при показе хуком 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 это всё равно отдельный запрос для каждой строчки в любом случае. По другому никак.

  • ITFrogs 19 декабря 2015 05:23

    Александр, пример из поста содержится в плагине debug. Я как раз его и ковыряю. Т.е. здесь я ошибиться никак не могу.

    Я поставил точку остановки при помощи xdebug на

    public function productSaveHandler($params)

    там, где происходит запись в лог, и ожидаю в $params дополнительные поля, которые объявлены в плигине в

    productCustomFieldsHandler()

    Там эти поля у меня не появляются почему-то. Вот поэтому я и задаю вопросы.

  • Андрей, вы делаете импорт из CSV?
    При этом вы сопоставляете колонки плагина колонкам в файле? Но ничего не приходит?
    Хук product_custom_fields сделан именно для импорта в данный момент.
    Больше он нигде пока не вызывается.

  • Михаил Морозов (welldi) 19 декабря 2015 05:35

    Пункт №4 ликвидирует пару костылей, что очень хорошо, в анансе не увидел ничего про локализацию. Как обстоят дела с ней? Ждать?

  • Syrnik.com 19 декабря 2015 05:38

    Ну кагбэ возможность подменять информацию о товаре намкает на то, что можно сделать l10n плагин для товара

  • DemoLLC 19 декабря 2015 06:56

    Сергей, скорее i18n =)

    l10n = localization (country-specific settings such as how to represent numbers, dates, money, ...)
    i18n = internationalization (translations)

    Я уже представляю сколько придётся инструментов делать для этого перевода.

  • ITFrogs 19 декабря 2015 07:19

    Становится понятнее.

  • ITFrogs 19 декабря 2015 11:15

    Михаил, я тут переделываю оптовый плагин под новый движок, костыли разлетаются в разные стороны.

    На одном только backend_product_sku_settings тонну кода сократил.

  • ITFrogs 19 декабря 2015 11:47

    Александр, прошу пояснить вот это:

    Эти поля можно обрабатывать в хуке 'product_save'

    Я правильно понимаю, что product_save срабатывает как из сохранения продуктов в бэкенде, так и при импорте?

    Т.е. нужно так подогнать массив, чтобы и там и там в точности совпало?

  • Syrnik.com 19 декабря 2015 11:48

    думаю, там идентификаторы полей совпадать должны

  • ITFrogs 19 декабря 2015 12:16

    С идентификаторами вроде разобрался.

  • ITFrogs 19 декабря 2015 12:19

    Александр, заметил один недостаток.

    В связи с тем, что у нас появился хук backend_product_sku_settings и мы можем вводить новые поля, нам обязательно нужен хук product_sku_delete, чтобы плагины не оставляли за собой кучу мусора в таблицах.



Чтобы добавить комментарий, зарегистрируйтесь или войдите