Markus

Скрипта или всего фреймворка?

Я же выше написал, копия всего магазина. Фреймворк конечно же.

И опять я выше писал.

Вернее к json строке подмешивается вывод кода, который был вставлен предыдущим нерадивым программистом в setting.php плагина.

т.е. BOM в данном случае не причем. И да я проверял файлы на BOM, знаю о таком. 

Причина найдена. Оформление не хочет работать с jQuery v3.4. Теперь вопрос в том как подружить оформление с jQuery v3.4?!

А чем не устраивает магазинный поиск?

Поддерживаю!

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

$view = wa()->getView();

А после него в экшенах или контролерах вызывается 

wa()->getView($options);

передается экземпляр который был создан ранее и параметры этому экземпляру не передаются. У вас же есть в waSmarty3View метод setOptions! Может стоит его расширить.

    public function setOptions($options)
    {
        foreach ($options as $k => $v) {
            $this->options[$k] = $v;
            switch ($k) {
                case "left_delimiter":
                    $this->smarty->left_delimiter = $v;
                    break;
                case "right_delimiter":
                    $this->smarty->right_delimiter = $v;
                    break;
                case "auto_literal":
                    $this->smarty->auto_literal = $v;
                    break;
                case "template_dir":
                    $this->smarty->setTemplateDir($v);
                    break;
                case "compile_dir":
                    $this->smarty->setCompileDir($v);
                    break;
            }
        }
    }

Тогда в shopFrontendProductReviewsAddController renderTemplate

$view = wa()->getView(array('template_dir' => $theme_path));

Меняем на 

$view = wa()->getView();
$view->setOptions(array('template_dir' => $theme_path));

и вуаля все работает как надо и контроллер и плагины. 

Это же 1 минута времени!

Это не решение.

Ответа не ждать? :)

он то class_exists но выключен ли он или нет?

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

В моем случае подкатегории это серии товара. Стандартно, чтобы не делать лишних запросов к базе сделать не вышло.

Пришлось использовать кастомный routing.php в в wa-config/apps/shop/routing.php и для категорий просписать свой плагин. Плагин проверяет какой массив товаров нужен для данной категории, если стандартный то просто вызывается родительский execute, если не стандартный я сам формирую массив товаров

В новых версиях есть своя настройка для товаров которых нет на складе есть своя настройка в настройках магазина

Это уже реальные костыли. Тогда уж 

свой роутинг в wa-config/apps/shop/routing.php

Мне не для маркета.

Нужно чтобы дефолтовый экшен не вызывался.

вариант свой роутинг в wa-config/apps/shop/routing.php справляется с задачей.

Полулегальный способ есть, даже не один.

Какой например, только с вышеизложенным условием.

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

Тогда почему в многочисленных темах на эту тему от саппорта ни слова о том, что переопределять стандартные правила роутинга нельзя?!

Syrnik.com, последний вопрос, собственно, не Вам, а саппорту

Спасибо огромное.

Судя по всему wa('app')->getPlugin('plugin', true) работает правильнее. Работает локализация и в экшене и в шаблоне.