Eugen Nichikov

не надо так пробовать)

Если соблюдать нейминг из поста, выйдет так

$plugin = wa('shop')->getPlugin('[name]');
$plugin->one();

где id плагина должен указываться без квадратных скобок.

¯\_(ツ)_/¯ 

Вот кто-то зайдёт на форум с тем же вопросом, а вы тему удалили.

Написали бы решение, а мы бы с удовольствием его почитали и приняли на заметку ;)

Ну а по теме, можно глянуть как реализовано тут или тут.

Но если хочется жести, её можно устроить при помощи controller_before.* и controller_after.*

Правда, я уверен, что есть решение попроще.

@Koin, таков путь.

Вообще не вижу "лёгких денег" в "галочке". Ведь помимо того, чтобы её поставить, надо же ещё и сами обновления сделать.

Основная идея: нет обновлений - нет денег, нет денег - нет обновлений.

Клиент покупает продукт (плагин/тему) и получает год (ограниченное время) обновлений. Продлевает - аналогично.

А если клиент по окончанию срока лицензии будет видеть в Инсталлере:

- Мелкие исправления
- Мелкие исправления
- Мелкие исправления

Зачем продлевать обновления на такой продукт (плагин/тему)?

Не хотелось бы опускаться до откровенного саботажа, но как ещё донести мысль?!

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

Через пару месяцев мы подумаем над обновлением продуктов до ПРЕМИУМ.

А это

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

разве забота об интересах конечных пользователей?! Новый отдельный продукт устанавливается и настраивается с нуля вместо обновления "одной кнопкой".

Обновления требуют хорошей рекламы

Какие инструменты у нас для этого есть? Публиковать баннер-растяжку, как это делает ШС? А разработчики тем должны публиковать такой баннер сразу во фронтенде?!

Текущая система временной подписки с ограничением функциональности - это рациональная модель монетизации?!

В связи с отсутствием каких-то подвижек в данном направлении объявляю забастовку.

15 февраля 2022 года изменится стоимость подписки на обновления Shop-Script.
Старая цена: 7 599 руб./год.
Новая цена: 9 999 руб./год.

Цена на платные плагины будет 9999 как стоимость обновления Shop-Script.

Где подписывать? :)

Хук вызывается при загрузке layout'а. При этом контент сайта в основном обновляется аяксом.

Поэтому при хук вызывается по сути только при перезагрузке страницы.

Вы можете принудительно установить язык в настройках профиля (правый верхний угол).

Затем очистить кэш в приложении "Настройки"

Как-то так:

$order_id = 1;
$stock_id = 1;

$original_data = (new shopOrderModel())->getOrder($order_id);

if ($original_data) {
	foreach ($original_data['items'] as &$item) {
		$item['stock_id'] = $stock_id;
	}

        // ignore_stock_validate опционально. Если установлено, то новый склад может в минус уйти.
        // Если не установлено, то надо ошибки обработать.
	$order_new = new shopOrder($original_data, ['ignore_stock_validate' => true]);
	$order_new->save();
}

Странно, у меня такая же нога и не болит.

Интересно было бы разобраться почему не работает, если это действительно так. У меня на двух установках (более старый фрейм и ШС и почти актуальный) всё ок. Иначе бы не выкладывал.

Поэтому:

1) Плагин siterouting для ШС(!)

2) Чистим кэш (!!)

3) урл siterouting_url открываем в поселении сайта. Например, /site/siterouting_url

плагин не запускал, но осуждаю.

Я к тому, что если менять что-то в редактировании категории, следовало бы аналогично менять и в редактировании товара. Ещё более нелогичным будет, если в категории будет работать хук, а в товаре - нет.

мое дело - указать на проблему

Ну, тогда моё дело указать на потенциальную проблему при решении проблемы "в лоб" XD

Если хук "внезапно" станет вызываться там, где не вызывался ранее, это может привести к проблемам в существующих плагинах.

Ждём интерфейс 2.0. Там, может, будет всё иначе :) Ну или ошибка будет, но уже в другом интерфейсе.

По поводу "дёргать нужные хуки" может быть чревато тем, что плагины могут ожидать данные в POST, чтобы сохранить настройки категории. При редактировании только названия эти данные не передаются. Соответственно, могут быть скинуты какие-то настройки. Такое было со Smart Filters при импорте товаров.

Аналогично хук product_save не вызывается при редактировании названия товара.

Вместо отключения функциональности (которая может кому-то нужна и удобна), можно было бы предложить добавить новый хук.

А если говорить о решении задачи здесь и сейчас, хуки controller_before и controller_after помогут.

пфф... будет.

Можно подписаться на хук routing приложения shop или site.

Это преобразование, например, заложено в основе перевода суммы заказа в текст в печатных формах.

Плюс добавить автоматическую локализацию контролов из настроек, и картинка складывается.

А вот почему в английской не тянется, да и почему подтягивается системная - тайна покрытая мраком.

Код - это кука shop_cart. Она генерируется уникальной для каждого покупателя при первом добавлении товара в корзину.

