Посмотрите логику API-метода shopProductImagesAddMethod — возможно, вам будет проще использовать API, не вникая в сложности формирования путей к картинкам.
Но, если надо разобраться, то эта логика описана в методе shopProduct::getFolder(). Вы доберётесь сюда, если начнёте изучать код с этой строки файла wa-apps/shop/api/v1/shop.product.images.add.method.php
Класс JSON-контроллера должен сформировать ответ в виде массива в $this->response, а не возвращать просто строку. И нужен ещё конфиг routing.php, чтобы фреймворк знал, какому контроллеру отдавать запрос на обработку во фронтенде.
Если такой код у вас показывает неправильные ссылки товаров, то, возможно, что-то испортилось в вашей базе данных, или вносились изменения в код магазина.
{foreach $wa->shop->products('...') as $product}
{$product.frontend_url}<br>
{/foreach}
В моём магазине ссылки для "Естественных" URL формируются правильно.
NULL означает, что значение характеристики относится к товару, а не к артикулу. А в чём состоит проблема, которую вы пытаетесь решить? Или в чём состоит конечная задача?
Только надо кеш почистить, чтобы сработало. Даже в режиме отладки мне потребовалась чистка кеша, чтобы стала применяться локализация магазина вместо локализации плагина.
И немного офтопика: а если в теме нет файла list-thumbs.html? Я бы сделал настройку в плагине, которая позволит пользователю самому выбрать нужный шаблон для темы выбранного поселения магазина. Тогда и хардкодить не придётся.
Пока мух и котлет не отделили друг от друга, можно в поселения приложений добавлять новые параметры с префиксом приложения. Сильно вряд ли у плагинов есть такие параметры маршрутизации.
Тут, видимо, речь не о произвольных параметрах запроса, которые можно устанавливать в коде плагина вызовом
waRequest::setParam()
а о параметрах маршрутизации фронтенда плагина и настройках поселения приложения, для которого написан этот плагин — и то, и другое можно получить методом
waRequest::param()
Если идентификаторы параметра маршрутизации плагина и параметра настроек поселения совпадут, может получиться конфликт (а именно параметр маршрутизации плагина окажется недоступным). Поэтому тут скорее разработчикам приложений нужно быть осторожными с добавлением новых настроек поселений.
Судя по коду, который написали разработчики магазина в wa-apps/shop/lib/config/shopConfig.class.php, получается примерно такой способ для формирования ссылки на оформление заказа с учётом этой галки:
Зависит от того, где выполняется код. Если во фронтенде, то я выше показал как получить это значение. Чем конкретно не устраивает предложенный способ? В какой ситуации он возвращает не тот результат, который нужен?
Либо вы не пробовали сделать, что я предложил, либо вы не до конца объяснили, что требуется. Оттого и недопонимание...
Если это значение надо получить во фронтенде магазина, то как раз таким способом. Если в бекенде или в других приложениях, то читать содержимое системного конфига routing.php (соответствующими методами фреймворка), в который оно сохраняется.
Чтобы результат каждого экшена отображался с использованием шаблона 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 вы создали в рамках темы дизайна для своего приложения? И настроили поселение для своего приложения в разделе "Структура" приложения Сайт?
В вашем файле маршрутизации я не вижу правила для подключения контроллера appFrontend.action.php. Оно должно быть таким:
'' => 'frontend',
Т. е. в корне поселения приложения отрабатывает контроллер с пустым action_id, который в вашем случае должен быть описан в файле appFrontend.action.php.
порядок этих полей разный в разных элементах передаваемого массива
Массив точно ассоциативный (слово "порядок" заставляет подозревать...)? И зачем в разных элементах массива передавать разные наборы полей? Может, стоит привести к общему виду все элементы (хотя бы для порядка, что ли).
Посмотрите логику API-метода shopProductImagesAddMethod — возможно, вам будет проще использовать API, не вникая в сложности формирования путей к картинкам.
Но, если надо разобраться, то эта логика описана в методе shopProduct::getFolder(). Вы доберётесь сюда, если начнёте изучать код с этой строки файла wa-apps/shop/api/v1/shop.product.images.add.method.php
в ответ на Загрузка изображений
Какой метод? После успешного выполнения чего? JQ == JavaScript?
в ответ на Приостановить сохранение категории в бекэнде и запуск метода
Для категории примерно так должно сработать
в ответ на Приостановить сохранение категории в бекэнде и запуск метода
Возможно, стоит попробовать устранить причину, а не бороться со следствием. Что именно вы изменили в этом шаблоне, и для чего?
в ответ на Переопределение файла шаблона движка
Класс JSON-контроллера должен сформировать ответ в виде массива в $this->response, а не возвращать просто строку. И нужен ещё конфиг routing.php, чтобы фреймворк знал, какому контроллеру отдавать запрос на обработку во фронтенде.
в ответ на Передать ajax данные своему плагину
Если такой код у вас показывает неправильные ссылки товаров, то, возможно, что-то испортилось в вашей базе данных, или вносились изменения в код магазина.
В моём магазине ссылки для "Естественных" URL формируются правильно.
в ответ на Не правильные URL в списке товаров
NULL означает, что значение характеристики относится к товару, а не к артикулу. А в чём состоит проблема, которую вы пытаетесь решить? Или в чём состоит конечная задача?
в ответ на Подскажите как заполнить в таблице `shop_product_features` колонку SKU_ID ?
У разработчика в аккаунте есть ссылочка "Пожаловаться" напротив каждого отзыва. А если это не поможет, то... иг-но-ри-ро-вать!
в ответ на Черный список шантажистов
Только надо кеш почистить, чтобы сработало. Даже в режиме отладки мне потребовалась чистка кеша, чтобы стала применяться локализация магазина вместо локализации плагина.
в ответ на Активация локализации темы дизайна из плагина
У меня получилось вот так — код из тестового плагина:
в ответ на Активация локализации темы дизайна из плагина
Может, примерно так, но применительно к приложению: https://support.webasyst.ru/2503/lokalizatsiya/#comment5910.
И немного офтопика: а если в теме нет файла list-thumbs.html? Я бы сделал настройку в плагине, которая позволит пользователю самому выбрать нужный шаблон для темы выбранного поселения магазина. Тогда и хардкодить не придётся.
в ответ на Активация локализации темы дизайна из плагина
Хотя это кривой и неудобный костыль , конечно же. Так, мысли вслух.
в ответ на Возможные проблемы с перезаписью параметров роутинга
Пока мух и котлет не отделили друг от друга, можно в поселения приложений добавлять новые параметры с префиксом приложения. Сильно вряд ли у плагинов есть такие параметры маршрутизации.
в ответ на Возможные проблемы с перезаписью параметров роутинга
Тут, видимо, речь не о произвольных параметрах запроса, которые можно устанавливать в коде плагина вызовом
а о параметрах маршрутизации фронтенда плагина и настройках поселения приложения, для которого написан этот плагин — и то, и другое можно получить методом
Если идентификаторы параметра маршрутизации плагина и параметра настроек поселения совпадут, может получиться конфликт (а именно параметр маршрутизации плагина окажется недоступным). Поэтому тут скорее разработчикам приложений нужно быть осторожными с добавлением новых настроек поселений.
в ответ на Возможные проблемы с перезаписью параметров роутинга
Лицензию требуют только платные продукты из магазина Webasyst. Все остальные (бесплатные и самописные) не требуют.
в ответ на Самописные плагины
Судя по коду, который написали разработчики магазина в wa-apps/shop/lib/config/shopConfig.class.php, получается примерно такой способ для формирования ссылки на оформление заказа с учётом этой галки:
в ответ на Ссылка на оформление заказа с учетом параметра ssl
Зависит от того, где выполняется код. Если во фронтенде, то я выше показал как получить это значение. Чем конкретно не устраивает предложенный способ? В какой ситуации он возвращает не тот результат, который нужен?
Либо вы не пробовали сделать, что я предложил, либо вы не до конца объяснили, что требуется. Оттого и недопонимание...
в ответ на Ссылка на оформление заказа с учетом параметра ssl
А чем конкретно не устраивают ответы-то?
в ответ на Ссылка на оформление заказа с учетом параметра ssl
"Используется" и "доступен" — разные понятия. Доступен он на всех страницах фронтенда, а использовать его можно необязательно везде.
в ответ на Ссылка на оформление заказа с учетом параметра ssl
Если это значение надо получить во фронтенде магазина, то как раз таким способом. Если в бекенде или в других приложениях, то читать содержимое системного конфига routing.php (соответствующими методами фреймворка), в который оно сохраняется.
в ответ на Ссылка на оформление заказа с учетом параметра ssl
в ответ на Ссылка на оформление заказа с учетом параметра ssl
в ответ на Как проверить существование контакта по id?
Вроде так )
в ответ на Routing в своем приложении
Чтобы результат каждого экшена отображался с использованием шаблона index.html, можно создать класс экшена, унаследованный от системного waViewAction (например, myappFrontendAction), и в его конструкторе добавить создание макета:
У себя в приложении создайте такой класс макета (myappFrontendLayout) и в его методе execute() укажите использование шаблона index.html:
Каждый свой экшен фронтенда наследуйте не от системного waViewAction, а от своего myappFrontendAction.
Получится, что при выполнении любого вашего экшена фронтенда будет использоваться конструктор родительского класса myappFrontendAction, в котором устанавливается макет, использующий в качестве шаблона index.html.
в ответ на Routing в своем приложении
Есть в вашей теме 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.
в ответ на Routing в своем приложении
Да, точно, простите, не заметил. А в чём именно сейчас проблема? У вас там что-то менялось, я вижу:
в ответ на Routing в своем приложении
На всякий случай уточню: файлы index.html, main.html, contents.html вы создали в рамках темы дизайна для своего приложения? И настроили поселение для своего приложения в разделе "Структура" приложения Сайт?
В вашем файле маршрутизации я не вижу правила для подключения контроллера appFrontend.action.php. Оно должно быть таким:
Т. е. в корне поселения приложения отрабатывает контроллер с пустым action_id, который в вашем случае должен быть описан в файле appFrontend.action.php.
в ответ на Routing в своем приложении
Как выглядит ваш запрос, который нужно оптимизировать?
в ответ на Оптимизация запроса к базе при случайном выборе товаров
Массив точно ассоциативный (слово "порядок" заставляет подозревать...)? И зачем в разных элементах массива передавать разные наборы полей? Может, стоит привести к общему виду все элементы (хотя бы для порядка, что ли).
в ответ на waModel -> multipleInsert($data)
внутри foreach для отладки вставлено? В окончательном варианте его не будет там?
в ответ на waModel -> multipleInsert($data)