Чем код из стандартного модуля новостей не устроил?

Не-не...

Ну я же всё это выкосил сначала!

У меня лыжи почему-то не едут!

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

Получается так. Если вкратце.

$eventContentPrepare = AbstractEvent::create( 'onContentPrepare', ['context' => 'com_content.article', 'subject' => &$item, 'params' => &$params, 'page' => 0 ] ); $app->getDispatcher()->dispatch($eventContentPrepare->getName(), $eventContentPrepare); Теперь так.

Зато на 6-й версии править не надо будет. Плюс же какой-нибудь должен быть в этом всём.

а оно отрабатывает?

Знаете, сколько лет уже висит в deprecated угроза удаления методов getError и setError у CMSObject?

Теперь знаю. В смысле вообще всё было зря с этими триггерэвентами?

Теперь знаю. В смысле вообще всё было зря с этими триггерэвентами?

нужно будет переписать абсолютно все плагины контентные. И там не просто аргументы поправить. Там прям логику поменять нужно

Знаете, сколько лет уже висит в deprecated угроза удаления методов getError и setError у CMSObject?

Там сам объект ещё устаревший 😀

Они его передумали убирать

К стати. Тем кто пишет свои event'ы Может кто-то не знал...? При вызове метода setArgument() будет автоматически вызван метод onSet{$argumentName} Таким образом можно внедрить строгую типизацию аргументов для Event

Да это понятно, но вот только тебе помняют те агрументы которые не нужно. Это раз. А во вторых вопрос в том что при большом кол-ве ивентов это тупо не удобно

в смысле?

Ты можешь менять любой аргумент ивента

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

И что ты сдеешь если будет не тот тип?

упаду нахер в ошибку

То же самое будет и без Event

ну да

Но у нас теперь всё на event'ах и приходится как-то жить в этой реальности

У вас. Я свой обработчик написал и в ус не дую =)

О том и реч. Да это круто. Если у тебя 3 ивента. Но когда 30+ а у кого-то их под 100 это того не стоит

вам привет от симфонистов =)

и конструктор контроллера

И. Это удобно и здраво и проще чем контролер который тянет то что не нужно

ну как тебе сказать... Вот компонент на 12 контроллеров. Я затрахаюсь писать это всё через контейнер

и конструктор контроллера

это бандл для тех, кто будет это расширять....

Не будет. Ты делаешь сайт на фрейме а не расширение на joomla

и конструктор контроллера

И кстати контролер j5 не намного меньше =) просто ты его расширяешь родным контролером а не пишешь констракт. Так же ты можешь и в симфонии сделать

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

Добавление своих команд для CLI в Joomla 4 и Joomla 5 с помощью плагина В Joomla, как и во многих других PHP фреймворках и движках, уже довольно давно (с версий 1.7.x) существует возможность работы с помощью CLI. С его помощью обычно решают те задачи, решение которых в веб-интерфейсе Joomla нецелесообразно из-за возможных ограничений веб-сервера - так называемые "тяжелые" задачи. Это может быть миграция большого количества контента со старой версии Joomla на новую, синхронизация данных с внешним источником по API (синхронизация цен и остатков, выгрузка заказов), работа с файлами и каталогами, выполнение пакетных заданий на больших объёмах и т.д. - всё то, что может занимать много времени и ресурсов сервера. Как добавить свою команду в CLI интерфейс Joomla расскажет эта статья. Читать статью #разработка

Народ, как время будет - гляньте статью. Вдруг где косяк какой.

Ну я провайдер теперь делаю так. /** * Registers the service provider with a DI container. * * @param Container $container The DI container. * * @since 1.0.0 */ public function register(Container $container) { // Register MVCFactory $container->registerServiceProvider(new MVCFactory('Joomla\\Component\\RadicalMart')); $container->set(PluginInterface::class, function (Container $container) { // Create plugin class $subject = $container->get(DispatcherInterface::class); $config = (array) PluginHelper::getPlugin('system', 'radicalmart'); $plugin = new RadicalMart($subject, $config); // Set application $app = Factory::getApplication(); $plugin->setApplication($app); // Set database $db = $container->get(DatabaseDriver::class); $plugin->setDatabase($db); // Set MVCFactory $mvcFactory = $container->get(MVCFactoryInterface::class); $plugin->setMVCFactory($mvcFactory); // Load component language $app->getLanguage()->load('com_radicalmart', JPATH_ADMINISTRATOR); return $plugin; } ); } В j5 есть еще setLanguage но у меня и для l4 так что я его не юзаю. Так же я просто добалвяю команды прямо в app не в контейнер.

Я на пятерке смотрел, там только из контейнера лоадер читает команды

Ну я провайдер теперь делаю так. /** * Registers the service provider with a DI container. * * @param Container $container The DI container. * * @since 1.0.0 */ public function register(Container $container) { // Register MVCFactory $container->registerServiceProvider(new MVCFactory('Joomla\\Component\\RadicalMart')); $container->set(PluginInterface::class, function (Container $container) { // Create plugin class $subject = $container->get(DispatcherInterface::class); $config = (array) PluginHelper::getPlugin('system', 'radicalmart'); $plugin = new RadicalMart($subject, $config); // Set application $app = Factory::getApplication(); $plugin->setApplication($app); // Set database $db = $container->get(DatabaseDriver::class); $plugin->setDatabase($db); // Set MVCFactory $mvcFactory = $container->get(MVCFactoryInterface::class); $plugin->setMVCFactory($mvcFactory); // Load component language $app->getLanguage()->load('com_radicalmart', JPATH_ADMINISTRATOR); return $plugin; } ); } В j5 есть еще setLanguage но у меня и для l4 так что я его не юзаю. Так же я просто добалвяю команды прямо в app не в контейнер.

В четверке такое тоже работает?