Rat

Посмотрите логику API-метода shopProductImagesAddMethod — возможно, вам будет проще использовать API, не вникая в сложности формирования путей к картинкам.

Но, если надо разобраться, то эта логика описана в методе shopProduct::getFolder(). Вы доберётесь сюда, если начнёте изучать код с этой строки файла wa-apps/shop/api/v1/shop.product.images.add.method.php

$image_path = shopImage::getPath($data);

Какой метод? После успешного выполнения чего? JQ == JavaScript?

Для категории примерно так должно сработать

$(document).on('click', '.s-category-settings :submit', function (event) {
    event.preventDefault();
});

Возможно, стоит попробовать устранить причину, а не бороться со следствием. Что именно вы изменили в этом шаблоне, и для чего?

Класс JSON-контроллера должен сформировать ответ в виде массива в $this->response, а не возвращать просто строку. И нужен ещё конфиг routing.php, чтобы фреймворк знал, какому контроллеру отдавать запрос на обработку во фронтенде.

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

{foreach $wa->shop->products('...') as $product}
    {$product.frontend_url}<br>
{/foreach}

В моём магазине ссылки для "Естественных" URL формируются правильно.

NULL означает, что значение характеристики относится к товару, а не к артикулу. А в чём состоит проблема, которую вы пытаетесь решить? Или в чём состоит конечная задача?

У разработчика в аккаунте есть ссылочка "Пожаловаться" напротив каждого отзыва. А если это не поможет, то... иг-но-ри-ро-вать!

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

У меня получилось вот так — код из тестового плагина:

$route = wa()->getRouting()->getRoute();
$collection = new shopProductsCollection('category/1');
$products = $collection->getProducts('*');

$products_template = wa()->getDataPath('themes/'.$route['theme'].'/list-thumbs.html', 'shop');
$this->view->assign(compact('products'));

//я имел в виду вот это
waLocale::loadByDomain('shop');
waSystem::pushActivePlugin(null, 'shop');
$template = $this->view->fetch($products_template);
waSystem::popActivePlugin();

$this->view->assign(compact('template'));
$html = $this->view->fetch(wa()->getAppPath('plugins/test/templates/actions/frontend/page.html'));

$this->view->assign('page', array(
    'id' => 'myplugin',
    'title' => '',
    'name' => '',
    'content' => $html,
));

$this->setThemeTemplate('page.html');

Может, примерно так, но применительно к приложению: https://support.webasyst.ru/2503/lokalizatsiya/#comment5910.

И немного офтопика: а если в теме нет файла list-thumbs.html? Я бы сделал настройку в плагине, которая позволит пользователю самому выбрать нужный шаблон для темы выбранного поселения магазина. Тогда и хардкодить не придётся.

Хотя это кривой и неудобный костыль , конечно же. Так, мысли вслух.

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

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

waRequest::setParam()

а о параметрах маршрутизации фронтенда плагина и настройках поселения приложения, для которого написан этот плагин — и то, и другое можно получить методом

waRequest::param()

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

Лицензию требуют только платные продукты из магазина Webasyst. Все остальные (бесплатные и самописные) не требуют.

Судя по коду, который написали разработчики магазина в wa-apps/shop/lib/config/shopConfig.class.php, получается примерно такой способ для формирования ссылки на оформление заказа с учётом этой галки:

$protocol =  waRequest::param('ssl') ? 'https' : 'http';
$url = $protocol.'://'.waRequest::server('HTTP_HOST').wa()->getRouting()->getUrl('/frontend/checkout');

$ssl = ???;

Зависит от того, где выполняется код. Если во фронтенде, то я выше показал как получить это значение. Чем конкретно не устраивает предложенный способ? В какой ситуации он возвращает не тот результат, который нужен?

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

А чем конкретно не устраивают ответы-то?

"Используется" и "доступен" — разные понятия. Доступен он на всех страницах фронтенда, а использовать его можно необязательно везде.

Если это значение надо получить во фронтенде магазина, то как раз таким способом. Если в бекенде или в других приложениях, то читать содержимое системного конфига routing.php (соответствующими методами фреймворка), в который оно сохраняется.

$secure_checkout = (bool) waRequest::param('ssl');

Как проверить существование контакта по id?

$contact = new waContact($id);
$contact_exists = $contact->exists();

Вроде так )

Чтобы результат каждого экшена отображался с использованием шаблона index.html, можно создать класс экшена, унаследованный от системного waViewAction (например, myappFrontendAction), и в его конструкторе добавить создание макета:

$this->setLayout(new myappFrontendLayout());

У себя в приложении создайте такой класс макета (myappFrontendLayout) и в его методе execute() укажите использование шаблона index.html:

$this->setThemeTemplate('index.html');

Каждый свой экшен фронтенда наследуйте не от системного waViewAction, а от своего myappFrontendAction.

Получится, что при выполнении любого вашего экшена фронтенда будет использоваться конструктор родительского класса myappFrontendAction, в котором устанавливается макет, использующий в качестве шаблона index.html.

Есть в вашей теме main.html или нет — это непринципиально. Если вам очень уж нужно иметь main.html (хотя это скорее вопрос удобства организации кода темы дизайна), то включите его в index.html с помощью {include file="..."}. Вообще main.html — это просто вынесенная в отдельный файл часть шаблона index.html.

Поэтому в итоге в index.html (а если у вас кусок этого файла вынесен в main.html, то, значит, в main.html) должна присутствовать переменная {$content} для отображения результата, который формирует экшен.

У вас есть экшен appFrontendAction. В нём в качестве шаблона устанавливается файл темы index.html. Это неправильно, потому что это будет означать отображение index.html, внутри которого должен отработать index.html, внутри которого... и так до бесконечности, т. е. возникает бесконечная рекурсия. Наверное, поэтому главная страница фронтенда у вас и не отображается. Вместо index.html в этом экшене вам нужно указать файл-шаблон для главной страницы. Обычно его называют home.html. Ну и, конечно, в теме должен присутствовать такой файл.

Для формирования содержимого экшеном appFrontendPagesAction у вас используется использоваться другой шаблон. Сформированное этим шаблоном содержимое, подготовленное экшеном, тоже будет вставлено в index.html (напрямую либо опосредованно — через main.html) вместо переменной {$content}.

А index.html в качестве шаблона нужно использовать только в классе макета, унаследованного от waLayout.

Да, точно, простите, не заметил. А в чём именно сейчас проблема? У вас там что-то менялось, я вижу:

Вчера вечером мудрил мудрил и перемудрил теперь фронт пустая.

2)Создал фронтенд - файлы (index.html, main.html, contents.html) в файле индекс подключается файл main в котором в свою очередь вывод для всех страниц и {$content}

На всякий случай уточню: файлы index.html, main.html, contents.html вы создали в рамках темы дизайна для своего приложения? И настроили поселение для своего приложения в разделе "Структура" приложения Сайт?

3)создал роутинг
...
4) файл appFrontend.action.php

В вашем файле маршрутизации я не вижу правила для подключения контроллера appFrontend.action.php. Оно должно быть таким:

'' => 'frontend',

Т. е. в корне поселения приложения отрабатывает контроллер с пустым action_id, который в вашем случае должен быть описан в файле appFrontend.action.php.

Как выглядит ваш запрос, который нужно оптимизировать?

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

Массив точно ассоциативный (слово "порядок" заставляет подозревать...)? И зачем в разных элементах массива передавать разные наборы полей? Может, стоит привести к общему виду все элементы (хотя бы для порядка, что ли).

$model_member->insert($member);

внутри foreach для отладки вставлено? В окончательном варианте его не будет там?