CMS *

Как понять, что ваш интернет-магазин вот-вот сломается: триггеры и решения для сайтов на Magento

Привет! Это Дмитрий Абакумов magento-разработчик в Далее, и Максим Бровко, тимлид в Далее.

Мы собрали 5 типичных симптомов, которые сигнализируют, что система уже нестабильна — на примере Magento, популярной CMS в сфере e-com.

В первую очередь скажем, что на Magento работают крупные бренды по всему миру. Она гибкая, масштабируемая, с богатой экосистемой. Однако без регулярных обновлений, контроля и DevOps-поддержки любой проект начинает замедляться, сбоить, а со временем — ломаться. Сигналы появляются заранее: сначала падает скорость, потом checkout, потом весь сайт.

Сигнал 1: падение скорости при большом трафике — во время акций и распродаж

Что проверить

• Узкие места в БД: тяжелые SELECT, отсутствие индексов.

• Дублирующиеся или вложенные вызовы блоков в Magento layout.

• Как ведет себя cron и очередь задач.

• Используется ли Varnish для FPC и/или Redis для общего кеша.

Как чинить

1. Настроить загрузку тяжелых блоков после рендера страницы — через AJAX.

2. Внедрить нагрузочное тестирование — k6, Siege, JMeter.

3. Перенастроить кеш Magento, включить компиляцию DI.

4. Заложить горизонтальное масштабирование или CDN.

Сигнал 2: долгая загрузка интернет-магазина при обычной посещаемости (более 3 секунд)

Что проверить

• Логи Magento и серверов: timeouts, ошибки, блокировки.

• Скорость отклика API.

• Время сборки layout и количество подключаемых блоков.

Как чинить

1. Проанализировать профилировку — Xdebug, New Relic.

2. Отключить неиспользуемые плагины и модули.

3. Настроить мониторинг производительности и ошибок — New Relic, Grafana, Prometheus.

Сигнал 3: Клиенты доходят до оформления, но не покупают — особенно на мобильных устройствах

Что проверить

• Как работает checkout: отрисовка, JS, блоки, сторонние виджеты доставки/оплаты.

• Как отрабатывает кнопка «Оформить заказ» — все ли проходит быстро.

• Нет ли тяжелых или повторяющихся вызовов.

Как чинить

1. Кешировать доступные блоки внутри checkout.

2. Упростить форму и ускорить ввод данных — DaData.

3. Включить асинхронную обработку заказов, если оформление занимает много времени.

4. Протестировать на реальных устройствах и подключить фронтовый логгер — Sentry.

Сигнал 4: когда починили один баг — появился другой 

Что проверить

• Архитектуру модулей: tight coupling, перезапись классов, обилие around-плагинов.

• Есть ли автотесты, CI.

• Как внедряются хотфиксы.

Как чинить

1. Минимизировать around-плагины и preference (перезаписей классов), отдавать предпочтение before/after-плагинам и observer.

2. Покрывать фиксы хотя бы базовыми unit/integration-тестами.

3. Настроить dev → stage → prod, релизный процесс с changelog.

4. Ввести code style, практику ревью и договоренности внутри команды.

Сигнал 5: CMS или модули устарели, все «на костылях» и никто не решается трогать

Что проверить

• Версии ядра Magento и зависимостей.

• Нет ли deprecated-библиотек, особенно JS.

• Насколько кастомно переопределены шаблоны и классы.

• Есть ли onboarding-документация, описание архитектуры, миграций, cron.

Как чинить

1. Если кастомный код внесен прямо в ядро Magento, то его нужно вынести в отдельные модули.

2. Сравнить архитектуру с best practices Magento и рекомендациями вендоров.

3. Написать README и настроить автоматизацию — Docker, Ansible.

4. Запланировать регулярные апдейты проекта.

Если у вас совпадают 3+ пункта — пора на техаудит

Magento почти всегда подает сигналы заранее: снижается скорость, растет количество багов, страдает checkout. Если таких симптомов становится много — пора остановиться и разобраться, что происходит внутри.

Что делать

• Использовать метрики: PageSpeed, TTFB, логи ошибок.

• Провести аудит: кеш, модули, layout, архитектура, DevOps.

• Найти узкие места и критичные зависимости.

• Выделить приоритеты по улучшениям и составить roadmap по рефакторингу.

Спустя почти год работы мой PR приняли в ядро Joomla!

[Тут должна быть победная пляска] Год назад у моих клиентов возникла необходимость во вставке видео в кастомные поля материалов в раздел портфолио. Я начал делать и увидел, что именно стандартное пользовательское поле Media не умеет вставлять в поле ничего, кроме изображений, хотя поле Joomla Form MediaField умеет выбирать и документы (pdf и иже), аудио, видео и даже папки. Я начал работу над тем, чтобы добавить этот функционал  в ядро и очень надеялся успеть к Joomla 5.3, которая выходила в апреле. В целом все сделал, сделал PR 25 февраля 2025 года, но PR не приняли, сказав, что это шибко новый функционал и ему будет хорошо в Joomla 6.0.0. Клиентам пришлось использовать  медиа-менеджер от JCE, а PR отправился ждать релиза 6.0.0, который выходил осенью. К слову сказать, эта пауза была полезна для него, так как летом, уже неспешно я получал советы по улучшению и в июле всё точно было готово.

