Joomla *

Много лет висело без откликов у меня на hh.ru резюме на вакансию «Web-реаниматор старых сайтов» и вдруг прилетела «подработка»…

У небольшой организации занимающейся разработкой очень специфичной техники есть в интернете несколько информационных сайтов на Joomla 3 и уже года 4 без каких-либо изменений, и, соответственно без необходимости иметь сотрудника для их поддержки.
И что примечательно, у этих сайтов в среднем около 1 посещения в неделю..

Но месяц назад на двух сайтах вдруг появились вместо заглавных страниц сообщения «Взломан CoupDeGrace» и «Взломан ANTONKILL».
Так у меня появилась хоть какая-то работа за последние 4 года.
Убрать заставки взломщиков оказалось достаточно просто, сложнее перекрыть дальнейшие возможности для подобных хулиганств – не представляю как удалить из работающего сайта модули Helix и Sppagebuilder, через которые происходит основной вход «хулиганов»… частично их «деактивировал».  Но наверняка есть и другие способы, про которые я тогда не знал.
Обновлять Joomla до актуальной версии занятие долгое и непредсказуемое, а потому один сайт остался жить просто почищенным от заставок «Взломан …», а их там оказалось несколько десятков, а другой достаточно быстро перелопачен в статичные html страницы.
Первый этап «реанимации» закончен и очень постепенно начался второй – поиск нового движка для сайтов. Желательно отечественного производства, с активной поддержкой, чётким MVC, а ещё и бесплатным… в общем – проблематичные условия, но несколько кандидатов нашлось, и даже лидер образовался с самым маленьким количеством проблем на входе.

Но опять возникло «НО»!
Тот сайт, что остался крутиться на Joomla был заселён несколькими бэкдорами и это обнаружилось совершенно случайно только потому, что развили очень активную деятельность и буквально подвесили виртуальный сервер с очень скромными ресурсами.

За прошедшие выходные я понял, что мои возможности уже сильно устарели и резюме на вакансию «Web-реаниматор» надо бы убрать…
Мало того, что «искусство обфусцирования» вышло за уровни моего понимания, но как можно перехватывать пересылаемый по ftp на сайт index.php и класть его в корень с уже вписанным «вирусом» - мне уже видимо не осознать.

В прошлом году на секции «Слабое звено ИБ» один выступающий рассказал о своём эксперименте по «взлому» - всего $10 долларов на оплату токенов и ВСЁ!
Про миллион за взлом «белым хакерам» можно забыть – нейросети обесценили труд этих специалистов на несколько порядков.

Любая известная и популярная CMS со средствами «web-администрирования» и самообновления уже имеет в себе «парадные ворота» для взлома и заселения всем чем захочется.

На мой «устаревший» взгляд, самым эффективным вариантом решения проблемы для подобных информационных сайтов, мне видится CMS с полным функционалом по управлению сайтом на локальном компьютере, а в «публичное пространство» выгружаются только html страницы. И только 555 для папок и 444 для файлов.

А может не всё так грустно?
Может есть уже простые решения, про которые всем кроме меня всё давно известно?

Переопределение макета НЕ в шаблоне Joomla.

Мы все знаем, что при работе с сайтом создание своих переопределений стандартных макетов — это типовая, стандартная работа. Она позволяет сделать из материалов, контактов почти всё, что угодно.

И так же мы знаем, что по классике эти переопределения кладутся в папку html активного шаблона Joomla (не важно, для админки или для пользовательской части).
Макет blog.php и blog.xml к нему из JPATH_SITE/components/com_content/tmpl/category/ мы помещаем в templates/<ВАШ_ШАБЛОН>/html/com_content/category и творим там всё, что захотим:

• любая вёрстка в blog.php и субмакетах

• любое название для типа пункта меню (гаражи, дачи, самолёты — каталог чего вы делаете на материалах) — в blog.xml (или samolet.php + samolet.xml).

• любые дополнительные параметры для пункта меню на этот тип — добавьте нужные кнопки и инпуты в blog.xml

Да, это всё классика. Удобно то, что мы создаём нужный нам тип пункта меню таким образом и можем выбрать его в админке: список самолётов, список гаражей.

