Joomla *

Класс расширения (Extension) для компонентов Joomla 5

Перевод с английского: Joomla! Programmers Documentation for Joomla 5.2

В ряде случаев Joomla может взаимодействовать с нашим компонентом. Например:

• Роутер Joomla может использовать роутер нашего компонента для анализа и создания ЧПУ-адресов;

• Если наш компонент поддерживает категории, то com_categories будет отображать в представлении категорий сводку по каждой категории, содержащую количество материалов с этой категорией, с разбивкой по статусу публикации;

• Если наш компонент поддерживает пользовательские поля, то com_fields будет вызывать метод getContexts(), чтобы получить типы материалов, к которым можно привязать пользовательские поля;

• Если наш компонент поддерживает мультиязычные связи, то com_associations потребуется знать типы материалов, для которых возможны связи;

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

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

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

А в Joomla 4 это упрощено:

Начиная с Joomla 4, другие компоненты получают доступ к нашему компоненту com_example, вызывая метод:

$extension = $app->bootComponent("com_example");

Затем они могут вызывать необходимые им методы через этот экземпляр класса расширения.

Справка:

Класс расширения (Extension) компонента вы можете найти в административной части компонента. Например, для компонента com_content это файл Root/administrator/components/com_content/src/Extension/ContentComponent.php, для com_example — Root/administrator/components/com_example/src/Extension/ExampleComponent.php

Сразу после создания экземпляра класса расширения компонента код библиотеки Joomla вызовет метод boot вашего класса расширения, передавая дочерний экземпляр Контейнера внедрения зависимостей (Dependency Injection Container):

$extension->boot($container);

По сути, это возможность делать буквально всё, что вам нужно. Например, метод иногда используется для настройки определённых классов, которые будут использоваться с вызовами HtmlHelper::_(). Или же можно сохранить ссылку на ваш дочерний DI-контейнер (который иначе может быть сложно получить).

После первого создания экземпляра вашего компонента Joomla кэширует этот экземпляр. При повторном вызове

$extension = $app->bootComponent("com_example");

Joomla просто возвращает существующий экземпляр вашего класса расширения, вместо повторного создания объекта и вызова метода boot(). Вы даже можете вызвать bootComponent, передав свой компонент, чтобы получить ссылку на свой собственный объект расширения.

Расширения и дочерние контейнеры в Joomla 5

Перевод с английского: Joomla! Programmers Documentation for Joomla 5.2

Всякий раз, когда Joomla загружает расширение, она создает дочерний Dependency Injection Container (далее контейнер), исключительно для использования этого расширения. Это показано на схеме ниже.

Дочерний контейнер содержит указатель на родительский контейнер и функционирует аналогично основному контейнеру, но с некоторыми отличиями:

• При каждом вызове метода set() для этого дочернего контенера пара ключ-значение добавляется в дочерний контейнер;

• При каждом вызове метода get() для этого дочернего контейнера ресурс извлекается из дочернего контейнера, но если он там не найден, то поиск выполняется также в родительском контейнере.

Начиная с версии Joomla 4, разработчики Joomla рекомендуют создателям расширений использовать внедрение зависимостей (dependency injection) для своих расширений, определяя файл services/provider.php. Загрузка расширения теперь выполняется в два этапа, которые обрабатываются внутри файла services/provider.php:

1. Класс расширения регистрируется в дочернем контейнере;

2. Класс расширения извлекается из дочернего контейнера, создавая экземпляр этого класса.

Давайте рассмотрим минимальный пример этого для компонента com_example с пространством имён Mycompany\Component\Example.

use Joomla\CMS\Extension\ComponentInterface;
use Joomla\DI\Container;
use Joomla\DI\ServiceProviderInterface;
use Mycompany\Component\Example\Administrator\Extension\ExampleComponent;
return new class implements ServiceProviderInterface
{
  public function register(Container $container): void
  {
    $container->set(
      ComponentInterface::class,
      function (Container $container)
      {
        $component = new ExampleComponent();
        return $component;
      }
    );
  }
};

Мы видим, что когда Joomla выполняет require этого PHP-файла, возвращается экземпляр класса.

$provider = require $path;  // $path points to the relevant services/provider.php file

Переменная $provider указывает на объект, который является экземпляром этого анонимного класса. Кроме того, класс реализует интерфейс Joomla\DI\ServiceProviderInterface, что, по сути, означает, что он содержит метод register с указанной выше сигнатурой.

Когда Joomla выполняет