Релизный цикл Joomla состоит из нескольких этапов: сначала выходят alpha-версии (до 3х штук), где просто фиксируются накопленные изменения, потом beta, где наступает feature freeze - заморозка новых функций, их нельзя уже добавлять. Дальше только отладка и правки  существующих новшеств. У каждого релиза есть 2 релиз-менеджера.

В работе над PR мне помогал все это время Брайан Тиман - ко-фаундер Joomla. К концу июля все было готово, проверено, PR имел 2 необходимых независимых теста. Ждём беты.

Дата беты приходилась на понедельник. Где-то в пятницу днём я отписался в PR и получил совет написать релиз+менеджерам. Как-то удалось найти их в Mattermost, где обитает международное сообщество, но пятница и выходные, а все ж волонтеры и не на зарплате... Моё сообщение прочитали после релиза беты... Сказали, что не были в курсе моего PR (ожидаемо, их около 200-250 все время открытых). И сказали, что поезд ушёл, хоть и so sorry. Зато будет хорошо увидеть PR на тестах в Pizza, Bugz and Fun и вообще welcome в 6.1.

После выхода 6.0.0 меняются релиз-менеджеры. Мы списались: да, все хорошо, но нужно кое-что подправить. Тут конец года и закрытие дедлайнов, потом Новый год и весь январь никто толком не работает. Beta для 6.1 выходит 17 февраля. Последняя alpha  недели за 3 до этого.

Незадолго до выхода альфы я-таки получаю сообщение, что реализуемый функционал сделан не по "Joomla way" и если код в ядре, то этот код является учебным пособием по тому, как ядро использовать. Резонно. А ещё у релиз-менеджера есть собственные наработки и экспертиза в этой теме и свой медиа-менеджер, в котором он тоже прошел огонь, воду и медные трубы. Согласно Joomla way мне нужно было разделить одно мега-крутое поле на 4 отдельных (картинки, аудио, видео и документы). Я подумал, что требуется сделать 4 плагина вместо одного и сказал, что не успею. Мне ответили, что beta is more important for us и время ещё есть, что мне подскажут и 4 плагина делать не нужно.

Пока суть да дело - время идёт. У меня тоже работа, трое детей, карантины, уроки... Но добить этот PR уже стало делом принципа. Я  нашел как нужно было делать, принял несколько правок и пожеланий, потом фиксы code style. Сегодня с утра был последний коммит. Сегодня вечером, 11 февраля 2026 года, PR наконец-то смержен в ядро Joomla.

Эта работа научила меня очень многому. 170 комментариев в conversation на GitHub, несколько отдельных переписок, 1 год на разработку и внедрение простой в целом фичи, "звоночек" в голове: "не забыть, успеть, сделать, найти"...

Сегодня я поднимаю кружку пенного за этот небольшой  в целом PR, за этот прошедший год, за Joomla и за Open Source.

https://github.com/joomla/joomla-cms/pull/45013

#joomla #cms #opensource #community #webdev

P.S. Фото с пивом сюда выставлять не буду, но представьте, что оно тут есть.

Событие Pizza, Bugs & Fun - 29-30 января 2026 года.

