Николай Савин

Раз уж зашел холивар про jQuery позволю и я себе вставить свои пять копееек.
Давайте немного структурируем информацию и разберемся, почему и зачем сейчас все отказывются от jQuery.
Что это? Дань моде? Да здравствует Ванильный JS?
Да вот нет. Причин на самом деле две. Одну из них выше упомянули. Использование в компоненте jQuery — это лишняя зависимость для проекта в целом.. Да скорее всего он и так подключен. Тот же miniShop2 до сих пор требует jQuery. Кстати совсем немного. Скрипты минишопа написаны на чистом стареньком JS пятой версии. Но в нескольких местах пока еще используется jQuery. При желании можно переписать и отказаться от зависимости.

Вторая причина, которой я здесь в обсуждении не увидел это дополнительная нагрузка на память. Дело в том, что jQuery сильно нагружает используемые DOM-элементы собственными свойствами и методами. Грубо говоря, добавляя под сотню (не считал) свойств в каждый используемый элемент. И это все висит в памяти, чтобы браузер в любой момент мог использовать все дополнительные методы каждого элемента.

Современный веб — он же про оптимизацию и быстродействие верно? Так что приходится избавляться.

Давайте также до кучи разберем почему вообще jQuery получил такую популярность исторически.
Причин собственно так же две. Начну с конца.
Во-первых, jQuery дал возможность использовать короткие вызовы для различных популярных действий. И это частично по прежнему актуально. Те же методы show(), hide(), classToggle() и тому подобное все еще короче, чем то же самое на чистом JS. Но напоминаю эти методы и еще куча других нагружают узлы DOM дерева, независимо от того пользуетесь ли вы ими.

Во-вторых кроссбраузерность. Раньше у каждого браузера были свои собственные движки JS, которые по разному реализовали те или иные возможности. Либо вообще не реализовали. Jquery давал возможность не задумываться для какого из браузеров пишется код. Магия внутри преобразовывала все как надо. все изменилось с приходом на рынок Chrome и его движка для рендера JS V8. Он получился насколько качественным, что его стали использовать и другие браузеры, и даже портировали в NODE JS. и даже те браузеры которые не стали его использовать — все равно волей неволей стали подстраиваться под лидера рынка. Таким образом от проблем кроссбраузерности мы практически избавились и для решения этой проблемы jQuery стал не нужен.
Ну и не нужно забывать что движок JS и сам упрощается. Все ранее недоступные или сложные возможности становятся все проще и доступнее.

Надеюсь такой мини-ликбез будет кому то полезен. Спасибо.

У тебя всегда доступен объект $modx->resource
Пиши условие, проверяй у него content_type или как там, не помню сейчас на лету.

Ну… приходится иметь дело с тем, что предложили авторы. Моя задача была показать основные принципы работы из коробки.
Посмотрим — может получится реализовать вариант OpenAPI. Но вообще вряд ли.
Проще подготовить собственную надстройку к MODX, по-моему.

Всегда надо перечитывать свой текст. Это называется вычитка. Вылавливаешь ошибки

Дядь Сережа — я как раз этим занимаюсь.
Фильтр по родителю вот такой

GET https://shopname.com/rest/products?parent=13

Изложение получилось сумбурное, торопливое — т.к. тема объемная на самом деле. Будем считать это черновиком. Постараюсь по настроение подкорректировать текст, снабдив наглядностью.

В админке залогинен? Это дает дополнительные права. Нужно пробовать анонимный порно-режим.
Во вторых в параметрах вызова pdoMenu нужно указывать права для проверки доступа. Например &checkPermissions=`list`.

Правильно да. это работает автоматически

Я говорю о PHP функции sleep, которая останавливает работу скрипта на указанное время, и, насколько я понимаю (я могу ошибаться), предотвращает наступление max_execution_time.
По крайней мере я пользовался примером Николая-философа и это помогало делать пошаговую разбивку чтения больших данных.

А через sleep() разве нельзя такое сделать без js?

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

Привет Сергей. Яндекс закрыл этот API. Компонент тупо не может получать данные.

Здравствуйте. За все годы работы я впервые слышу о

такой самой распространенной и необходимой вещи для modX

. Уж извините, не предусмотрел, Вы первый кому подобное понадобилось.
Как то странно, что вы перешли на MODX не изучив для себя вопрос — а выйдет ли задумка. Уж тем более странно покупать дополнение, в котором нет нужных вам возможностей. Что мешало предварительно спросить?

Могу написать для вас нужный функционал отдельно, за деньги. Все мои контакты в профиле.

Минус за bootstrap3 — вы серьезно? Сколько вы делали сайт года 4?

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

Здравствуйте. Рекомендую приобрести техподдержку еще на год. Деньги не то чтобы серьезные.
У LiqPay (самого банка) нет настроек для возврата в случае ошибки. Поэтому всегда срабатывает редирект только на один единый адрес. По крайней мере я таких настроек не видел. Если я ошибаюсь — можете ткнуть пальцем.
Что касается языков и контекстов — что вы имеете ввиду? Сам платежный модуль с языком вообще не работает. Только с валютой. Пользователю модуль ничего не выводит, все что видит пользователь, и то что можно переводить — это уже miniShop2.
Ваша задача наверняка решаема, но не в формате вопроса-ответа.

В таких скриптах не нужно писать никаких echo и print. Это ж аякс.
Для начала если хотите проверить поступление данных или что то залогировать используйте $modx->log();
Примеры

$modx->log(1, print_r($_POST, 1));
$modx->log(1, $_POST['name']);

AjaxForm не особо то предназначен для возврата значений. Его основная цель захватить данные формы и куда то отправить. Чтобы манипулировать возвращенными данными нужно переписывать скрипт js ajaxForm, добавляя свою логику

Здравствуйте. Для начала вам нужно убедиться что mSearch2 верно вызывает miniShop2. Для этого проверьте в вызове mSearch2 должна стоять строка &element=msProducts. При таком вызове по умолчанию доступны два изображения с плейсхолдерами image и thumb. Если нужны другие изображения нужно в вызове mSearch2 указать параметр includeThumbs, в котором перечислите нужные изображения.
Что касается чанка.
Попробуйте переписать ваш вызов вот так

{if $image?}
<img src="{$image}" class="mw-100" alt="{$pagetitle}" title="{$pagetitle}"/>
{else}
<img src="/assets/images/no-image.png" class="mw-100" alt="{$pagetitle}" title="{$pagetitle}"/>
{/if}

Сергей, позволю себе возразить. С нуля, наверное никто не будет делать RESTFul сервис на MODX, когда есть Laravel, но вот для существующих проектов, когда нужно пробрасывать запросы к API MODX из мобильного приложения, или JS приложения какая никакая RESTful болванка все таки нужна.

Другое дело что в здравом уме расчитывать оправдать трудозатраты какой то выручкой — это бред. Здесь может быть только собственный интерес, который у каждого разный. Это уже конечно личное дело.

Пользуйтесь на здоровье!

Пост 17 года, вполне может быть на момент написания была еще 4, а то и третья версия API.
На данный момент в компоненте пятая актуальная версия. Нормально все.