if ($provider instanceof ServiceProviderInterface)
{
  $provider->register($container);

будет вызван метод register, который добавит запись в дочерний контейнер с

• key - ComponentInterface::class – это сокращённый способ в PHP указать строку 'Joomla\CMS\Extension\ComponentInterface';

• value - функция, которая возвращает новый экземпляр класса ExampleComponent (основного класса расширения компонента com_example).

$extension = $container->get($type);

Функция выше будет запущена и вернет новый экземпляр ExampleComponent.

Вы можете самостоятельно изучить код Joomla в файле libraries/src/Extension/ExtensionManagerTrait.php и убедиться, что описанный выше шаблон также применяется к модулям и плагинам.

Обратите также внимание на следующую строку в этом файле:

if ($extension instanceof BootableExtensionInterface)
{
  $extension->boot($container);
}

Таким образом, если класс расширения реализует интерфейс BootableExtensionInterface, Joomla немедленно вызовет метод boot() экземпляра расширения, как описано в документации по расширениям.

Почему не следует напрямую обращаться к глобальному контейнеру в Joomla 5

Что общего у нижеперечисленных методов?

• Joomla\CMS\Factory::getCache()

• Joomla\CMS\Factory::getDbo()

• Joomla\CMS\Factory::getMailer()

• Joomla\CMS\Application\AdministratorApplication::getRouter()

• Joomla\CMS\Application\Administrator\ApiApplication::getRouter()

• Joomla\CMS\Toolbar\Toolbar::getInstance()

Они объявлены устаревшими с Joomla 4.x и вместо них предлагается использовать Joomla\CMS\Factory::getContainer()->get('Соответствующий_интерфейс').

Например, вместо Joomla\CMS\Factory::getDbo() — Factory::getContainer()->get(DatabaseInterface::class);

Но давайте посмотрим на описание метода Joomla\CMS\Factory::getContainer():

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

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

Допустимые сценарии использования:

• Статический метод getInstance(), вызывающий сервис из контейнера (пример: Joomla\CMS\Toolbar\Toolbar::getInstance());

• Фронт-контроллер приложения, загружающий и исполняющий класс Joomla (пример: файл cli/joomla.php);

• Получение опциональных зависимостей конструктора во время переходного периода для сохранения обратной совместимости (в этом случае следует добавлять уведомление об устаревании).

Не рекомендуется использовать этот метод как прямую замену статическим вызовам, например заменять Factory::getDbo() на Factory::getContainer()->get(DatabaseInterface::class). Вместо этого код следует рефакторить для использования внедрения зависимостей.

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

Как же внедрять зависимости?

Рассмотрим как это сделано в плагине joomla группы content:

В сервис-провайдере плагина Root/plugins/content/joomla/services/provider.php используются методы setDatabase() и setUserFactory() для установки зависимостей.

$plugin->setDatabase($container->get(DatabaseInterface::class));
$plugin->setUserFactory($container->get(UserFactoryInterface::class));

А в классе расширения плагина plugins/content/joomla/src/Extension/Joomla.php используются методы getDatabase() и getUserFactory(). Аналогично в компонентах.

Мой пример использования:

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

Выводы:

• Сервис-провайдер расширения — единая точка установки зависимостей для своего расширения.

• Событие onAfterExtensionBoot - точка для замены зависимости в любом расширении.

• Если бы расширения напрямую брали зависимости из глобального контейнера, такая замена была бы невозможна.

Материалы по теме:

• Пост: Использование своего класса MVC фабрики в компоненте Joomla 5​;

• Github: Плагин WT Multicategories, в котором подменяется MVC фабрика в компоненте com_content;

• Статья: Учимся использовать Dependency Injection Containers (DI контейнеры) в Joomla 5.

Работаем в лоб: Прямое редактирование XML форм Joomla

Используя событие onContentPrepareForm можно изменять почти любую форму Joomla, но методов класса Joomla\CMS\Form\Form обычно не хватает для работы со сложными формами (например с полями типа subform).

Но есть простое решение - работать с формой как c экземпляром SimpleXMLElement.

Получаем XML формы.

echo $form->getXml()->asXMl();
die;

Отправляем его в ChatGPT с описанием что и как надо изменить в форме, и просим написать PHP-код.

Например у меня такая форма:

<?xml version="1.0"?>
<form>
	<config>
		<fieldset label="PLG_CONTENT_WISHBOXRADICALMARTCDEKORDERREGISTRATOR_FIELDSET_LABEL" name="wishboxradicalmartcdekorderregistrator"
                  addfieldprefix="Joomla\Component\Wishboxradicalmartcdek\Administrator\Field">
			<field name="wishboxradicalmartcdekorderregistrator" type="subform"
                   label="PLG_CONTENT_WISHBOXRADICALMARTCDEKORDERREGISTRATOR_FIELD_REGISTRATOR_LABEL"
                   buttons="add,remove,move"
                   multiple="false"
                   hiddenLabel="true">
				<form>
					<fieldset>
						<field name="order_number_prefix" type="text"
                               label="COM_WISHBOXRADICALMARTCDEK_FIELD_ORDER_NUMBER_PREFIX_LABEL"
                               default="test_" />
					</fieldset>
				</form>
			</field>
		</fieldset>
	</config>
</form>

И для изменения атрибута default поля order_number_prefix получаем следующий код:

$fields = $xml->xpath('//field[@name="wishboxradicalmartcdekorderregistrator"]/form/fieldset/field[@name="order_number_prefix"]');

$fields[0]['default'] = 'Test ';

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

Заменяем ещё не устаревший метод Joomla\CMS\Toolbar\ToolbarHelper::custom

Недостаток данного метода заключается в том что мы не можем задать id для тега joomla-toolbar-button, он формируется из параметра icon. Это особенно неудобно когда требуется несколько кнопок с одинаковыми иконками.

было:

ToolbarHelper::custom(
	'cities.update',
	'refresh',
	'',
	Text::_('COM_WISHBOXCDEK_TOOLBAR_UPDATE_CITIES'),
	false
);

<joomla-toolbar-button id="toolbar-refresh" task="cities.update">
<button class="button-refresh btn btn-primary" type="button">
    <span class="icon-refresh" aria-hidden="true"></span>
    Обновить города
</button>
</joomla-toolbar-button>

стало:

Factory::getApplication()->getDocument()->getToolbar()->standardButton(
	'cities-update',
	'COM_WISHBOXCDEK_TOOLBAR_UPDATE_CITIES',
	'cities.update'
	)
	->icon('icon-refresh')
	->listCheck(false);

<joomla-toolbar-button id="toolbar-cities-update" task="cities.update">
<button class="button-cities-update btn btn-primary" type="button">
    <span class="icon-refresh" aria-hidden="true"></span>
    Обновить город</button>
</joomla-toolbar-button>

Как в тулбар одного компонента добавить кнопку, которую будет обрабатывать другой компонент Joomla 5?

Для примера добавим в компонент стандартных материалов (com_content) кнопку из компонента очистки кэша (com_cache).

Как работают стандартные кнопки

Нажатия кнопок тулбара обычно обрабатываются компонентом, на странице которого мы находимся. Вот HTML-код кнопки «Создать» в стандартном компоненте материалов:

<joomla-toolbar-button id="toolbar-new" task="article.add">
    <button class="button-new btn btn-success" type="button">
        <span class="icon-new" aria-hidden="true"></span>
        Создать
    </button>
</joomla-toolbar-button>

Как вы видите, у тега joomla-toolbar-button есть аттрибут task, со значением article.add. Когда вы нажимаете на подобную кнопку, Joomla находит на странице форму adminForm, устанавливает в её поле с именем task значение из атрибута и отправляет форму. По значению поля task мы понимаем что будет вызван метод add контроллера article. А на компонент com_content нам указывает атрибут action формы.

Значит нам нужна отдельная форма

Создадим системный плагин и добавим в конец страницы форму с id 'cacheAdminForm':

/**
 * @return  void
 *
 * @since 1.0.0
 */
public function onAfterRender(): void
{
	$app = $this->getApplication();

	if (!$app->isClient('administrator'))
	{
		return;
	}

	$option = $app->getInput()->getCmd('option', '');
	$view = $app->getInput()->getCmd('view', '');

	if ($option == 'com_content' && $view == 'articles')
	{
		$buffer = $app->getBody();

		$buffer .= '<form'
			. ' action="' . Route::_('index.php?option=com_cache') . '"'
			. ' method="post"'
			. ' name="cacheAdminForm"'
			. ' id="cacheAdminForm"'
			. '>'
			. '<input type="hidden" name="task" value="" />'
			. HTMLHelper::_('form.token')
			. '</form>';

		$app->setBody($buffer);
	}
}

А теперь добавим на тулбар нашу кнопку:

/**
 * @param   Event  $event  Event
 *
 * @return void
 *
 * @throws Exception
 *
 * @since 1.0.0
 *
 * @noinspection PhpUnused
 * @noinspection PhpUnusedParameterInspection
 */
public function onBeforeRender(Event $event): void
{
	$app = $this->getApplication();

	if (!$app->isClient('administrator'))
	{
		return;
	}

	$option = $app->getInput()->getCmd('option', '');
	$view = $app->getInput()->getCmd('view', '');

	if ($option == 'com_content' && $view == 'articles')
	{
		/** @var Document $document */
		$document = $app->getDocument();

		/** @var Toolbar $toolbar */
		$toolbar = $document->getToolbar();

        // Метод standardButton добавляет кнопку и возвращает её
		$toolbar->standardButton(
			'cachedeleteall',
			'PLG_SYSTEM_WISHBOXTOOLBARBUTTONTODIFFERENTCOMPONENT_BUTTON_TO_DIFFERENT_COMPONENT',
			'deleteAll'
		)
			->icon('icon-remove')
			->listCheck(false)
			->buttonClass('button-remove btn btn-primary')
			->form('cacheAdminForm');
	}
}

Обратите внимание что в кнопку мы передали id формы 'cacheAdminForm'.

GitHub c кодом плагина

Как вызвать событие только для указанной (одной или более) группы плагинов в Joomla 5

Обычно события в Joomla вызываются следующим образом:

Шаг 1: Получаем объект диспечера

В коде Joomla можно найти несколько способов получить объект диспечера:

От приложения:

$dispatcher = Joomla\CMS\Factory::getApplication()->getDispatcher();

Из контейнера:

$dispatcher = Joomla\CMS\Factory::getContainer()
 ->get(Joomla\Event\DispatcherInterface::class);

Свой диспечер (если ваш класс реализует Joomla\Event\DispatcherAwareInterface):

$dispatcher = $this->getDispatcher();

Шаг 2: Подключаем плагины нужной группы

PluginHelper::importPlugin('mycomponent');

Шаг 3: Создаём экземпляр события и вызываем метод диспечера dispatch

$dispatcher->dispatch('onMyComponentEvent', $event);

В результате будут вызваны плагины не только группы mycomponent, но и всех ранее подключенных групп (например, 'system'). Потому что любым из вышеперечисленных способов, мы получаем возвращают один и тот же экземпляр диспечера. И код PluginHelper::importPlugin('mycomponent'); работает с тем же экземпляром диспечера.

А следующим образом можно вызвать плагины только нужных групп:

// Создаём свой обьъект диспечера
$dispatcher = new Dispatcher;

// Подключаем нужную группу плагинов, и четвертым параметром передём наш диспечер
PluginHelper::importPlugin('mycomponent', null, true, $dispatcher);
// Так же можем подключить ещё одну группу
PluginHelper::importPlugin('content', null, true, $dispatcher);

// Создаём екземпляр события
// ...

// Вызываем метод dispatch
$dispatcher->dispatch('onMyComponentEvent', $event);

Управление очередностью плагинов в Joomla 5 с помощью приоритетов обработки событий

В Joomla 5 плагины подписываются на события с помощью интерфейса Joomla\Event\SubscriberInterface в нём всего один метод — getSubscribedEvents(), который должен вернуть массив соответствий событий, которые будет прослушивать этот плагин и их обработчиков.

Например, в плагине «Content — Email Cloaking» этот метод выглядит следующим образом:

    public static function getSubscribedEvents(): array
    {
        return ['onContentPrepare' => 'onContentPrepare'];
    }

Ключи массива — имена событий, а элементы масива — имена методов класса плагина.

Но если посмотреть на этот же метод плагина «Behaviour — Backward Compatibility»:

    public static function getSubscribedEvents(): array
    {
        /**
         * Note that onAfterInitialise must be the first handlers to run for this
         * plugin to operate as expected. These handlers load compatibility code which
         * might be needed by other plugins
         */
        return [
            'onAfterInitialiseDocument' => ['onAfterInitialiseDocument', Priority::HIGH],
        ];
    }

То видим что в нём элементы массива - тоже массивы, первый элементом которых - имя метода, второй - приоритет Joomla\Event\Priority::HIGH. И комментарий объясняет что событие onAfterInitialise этим плагином должно обрабатываться раньше чем другими плагинами, потому что этот плагин загружает код, необходимый для работы других плагинов.

Всего доступно семь уровней приоритета:

public const MIN = -3;
public const LOW = -2;
public const BELOW_NORMAL = -1;
public const NORMAL = 0;
public const ABOVE_NORMAL = 1;
public const HIGH = 2;
public const MAX = 3;

По-умолчанию устанавливается «нормальный» приоритет.

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

Автоматическое подключение локализации для веб-ассета в Joomla

Начиная с Joomla 4 в ядре реализована концепция веб-ассетов. Управление JavaScript и CSS в Joomla значительно упростилось благодаря классу WebAssetManager. Есть замечательная статья Как правильно подключать JavaScript и CSS в Joomla 4, в которой подробно и с примерами кода рассказывается об этой концепции и её применении. Например, в web asset мы можем оформить какую-нибудь готовую js-карусель или библиотеку.

Также можно оформить веб-ассетом и свой собственный js-скрипт, которому могут понадобиться дополнительные данные для работы на странице: как данные из PHP, так и языковые константы. С помощью WebAssetManager мы можем получить эти данные в момент сразу при подключении ассета. Как это сделать?

Для веб ассетов в Joomla создаётся файл joomla.asset.json, в котором описываются url подключаемых файлов, версии, их зависимости друг от друга, собираются пресеты для подключения пачкой и т.д. В нём можно указать пользовательский класс WebAssetItem, который будет выполнять нужную работу для вашего ассета. Для этого определите свойства namespace и class для всего файла или же для каждого ассета.

{
  "$schema": "https://developer.joomla.org/schemas/json-schema/web_assets.json",
  "name": "com_example",
  "version": "4.0.0",
  "namespace": "Joomla\Component\Example\Administrator\WebAsset",
  "assets": [
    {
      "name": "foo",
      "type": "script",
      "class": "FooAssetItem",
      "uri": "com_example/foo.js"
    },
    {
      "name": "bar",
      "type": "script",
      "namespace": "MyFooBar\Library\Example\WebAsset",
      "class": "BarAssetItem",
      "uri": "com_example/bar.js"
    }
  ]
}

Ассет foo будет работать с классом Joomla\Component\Example\Administrator\WebAsset\FooAssetItem, а ассет bar с классом MyFooBar\Library\Example\WebAsset\BarAssetItem. Если namespace не указан, будет использоваться Joomla\CMS\WebAsset по умолчанию. Ну и сам класс должен находиться по указанному неймспейсу.

<?php
/**
 * Класс WebAssetItem для подключения данных для работы веб ассета
 */

namespace Joomla\Component\Example\Administrator\WebAsset\AssetItem;

\defined('_JEXEC') or die;

use Joomla\CMS\Document\Document;
use Joomla\CMS\Factory;
use Joomla\CMS\Language\Text;
use Joomla\CMS\WebAsset\WebAssetAttachBehaviorInterface;
use Joomla\CMS\WebAsset\WebAssetItem;

class FooAssetItem extends WebAssetItem implements WebAssetAttachBehaviorInterface
{
    /**
     * Method called when asset attached to the Document.
     *
     * @param   Document  $doc  Active document
     *
     * @throws \Exception
     *
     * @since   1.0.0
     */
    public function onAttachCallback(Document $doc)
    {
        Factory::getApplication()->getLanguage()->load('com_example');

        // Add my-js-script.js language strings
        Text::script('COM_EXAMPLE_LANGUAGE_STRING_FOR_FRONTEND');

        /** @var array $data Данные для фронтенда, чтобы получать их
         *  в js через Joomla.getOptions('com_example.foo.js.data';)
         */
        $data = [
            'any' => 'data',
        ];
        /** @var bool $merge Whether merge with existing (true) or replace (false) */
        $merge = true;
        $doc->addScriptOptions('com_example.foo.js.data', $data, $merge);
    }
}

Таким образом для нашего js-скрипта мы получили и локализованные стринги сообщений (как? - пост на Хабре) и дополнительные данные из PHP для фронтенда (статья на Хабре - в середине). Теперь когда вы где-то в любом месте Joomla подключаете веб ассет с помощью $wa->useScript('foo') - автоматически подключится всё необходимое для его работы.

Совет по Joomla: dot-нотация для доступа к значениям вложенных массивов.

Позволю себе немного ребячества ))

