Алексей Шумаев

Привет.
Одно из самых заметных изменений в MODX 3 это наличие системного Composer для установки своих зависимостей.

Что такое Composer из зачем он нужен ?

Composer — это менеджер для подключения и управления этими сторонними библиотеками или пакетами в вашем PHP-проекте который решает следующие проблемы:

1. Быстрая установка и обновление пакетов
2. Резолвинг зависимостей между пакетами
3. Хранение пакетов и их версии в едином файле без необходимости версионировать все пакеты вручную

Перевод заметки Using MODX Outside of MODX3

В одной из статей было рассмотрено создание экземпляра объекта $modx в эпоху до MODX3. В этой статье мы рассмотрим использование MODX вне MODX Revolution 3. Большая часть кода такая же, как и в предыдущей статье (прим. переводчика: предыдущая статья не переведена, так как немного не актуальна в рамках перехода на модх3). Основное отличие состоит в том, что MODX Revolution 3 широко использует пространства имен и имеет автозагрузчик для загрузки классов.

Друзья впервые за 5 лет, после версии 2.4 команда minishop2 пришла к кардинальным, не косметическим изменениям, и впервые за всю историю компонента мы готовим к выпуску мажорный релиз.

Хочу поделиться тем, как я в своей работе использую Docker для локальной разработки сайтов. Я не до конца понимаю, как оно там внутри устроено и частично тут будет описано то, как я работаю «по наитию». Если у кого-то будут комментарии и предложения, буду рад услышать, как этот воркфлоу можно оптимизировать.

Главное, что нам понадобится — это Docker.
Скачать его можно по этой ссылке: https://www.docker.com/get-started.

Небольшое вступление

Данная статья не претендует на универсальное решение. Всегда пользуйтесь собственной головой. Всё описанное ниже актуально для MODX Revolution 2.8.3-pl, miniShop2 2.9.1-pl.

Всем привет!

Небольшая предыстория
Когда я на свой VPS сервер закинул очередной более-менее крупный сайт (в базе около 25 тыс. товаров), у меня начались проблемы с нехваткой памяти, mysql ее нещадно отъедал.

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

Но… почему? У сайта посещаемость 150-200 человек в сутки, сессии хранятся 7 дней (да, я проверил, они действительно очищаются), но в таблице почему-то 200000 записей, хотя по логике вещей должно быть 200*7=1400+. Реальность расходится с теорией не на 5-10%, а в десятки раз!
В итоге таблица весит полгигабайта, сайтов штук 10, каждому дай памяти, вот VPS и падает периодически… непорядок!

Всем привет!
Я тут работал над одним проектом, в котором очень много контентной и интерфейсной графики, десятки тысяч изображений и, конечно, возник вопрос оптимизации сайта, чтобы удовлетворить требования поисковых систем.
Энтузиазма добавили, появившиеся относительно недавно у гугла, так называемые Core Web Vitals.
Кто не в курсе это пачка технических показателей качества сайта, которые скоро будут включены в алгоритм ранжирования и все тормознутые сайты из-за них, типа, покатятся вниз.
Ну в общем, встала задача оптимизировать картинки, а также сделать так, чтобы не пришлось переписывать кучу html кода, чтобы эти картинки туда вставить.

MODX 3 приближается к замораживанию функции перед бета-циклом и последующим релизом. Так как нам нужна максимально возможная помощь в тестировании и проверке ключевых проблем и Pull Requests («PRs»), мы создали это учебное пособие по подходу для тех, кто не привык жить в командной строке и работать с git'ом каждый день.

В настоящее время существует более двух десятков PR, которые должны быть объединены перед окончательным альфа-релизом.

Во время альфа версии, вещи, которые нарушают обратную совместимость, являются кандидатами для включения в релиз MODX 3.0. Однако, во время предстоящей бета-версии, больше никаких изменений, нарушающих совместимость, приниматься не будут. Бета-версия предназначена для шлифовки вещей и работы над тем, чтобы как можно больше дополнений работали без рефакторинга. Многие уже работают.

В этой статье я делюсь своим опытом о том, как лучше всего обновить существующие таблицы БД при работе с VESP.

В заметке Знакомимся с Vesp Core описан базовый функционал создания таблиц через миграции. Пока сайт находится в разработке и в таблицах нет ценных данных, можно менять таблицы полностью откатывая все миграции, и запуская их заново. Это отлично работает. Но удаляет все данные из таблиц и для работающего сайта не годится.

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

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

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