Уже несколько лет в мире Joomla проводятся мероприятия "Pizza, Bugs & Fun" (#PBF), где каждый может посвятить несколько часов своего мозгового времени тому, чтобы наша любимая CMS стала ближе к идеалу.

Ссылки на видео и статьи из этого поста рассказывает об организационных вопросах, которые пригодятся для участия в PBF, а так же что и как делать. Координация международного сообщества Joomla происходит в Mattermost (присоединиться).

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

Каждый помогает тем, что он умеет:

• кто-то пишет недостающую документацию,

• кто-то пишет код,

• кто-то тестирует как исправлены ошибки или сделан новый функционал.

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

На момент написания данного поста в репозитории Joomla 810 открытых Issue (как правило это баги) и 236 Pull request (PR, исправление багов и новый функционал). Все PR обязательно тестируются минимум двумя участниками сообщества, дабы в конечный код движка не проскочила ошибка.

Если каждый из участников только нашего сообщества сделает даже одно тестирование, то, боюсь, PR и Issue на всех не хватит 😀 И ничего не останется нашим коллегам из международных Joomla-чатов.

• Смотреть видео

• Сайт события

• Joomla: как тестировать? Всего 8 минут.

• Как тестировать Joomla PHP-разработчику? Компонент Patch tester. (кстати, не только PHP разработчику)

Чат русскояызчного Joomla-сообщества

DDoS-атаки: почему стандартные решения не спасают и как выстроить эффективную защиту. Интервью ispmanager с GreyWeb

Рады вас приветствовать, дорогие читатели!

Тема противодействия DDoS-атакам остается одной из самых острых и актуальных в сфере IT. Атаки постоянно эволюционируют, становятся более сложными и мощными, заставляя специалистов искать новые, более изощренные методы защиты.

В ispmanager мы регулярно сталкиваемся с вопросами наших пользователей о том, как обезопасить свои серверы и проекты. Именно поэтому мы провели глубокое интервью с ведущими экспертами по кибербезопасности из компании GreyWeb, которые специализируются на профессиональной защите от DDoS.

Что мы обсудили и почему это важно для каждого, кто управляет инфраструктурой:

•  Эволюция угроз: Как меняются DDoS-атаки и почему вчерашние методы защиты сегодня уже неэффективны.

•  Ограничения стандартных решений: Разбор типовых ошибок и мифов, связанных с "базовой" защитой.

•  Комплексные стратегии: Какие подходы и технологии позволяют эффективно отражать даже самые мощные и целевые атаки.

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

•  Подготовка к атаке: Что нужно сделать заранее, чтобы быть готовым к худшему сценарию.

Это интервью — не просто набор теоретических выкладок, а концентрат практического опыта и аналитики от специалистов, которые ежедневно борются с киберугрозами. Если вы системный администратор, DevOps-инженер, разработчик или владелец сервиса, который не понаслышке знает о рисках DDoS, этот материал будет для вас крайне полезен.

Приглашаем к прочтению: ➡️

https://www.ispmanager.ru/news/case-greyweb

Делитесь вашим опытом борьбы с DDoS в комментариях!

Как тестировать Joomla PHP-разработчику? Компонент Patch tester.

Joomla - open source PHP-фреймворк с готовой админкой. Его основная разработка ведётся на GitHub. Для того, чтобы международному сообществу разработчиков было удобнее тестировать Pull Requests был создан компонент Patch Tester, который позволяет "накатить" на текущую установку Joomla именно те изменения, которые необходимо протестировать.

На стороне инфраструктуры Joomla для каждого PR собираются готовые пакеты, в которых находится ядро + предложенные изменения. В каждом PR обычно находятся инструкции по тестированию: куда зайти, что нажать, ожидаемый результат. Тестировщики могут предположить дополнительные сценарии, исходя из своего опыта и найти баги, о которых сообщить разработчику. Или не найти, и тогда улучшение или исправление ошибки быстрее войдёт в ядро Joomla.

Напомню, что для того, чтобы PR вошёл в ядро Joomla нужны минимум 2 положительных теста от 2 участников сообщества, кроме автора.

Компонент на GitHub

Это видео также на:

• Видео на YouTube

• Видео на RuTube

Чат русскоязычного Joomla-сообщества

#joomla #php #webdev #community

Метод registerListeners() в CMSPlugin в плагинах планируется удалить в Joomla 7.0.

Этот метод регистрирует устаревшие слушатели событий в диспетчере, имитируя работу плагинов Joomla! 3.x и ниже для Joomla 4+. По умолчанию этот метод ищет все общедоступные методы, название которых начинается с on. Он регистрирует лямбда-функции (замыкания), которые пытаются преобразовать аргументы отправленного события в аргументы вызова метода и вызвать ваш метод on<Нечто>. Результат передаётся обратно событию в его аргумент result.

Теперь этот слой совместимости с устаревшей Joomla 3 помечен к удалению в Joomla 7.0, которая должна выйти осенью 2027 года. Это означает, что те уникальные расширения от Joomla 2.5 / Joomla 3, которые ещё работали на Joomla 4-6 скорее всего окончательно перестанут работать на Joomla 7. Предполагается, что активные разработчики планомерно и постепенно избавляются от технического долга и обновляют свои расширения 😎

Чат русскоязычного Joomla-сообщества.

Совет по Joomla: использовать выключенное состояние для кнопок в списках элементов админки - listCheck().

Мы добавляем в тулбар панели администратора Joomla некую кнопку, которая что-то делает со списком id выделенных элементов и ajax-запросом отсылаем их в свой плагин. Но нам надо предупредить нажатия на кнопку в тех случаях, когда ни один элемент не был выбран. Для этого можно написать свою проверку на js. А можно воспользоваться встроенной в Joomla.

Добавить кнопку в тулбар Joomla 6.

use Joomla\CMS\Toolbar\Button\BasicButton;
use Joomla\CMS\Language\Text;

// ниже по коду, где-нибудь в плагине на onAfterDispatch()
// Предварительно проверяем в каком компоненте мы находимся по option из $app->getInput()
// пример из плагина, поэтому $this->getApplication()
$app = $this->getApplication();
// Берём текущий тулбар
$toolbar = $app->getDocument()->getToolbar('toolbar');

// Создаём кнопку
$button = (new BasicButton('send-to-indexnow'))
    ->text(Text::_('PLG_WTINDEXNOWSWJPROJECTS_BUTTON_LABEL'))
    ->icon('fa-solid fa-arrow-up-right-dots')
    ->onclick("window.wtindexnowswjprojects()");

// Добавляем кнопку в тулбар
$toolbar->appendButton($button);

Заблокировать кнопку тулбара Joomla, если не выбраны элементы списка.

Теперь нам надо проверить находимся ли мы в списке. Делаем это по view из $app->getInput().

if(in_array($app->getApplication()->getInput()->get('view'),
            ['categories','documentation','projects','versions'])
  ) {
        $button->listCheck(true);
}

И если мы в списке - используем метод $button->listCheck(true), который сделает проверку за нас. Если ни один элемент не выбран - кнопка в тулбаре Joomla будет заблокирована и JS-обработчик не будет вызван. Этот метод есть у всех классов кнопок, наследующих класс \Joomla\CMS\Toolbar\ToolbarButton.

Человек на GitHub ускорил Joomla в 600 раз на объёме 150к+ материалов в 1700+ категориях.

На старте его сайт на Joomla 3 вообще не смог обновиться на Joomla 5. Пришлось делать экспорт/импорт материалов. Проделав всё это он запустил-таки этот объём данных на Joomla 5. Тестовый скрипт грузил 200 материалов из этого объёма всего за 94 секунды ))) А главная страница с категориями грузилась 20 секунд.