Наткнулся на пост в одном из php-шных каналов о том, как в Laravel можно использовать нотацию "точка" для доступа к значениям вложенных массивов. И тем самым упростить доступ к многомерным массивам с помощью одной строки, разделенной точками.

😎 Joomla тоже так может!

use Joomla\Registry\Registry;
$data = [
        'user' => [
                'name' => 'John Doe',
                'email' => 'john@example.org',
        ]
];

$data = new Joomla\Registry\Registry($data);

$name = $data->get('user.name');
dump($name); // 'John Doe'

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

Upd. И коллеги сразу решили дополнить:

Преимущество джумлы перед ларой в этом плане:

• можно так обращаться не только к массивам, но и к объектам и даже к json'у

• можно дополнять

• можно выполнять merge. Причём, как на весь объект, так и на отдельные его вложенности

Недостатки:

• нужно сначала создать новый объект

• нет вот такой нотации get('*.key'), т.е. чего-то похожего на array_column()

Использование своего класса MVC фабрики в компоненте Joomla 5​

Давно назрела необходимость переопределить ->createModel() в своём компоненте. И я хотел сделать это правильно, заменив класс MVC фабрики своим.

Давайте разберемся как создаётся экземпляр MVCFactory в компоненте

Откройте файл administrator/components/com_mycomponent/services/provider.php одного из стандартных компонентов Joomla. В нём нас интересует строка:

