Nichikov Eugen

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

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

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

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

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

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

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

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

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

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() добавить доступные валюты.

Метод payment(..) вызывается, когда выбран этот способ оплаты, заказ находится в статусе, на котором доступна оплата, а клиент - на странице, где должна быть кнопка (либо checkout.suceess.html, либо my.order.html).

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

Попробуйте для начала оставить только logger в этом методе. Как минимум, ошибка в вызове 

    return $view->fetch("/templates/payment.html"); 

Файл по заданному пути вряд ли существует, т.к. путь от корня сервера.

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

https://developers.webasyst.ru/hooks/shop/backend_menu/

И вернуть что-то типа

[
    'aux_li' => '<style>ul.s-orders li.selected { background: #D3D3D3 }</style>'
]

Странная постановка вопроса.

Создайте меню, выведите ссылки на категории https://www.webasyst.ru/store/app/menu/

При необходимости поменять ссылку можно будет уже в приложении.

Так внесли же, и даже плагины сделали

https://www.webasyst.ru/store/plugin/shop/ordersfilter/

https://www.webasyst.ru/store/plugin/shop/desordersearch/

Кроме того, дополнительно ещё обсуждали возможность фильтрации/дополниения стандартного поиска, но это пока вроде не сделано

Решается проблема другого рода: когда по ошибке остаются старые файлы (например, перенесли в другой каталог без соответствующего мета-обновления), которые иногда могут грузиться вместо новых.

А БД если уже по какой-то причине имеет некорректную структуру относительно последней версии файлов из Инсталлера, то в любом случае поможет лишь полная переустановка. И, наоборот, если БД правильная, а файлы - нет, то поможет решение ITFrogs.

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

Так что это не проблема вовсе: удаляем файлы, заливаем новые => метаобновления не выполнятся, т.к. в БД уже есть нужная запись.

https://www.webasyst.ru/store/plugin/shop/prioritysort/

Ну в такой постановке непонятно, почему, чтобы исключить дубли, было выбрано решение исключать их каждый раз при загрузке каждой страницы и тратить на это ресурсы сервера вместо того, чтобы исключить (удалить/скрыть) один раз в БД ¯\_(ツ)_/¯