Добавив индекс для таблицы #__content

CREATE INDEX idx_catid_state ON #__content (catid, state);

он сократил время загрузки категорий до 1 секунды. Затем наш герой решил поковырять SQL-запрос в ArticleModel, который отвечает за выборку материалов. И решил заменить тип JOIN на STRAIGHT_JOIN для категорий.

// ->from($db->quoteName('#__content', 'a'))
->from(
    $db->quoteName('#__content', 'a')
    . ' STRAIGHT_JOIN ' . $db->quoteName('#__categories', 'c')
    . ' ON ' . $db->quoteName('c.id') . ' = ' . $db->quoteName('a.catid')
)
// ->join('LEFT', $db->quoteName('#__categories', 'c'), $db->quoteName('c.id') . ' = ' . $db->quoteName('a.catid'))

Что сократило загрузку 200 материалов из 150к с 94 секунд до 5. К слову сказать, боевой сайт на Joomla 3 крутится на 12CPU 64GB рамы. А все манипуляции с кодом он делает на базовом 1CPU 1GB сервере и замеры скорости даны именно для базового сервера.

Но это всё в дискуссии, хотя в идеале должно вылиться в Pull Requests. Дальнейшие его изыскания и результаты можно поглядеть в дискуссии на GitHub. Это ещё не конец.

Мы - Open Source сообщество, где никто никому ничего не должен. Джунгли. Но человек ищет пути оптимизации Joomla и предлагает решения. Если оказать поддержку и предложить помощь хотя бы с тестированием самых разнообразных сценариев, то возможно эти улучшения смогут войти в ядро. Пусть не быстро, пусть через несколько лет, пусть не все, но войдут. Достаточно предложить руку помощи и приложить немного усилий.

Дискуссию на GitHub можно почитать здесь.

Обработка HTTP ответа в Joomla 6+. Изменения по сравнению с Joomla 3 - Joomla 5.

В Joomla для выполнения внешних запросов из PHP к сторонним API используется класс Joomla\Http\Http напрямую или же Joomla\Http\HttpFactory, который возвращает для работы преднастроенный по умолчанию класс Http. О работе с HTTP-запросами подробно рассказывалось в статье 2021 года Создание внешних запросов с использованием HttpFactory (Joomla) (на Хабре), (на сайте автора). Некоторые изменения касаются работы с ответами на запросы. Например, наш запрос:

use Joomla\Http\HttpFactory;

$http = (new HttpFactory)->getHttp($options, ['curl', 'stream']);
$response = $http->get('https://any-url.ru/api/any/endpoint');

Раньше можно было получить код ответа или тело ответа как свойство $response - $response->code или $response->body. Однако, Joomla, начиная с Joomla 4 во многом переходит на стандарты PSR. В частности для работы с HTTP-ответами - на PSR-7. Также хорошая статья на Хабре о PSR-7: PSR-7 в примерах.

Прямое обращение к свойствам code, headers, body объявлено устаревшим в Joomla 6.0.0 и обещают удалить в Joomla 7.0.0.

Вместо этого нужно работать с HTTP-ответом по стандартам PSR-7.

Код ответа.
Было $response->getContents(). Стало $response->getStatusCode().

Заголовки ответа.

Было $response->headers. Стало $response->getHeaders().

Тело ответа.

Было $response->body. Стало (string)$response->getContents().

В тело ответа теперь приходит не строка, а поток - объект класса Laminas\Diactoros\Stream. Поэтому его нужно привести к строке (если это json, к примеру): (string)$response->getContents(). Чаще всего в коде Joomla встречается именно такой вариант. Однако, есть и вариант с перемещением указателя чтения на начало потока:

// Получили ответ в виде потока
$stream = $response->getBody();
// "перемотали" на начало
$stream->rewind();
// Получили строковый ответ
$json = $stream->getContents();

В итоге результат одинаковый.

Telegram чат русскоязычного Joomla-сообщества.

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

Если вы ищете надёжный движок для сайта, защищённую CMS или систему управления с повышенной безопасностью, HyperFlow 1.2 — это решение, которому можно доверять.

https://hyper-flow.ru/news/info/hyperflow-12-novaya-versiya-bezopasnogo-dvizhka-saytov

Joomla 6: Автоматические обновления ядра в Joomla.

В октябрьском номере официального журнала Joomla - Joomla Community Magazine вышла статья David Jardin, где рассказывается о внедрении функционала автоматического обновления ядра Joomla.