$container->registerServiceProvider(new MVCFactory('\Joomla\Component\MyComponent'));

В этой строке создаётся объект класса сервис-провайдера Joomla\CMS\Extension\Service\Provider\MVCFactory реализующего интерфейс Joomla\DI\ServiceProviderInterface. В этом интерфейсе всего один метод register.

Вот содержимое этого метода:

$container->set(
	MVCFactoryInterface::class,
	function (Container $container) {
		if (\Joomla\CMS\Factory::getApplication()->isClient('api')) {
			$factory = new ApiMVCFactory($this->namespace);
		} else {
			$factory = new \Joomla\CMS\MVC\Factory\MVCFactory($this->namespace);
		}

		// ...
		return $factory;
	}
);

Как видим, в контейнер Joomla\DI\Container в метод set передаются два параметра:

• имя ресурса — string имя интерфейса Joomla\CMS\MVC\Factory\MVCFactoryInterface::class, который должна реализовывать MVC-фабрика;

• функция — callable функция, которая создаёт экземпляр класса MVC-фабрики, реализующего данный интерфейс.

Таким образом, для внедрения собственного класса MVC фабрики надо создать два новых класса (я не привожу код классов, так как вы можете просто наследовать их от стандартных.):

• Собственно класс фабрики, реализующий интерфейс Joomla\CMS\MVC\Factory\MVCFactoryInterface (можно наследовать от стандартного Joomla\CMS\MVC\Factory\MVCFactory);

