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

Немножко промахнулся. Вот событие для коммента. Нужно повесить на него свою логику.

Во-первых, ограничивайте количество в запросе, а не тащите всю таблицу в PHP.
Во-вторых, у таблицы msCategoryMember нет индекса для связи с таблицей категории (ресурсов). Попробуйте добавить.

Запрос в БД в цикле — плохой вариант.

теперь все функции на сайте работают нормально…

До первого обновления.

Я в своё время делал такое же для mSearch2. Только создал новый класс, который наследовался от базового.

Нужно подумать — проблема ли это вообще

Конечно проблема. Сейчас многие собирают скрипты в один файл, а конкретно в минишопе сделать это нельзя.

Странные пацаны — тыкнули пальцем туда, где как раз и запрещается указывать пустое значение. Что бы это могло значить? )

Если удалить поставщика modstore и подключить заново, то уже установленные пакеты не отображают поставщика modstore.

Естественно, ведь связь по id (вторичный ключ), а у нового поставщика он другой.

У меня на локалку с modstore.pro не ставится, с modx.com без проблем.

Версия 1.2.0 не совместима с предыдущими версиями. При обновлении все может поломаться.

Для информации. При использовании семантического версионирования необходимо следовать следующим правилам:

Учитывая номер версии МАЖОРНАЯ.МИНОРНАЯ.ПАТЧ, следует увеличивать:

МАЖОРНУЮ версию, когда сделаны обратно несовместимые изменения API.
МИНОРНУЮ версию, когда вы добавляете новую функциональность, не нарушая обратной совместимости.
ПАТЧ-версию, когда вы делаете обратно совместимые исправления.

Таким образом, разработчик в менеджере пакетов сразу видит можно обновляться или нет.

В минишопе нельзя указывать пустое значение в настройке ms2_frontend_js. Напишите issue в репозиторий минишопа, чтобы добавить такую возможность. Пацаны сделают.

Вопрос: а зачем вот тут тогда MODX?

Готовая архитектура.

Просто потому что API известно?

Да.

Просто потому что знаешь куда что прописать?

Да.

И вот потому что админка есть?

Да. Её не нужно самому писать.

Или потому что типа есть много компонентов на все случаи жизни?

Да. Готовые компоненты с UI в отличие от тех же пакетов Composer, которые используются в той же Ларе, где нужно в большинстве случаев писать интерфейсы, так как архитектура у всех сайтов разная.

И я не только прочитал твой топик, но и на сайт твой сходил

Как же ты читаешь, если после пишешь такое?

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

Ведь я как раз и пишу и делаю всё для того, чтобы можно было из MODX плавно перемещаться в стек фреймворков для решения более сложных задач без каких-либо накладных расходов на адаптацию. Чтобы пользователи MODX знакомились с техникой работы старших братьев.

Можешь в двух словах объяснить весомую причину?

В тысячный раз… Я занимаюсь программированием ради удовольствия. И мне нравится то, что я делаю. Я поучаствовал в паре проектов на Laravel, активно тусовался в их сообществе. Оттуда кстати и позвали в проекты. Но там другая атмосфера. В основном всё сводится к знаниям различных пакетов. Очень много рутинной работы и мало творчества. Да, там другие расценки. Но я на зарплате не сижу. И участвовал ради интереса.

А в нашем сообществе совершенно другая аура. Я к нему привык. И я прекрасно понимаю потолок MODX и нигде не говорил, что ему нет альтернативы. Но пока есть интерес его развивать — буду развивать. Что в этом плохого не понимаю.

А здесь по прежнему не приветствуется инакомыслие :)

Здоровая критика приветствуется. И мы частенько поливаем негодованием MODX. А наброс на вентилятор позитивного эффекта не вызывает. Обычный холивар.

Вспоминается поговорка: «Пока ты стоишь лицом к своему прошлому, ты стоишь спиной к своему будущему!»

Точно. Купил машину — велосипед на помойку. Он — прошлое. Ведь только люди без фантазии используют каждый инструмент по своему назначению. По парку можно и на машине прокатиться.

Вот ты же никакими CMS не пользуешься и даже свою не разрабатывал. Любой сайт с нуля. Ага. Ну для чего этот пафос? Течение IT технологий каждого выносит на разные берега. MODX позволяет стартовать, оттолкнуться. Фрилансеры сами решают каким инструментом им удобнее пользоваться. А наёмные используют стек компании. К чему эти споры?

И про топчик и актуальность еще: Smarty в MODX? Не, никогда такого не было. Или было?

