Eugen Nichikov

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

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

Категорически против вызова 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 "должны" придумать "идеальный" вариант, вместо того, чтобы дать возможность экспериментировать уже нам.

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

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

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

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

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

По опыту своего последнего крупного обновления получил кучу негатива от тех, кто обновился бесплатно, а вот у тех, кто за эту разработку по сути заплатил (последующие новые продажи) всё было в порядке.

И вот что действительно логично: зачем что-то менять тогда в плагине, если всё работает?

это будет иметь обратный эффект

Логика сомнительная. Что мешает сейчас написать приложение "Жёлтый снег" и требовать подписку ¯\_(ツ)_/¯? Никто ж почему-то не сделал так.

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

Модель подписок применима и хорошо работает для сложных решений

Да и много ли приложений действительно можно назвать "сложным решением", которое достойно быть приложением?

FYI: порядок иконок можно поменять перетянув ненужные в конец списка.

Спойлер "ещё" появляется в зависимости от ширины экрана (я иногда замечал баги с ним, но в основном вроде работает)

а мой друг сервер уронил...
он, что, такой крутой хакер? нет, он мудак, он его на пол уронил

Можно.

Но стоит понимать, что метод payment() вызывается каждый раз, когда покупатель переходит на страницу /success или на страницу заказа в личном кабинете (для заказов, которые можно оплатить, ессно).

Поэтому, если API платёжной системы предусматривает только сервер-сервер запросы, а я правильно понял суть проблемы, возможно, всё-таки стоит сделать форму, которая будет отправлять данные в сам магазин по ссылке

$this->getRelayUrl()

Пример бы привёл, но он ещё не опубликован)

Немного абстрагируясь нужна возможность штучно запретить просматривать И/ИЛИ редактировать отдельные поля.

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

Кому-то надо, чтобы редактировали контент, а не цены.

Кому-то надо, чтобы цены редактировали, а остатки выгружаются из 1С.

Кому-то надо, чтобы и цены, и остатки только из 1С обновлялись, но при этом в админке они тоже отображаются.

В основном добавляю разные дополнительные поля на разных вкладках, но об этом писали.

Вот несколько неочевидные примеры:

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

2) блокировка различных полей (по разным причинам, но самая очевидная - права доступа, но далеко не всегда!)

Обе задачи приходится решать обходными путями через JS.

¯\_(ツ)_/¯

Чем возможность настраивать - "не масштабируемо"?

Гипотетически можно тот же один хук использовать, а в нём проверять какой класс отвечает за обработку действия и уже в зависимости от этого включать обработку или нет.

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

Можно оставить только

'order_action.*'        => 'orderActionProcess',

Потом не забыть почистить кэш!

А сам метод уже выглядит так

    public function orderActionHandler($data, $event_id = null)
    {
        if(!empty($data) && !empty($data['action_id'])) {
            $event_id = $data['action_id'];
        }

        if(empty($data['order_id']) || !$event_id) {
            return;
        }

        if(in_array($event_id, [ 'process', 'nalozhennyy-platezh'])) {
            // обработка
        }
    }

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

regex_replace

P.S.

потихоньку и начинаю вникать

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

Плагин писал я) Да, это отладочная информация по импорту сотни товаров. Номер сотни, время и потребляемая память.

В PHPStorm. Settings -> Editor -> File Types -> Smarty добавить *.html

http://dl4.joxi.net/drive/2020/08/21/0009/0563/614963/63/2789c11b6b.jpg

{$items = $wa->shop->cart->items()}

$view = wa()->getView();
$wa = new waViewHelper($view);
$test = $wa->block("some_block", ['item' => 'some_param']);

0_o

странный подход к вырезанию пробелов...

Внутри блока всё завернуть в {strip} ... {/strip} и всё

Старый баг. Только блоки :(

Файл routing.php лежит в папке lib/config соответствующего плагина или приложения (там же, где и plugin.php/app.php). Вот есть более детальная статья по этой теме 

https://developers.webasyst.ru/docs/cookbook/basics/routing/ (фронтенд)

В бекенде немного по-другому

https://developers.webasyst.ru/docs/cookbook/backend-routing/

Блин, пропустил, что в приложении...

plugin.php => app.php, 

{$wa->getUrl('myapp/frontend/ajax', ['plugin' => 'myplugin'])}

а в остальном только классы правильно назвать.

1) plugin.php:

...
'frontend' => true,
...

2) routing.php:

<?php
return [
  'myplugin/ajax' => 'frontend/ajax'
];

3) shopMypluginPluginFrontendAjax.controller.php

<?php

class shopMypluginPluginFrontendAjaxController extends waJsonController {

  public function execute() {
    $this->response = 'It\'s alive!';
  }
}

4) js + Smarty

$.get("{$wa->getUrl('shop/frontend/ajax', ['plugin' => 'myplugin'])}", function(r) {
  if(r.status == 'ok') {
    alert(r.data);
  } else {
    console.log(r.errors);
    alert('Some errors. See console');
  }
}, 'json')

Мож где-то опечатался, но в целом так.

Метод отрабатывает вот тут https://yadi.sk/i/cJDfqeNVXtCHVA но не отрабатывает потому, что там написано почему.

Нужно в allowedCurrency() добавить доступные валюты.