• И класс сервис-провайдера реализующий интерфейс Joomla\DI\ServiceProviderInterface (можно наследовать от стандартного Joomla\CMS\Extension\Service\Provider\MVCFactory).

И в файле administrator/components/com_mycomponent/services/provider.php в методе register зарегистрировать свой сервис-провайдер вместо стандартного:

$container->registerServiceProvider(new MyMVCFactory('\\Joomla\\Component\\MyComponent'));

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

В контроллерах (MVC фабрику своего компонента):

$mvcFactory = $this->factory;

В классах использующих MVCFactoryAwareTrait , например в моделях наследующих класс BaseDatabaseModel(MVC фабрику своего компонента):

$mvcFactory = $this->getMVCFactory();

В любом месте можно получить MVC фаблику любого компонента:

$mvcFactory = Joomla\CMS\Factory::getApplication()
  ->bootComponent('my_component')
  ->getMVCFactory();

Заменяем устаревший метод Joomla\CMS\Toolbar\Toolbar::getInstance() в Joomla 5.2.5.

Joomla предлагает использовать Factory::getContainer()->get(ToolbarFactoryInterface::class)->createToolbar().

/**
 * @deprecated  4.0 will be removed in 6.0
 *              Use the ToolbarFactoryInterface instead
 *              Example:
 *              Factory::getContainer()->get(ToolbarFactoryInterface::class)->createToolbar($name)
 */