❓ Почему сейчас? Joomla же жила как-то 20 лет без автоматических обновлений?

Это оказалась самая востребованная за последнее время от пользователей Joomla функция. Но, основная причина внедрения - проблемы безопасности.

Всякий раз, когда в новой версии Joomla устраняется уязвимость, злоумышленники начинают анализировать код, чтобы выяснить, какая именно уязвимость была исправлена. И как только они это выясняют - начинается разработка автоматизированных скриптов для взлома как можно большего количества сайтов. Затем доступы к автоматически взломанным сайтам продаются в профильных чатах и ресурсах "пачками" по несколько сотен тысяч или миллионов сайтов. Ваш сайт могли взломать несколько лет назад, но воспользоваться уязвимостью могут не сразу, а тогда, когда у злоумышленников возникнет необходимость. И только после этого вы может быть узнаете об этом.

Анализ патча, понимание проблемы и разработка скрипта требуют времени. И если владелец сайта не обновит его до истечения этого срока, сайт может быть взломан. А хакеры действуют быстро! Для критических, легко эксплуатируемых уязвимостей речь идёт о временном окне в 10–12 часов — и этого времени явно недостаточно, чтобы все успели обновить свои сайты.

Здесь выходят на первый план автоматизированные обновления: проект Joomla теперь может активно устанавливать обновления (и, следовательно, исправления безопасности) на сайты, чтобы гарантировать, что сайты действительно обновляются вовремя.

От первых идей до реализации прошло 5 лет. И здесь можно вспомнить, как в Joomla 5.1 внедрили TUF - The Update Framework, позволяющий устанавливать защищённое соединение между сайтом и сервером обновлений и исключает возможность supply chain attack (атаки на цепочку поставок).

Об особенностях реализации и требованиях к сайту читаем подробнее в статье на JCM.

Как триггерить события для плагинов на манер Joomla 5+?

В Joomla 6 должны удалить метод triggerEvent(), с помощью которого раньше вызывались события для плагинов. Теперь чтобы в своём коде вызвать событие для плагина и получить от него результаты нужно:

• создать объект класса события

• передать в него именованные параметры

use Joomla\CMS\Event\AbstractEvent;
use Joomla\CMS\Factory;
use Joomla\CMS\Plugin\PluginHelper;

// Грузим плагины нужных групп
PluginHelper::importPlugin('system');
// Создаём объект события
$event = AbstractEvent::create('onAfterInitUniverse', [
    'subject' => $this,
    'data'    => $data, // какие-то данные
    'article' => $article, // ещё материал вдовесок
    'product' => $product, // и товаров подвезли
]);
// Триггерим событие
Factory::getApplication()->getDispatcher()->dispatch(
    $event->getName(), // Тут можно строку передать 'onAfterInitUniverse'
    $event
);
// Получаем результаты
// В случае с AbstractEvent это может быть не 'result',
// а что-то ещё - куда сами отдадите данные.
// 2-й аргумент - значение по умолчанию, 
// если не получены результаты
$results = $event->getArgument('result', []);

Плюсы такого подхода - вам не нужно запоминать порядок аргументов и проверять их наличие. Если вы написали свой класс события, то в плагине можно получать аргументы с помощью методов $event->getArticle(), $event->getData(), $event->getProduct() и подобными - реализуете сами под свои нужды.

Если такой класс события написали, то создаёте экземпляр своего класса события и укажите его явно в аргументе eventClass

use Joomla\Component\MyComponent\Administrator\Event\MyCoolEvent;

$event = MyCoolEvent::create('onAfterInitUniverse', [
    'subject'    => $this,
    'eventClass' => MyCoolEvent::class, // ваш класс события
    'data'       => $data, // какие-то данные
    'article'    => $article, // ещё материал вдовесок
    'product'    => $product, // и товаров подвезли
]);

Ожидаемо, что класс вашего события будет расширять AbsractEvent или другие классы событий Joomla.

🙁 Есть неприятный нюанс - нельзя просто так вызывать событие и ничего не передать в аргументы. Аргумент subject обязательный. Но если вы всё-таки не хотите туда ничего передавать - передайте туда пустой stdClass или объект Joomla\registry\Registry.

Чат русскоязычного Joomla-сообщества.

Раскопал интересный тип поля в Joomla - Groupedlist.

В процессе работы над компонентом нужно разделить опции выпадающего списка на группы. Я писал ранее как это сделать просто в коде тут: статья, пост.

Но как сделать такой список для использования в описаниях форм в xml? Первой мыслью было сделать свой тип поля, расширяющий стандартный \Joomla\CMS\Form\Field\ListField. Однако, в ядре Joomla нашёлся уже готовый класс поля для группированных списков \Joomla\CMS\Form\Field\GroupedlistField. Он расширяет напрямую FormField и имеет 2 метода - getGroups() и getInput().

В getInput() вызывается метод getGroups() для получения массивов с группами опций и его можно было спокойно заменить на getcollectLayoutData(), где этой работе самое и место, но это не слишком принципиально. И там и там работа делается. Поэтому нас интересует именно метод getGroups().