Если наше переопределение лежит в шаблоне, то URL при создании пункта меню будет вида index.php?option=com_content&view=category&layout=yourtemplate:samolet.

Именно так, через двоеточие: layout=yourtemplate:samolet. Joomla будет знать, что нужно залезть в нужный шаблон и взять нужное переопределение. Если мы НЕ создаём свой тип пункта меню таким образом, а просто переопределяем — то всё ок.

❓ А что будет с сайтом, если мы переключили шаблон на другой?

На старых долгоживущих проектах нередко структура пунктов меню большая и запутанная. Если мы сделали новый шаблон сайта и переключили его в админке — у нас послетают все наши переопределения. И они не будут работать до тех пор, пока мы не прощёлкаем все пункты меню и не пересохраним их. Так, чтобы в их url теперь был new-template:samolet в параметре layout.

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

Если макет лежит в папке с модулем.

• Он работает

• Его можно переопределить в шаблон (хотя зачем, это же наш макет)

• Он не изменится при смене шаблона

• ⛔️ Минус — неудобно в работе, когда все макеты разложены по своим модулям и нужно прыгать по папкам в проекте

Макеты лежат в папке html шаблона.

• всё рядышком

• типовой подход Joomla (хотя и предыдущий тоже типовой)

• удобно для типовых шаблонов — сделал комплект переопределений в своём шаблоне и таскаешь из проекта в проект

• ⛔️ неудобно, когда впереди большая работа по смене шаблона и нельзя, чтобы сразу послетало всё из‑за смены шаблона.

Я решил провести мини‑эксперимент, в целом заранее зная его результат: положить «переопределение» материала не в html/com_content шаблона, а в папку с компонентом. Точь‑в-точь как с модулями.

Оно работает. Мы создаём собственный тип вывода контента, не привязанный к конкретному шаблону. URL нашего пункта меню будет без двоеточия и имени шаблона. Просто index.php?option=com_content&view=category&layout=samolet.

И знаете, это повод задуматься о применении этой возможности, хотя раньше я бы первым закричал: «Вы что‑о-о?!?! Нельзя‑а-а!»

Когда у нас проект, где:

• не сложная структура

• переопределения макетов в шаблоне делаются один раз на несколько лет.

• их (переопределений и новых типов пунктов меню) МАЛО...

..здесь положить всё в шаблон сам Бог велел.

Когда же:

• сложная структура меню

• в ней много разных ТИПОВ пунктов меню

• и все они норовят зависеть от шаблона...

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

Риски есть — когда‑нибудь кто‑нибудь добавит в ядро файл с совпадающим именем. Но это решается брендированным префиксом в именах файлов.

При обновлении эти файлы не затираются — проверил сценарий обновления.

🤔 В общем, это скорее философские вопросы о разграничении ответственности и кто эту ответственность на себя берёт, кто это будет поддерживать, документировать и следить за тем, чтобы практике проекта следовали коллеги.

Совет по Joomla: Как сделать ссылки на списки сущностей Joomla с фильтрацией?

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

Например:

• разработчик хочет дать ссылку на плагин для быстрого перехода к настройкам;

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

Админка Joomla поддерживает фильтры в URL-адресе, а названия GET-параметров для фильтрации можно посмотреть в названиях полей фильтров админки.

Например, в списке плагинов поле фильтра:

• выбор состояния - filter[enabled]=1 или 0

• выбор типа (группа плагинов) - filter[folder]={название группы плагина, например content или system}

• element плагина (уникальное систеное имя) - filter[element]={element}

• уровень доступа, с которым работает плагин - filter[access]={числовой-код-уровня-доступа}

• строка поиска - filter[search]={любой%20текст%20для%20поиска}

Таким образом, чтобы дать ссылку на свой плагин в админке можно сделать следующий url:

https://your-joomla-site.ru/administrator/index.php?option=com_plugins&view=plugins&filter[element]=wtotpravkapochtaru&filter[folder]=system

