Сергей Шлоков

Вообще не понимаю этой суеты с jQuery. Это просто синтаксический сахар над js.Вполне себе удобный. Почему-то с бутстрапами, Guzzle и ещё кучей библиотек такого кипиша не происходит. А тут прям холиварище.

Конечно, можно всё писать с нуля самому. Но в конечном счёте, всё равно хороший разработчик сделает для себя аналогичную библиотеку для удобства и простоты разработки. Каждый решает сам что лучше для него и легче — если проще писать с нуля и надоело в техподдержке решать вопросы совместимости, пиши с нуля. Удобно работать с jQuery, работай.

Для меня этот вопрос вообще не принципиальный. Мне нравится плагин dataTables. Круче него ещё не видел. И тут без jQuery не обойтись. Уверен, каждый найдёт много примеров нужных плагинов.
Но, другой вопрос, если для несложных манипуляций, легко решающихся нативным js тащить jQuery, то это конечно перебор.

П.С. А что такое МД?

Записал видео, в котором постарался всё объяснить.

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

Я ровно так и думал. ;) MODX отстаёт от сегодняшнего уровня разработки во всём. В том числе и в поддержке REST архитектуры. Так как я на некоторое время погружался в эту тему, то с определённой долей уверенности могу это утверждать. Я даже нацарапал статейку про «недоRESTfull API» в MODX.

Общепринятым форматом для описания REST API на сегодняшний день является OpenAPI, который также известен как Swagger.

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

GET https://shopname.com/rest/catalogs/13/products

А аргументы используются для дополнительных действий типа "?search=телевизоры". Хотя тут больше свободы. В итоге у тебя есть готовый эндпойнт, для которого автоматом пишется документация.

Конечно, никто не заставляет под дулом пистолета следовать OpenAPI. То же самое можно сказать и про стандарты PSR. Но считается дурным тоном им не следовать. Поэтому я считаю, что делать что-то новое нужно с учетом текущих требований.

Представь, как было бы удобно, если бы у всех платформ API следовали бы единому стандарту, а не так как сейчас

https://api.vk.com/method/users.get?user_id=210700286&v=5.52
https://api.ok.ru/api/friends/get
https://graph.facebook.com/{page-id}/conversations?fields=id,messages{message,from}

Это как единый стандарт разъема для телефонов.

Постараюсь по настроение подкорректировать текст

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

Возможности заготовкки

и конструкции типа

Особенно обратите внимание на префикс shop. Обратите внимание на префикс shop — он нам пригодится, дальше. Префикс может быть любым.

А как получить все продукты из определённого каталога?

Может тут что пригодится.

Потестил. Создание 1000 ресурсов через обычный newObject() занимает 10 секунд. А через exec_bg_script() — 1 секунду. Использовал 10 параллельных потоков. Если интересно, могу запилить видос.

Хотя эти айдишники будут внутри сетки гоняться.

В варианте с join нет селекта. Т.е. условия теста не равнозначны.

При учете что мне к примеру не нежно ничего получать из site_content а только id, оно еще быстрее будет.

Не будет. Только если ты поле контент гнать не будешь. Даже 3G не заметит разницы в несколько небольших полей. Простыня айдишников весит больше, чем price и pagetitle вместе взятые.

Этот код будет делать выборку в десятки раз быстрее:

На практике или в теории? Уверен, если замерить, то join выиграет. Ибо один подготовленный запрос отработает быстрее, чем 2 запроса. Тем более со вторым запросом нужно гнать тонны айдишников по сетке.

join — зло еще то))

Только, если ты не умеешь его готовить )) Молотком можно и гвозди забивать и шурупы.

Контролировать можно через лог. Попробую на выходных.

Моё решение без js. Правда ни разу не пробовал ))

П.С. Самому интересно стало. Надо будет попробовать.

sleep() там только для того, чтобы видеть, что пишется в логе. Иначе будет сразу done. У Николая ровно такая же связка php+js.

Видимо, это какой-то квест. Другого объяснения нет. Человек задал вопрос, ему несколько человек ответили, а он — вы неправильно отвечаете. Мне нужен другой ответ.

Все выдохнули. Пусть носит круглое и катает квадратное. Это его решение.

Как раз в плагине будет проще. Ибо запрос заворачивается на входе. А феном уж тут совсем не пришей рукав. Логика пишется на php. Причем здесь феном???
Просто в плагине написать ограничение только для этой пары папок. А если уже есть готовый каталог, то проще и быстрее сделать переадресацию на web сервере.

Делать это лучше в плагине.

Давно уже написано. Да и в инете полно такой информации.

Если бы ты принял этот PR, пришлось бы pdoTools удалять.

Магистр кода 99 уровня

$modx->setPlaceholder('date1',$_GET['date1']);
$where['o.makedate:>='] = '".$_GET['date1']." 00:00:00'";

Ну нахер. Штопать таки дыры, искать в коде display и fonts. И ещё Бог знает чего.

если не считать статических сниппетов, они в fenom ужасно работают, постоянно кэшируются и выдают неверные данные.

Можешь рассказать подробнее?