Но код:

$toolbar = Factory::getContainer()->get(ToolbarFactoryInterface::class)->createToolbar();

Создаст новый объект класса Toolbar и не является заменой коду:

$toolbar = Toolbar::getInstance();

Правильно будет получать объект Toolbar от объекта Document:

$toolbar = Factory::getApplication()->getDocument()->getToolbar();

Собственные макеты вывода для пользовательских полей Joomla

Мы привыкли использовать механизм переопределения макетов Joomla: скопируй нужный тебе файл макета в папку html шаблона и твори там что хочешь. Это в полной мере относится и к пользовательским полям Joomla.

Joomla ищет макеты рендера всех пользовательских полей в следующем порядке:

• Есть ли файл templates/[template name]/html/layouts/[component name]/fields/render.php , переопределяющий макет вывода полей для конкретного компонента? Да - используем его.

• Нет? Есть ли файл components/[component name]/layouts/fields/render.php в папке компонента? Да - используем его.

• Нет? Есть ли файл templates/[template name]/html/layouts/com_fields/fields/render.php, переопределяющий вывод полей для com_fields? Да - используем его.

• Нет? Используем файл components/com_fields/layouts/fields/render.php Это механизм поиска переопределений файлов макетов.

Вчера столкнулся с тем, что если поле вставлено в текст материала с помощью шорт-кода (кнопкой редактора) вида {field 25}, то переопределения не сработали. Поэтому стал вспоминать как сделать свой макет для поля Joomla.

Файл components/com_fields/layouts/field/render.php копируем в templates/YOUR_TEMPLATE/html/layouts/com_fields/field/etapy-raboty-nad-proektom.php. Обратите внимание, что мы файл переименовали, чтобы в настройках поля видеть его в выпадающем списке. После этого всё заработало как надо.

Благо, переводил уже раньше статью Как происходит рендер пользовательских полей в Joomla?. Потом, порывшись по своему же переводу увидел, что эта особенность работы Joomla в статье уже в ней описана 😂. А также напомнил себе о возможности указывать макет поля прямо в шорт-коде, через запятую: {field 25,etapy-raboty-nad-proektom}.

В Joomla 4 и Joomla 5 появилась концепция Web Assets и WebAssetManager, с помощью которого можно управлять подключениями css, js файлов, подключением. Все css и js файлы включаются в общий реестр ассетов, затем выстраивается граф зависимостей и в итоге на генерируемую страницу подключается только то что нужно на данной странице.

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

Одним из таких плагинов веб-ассетов является WT JSwiper.js. Плагин добавляет в Joomla Web Assets Registry ассет популярного скрипта swiper.js, который потом легко можно использовать в коде:

use Joomla\CMS\Factory;

$wa = Factory::getApplication()->getDocument()->getWebAssetManager();
// Локальный файл
$wa->useScript('swiper-bundle')->useStyle('swiper-bundle'); 
// Подключение из CDN
$wa->usePreset('swiper-bundle-remote'); 

😐 Например, было: иконочный шрифт могут использовать 2 разных модуля. CSS обычно подключается в шаблоне и он грузится везде, даже там, где не надо. Если же подключать CSS в одном модуле, а в другом нет - на странице стиль есть ровно до тех пор, пока опубликован модуль с этим подключением.

👍 Стало: теперь в макетах расширений мы просто пишем $wa->useStyle('my.style'); и за необходимостью подключения нужного ассета (в данном случае CSS с иконочным шрифтом) следит Web Asset Manager. Если мы снимем один модуль с публикации, то нужный ассет подключит другой модуль.

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

В этой версии, кроме обновления собственно ассета до версии 11.2.5 к нему добавился пока что частичный перевод документации Swiper на русский язык.