Мы создаём свой класс поля, расширяем GroupedlistField. Делаем обязательно свой $type для поля и реализуем метод getGroups(). Всё.

<?php
use Joomla\CMS\Form\Field\GroupedlistField;
use Joomla\CMS\HTML\HTMLHelper;

class ServerschemelistField extends GroupedlistField
{
    // type совпадает с именем файла и класса
    // без суффикса 'Field'
    protected $type = 'Serverschemelist';

    /**
     * Method to get the field options.
     *
     * @return  array  The field option objects.
     *
     * @throws  Exception
     *
     * @since  1.0.0
     */
    protected function getGroups(): array
    {
        // наши группы
        $group1 = [];
        $group2 = [];
        // Собираем первую группу опций
        foreach ($data as $item) {
            $optionattr = [];
            // Атрибуты для <option>
            if ($something_happend) {
                $optionattr['option.attr'] = [
                    'selected' => 'selected',
                    'onclick'  => 'earthQuake()',
                    'showon'   => 'field1:value1000',
                ];
            }

            $group1[] = HTMLHelper::_(
                'select.option',
                $item->option_value,
                $item->option_label_text,
                $optionattr
            );
        }
        // Аналогично собираем $group2
        // ...
        $groups = [
            ['Имя группы 1'] = $group1,
            ['Имя группы 2'] = $group2,
        ];
        // В parent::getGroups() будут значения
        // из xml-описания формы, если они есть.
        // Соединяем их с нашими.
        return array_merge(parent::getGroups(), $groups);
    }
}

WT Yandex map items v.2.1.0 модуль для Joomla.

Выводит материалы Joomla в виде меток на Яндекс.Карты. Используется API 3.0.

v.2.1.0. Что нового?

Сохранение последнего вида карты.
Добавлены новые опции, позволяющие как для одного экземпляра модуля, так и для всех сохранять на устройстве пользователя последний использованный центр (координаты) и масштаб (zoom) карты. Это позволит открыть карту в том же месте после обновления страницы или при повторном открытии браузера.

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

CSS классы для маркеров карты.
Всем маркерам карты добавлен CSS-класс wt-yandex-map-items-marker. Для просмотренных маркеров (по которым кликали) добавляется CSS-класс wt-yandex-map-items-marker-viewed, что позволит выделять просмотренные маркеры с помощью стилей в CSS-файлах вашего шаблона. Также для контейнеров маркеров ymaps на карте добавлены data-атрибуты: data-module-id - id модуля и data-marker-id - id маркера.

Обработка GET-параметров в URL.

Карта может реагировать на GET-параметры в url:

• map[zoom] - устанавливает параметр масштаба.

• map[center_latitude] и map[center_longitude] - широта и долгота центра карты.

• map[marker_id] - id маркера, на котором центрируется карта. Таким образом вы можете создавать ссылку на карту с указанием конкретного маркера, на котором карта сфокусируется после загрузки маркеров. Например, https://site.ru/map?map[marker_id]=18465. Или же ссылку с указанием конкретных координат: https://site.ru/map?map[zoom]=16&map[center_latitude]=51.529706&map[center_longitude]=46.033922

Страница расширения

GitHub расширения

Видео-обзор на Youtube

Видео-обзор на VK Видео

Видео-обзор на Rutube

Совет по Joomla: расположение полей Form в параметрах модулей и плагинов.

Обычно поля настроек модулей и плагинов идут столбиком - сверху вниз. Название поля находится слева, а само поле - справа. В вёрстке админки мы видим div.control-group, в котором находятся label и поле. Посмотрим как можно просто кастомизировать админку.

Название поля НАД полем - parentclass="stack".

Если в XML-манифесте модуля или плагина добавить к полю атрибут parentclass, то мы можем указывать любые CSS-стили для div.control-group. Если указать CSS-класс stack, то название поля встанет над самим полем. Это удобно для больших сабформ - экономится место на экране.

<field type="text"
     name="map_center"
     label="MOD_WTYANDEXMAPITEMS_MAP_CENTER"
     description="MOD_WTYANDEXMAPITEMS_MAP_CENTER_DESC"
     default="51.533562, 46.034266"
     hint="51.533562, 46.034266"
     parentclass="stack"
/>

2 и более полей в ряд в параметрах модуля/плагина - классы span-*

Мы можем 2 или 3 небольших поля поставить рядом (для десктопов). Табы настроек являются grid-сеткой из 4-х колонок. Для поля можно указать ширину в виде количества колонок. Нам нужно в parentclass добавить класс span-*-inline. Допустимы числа от 1 до 4.

span-1-inline - поле будет шириной в 1 колонку сетку. span-4-inline - ширина в 4 колонки, равносильно поведению по умолчанию. Этот код выведет 2 поля в админке в параметрах модуля рядом на десктопах. Поскольку используется также класс stack - название поля будет над самим полем.

<field type="list"
     name="map_zoom"
     label="MOD_WTYANDEXMAPITEMS_MAP_ZOOM"
     default="7"
     parentclass="stack span-2-inline"
     filter="integer">
          <option value="0">0</option>
          <option value="1">1</option>
          <option value="21">21</option>
