Максим

Если суть поста: стоит или не стоит, то тут всё зависит от тебя. Хочешь копаться, разбираться — стоит. А иначе можешь и откатиться, но не факт что всё заработает…

Раз уж в статье написано про «подтянуть в очередной раз свои знания в PHP», напишу тут свои мысли.

1. Работать с датами можно через объект DateTime. Насколько помню там даже можно просто сравнивать даты обычным оператором $myDate > $yourDate
2. Может быть имеет смысл не привязываться к году, а просто выводить за столько то дней до и после определённой даты. Новый год всегда 1 января не важно какого года, другие праздники тоже.
3. На мой взгляд удобнее и нагляднее вместо:

$start = $modx->getOption('start', $scriptProperties, '');
$end = $modx->getOption('end', $scriptProperties, '');
$chunk = $modx->getOption('tpl', $scriptProperties, '');

писать в таком стиле:

$options = array_merge([
        'start'   => '',
        'end'    => '',
        'tpl'      => "@INLINE {$var}"
    ], $scriptProperties);

4. Я всегда стараюсь делать один return в сниппетах или функциях. Для меня лично тоже так удобнее и нагляднее (единая точка выхода).

Думаю, лучше оформить «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 версии одной зависимости? И как потом этим пользоваться?

2. Те, кто не знают php, могут и дальше по старинке работать.

Давно мечтал о подобных формах! Спасибо!

Что вы имеете ввиду под «изменениями на сайте»? Изменение ресурсов? Или изменение кода (плагины/сниппеты/шаблоны)?

Может быть в .htaccess как-то прописать запрет на изменение (удаление) файла?

Да, но самый логичный как мне кажется. Тема вроде не так часто меняется, можно и вручную обновлять иногда оставшиеся файлы.

Потому и говорю, что на их стороне полюбому проблема. Сталкивался с прошлой версией, тоже голову сломал себе, в итоге заказчика просто отказался от него))

Я сейчас тоже посмотрел и глюк на глюке)) Тормозит ужасно всё)) Но, думаю, тут не к вам претензия, а к разработчикам виджета))

Да, проблемы есть в modx-3…

Кончился похоже modx.

Wordpress вон живёт и вроде не скоро еще собирается умирать)) Хотя, на мой взгляд, там проблем поболее… Так что…

Да, у меня тоже есть базовый пакет настроек)) Если это так можно назвать… Через Vapor делаю бэк-ап сайта с базовыми настройками, потом где надо разворачиваю, меняю ключи от modstore и другие настройки под новый сайт))

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

А для чего тогда нужно использовать сессии в PHP, если не для этого в том числе? Когда лет 10 назад (а то и больше) изучал PHP, препод как раз так и предлагал делать: хранить данные формы в сессии! Думаю, ничего принципиально нового в подходе не поменялось за это время… если мы говорим именно про PHP.