• Скачать WT JSwiper.js для Joomla

• Документация Swiper.js на русском

Также будет полезно:

• Статья на JPath.ru Как правильно подключать JavaScript и CSS в Joomla 4

• Статья на Хабре: Использование WebAssetsManager Joomla 4 (Joomla 5) и добавление собственных пресетов с помощью плагина

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

Судьба плагина обратной совместимости в Joomla

Некоторых разработчиков и вебмастеров интересует останется ли плагин обратной совместимости в Joomla 6. Этот плагин был создан для того, чтобы сделать переход от версии к версии более гладким и бесшовным.
Подробнее почитать о роли плагина можно в официальной документации на manual.joomla.org: Compatibility Plugin.

Устаревший код МОЖЕТ быть перемещен в плагин совместимости. Плагин обеспечивает более плавное обновление между основными версиями. Он содержит код из предыдущей версии, который может сломать сайт после обновления, поскольку расширение использует устаревший код. Расширение полностью совместимо только тогда, когда оно работает без проблем с отключенным плагином совместимости.

От версии к версии часть кода ядра Joomla помечается как устаревшая, а затем, спустя некоторое время удаляется из основного ядра и МОЖЕТ быть перемещена в плагин обратной совместимости. Эта концепция появилась при переходе от Joomla 4 к Joomla 5.

Важным уточнением является то, что для новой мажорной версии (joomla 3, joomla 4, joomla 5 и т.д.) плагин содержит устаревший код предыдущей версии. То есть для Joomla 5 это код из Joomla 4. Для Joomla 6 - код из Joomla 5.

Таким образом расширения, использующие методы и функции ядра Joomla и всё ещё работающие даже с плагином обратной совместимости на Joomla 5 в Joomla 6 скорее всего работать уже не будут. В Joomla 6 из плагина обратной совместимости будет удален код, поддерживающий обратную совместимость с Joomla 4. Таким образом стабильно работать в Joomla 6 будет то, что сейчас стабильно работает на Joomla 5 с отключённым плагином обратной совместимости.

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

Joomla-разработчикам: обращение к методам модели в HtmlView напрямую

Когда-то, давным-давно в одной далёкой галактике кто-то решил, что было бы неплохой идеей ввести в Joomla косвенный доступ к методам модели (MVC) для получения данных, добавив метод AbstractView::get(). Этот метод извлекает модель и затем запускает get(). Простыми словами, когда мы во View (файл HtmlView нашего компонента) видим конструкцию $this->item = $this->get('Item') это означает обращение к методу getItem() модели для текущего View.

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

Новый способ выглядит так:

// Файл HtmlView компонента

    public function display($tpl = null)
    {
        $model = $this->getModel();
        $this->items = $model->getItems();

        parent::display($tpl);
    }

Старый подход (то есть метод get() во View) будет удалён в Joomla 7. Памятуя о релизном цикле Joomla, это означает, что:

1. осенью 2025г выйдет Joomla 6.

2. 2 года она будет основной веткой. Joomla 5 будет в режиме поддержки

3. через 2 года, в 2027 выйдет Joomla 7, в которой будет удалён этот метод.

4. но Joomla 6 будет ещё 2 года в режиме тех.поддержки и в ней (до 2029 года) этот метод останется.

Таким образом у разработчиков есть от 2,5 до 4,5 лет (на момент написания этого поста) на то, чтобы сделать этот рефакторинг.

Пруф [5.3] Deprecate AbstractView::get() #44162

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

Совет по Joomla: показ уведомлений Joomla.renderMessages.

Пользователь совершает какие-то действия на сайте и получает сообщения об успешном или не успешном их результате, а также просто информационные сообщения. В php коде мы привыкли использовать для этого метод enqueueMessage():

use Joomla\CMS\Factory;

$html = 'Message';
Factory::getApplication()->enqueueMessage($html, 'warning');

Чаще всего в качестве сообщения используются языковые константы, чтобы пользователи могли получать сообщения на своём языке:

use Joomla\CMS\Factory;
use Joomla\CMS\Language\Text;

Factory::getApplication()->enqueueMessage(Text::_('SOME_LANG_CONSTANT'), 'info');

Рендер сообщений Joomla во фронтенде.

Здесь нам потребуется файл подключённые файлы ядра core.js и messages.js. Немного выдержки из кода:

/**
* Рендер сообщений, отправленных через  JSON
* Используется некоторыми javascript, в частности validate.js
*
* @param   {object}  messages JavaScript объект, содержащий сообщения для рендера.
* Пример:
*    const messages = {
*        "message": ["Это будет зелёное сообщение", "И это тоже"],
*        "error": ["Это будет красное сообщение", "И это тоже"],
*        "info": ["Это будет синее сообщение", "И это тоже"],
*        "notice": ["Какое-то информационное сообщение", "И это тоже"],
*        "warning": ["Оранжевое сообщение", "И это тоже"],
*        "my_custom_type": ["Такое же как инфо-сообщение", "И это тоже"]
*    };
* @param  {string} selector CSS-селектор контейнера для рендера сообщений
* @param  {bool}   keepOld  Удалить предыдущие сообщения? Да, если true
* @param  {int}    timeout  Таймаут исчезновения сообщения в миллисекундах
* @return  void  Метод ничего не возвращает
*/