Я первым делом смотрел твой репозиторий. Но там логика такая же как и в pdoTools — рулит всем шаблонизатор MODX. Я пошёл другой дорогой — разработка фронта полностью вынесена из MODX — роуты, контроллеры, полноценная однократная PHP шаблонизация без многоразовой компиляции страницы в PHP код на каждом этапе парсера MODX.
Твоё решение мне нравится. Для того времени очень даже. Но ты не смог сообществу разъяснить его достоинства. А я в том момент не смог его оценить по причине невысокого уровня знаний.

Вообще, когда читаешь наискосок есть минус — сути не ухватываешь. Smarty я использую только потому, что он уже есть в ядре. Вот и вся тайна. Есть планы и остальные шаблонизаторы добавить.
Та же проблема «наискосок» и с перехватчиком. Он перехватывает не ошибки Smarty, а все. Можно в роутах, в классах выкинуть исключение — и получить красивую страницу ошибки. А если это PHP ошибка, то и трассировку. Как это делает XDebug. Как это делают разработчики фреймворков.

И ещё, я на твоём месте не стал бы переживать насчёт топика. Кроме лайков ничего не будет. Много было разговоров о том, что нужно добавить в MODX что-то из современной разработки, нужен механизм REST API. Сделал. И никому это особо и не нужно. Ровно такая же тема с MODX3. Все соревнуются в остроумии по поводу его выхода. Но на самом деле, даже если он выйдет, никому он будет не нужен.

Закончу тоже народной мудростью «Все мечтают о бессмертии, но не знают чем себя занять в холодный дождливый вечер.»

А чем MODX хуже Вордпресса, Джумлы, Битрикса и др.? CMS востребованы. У них своя ниша. И ниша немаленькая. А пилить сайты на фреймворках удовольствие сомнительное.
Да, мы (те, кто занимаются поддержкой и развитием MODX), иногда бубним про устаревший код в ядре. Но разработчик сайта в первую очередь думает не над тем, как править ядро или админку, а над тем, как быстро и хорошо сделать сайт. И MODX позволяет делать это гораздо удобнее, чем многие другие CMS.

В чём нечестность привлечения молодого разработчика? Я правильно понимаю, что этот начинающий веб разработчик должен пилить сайты на фреймворках с микросервисной архитектурой и деплоем с CI? Очень странное соображение. Новички вообще в ядро не лезут. В этом и смысл CMS. А тот, кто выбрал MODX для высоконагруженного сервиса, должен не на него плеваться, а на зеркало.

П.С. Ко мне как-то за помощью обращался человек из студии, разрабатывающей сайт для одного министерства одной области. На ларавел. Так вот я вообще был в шоке — он практически ничего не знал о вэб разработке. Видимо какой-то студент или родственник министра. Но его заставили делать сложные задачи. Посоветовал ему заняться самообучением. Ибо весь смысл его обращения был — сделай как мне нужно. Представляю, какой сайт получился.

Вот тут бегло пробежался по отличиям шаблонизаторов.

какие преимущества даст переход с Fenom на Smarty?

Цель ZoomX не шаблонизаторы менять, а подход к программированию. Smarty был выбран только потому, что он уже есть в ядре MODX. А вот кодить с ZoomX можно так, как это делают старшие браться из сообщества фреймворков со всеми вытекающими преимуществами современной разработки.
А по скорости вот тест, сделанный по инструкции в документации, для 800 ресурсов.


---------------------------------------------------------------------------------



По скорости Smarty чуть быстрее, но памяти отнимает чуть больше.

Планирую. Только мысль о других шаблонизаторах не чтобы народ из MODX убегал на другую платформу, познакомившись с разработкой на фреймворках, а и обратное движение. Досталось челу из Symfony или Laravel стека MODX на поддержку, он без проблем с этим справится.

А зачем переписывать работающие сайты? Нервы пощекотать? Например, с выходом новой мажорной версии Laravel сайты в большинстве случаев не обновляют. Это для новых проектов.

сложно ли это?

Сделать можно всё. Но если честно, у меня нет никакой мотивации этим заниматься.

Жаль, что не прислушались к моей рекомендации шифровать параметры и сохранять их в форме. Данных получится не больше 1Кб. Уверен, даже мобилы потянут. А плюсов много — можно использовать как CSRF токен, не нужна инвалидация кэша (эта проблема решается в текущем обновлении?), привязка не к сессии, а к пользователю.

Исправил. Походу всё-таки придётся писать тесты. Самому уследить за всем очень сложно.

Проверяйте перед релизом.

Первым делом поставил на свой сайт. Прогнал все страницы. Ничего не сломалось. Единственное, что повылезало

[pdoTools] The "tplPath" and "elementsPath" parameters are deprecated and will be removed in the next version.

Первый блин… За композером не углядел. Выпустил 2.13.1 версию с исправлением.