Аналогичным образом работает список модулей, контактов, материалов и т.д. Найти имена параметров можно либо в HTML-коде страницы, либо в XML-форме опций фильтра нужного компонента. Для списка плагинов используется компонент com_plugins, а форма фильтра лежит в administrator/components/com_plugins/forms/filter_plugins.xml. Для списка материалов Joomla - в administrator/components/com_content/forms/filter_articles.xml. Другие компоненты - ищем по анналогии.

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

WT Max v.0.2.0. - библиотека для интеграции с Joomla

Обновление Joomla-библиотеки для API мессенджера MAX с системным плагином для настроек и диагностики подключения. Библиотека предназначена для разработчиков.

Расширение является Joomla-обёрткой над самостоятельным PHP Composer-пакетом Webtolk\Max, у которого так же состоялся релиз 0.2.0. PHP SDK разрабатывалось с учётом стандартов PSR и полностью не зависит от какого-либо фреймворка и/или пакета.

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

• Подключена новая версия API-хоста: platform-api2.max.ru. Для корректной работы ваших чат-ботов и мини-приложений до 19 июля 2026 необходимо перенаправить HTTP-запросы с домена platform-api.max.ru на platform-api2.max.ru, а также добавить сертификат Минцифры в список доверенных. Как это сделать - ссылка на инструкция внизу поста. ‼️Если этого не сделать - вы получите уведомление об ошибке соединения и неверном сертификате.

• Расширена публичная API-поверхность. Обновлены и дополнены методы для работы с чатами и сообщениями (включая новые сценарии по ссылкам на чат и выборке по query-id сообщения). Удалены устаревшие методы.

• Обновлён набор публичных JSON-схем. Добавлены и синхронизированы схемы для новых и изменённых endpoint-ов. Эти схемы - снимки реальных ответов API Max, так как мы прекрасно знаем, что документация и реальное API может отличаться порой очень и очень значительно.

• Обновление документации. README, стартовые руководства, референсы и описания сущностей/пэйлоадов приведены к текущему API-уровню.

Ссылки:

• PHP SDK, Composer-пакет

• Joomla-обёртка WT Max

• Инструкция: Установка сертификатов МинЦифры Российской Федерации на свой сервер.

WT Max библиотека для интеграции с Joomla.

Вышла Joomla-библиотека для API мессенджера MAX с системным плагином для настроек и диагностики подключения. Библиотека предназначена для разработчиков.

Расширение является Joomla-обёрткой над самостоятельным PHP Composer-пакетом Webtolk\Max. PHP SDK разрабатывалось с учётом стандартов PSR и полностью не зависит от какого-либо фреймворка и/или пакета.

Библиотека может использоваться для:

• отправки сообщений через бота в мессенджере Макс с сайта (разного рода уведомления),

• отправки контента с сайта в мессенджер - видео, аудио, картинки

• кнопок-ссылок к сообщениям

• приёма и обработки реакций на эти кнопки

• обработки ответов в чате / личных сообщениях

• работы с пользователями, чатами, статусами “печатает/просмотрено” и т.д.

PHP SDK работает с:

• PHP 8.1+

• любым PSR-18 HTTP-клиентом (Guzzle, Symphony Http client, Joomla HTTP и другие)

• стандартом PSR-17 RequestFactoryInterface и StreamFactoryInterface

• любым PSR-3 логгером

Joomla-библиотека интегрирует в ваш сайт PHP SDK, использующий инструменты ядра Joomla: http клиент, фабрики PSR-17, стандартный PSR-3 логгер из ядра Joomla.

<?php

declare(strict_types=1);

use Webtolk\Wtmax\Wtmax;

defined('_JEXEC') or die;
// В Joomla отдаёт подготовленный объект Webtolk\Max\Max 
// с фабриками, HTTP-клиентом и штатным логгером Joomla
$max = Wtmax::getInstance();

$bot = $max->bots()->me();

echo $bot->getId();
echo $bot->getUsername();

В составе Joomla-библиотеки собирается коллекция полей Joomla Form. В частности сейчас в ней есть стандартное поле выбора чата из списка доступных чатов для бота в Максе в модальном окне (поле ModalSelect).

• PHP SDK, Composer-пакет

• Joomla-обёртка WT Max

WT CDEK library v.1.3.0 - обновление PHP SDK для Joomla + CDEK.