Вот как это выглядит на практике:

Joomla.renderMessages({
    message: [Joomla.Text._('COM_SWJPROJECTS_USER_KEYS_KEY_SUCCESSFULLY_COPYED')]
});

Теперь мы видим, что в качестве сообщения мы и в Javascript можем использовать языковые константы. Для этого мы используем метод Joomla.Text._() (по аналогии с Text::_() в PHP). Но Javascript откуда-то должен получить значения этих языковых констант. И для этого в php коде нашей страницы мы должны позаботиться о нём и добавить нужные для js языковые константы с помощью метода Text::script().

use Joomla\CMS\Language\Text;

Text::script('SOME_LANG_CONSTANT_SUCCESS');
Text::script('SOME_LANG_CONSTANT_FAIL');

Таким образом я смогу получить в js доступ к значениям языковых констант SOME_LANG_CONSTANT_SUCCESS и SOME_LANG_CONSTANT_FAIL.

Источник

Событие Pizza, Bugs & Fun приближается - 22 февраля 2025 года

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

Видео из этого поста рассказывает об организационных вопросах, которые пригодятся для участия в PBF:

• как создать аккаунт в Mattermost (чат международного Joomla-сообщества)

• как создать аккаунт в Joomla! Documentation

• как написать статью в Joomla! Documentation

• как создать аккаунт на GitHub (у разработчиков обычно уже он есть)

• как настроить патч тестер

• как протестировать патч

• как получить вознаграждение

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

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

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

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

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

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

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

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

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

Сайт

Joomla по-русски: чат сообщества

Совет по Joomla: программный рендер модулей

Модули порой удобно использовать в местах, которые в Joomla не всегда предназначены для этого 😀. Например, в переопределениях макета. Из материала делаем посадочную страницу: часть инфы находится в самом материале, часть - в полях, а часть удобно вывести модулем. При этом модуль этот должен находиться между телом материала и данными из пользовательских полей.

Для реализации берём в руки ModuleHelper и приступаем.

<?php
use \Joomla\CMS\Helper\ModuleHelper;

$modules = ModuleHelper::getModules('landing-masonry');
if(!empty($modules))
{
    foreach ($modules as $module)
    {
        // рендерим всё, что нашли в позиции landing-masonry
        echo ModuleHelper::renderModule($module);
    }
}

А что если посложнее?

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

Вид карточки товара JoomShopping. Все тексты, кроме описания товара - одинаковые во всех товарах. Описание товара уникальное для каждого товара.

Но! В этот же аккордеон нужно было добавить и описание товара JoomShopping. Поэтому я сделал с помощью своего модуля WT Quick links следующее.

1. Создал модуль типа WT Quick Links, в котором в список элементов занёс все нужные тексты.

2. Не стал назначать модуль какой-либо позиции. В шаблоне JoomShopping захардкодил id модуля. Хотя лучше было бы назначить модуль в некой уникальной позиции, которая встречалась бы только в нужном нам месте на сайте.

3. Программным способом в данные модуля добавил нужные данные из JoomShopping так, как мне нужно (в начало списка - описание товара).

4. Отрендерил модуль с помощью ModuleHelper в product_default.php шаблона JoomShopping.

<?php
use Joomla\CMS\Helper\ModuleHelper;
use Joomla\Registry\Registry;

// Модуль id 136 - Доставка, оплата и гарантии в карточку товара + ОПИСАНИЕ ТОВАРА JoomShopping
$module = ModuleHelper::getModuleById('136');

$module_params = new Registry($module->params);
// Формируем новые параметры модуля перед рендером. 
$new_module_params = [];
$i = 1;

// Помещаем описание товара в самое начало

if (!empty($this->product->description)){
    $new_module_params['fields']['fields0'] =  (object) [
        'item_header' => Text::_('JSHOP_DESCRIPTION'),
        'item_text'   => $this->product->description
    ];
}
// Переименовываем все остальные ключи массива элементов из модуля
foreach ($module_params->get('fields') as $key => $value)
{
    $new_module_params['fields']['fields' . $i] = $value;
    $i++;
}
$new_module_params = new Registry($new_module_params);
// Соединяем старые и новые параметры модуля.
$module_params->merge($new_module_params);

$module->params = $module_params->toString();

// Всё готово! Рендерим модуль.
echo ModuleHelper::renderModule($module);

Joomla Web Services Collection For Postman

Разработчикам мобильных и WEB-приложений (и не только) весьма и весьма пригодится готовая коллекция для Postman. В коллекцию добавлены endpoint для REST API Joomla, с параметрами и примерами запросов.

Коллекция составлена трудами французского Joomla-разработчика Alexandre J-S William ELISÉ.

Смотреть коллекцию

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