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

Ну что ребята, дождались. Евгений Борисов откапал 2 просто чудовищных дыры безопасности в MODX Revolution.
Подвержены все сайты на Revo.

Первая: функция eval() в фильтре math. Позволяет вызывать произвольный php код. Багрепорт. Модыксеры сказали, что это не ошибка, мол так и надо. Хотя, на мой взгляд, там где есть eval() — всегда есть потенциальная уязвимость.

Эта заметка назревала уже очень давно, полгода минимум. Вокруг замечательного MODX Revolution сломано много копий. Ходят слухи, что он «тормозной», «прожорливый» и «неповоротливый». И главным виновником всегда называют xPDO.

Конечно, это чушь и цель заметки — развенчание мифов. Закрыть, наконец, вопрос с «тормозами» и «прожорливостью». Показать, насколько Revolution удобен и гибок, что он позволяет работать как через ORM xPDO, так и без него — через обычный PDO.

Не все знают, что MODX Revolution умеет работать с разными системами кэширования, для чего применяет следующие классы:

• xPDOFileCache — стандартный обработчик по умолчанию, хранит кэш в файлах.
• cache.xPDOAPCCache — обработчик для расширения php-apc
• cache.xPDOMemCached — обработчик для memcached. Есть заметка про него
• cache.xPDOMemCache — обработчик для memcache.
• cache.xPDOWinCache — обработчик для wincache. Это для windows хостингов, на IIS.

При большом желании, вы можете написать свой обработчик для любого кэшера. Нужно просто расширить класс xPDOCache и описать собственные методы: add, set, replace, delete, get, flush, по образу и подобию одного из этих классов.

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

Сегодня в комментариях хороший человек Денис Артамонов поделился ссылкой на собранную им виртуальную машину для работы с MODX.

«Это гениально!», подумал я, и немедленно принялся делать такую же, только лучше на Ubuntu — ибо сам на ней работаю и все свои скрипты\инструкции пишу именно для нее. Теперь многие люди смогут сказать «Прощай, Denwer!».

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

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

В рамках выполнения одной хитрой задачи, потребовалось написать скрипт, который будет запускаться по cron и что-то делать с MODX.

Проблемы, в общем то нет, вопрос изучен, но выплыл интересный глюк.
А именно: не работали процессоры для создания/обновления ресурсов.

То есть, процессор для логина — нормально, контекст mgr — нормально, а при попытке создать ресурс — просто пустая error.
Выложил вопрос на официальном форуме и никто мне не ответил. Пришлось разбираться самостоятельно, глубоко копая исходники.

Бывает, что вы используете какой-то сниппет или компонент, и он немного вас не устраивает. Вам нужно поправить буквально пару строк, но вы понимаете, что при обновлении эти измения пропадут.

Что же делать?
Все просто — нужно расширить сторонний класс своими методами. По сути, это очень похоже на «классные процессоры», только без процессоров и использовать можно везде — это стандартная возможность ООП.

Регулярно встречаю в сети разные велосипеды про то, как подключиться к MODX снаружи для работы с его Api. Даже на официальном сайте это описано сложновато.

Предлагаю вам свой очень вольный перевод записи из блога Mark Hamstra о новых процессорах, основанных на классах. Я буду называть их «классными» процессорами — так короче и точнее отражает их суть.

Одно из изменений в MODX 2.2 это новая, полностью переделанная система процессоров, основанных на классах («классные» процессоры), позволяющие вам cущественно упростить создание процессоров для компонентов. Как и любая обновка — эта позволяет вам использовать несколько новых фокусов.

Я использовал эти процессоры в своем новом проекте, и теперь хочу распространить эти наработки где только можно.