Небольшая нативная PHP Joomla библиотека для работы с API v.2 службы доставки CDEK. Библиотека представляет собой клиент для авторизации в CDEK API по OAuth, работы с некоторыми методами API: получения ряда данных и расчета стоимости доставки. Поддерживается Joomla 4.2.7 и выше.

В пакет входят:

• библиотека Webtolk/Cdekapi

• системный плагин System — WT Cdek для хранения настроек и AJAX‑интеграций

• task‑плагин Task — Update WT Cdek data для обновления локальных копий справочников CDEK по расписанию

• web asset с официальным JavaScript‑виджетом СДЭК

👉 v.1.3.0. Что нового?

• Полный рефакторинг библиотеки. Библиотека переработана в entity‑based API с фасадом Cdek и отдельным слоем запросов. Обратная совместимость не нарушена, поэтому версия библиотеки — 1.3.0.

• Добавлена поддержка новых разделов API СДЭК. Добавлена поддержка новых разделов API СДЭК: webhooks, prealert, печатные формы, payment, passport, reverse, intakes и других сущностей.

• Улучшена интеграция с Joomla. Улучшена интеграция с Joomla: installer script для layouts, новые поля Joomla Form для тарифов и обновлённые js виджета CDEK.

• документация библиотеки. Все методы библиотеки подробно описаны, а так же текст документации собран в отдельной папке в git репозитории.

Пример запроса — запрос информации о городе.

<?php

use Webtolk\Cdekapi\Cdek;

\defined('_JEXEC') or die;

// Вариант 1: брать credentials из настроек плагина
$cdek = new Cdek();

// Вариант 2: передать credentials явно
$cdek = new Cdek(test_mode: true, client_id: 'your_client_id', client_secret: 'your_client_secret');

$result = $cdek->location()->getCities([
    'postal_code' => '410012',
    'city'        => 'Саратов',
    'size'        => 1,
]);

Результат запроса:

Array
(
    [0] => Array
        (
            [code] => 428
            [city_uuid] => 7e54a0b3-76f0-41e2-92e0-f1e600ad84fd
            [city] => Саратов
            [fias_guid] => bf465fda-7834-47d5-986b-ccdb584a85a6
            [country_code] => RU
            [country] => Россия
            [region] => Саратовская область
            [region_code] => 47
            [fias_region_guid] => df594e0e-a935-4664-9d26-0bae13f904fe
            [sub_region] => городской округ Саратов
            [longitude] => 46.034266
            [latitude] => 51.533562
            [time_zone] => Europe/Saratov
            [payment_limit] => -1
        )

)

Библиотека эта нужна для разработчиков, создающих свои расширения для интеграции Joomla и курьерской службы CDEK.

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

GitHub расширения

Валидация полей форм в Joomla 6

У каждого поля в форме Joomla есть поле type, но за валидацию значения отвечает атрибут validate.

Например: number — очевидно что значение должно быть числом.

<field
	name="count"
	type="number"
	label="MOD_ARTICLES_FIELD_COUNT_LABEL"
	description="MOD_ARTICLES_FIELD_COUNT_DESC"
	default="5"
	filter="integer"
	min="0"
	validate="number"
/>

Или UserId — тут сложнее, значение должно быть реальным id сужествующего пользователя.

<field
    name="default_value"
    type="user"
    label="PLG_FIELDS_USER_DEFAULT_VALUE_LABEL"
    validate="UserId"
/>

А в моём компоненте нужна валидация id компании.

Добавляем в поле атрибут validate="CompanyId":

<field
    name="company_id"
    type="text"
    label="COM_WISHBOXBONUSSYSTEM_FIELD_COMPANY_LABEL"
    required="true"
    validate="CompanyId"
/>

Добавляем класс правила (в моём случае по сути копия правила UserId):

<?php
/**
 * @copyright   (c) 2013-2026 Nekrasov Vitaliy <nekrasov_vitaliy@list.ru>
 * @license     GNU General Public License version 2 or later;
 */
namespace Joomla\Component\WishboxBonusSystem\Administrator\Form\Rule;

