Кстати, так как данный баг пока не собираются исправлять, советую скрыть доступ к корневому файлу composer.json через .htaccess, либо nginx(в зависимости от настроек сервера).
А в связи с тем что fenom не обновляется уже больше года и по возможностям уступает другим шаблонизаторам, планируется ли в pdoTools добавить поддержку тогоже Smarty(Twig)? Ну или использовать по умолчанию не феном в pdotools для modx 3(если он когдато выйдет?).
Плюс можно расширить эту идею и при загрузки картинки сразу обрезать её под максимальный размер. Были случаи когда грузили 4К картинки, а потом удивлялись, что долго грузятся))))
И я также не понимаю, про какую такую обратную совместимость они всё время говорят, если по факту её нет?
[[+modx_setting]] — плейсхолдер, с чего вдруг он должен стать опцией? если имелось ввиду [[++modx_setting]] то он преобразуется в {'modx_setting' | config}
В любом случае, сказать точно что понадобится из вариантов вывода плейсхолдеров не получится, это надо уже самому смотреть и по ситуации применять один из выводов.
Точно нет, не хватало потом выслушивать жалобы, что закинули в конвертер шаблон, а потом сайт не работает, надо смотреть, что именно правишь на сайте, а не бездумно пихать весь шаблон страницы и смотреть что получится.
Если имеется ввиду модификаторы, то повторяюсь, тотже :default уже не имеет смысла использовать в fenom заместо него надо использовать {if ...}.
Какой практический смысл в этом? Я пользуюсь всегда двойными кавычками.
Чем так цвет фона душу раздерает?) Мне в дизайне всё нравится))
Если у кого то есть предложения по более лучшему варианту, велком с пуллреквестом))) github.com/alexsoin/modx2fenom
вместо как в данной статье
Б — безопасность)
Тут не соглашусь, у меня часто в работе лендинги для бизнеса у которых цель заключается в том, чтобы прорекламировать продукт и затем чтобы клиент зарегистрировался/подписался на рассылку или чтонибудь такое. Из требований там только чтобы текст и картинки менялись менеджерами, вот для таких случаев разрабатывать API-first на томже strapi + nuxtjs (или чем либо другом) банально дольше чем накатить верстку на modx подключить форму к formit и выкатить в прод.
Также и с магазинами, если требуется создать отдельный сайт под сезонную акцию и жизнь сайта 2-3 месяца, то разрабатывать на modx быстрее и дешевле для бизнеса, чем реализовывать чтото на современных решениях.
Както натыкался на статью, когда компания решила отказаться от вебпака в пользу своего решения и рассказывали, что у них сборка проекта производилась на 20% быстрее, а затем через годы программисты которые работали над этим решением уволились, документации никакой небыло и нужно было добавить в это решение поддержку postcss, в итоге проект начал собираться адски долго и все снова вернулись на вебпак)))
В связи с чем появляется вопрос, а чем можно заменить modx в современных реалиях?
Плюс можно расширить эту идею и при загрузки картинки сразу обрезать её под максимальный размер. Были случаи когда грузили 4К картинки, а потом удивлялись, что долго грузятся))))