</field>
<field type="list"
     name="map_type"
     label="MOD_WTYANDEXMAPITEMS_MAP_TYPE"
     parentclass="stack span-2-inline"
     default="scheme">
          <option value="scheme">MOD_WTYANDEXMAPITEMS_MAP_TYPE_MAP</option>
          <option value="satellite">MOD_WTYANDEXMAPITEMS_MAP_TYPE_SATELLITE</option>
</field>

Чат русскоязычного сообщества Joomla

Совет по Joomla: расположение полей Form в параметрах модулей и плагинов.

Обычно поля настроек модулей и плагинов идут столбиком - сверху вниз. Название поля находится слева, а само поле - справа. В вёрстке админки мы видим div.control-group, в котором находятся label и поле. Посмотрим как можно просто кастомизировать админку.

Название поля НАД полем - parentclass="stack".

Если в XML-манифесте модуля или плагина добавить к полю атрибут parentclass, то мы можем указывать любые CSS-стили для div.control-group. Если указать CSS-класс stack, то название поля встанет над самим полем. Это удобно для больших сабформ - экономится место на экране.

<field type="text"
     name="map_center"
     label="MOD_WTYANDEXMAPITEMS_MAP_CENTER"
     description="MOD_WTYANDEXMAPITEMS_MAP_CENTER_DESC"
     default="51.533562, 46.034266"
     hint="51.533562, 46.034266"
     parentclass="stack"
/>

2 и более полей в ряд в параметрах модуля/плагина - классы span-*.

Мы можем 2 или 3 небольших поля поставить рядом (для десктопов). Табы настроек являются grid-сеткой из 4-х колонок. Для поля можно указать ширину в виде количества колонок. Нам нужно в parentclass добавить класс span-*-inline. Допустимы числа от 1 до 4.

• span-1-inline - поле будет шириной в 1 колонку сетку.

• span-4-inline - ширина в 4 колонки, равносильно поведению по умолчанию.

Этот код выведет 2 поля в админке в параметрах модуля рядом на десктопах. Поскольку используется также класс stack - название поля будет над самим полем.

<field type="list"
     name="map_zoom"
     label="MOD_WTYANDEXMAPITEMS_MAP_ZOOM"
     default="7"
     parentclass="stack span-2-inline"
     filter="integer">
          <option value="0">0</option>
          <option value="1">1</option>
          <option value="21">21</option>
</field>
<field type="list"
     name="map_type"
     label="MOD_WTYANDEXMAPITEMS_MAP_TYPE"
     parentclass="stack span-2-inline"
     default="scheme">
          <option value="scheme">MOD_WTYANDEXMAPITEMS_MAP_TYPE_MAP</option>
          <option value="satellite">MOD_WTYANDEXMAPITEMS_MAP_TYPE_SATELLITE</option>
</field>

Joomla: как тестировать? Всего 8 минут.

Над CMS Joomla постоянно ведётся работа: создаётся новый функционал, исправляются ошибки, делаются мелкие правки. Разработка ведётся на GitHub. Изменения оформляются в виде Pull Request (PR). Для того, чтобы изменения могли войти в ядро - их обязательно должны успешно протестировать минимум 2 человека КРОМЕ автора изменений. А помочь с большинством PR можно очень и очень быстро, это не занимает много времени, чему подтверждением служит это видео.

Смотреть видео на YouTube

Смотреть на Vk Video

Смотреть на RuTube

Свои типы полей в Joomla.

Это большая тема, о которой можно говорить очень много. Самое главное, что возможности применения ограничиваются только вашей больной фантазией. Вы строите интерфейс своего модуля или плагина и вам нужно подтянуть данные из сторонней системы (список чего-нибудь по какому-нибудь API), чтобы сохранить выбранный id в Joomla. Или сделать какую-то проверку и в зависимости от неё показать то или иное сообщение пользователю. Для этого подойдут свои пользовательские типы полей.

Интерфейс Joomla по большей части описан в XML-файлах. У каждого из них свои параметры. Некоторые не описаны в документации (manual.joomla.org), поэтому самым любопытным будет полезно заглянуть в собственно файлы фреймворка по пути libraries/src/Form/FormField.php, а так же в libraries/src/Form/Fields. У каждого класса поля перечислены его специфические свойства, которые можно описывать в XML. А в своём типе поля вы можете устанавливать эти значения программно.

В моём модуле WT Quick links под капотом происходят изменения. Теперь для работы (в админке) ему нужен вспомогательный плагин. А в самом модуле нам бы проверить, а не выключен ли он?

В Joomla есть тип поля Note - заметка. Его можно использовать для вывода примечаний.

<field type="note"
     name="your_note_for_user"
     label="Заголовок примечания"
     title="Альтернативный способ для заголовка"
     description="Текст примечания"
     class="col-12 alert alert-info"
     heading="h1"
     close="true"
/>

heading- указывать уровень заголовка. close - позволяет закрыть это примечание.

В классе поля libraries/src/Form/Field/NoteField.php описана логика вывода. И в принципе оно нам подходит для нашей задачи. Но оно будет выводить сообщение всегда, а нам нужно только тогда, когда плагин отключён.