use Joomla\CMS\Form\Form;
use Joomla\CMS\Form\FormRule;
use Joomla\Database\DatabaseAwareInterface;
use Joomla\Database\DatabaseAwareTrait;
use Joomla\Database\ParameterType;
use Joomla\Registry\Registry;
use SimpleXMLElement;
use function defined;

// phpcs:disable PSR1.Files.SideEffects
defined('_JEXEC') or die;
// phpcs:enable PSR1.Files.SideEffects

/**
 * Form Rule class for the Joomla Platform.
 *
 * @since  1.0.0
 */
class CompanyIdRule extends FormRule implements DatabaseAwareInterface
{
    use DatabaseAwareTrait;

    /**
     * Method to test the validity of a Joomla User.
     *
     * @param   SimpleXMLElement  $element  The SimpleXMLElement object representing the `<field>` tag for the form field object.
     * @param   mixed              $value    The form field value to validate.
     * @param   ?string            $group    The field name group control value. This acts as an array container for the field.
     *                                       For example if the field has name="foo" and the group value is set to "bar" then the
     *                                       full field name would end up being "bar[foo]".
     * @param   ?Registry          $input    An optional Registry object with the entire data set to validate against the entire form.
     * @param   ?Form              $form     The form object for which the field is being tested.
     *
     * @return  boolean  True if the value is valid, false otherwise.
     *
     * @since   1.0.0
     *
     * @noinspection PhpMissingReturnTypeInspection
     */
    public function test(SimpleXMLElement $element, $value, $group = null, ?Registry $input = null, ?Form $form = null)
    {
        // Check if the field is required.
        $required = ((string) $element['required'] === 'true' || (string) $element['required'] === 'required');

        // If the value is empty, null or has the value 0 and the field is not required return true else return false
        if (($value === '' || $value === null || (string) $value === '0')) {
            return !$required;
        }

        // Get the database object and a new query object.
        $db    = $this->getDatabase();
        $query = $db->createQuery();

        // Build the query.
        $query->select('COUNT(*)')
            ->from($db->qn('#__wishboxbonussystem_companies'))
            ->where($db->qn('id') . ' = :companyId')
            ->bind(':companyId', $value, ParameterType::INTEGER);

        // Set and query the database.
        return (bool) $db->setQuery($query)->loadResult();
    }
}

И в модели нашей сущности (в моём случае OperationModel) подключаем префикс класса:

	public function getForm($data = [], $loadData = true)
	{
		FormHelper::addRulePrefix("\\Joomla\\Component\\WishboxBonusSystem\\Administrator\\Form\\Rule");

		return parent::getForm($data, $loadData);
	}

Особенность Joomla: json-значения для пользовательских полей и их рендер в subform и вне дочерней формы.

Опять длинное название, но куда уж без этого...

