Василий Наумкин

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

Итак, юзер @Futuris установил новенький mmxForms и словил Fatal Error 500 на сервере, при попытке создать форму.

В логах нашли вот такое сообщение:

PHP Fatal error:  
Declaration of Slim\Psr7\Uri::withScheme($scheme) must be compatible with
Psr\Http\Message\UriInterface::withScheme(string $scheme): Psr\Http\Message\UriInterface
in ...

Как же так? Почему у меня работает, а у него нет?

Привет, друзья, давно не виделись!

Прошло уже более 3х лет, как я перестал активно работать с MODX и занялся своим проектом Vesp. За это время я создал много разных сайтов и библиотек, неплохо освоил современные технологии, а теперь возвращаюсь порадовать сообщество MODX.

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

Плюсом к этому добавились мои разговоры с европейскими коллегами на недавнем митапе в Швейцарии, из которых я вынес, что никто ничего менять не планирует.

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

Последние полгода работаю в голландской компании Sterc, в основном, с MODX 3, хотя и не собирался. Не то, чтобы мне это очень нравилось, но деньги платят отличные.

Sterc интенсивно проводит апгрейды своих клиентов на 3ю версию MODX, в ходе которых обнаружилась очень неприятная проблема, и это — Composer. Да-да, тот самый composer, который мы дружно в MODX запихивали, стал причиной больших проблем. Точнее, не он сам, а его реализация.



Несмотря на прикрученный composer, MODX 3 всё еще использует свой собственный формат дополнений. Более того, MODX не устанавливает composer.json по умолчанию, предлагая уже скачанную директорию core/vendor со всеми зависимостями.

Всем привет!

Увидел тут в комментариях к одной заметке вопрос про MODX в Docker. Так уж совпало, что я как раз недавно освоил работу с Docker для своих проектов на Vesp, и Pixmill попросили меня сделать что-то такое же и для MODX.



Вызов был принят — и вот результат github.com/bezumkin/modx-docker, можете использовать. Ниже будут пояснения.

Третьего дня Сергей Шлоков провёл новый тест скорости работы парсера MODX и шаблонизаторов Fenom и Smarty.

До Smarty мне дела нет, но с итоговыми выводами, что никакой разницы в скорости между синтаксисом MODX и Fenom не видно, я категорически не согласен.



Итак, что нужно прояснить. У оригинального парсера MODX modParser есть две, на мой взгляд, фундаментальные проблемы:

Во-первых, каждый тег при разборе превращается в PHP объект modTag и в нём запускается метод process. То есть, если в чанке указан просто [[+id]], то MODX вместо обычной замены его через str_replace будет создавать новый объект и парсить.

Во-вторых, из-за своей рекурсивной природы, MODX выполняет все условия в чанках. Он просто не знает, во что могут превратиться эти условия на пятой, например, итерации. Причём делает он это изнутри наружу.
То есть, если вы прячете какой-то кусок оформления для вывода только нужным пользователям за условиями в чанке — именно этот кусок и будет первым делом разобран, а потом MODX решит, нужно ли его выводить, когда проверит условие с юзером. Народ придумывает разные костыли для обхода этого момента, чтобы парсить только нужное, типа [[![[+user:is=`admin`:then=`auth`:else=`guest`]]]].

Всем привет, давно не виделись!

Переодически почитываю новости на сайте и вот увидел ветку комментариев про хранение данных в сессии.

Казалось бы, совершенно заслуженный камень в мой огород, как автора дополнения. Зачем использовать сессии для ajax сниппетов, ведь сама по себе эта технология сессий не требует? Так-то оно так, но в мире MODX всё несколько сложнее.

Не знаю, заметили вы или нет, но из обещанного на 2020 год я так ничего и не сделал. Пытался, садился что-то делать много раз.
Больше чем на половину даже сделал новый modx.pro на Vue, но и там вдохновение закончилось как только понял, что сам им пользоваться уже не буду. Больше не прёт, увы.

Думаю что всё, что я мог сделать для MODX, уже сделал. Соответственно, пора перестать страдать фигней и просто уйти.

Поэтому в течение 2х месяцев, до 2021 года, нам нужно разобраться с кое-какими вопросами.

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

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

А потом я наткнулся на ранее неизвестные мне возможности Git — его хуки.

Не хочу писать эту заметку, но нужно информировать общественность.

Все вы знаете, что дела у MODX идут ни шатко, ни валко. 3й версии нет, активность сообщества на нуле, новых дополнений почти не выходит.

Для координации основных разработчиков еще во времена моей работы в Нидерландах (а может и раньше) был создан закрытый чат в Slack, где обсуждались всякие вопросы о будущем системы. Так вот, вчера меня из него исключили без объяснения причин.



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