Поэтому берём и создаём свой класс поля, который мы унаследуем от NoteField. Это значит, что у нас в руках будет весь инструментарий стандартного поля Note + то, что мы сами добавим.

В XML-манифест добавляем наше поле:

<field type="systempluginstatus" 
     name="systempluginstatus"
     addfieldprefix="Joomla\Module\Wtquicklinks\Site\Fields"/>

• type - имя файла и класса,

• addfieldprefix - указываем namespace к нашему классу, может быть любой нам нужный

• name - нельзя полю без имени...

Это означает, что Joomla будет использовать класс поля из файла modules/mod_wt_quick_links/src/Fields/SystempluginstatusField.php. А в классе поля будет написано следующее:

<?php
// namespace для атрибута addfieldprefix
namespace Joomla\Module\Wtquicklinks\Site\Fields;
// нельзя напрямую обращаться к этому файлу
defined('_JEXEC') or die;
// подключаем родительский класс для переопределения
use Joomla\CMS\Form\Field\NoteField;
use Joomla\CMS\Language\Text;
use Joomla\CMS\Plugin\PluginHelper;

// имя класса и имя файла точь-в-точь
class SystempluginstatusField extends NoteField
{
     protected $type = 'Systempluginstatus'; // тип поля без "Field" в конце

     protected function getLabel()
          {
               // если плагин не включён
               if(PluginHelper::isEnabled('system','wtquicklinks')) {
                    // меняем свойства родительского класса поля
                    $this->class = 'alert alert-danger w-100';
                    $this->element['label'] = '⚠️ А-а-а-а!';
                    $this->element['description'] = 'Плагин не включён!!';
                    // и просто рендерим его с нашими свойствами
                    return parent::getLabel();
               }
          // А иначе всё хорошо, скрываем поле из виду.
          $this->parentclass = 'd-none';
          return '';
     }
}

Просто и удобно. И людям приятно, что о них позаботились и рассказали почему что-то не работает.

Джентельменский набор расширений Joomla, которые стоят на каждом моём сайте

Сел немного формализовать свои процессы. Получился вот такой список:

• Blank page - компонент пустой страницы. Обычно используем для главной.

• Revars (GitHub) - плагин шорт-кодов для контактов, реквизитов и т.д.

• WT Revars insert (GitHub) - плагин кнопки редактора для вставки шорт-кодов

• RadicalForm (GitHub) - плагин формы обратной связи. Подробная инструкция на сайте. Статья Разработка форм обратной связи для магазинов на Joomla на Хабре как создать форму + примеры кода. Есть интеграции с Б24 и Amo.

• WT Quick links (GitHub) - модуль-конструктор повторяемых элементов

• WT SEO Meta templates - комплект плагинов для автоматического заполнения <title> и meta-description по формуле.

• JL Sitemap (GitHub) - компонент XML-карты сайта

• View logs (GitHub) - просмотр логов Joomla в админке

• WT Eternal admin - плагин автоматического продления сессии в панели администратора.

• Reset Media Version (GitHub) - для верстальщиков: гарантированная загрузка новых версий css и js файлов, а не из кэша браузера.

Установка остальных расширений уже зависят от конкретного проекта.

И так же welcome в чат русского Joomla-сообщества.

Свой класс события для плагинов Joomla. Продолжение.

Продолжение потому, что начало уже было в статье Виталия Некрасова на Хабре.

Кратко.

В Joomla 5+ для событий аргументы упаковываются в собственные классы событий: ContentPrepareEvent, AfterSaveEvent и т.д. Данные из них мы получаем в виде $event->getArgument('argument_name') или [$var, $var2] = array_values($event->getArguments());. Также для разных типов событий могут быть специфичные методы типа $article = $event->getItem(); в ContentPrepareEvent и т.д. И в статье Виталия как раз об этом рассказывается.

А так же рассказывается о методах onGet и onSet. В ядре Joomla в классе \Joomla\CMS\Event\AbstractEvent сказано:

/**
   * Add argument to event.
   * It will use a pre-processing method if one exists. The method has the signature:
   *
   * onSet($value): mixed
   *
   * where:
   *
   * $value  is the value being set by the user
   * It returns the value to return to set in the $arguments array of the event.
   *
   * @param   string  $name   Argument name.
   * @param   mixed   $value  Value.
   *
   * @return  $this
   *
   * @since   4.0.0
   */

Добрался я тоже до своего класса события для плагинов, порылся в ядре и подумал, что onSet... и onGet... методы не обязательно делать (хотя в статье по ссылке об этом не упоминается). Это методы для "предварительных проверок и манипуляций" с данными перед тем, как они будут отданы через getArgument() или get<ArgumentName>. Метод getData() отдаст данные, которые предварительно будут обработаны методом onGetData(). Но обработаны они будут только в том случае, если метод реализован. Если нет, то ничего страшного. Ошибки не будет.😎

Эти методы напоминают своеобразные плагины внутри плагинов. На мой взгляд излишнее усложнение, хотя сеттеры и геттеры должны заниматься по идее только сеттерством и геттерством, а проверку/ приведение типов можно отдать в методы onSet... / onGet....