Более подробно логику формирования можно посмотреть в конструкторе класса shopCart.

Про документацию не знаю - не читал :)

Если код плагина выполняется из браузера от имени конкретного покупателя, то можно получить так

$cart = new shopCart();
$items = $cart->items();

Если вызов API идёт откуда-то извне или, например, из консоли, нужно первым параметром передать код корзины

$cart = new shopCart('202cb962ac59075b964b07152d234b70');
$items = $cart->items();

Мета-обновления не срабатывают при первой установке плагина.

Для этого есть файл install.php

Особенность мета-обновлений в том, что они помогают обновиться до следующей версии (удалить лишние файлы, внести правки в БД и т.п.).

Временная метка как раз помогает отследить нужно ли выполнять мета-обновление или нет.

Исходная метка будет либо в момент установки плагина, либо в момент установки последнего мета-обновления.

Соответственно, когда пользователь обновит плагин через Инсталлер, выполнятся все мета-обновления с меткой больше исходной.

Тело POST-запроса вроде передаётся не в JSON, а urlencoded.

Вот так:

code=5185951762fe2dc3fdfaa5e1049fad7f&grant_type=authorization_code&client_id=wblink

Идея, хотя её следовало публиковать отдельным постом, не нова.

Как я понимаю, по историческим причинам такое уже вряд ли будет реализовано.

Однако добавили хуки notifications_send.before и notifications_send_one.before с передачей параметров по ссылке. 

Сейчас и вызывается хук order_action.tipa-oplachen.

В своём плагине можно подписать как на конкретно это событие, так и на любое по маске.

Согласен про "понимание", но хуки, имхо должны вызываться отдельно для каждого действия.

Либо должен быть инструмент, который в явном виде даст возможность вызвать один хук вместо другого. И тут тоже важно, чтобы у админа магазина было "понимание".

Категорически против вызова order_action.pay вместо order_action.tipa-oplachen как поведение по умолчанию.

P.S. Для себя взял за практику, что если плагин делает что-то по определённому действию, в настройки такого плагина выношу GROUPBOX с выбором нескольких действий.

Для работы с заказами используются коллекции. В них есть 3 удобных хука:

• orders_collection
• orders_collection.filter
• orders_collection.prepared

Но вот автокомплит не использует коллекций ¯\_(ツ)_/¯

Думаю, что правильным решением было бы не добавление нового хука, а интеграция коллекций в автокомплит.

Вроде обсуждалась такая доработка с кем-то из WA. Но, увы, не помню с кем и где.

1) Коллекции

Да, активно пользуюсь как коллекциями (1), так и действиями с ними (2)

Не совсем относится к коллекциям, но к разделу товаров: в табличном режиме отдельные колонки (3) или дополняю существующие (4) 

в режиме эскизов обычно иконками ограничиваюсь.

Было бы удобно, если бы пункты можно было бы сортировать перетаскиванием, и сортировка бы сохранялась для каждого пользователя отдельно.

Тут для включения беты нужно согласие двух сторон.

Время в секундах задаётся. Эта опция устанавливает значение CURLOPT_TIMEOUT при запросе.

Поэтому вероятно, что дробное значение обрезается до 0, а это вовсе отключает ограничение.

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

Но почему должен быть только один правильный?

Сейчас тоже можно поставить "неадекватную цену" на всё тот же "снег" (да что к нему приколупались?!) в 49 999. Так делают? Так покупают?

Если конечный клиент видит цену и понимает, как она будет меняться со временем, он сам сможет принять решение о покупке того или иного плагина. А ценовая политика обновлений может стать дополнительным инструментом в конкурентной борьбе аналогов.

Также недурно было бы вывести публично лог изменения цены/политики обновлений. Но это уже другая история.

Плата за конкретные обновления может выглядеть странной

А кому-то покажется странным платить за месяц подписки без обновлений :)

Но, имхо, больше различных вариантов монетизации - лучше. Вероятно и разработчики и их клиенты в конечном итоге нашли бы баланс.

Например, опции, различные комбинации которых, позволили настроить ценовую политику по своему усмотрению:

1) выбор что будет с продуктом без подписки: будет отключён, ограничена функциональность или просто нельзя обновиться?

2) срок подписки: месяц, год или произвольный (по сути плата за отдельные обновления)?

Лично мне бы подошёл вариант с отсутствием обновлений и подпиской на год (ещё и с дисконтом на своевременное продление), либо с платой за отдельные обновления, которые я бы всё-равно не делал чаще. В таком случае я могу строить хоть какие-то прогнозы относительно затраченного на разработку времени.

Но всё сводится к тому, что Webasyst "должны" придумать "идеальный" вариант, вместо того, чтобы дать возможность экспериментировать уже нам.

Вот есть же вменяемый пример обновлений ШС: покупка возможности обновляться в течение года.

Если за год разработчик ничего не выпустил или выпустил недостаточно для того, чтобы клиент счёл нужным обновиться, то не продлевать, да и всё.

И добавить в Инсталлере галочку "не учитывать в счётчике обновления продуктов с истёкшей лицензией".