Итак, если вы делаете плагин пользовательского поля - его можно использовать через FieldsHelper. И в процессе ваши данные проходят через различные этапы обработки (недавно была статья на эту тему). И может так оказаться, что ваше поле хранит в rawvalue json (и в базе данных соответственно тоже), а в value вы на его основе рендерите значение. Это стандартный подход Joomla. Так работают, например, поля accessiblemedia. Однако, если вы поместили ваше поле в дочернюю форму (пользовательское поле типа subform и включили "Рендеринг значений = Да", то у вашего замечательного поля может появиться поломанный Json в value вместо нормального значения.

Например:

{"basePath":"...","layout":"..."}

❓ Что там под капотом Joomla происходит?

1. В обычном потоке Joomla сначала вызывает событие onCustomFieldsBeforePrepareField, а потом onCustomFieldsPrepareField.

2. Внутри subform же для подполей при render_values=1 вызывается только событие - onCustomFieldsPrepareField.

3. Если преобразование значения (например, json_decode) сделано в вашем плагине только в beforePrepareField, оно не обработает данные для подполя и...

4. В шаблоне поля строка заэкранируется (htmlentities), кавычки превратятся в тыкву в " и вы получите кривой json, вместо вашего значения.

👉 Собственно полезный совет по Joomla:

Для полей, которые могут жить внутри subform, делайте нормализацию значения и в onCustomFieldsPrepareField тоже, не только в beforePrepareField.

Спустя почти год работы мой 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-сообщества

Как тестировать 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

WT IndexNow плагин для Joomla - отправка страниц сайта на переиндексацию в поисковые системы.

Пакет плагинов, обеспечивающий ручную и автоматическую отправку url адресов Joomla в поисковые системы на переиндексацию по протоколу IndexNow.

Согласно документации протокол поддерживают все крупнейшие поисковые системы, кроме Google. Протокол служит для получения от сайтов URL, которые нужно переиндексировать заново или проиндексировать в первый раз как можно быстрее. Отправка адресов сайта таким образом существенно ускорит индексацию нового или изменённого контента поисковыми системами.

Поисковые системы по этому протоколу обмениваются друг с другом данными, поэтому отправив URL в одну из них вы сообщаете их сразу всем.

Протокол IndexNow поддерживают:

• Amazon

• Microsoft Bing

• Naver

• Seznam.cz

• Yandex

• Yep

Суточный лимит URL - 10000 в сутки. Возможна отправка вручную и автоматически. Пакетом поддерживаются:

• материалы и категории материалов Joomla

• контакты и категории контактов Joomla

• SW JProjects - компонент каталога расширений для Joomla

• JoomShopping - компонент интернет-магазина для Joomla

• Phoca Download - компонент каталога файлоа для Joomla

• Phoca Cart - компонент интернет-магазина для Joomla

• RadicalMart - компонент интернет-магазина для Joomla

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

Пакет плагинов работает с Joomla 4.3+. Тестировался на Joomla 5 и Joomla 6.

Ссылки:

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

GitHub расширения

Раздел Поддержка протокола IndexNow в справке Яндекса

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

Метод 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.

[ВИДЕО] AmoCRM + Joomla: быстрая настройка интеграции. Библиотека WT AmoCRM.

- Как быстро настроить интеграцию AmoCRM и сайта на Joomla?

- использовать PHP библиотеку WT AmoCRM для Joomla, которая предполагает использование её разработчиками. А разработчики могут написать любое количество плагинов и решений по интеграции и автоматизации AmoCRM и Joomla.

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

• Youtube

• Rutube

• VK Видео

Содержание:

• 00:15 - что такое эта библиотека и как она работает? Тех.ликбез.

• 03:00 - установка с сайта или с GitHub

• 04:00 - собственно установка и настройка интеграции.

• 05:10 - создание внешней интеграции в интерфейсе AmoCRM

• 08:05 - что-то пошло не так... Почему и как исправить (случай с пересозданием интеграции)

• 08:48 - успешное подключение к AmoCRM

• 11:11 - как понять что всё работает?

• 11:50 - демонстрация работы: отправка заказа из компонента интернет-магазина RadicalMart в AmoCRM

• 14:20 - потенциальные возможности по автоматизации бизнес-процессов в связке Joomla с AmoCRM

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

Скачать с GitHub

Есть ряд готовых решений для интеграции:

• JoomShopping - Joomla компонент интернет-магазина

• RadicalMart - Joomla компонент интернет-магазина

• RadicalForm - Joomla плагин формы обратной связи

Человек на 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-сообщества.

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: значение переменной по умолчанию с помощью класса Joomla\Registry\Registry.

Очень часто в Joomla мы видим, что данные приходят не в виде массива или простого объекта (stdClass), а их нужно получать с помощью метода get(). Например, в плагине или модуле:

 $option = $this->params->get('my_option');

Это означает, что мы получили данные в виде объекта Joomla\Registry\Registry.

❓ Зачем это?

Возможность указать значение переменной по умолчанию. Лично для меня первое и самое важное - это возможность указать значение переменной по умолчанию, если его (значения) в параметрах нет.

Вы выпускаете новую версию своего мега-плагина и вводите в него новую опцию my_option. Мы используем её везде в PHP коде. Однако, мы же понимаем, что люди обновятся, а обновлять настройки плагина не полезут. Не полезут до тех пор, пока не станет любопытно "а что же там нового?" или что-нибудь не отвалится. И пока они не установят новый параметр и не сохранят настройки плагина - в коде он так и не появится.

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

 $myOption = $this->params->get('my_option', 'default_value_if_null_or_not_exists'); // string по умолчанию

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