В моей практике были разные сложные калькуляторы стоимости продукции. Можно конечно и на PHP отправлять запросы, но это явно дольше (запросы отправлять дополнительные), чем сразу на стороне клиента считать данные.
Если суть поста: стоит или не стоит, то тут всё зависит от тебя. Хочешь копаться, разбираться — стоит. А иначе можешь и откатиться, но не факт что всё заработает…
Раз уж в статье написано про «подтянуть в очередной раз свои знания в PHP», напишу тут свои мысли.
1. Работать с датами можно через объект DateTime. Насколько помню там даже можно просто сравнивать даты обычным оператором $myDate > $yourDate
2. Может быть имеет смысл не привязываться к году, а просто выводить за столько то дней до и после определённой даты. Новый год всегда 1 января не важно какого года, другие праздники тоже.
3. На мой взгляд удобнее и нагляднее вместо:
Думаю, лучше оформить «human_filesize» и «getFileInfo» в сниппеты и вызывать как модификатор фенома.
Плагины нагружают систему как мне кажется. Тем более такой мелкий и редко используемый.
Проверьте существует ли эта папка (/assets/cache/).
Проверьте путь на опечатки.
Проверьте права на запись у этой папки (может ли пользователь, из-под которого запускается php, записывать в неё).
Не совсем понял в чем решение… Да, есть стандартный парсер; да, некоторые «миксуют» его с Феномом. И? Ты предлагаешь вместо того, что бы прописать {ignore} там, где надо, подключить (написать) сниппет-обёртку, в который будут передаваться феном-чанки?
Сам относительно недавно столкнулся с проблемами phpThumb. Насколько помню в последних релизах modx была версия phpThumb, которая работала только с php 8 (в коде были фичи именно от 8-ки). А для сайта мне нужна была версия 7, соответственно были ошибки… Вручную скачивал phpThumb последней версии и заливал в core.
Мне вообще не нравится, что файлы дополнений раскиданы по всей системе… часть в assets/name, другая в core/name, а третья получается еще и в _build/name
Мне кажется, былоб логично, еслиб была одна папка в корне, например, components/name и уже в ней всё остальное: assets, core, build и т.п.
А можно подробнее? Каким образом можно будет избежать конфликтов, даже если все дополнения будут устанавливаться через Composer? Если МоёДополнение, например, использует зависимость версии 1, а ТвоёДополнение требует версию 5, где половина методов из версии 1 отсутствует, Composer как-то будет устанавливать 2 версии одной зависимости? И как потом этим пользоваться?
Потому и говорю, что на их стороне полюбому проблема. Сталкивался с прошлой версией, тоже голову сломал себе, в итоге заказчика просто отказался от него))
1. Работать с датами можно через объект DateTime. Насколько помню там даже можно просто сравнивать даты обычным оператором $myDate > $yourDate
2. Может быть имеет смысл не привязываться к году, а просто выводить за столько то дней до и после определённой даты. Новый год всегда 1 января не важно какого года, другие праздники тоже.
3. На мой взгляд удобнее и нагляднее вместо:
писать в таком стиле:
4. Я всегда стараюсь делать один return в сниппетах или функциях. Для меня лично тоже так удобнее и нагляднее (единая точка выхода).
Плагины нагружают систему как мне кажется. Тем более такой мелкий и редко используемый.
Проверьте путь на опечатки.
Проверьте права на запись у этой папки (может ли пользователь, из-под которого запускается php, записывать в неё).
Мне кажется, лучше пройтись по шаблонам и сразу сделать правильно. Дополнительный сниппет — это дополнительная нагрузка на систему.
Мне кажется, былоб логично, еслиб была одна папка в корне, например, components/name и уже в ней всё остальное: assets, core, build и т.п.