Joomla: как тестировать? Всего 8 минут.
Над CMS Joomla постоянно ведётся работа: создаётся новый функционал, исправляются ошибки, делаются мелкие правки. Разработка ведётся на GitHub. Изменения оформляются в виде Pull Request (PR). Для того, чтобы изменения могли войти в ядро - их обязательно должны успешно протестировать минимум 2 человека КРОМЕ автора изменений. А помочь с большинством PR можно очень и очень быстро, это не занимает много времени, чему подтверждением служит это видео.
Привет! Такое важное дело:
Мы в Хабре ищем к нам в команду старшего PHP-разработчика — можно работать удаленно.
Сильно ждем того, кто готов быть активным участником всего процесса разработки: начиная от проектирования и заканчивая запуском и поддержкой. Того, кто не боится участвовать в обсуждении идей и заниматься исследовательской деятельностью. Того, кто может продвигать свои и чужие идеи и добиваться их реализации. Кто понимает, что важно не только писать новый код, но и поддерживать старый.
Зарплатную вилку, требования и обязанности оставили на странице вакансии — откликайтесь, если хотите попасть в команду, или отправляйте вакансию друзьям, которые ищут работу.
Привет Хабр! Это мой первый пост, и я просто хотелось спросить, стоит ли уходить в Go? У меня есть небольшая база в программировании, делал сайты на реакт и ларавел, реализовывал бэкенд с Солид и паттернами, писал на нативном пхп файловые обменники и апи. Не много знаю базы данных соответственно, гит, докер. Сейчас засматриваюсь на Go, где то вычитал что мол крутая штука для бигтехов в России, а сам я студент и пока сижу на шее у родителей, но в следующем году я окончу к курс, и хочу где то месяца за 4-5 изучить все нужное в го и во всех других сопутствующих технологиях для разработки высоконагруженных приложений и микросервисов и всякого подобного. Стоит ли сворачивать на этот путь, или добить стек ларавел плюс вью? Немного боюсь, так как слышал что в го нужны уже 25 летние синьоры со стажем работы минимум в 20 лет, но и не хочется проторчать всю жизнь в челябинской галере на фуллстеке за 70 деревянных на руки.
Свои типы полей в 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. Продолжение.
Продолжение потому, что начало уже было в статье Виталия Некрасова на Хабре.
Кратко.
В 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....
Опубликовано исследование о том что индексирование сайтов поисковиком (Google) не зависит от того, SPA ли это или же он SSR. Также пару лет назад делал аналогичное расследование и пришел к тому же выводу.
Вообще, мы пришли к идеалу достаточно давно - когда сервер занимается своими делами, а клиент статический, минифицирован, и раздается из CDN для быстроты и без траты ресурсов сервера.
https://vercel.com/blog/how-google-handles-javascript-throughout-the-indexing-process
Автоматическое подключение локализации для веб-ассета в 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()
Multipart Upload в Laravel: загрузка больших файлов в S3
Что такое Multipart Upload и зачем он нужен?
Multipart Upload - это метод загрузки больших файлов в S3, при котором файл разбивается на части (чанки) и загружается параллельно. Это решает несколько ключевых проблем:
Надёжность - при обрыве соединения можно перезагрузить только failed-часть
Производительность - параллельная загрузка частей ускоряет процесс
Обход ограничений - позволяет загружать файлы больше 5 ГБ (максимальный размер для простой загрузки)
Как реализовать Multipart Upload в Laravel
1. Установка зависимостей
Убедитесь, что у вас установлен AWS SDK (обычно идёт с Laravel): composer require aws/aws-sdk-php
2. Пример реализации
use Illuminate\Http\UploadedFile;
use Aws\S3\MultipartUploader;
use Aws\Exception\MultipartUploadException;
private function uploadFileToS3(UploadedFile $file, string $fileName): string
{
// Получаем клиент S3 из Storage фасада
$client = Storage::disk('s3')->getClient();
// Путь для сохранения в S3 (можно добавить подпапки по дате и т.д.)
$s3Path = $this->s3path.'/'.$fileName;
// Настройки загрузчика
$uploader = new MultipartUploader($client, $file->getPathname(), [
'bucket' => config('filesystems.disks.s3.bucket'),
'key' => $s3Path,
'part_size' => 5 * 1024 * 1024, // 5 MB за часть чанка
'concurrency' => 3, // Количество параллельных загрузок
'before_initiate' => function ($command) {
// Можно добавить метаданные или ACL
$command['ACL'] = 'public-read';
},
'before_upload' => function ($command) {
// Логирование перед загрузкой каждой части
Log::info('Uploading part', [
'part_number' => $command['PartNumber'],
'upload_id' => $command['UploadId']
);
},
]);
try {
// Запускаем процесс загрузки
$result = $uploader->upload();
// Возвращаем полный путь к файлу в S3
return $s3Path;
} catch (MultipartUploadException $e) {
// Логируем ошибку
Log::error('Multipart upload failed', [
'file' => $fileName,
'error' => $e->getMessage(),
'upload_id' => $e->getUploadId()
]);
// Можно попробовать возобновить загрузку
// $this->resumeUpload($e->getUploadId(), $s3Path);
throw new \Exception('File upload failed: '.$e->getMessage());
}
}3. Дополнительные методы для работы с Multipart Upload
Возобновление прерванной загрузки
private function resumeUpload(string $uploadId, string $s3Path): string
{
$client = Storage::disk('s3')->getClient()
$uploader = new MultipartUploader($client, null, [
'bucket' => config('filesystems.disks.s3.bucket'),
'key' => $s3Path,
'upload_id' => $uploadId,
'part_size' => 5 * 1024 * 1024,
]);
try {
$result = $uploader->upload();
return $s3Path;
} catch (MultipartUploadException $e) {
throw new \Exception('Resume upload failed: '.$e->getMessage());
}
}Когда использовать Multipart Upload
Файлы больше 100 МБ - для меньших файлов обычная загрузка может быть эффективнее
Ненадёжные соединения - где возможны обрывы
Критичные по времени загрузки - когда нужно максимально ускорить процесс
Оптимизация параметров
part_size:
5-10 MB - хороший баланс для большинства случаев
Увеличивайте для очень больших файлов (>1 GB)
concurrency:
3-5 - оптимально для большинства случаев
Можно увеличить для очень быстрых соединениях
Что ждёт в следующих статьях?
🔹 Ограничения PHP при работе с файлами (максимальный размер загрузки, timeout-ы, memory_limit)
🔹 Глубокий разбор S3 — Versioning, Lifecycle Policies, Cross-Region Replication
🔹 Продвинутое потоковое чтение/запись — обработка гигабайтных логов, CSV и медиа без нагрузки на память
🔹 CDN-оптимизация — Geo-DNS, кеширование, пресеты для изображений
🔹 Секретные фишки — Signed URLs, временные доступы, обработка через очереди
Остались вопросы или есть темы, которые хотите разобрать подробнее? Пишите в комментариях — ваши пожелания станут основой для следующих статей!
В 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 на русский язык.
Также будет полезно:
Судьба плагина обратной совместимости в 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-разработчикам: обращение к методам модели в 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, это означает, что:
осенью 2025г выйдет Joomla 6.
2 года она будет основной веткой. Joomla 5 будет в режиме поддержки
через 2 года, в 2027 выйдет Joomla 7, в которой будет удалён этот метод.
но Joomla 6 будет ещё 2 года в режиме тех.поддержки и в ней (до 2029 года) этот метод останется.
Таким образом у разработчиков есть от 2,5 до 4,5 лет (на момент написания этого поста) на то, чтобы сделать этот рефакторинг.
Совет по 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 не всегда предназначены для этого 😀. Например, в переопределениях макета. Из материала делаем посадочную страницу: часть инфы находится в самом материале, часть - в полях, а часть удобно вывести модулем. При этом модуль этот должен находиться между телом материала и данными из пользовательских полей.
Для реализации берём в руки 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 следующее.
Создал модуль типа WT Quick Links, в котором в список элементов занёс все нужные тексты.
Не стал назначать модуль какой-либо позиции. В шаблоне JoomShopping захардкодил id модуля. Хотя лучше было бы назначить модуль в некой уникальной позиции, которая встречалась бы только в нужном нам месте на сайте.
Программным способом в данные модуля добавил нужные данные из JoomShopping так, как мне нужно (в начало списка - описание товара).
Отрендерил модуль с помощью 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: метод debug() для отладки лейаутов
В Joomla есть понятие layout. Это кусочек вёрстки, который можно многажды использовать в любом месте сайта: как в панели администратора, так и во фронтенде. Можно рассматривать лейауты как оторванные от контекста элементы дизайна. Находятся они в папке layouts в корне сайта. Также, в случае с модулями они могут находиться в папке tmpl модуля. А в случае с плагинами - в tmpl плагина.
Их можно переопределять в шаблонах, в чём и заключается одна из главных фишек Joomla. Лейауты чаще всего рендерятся с помощью классов LayoutHelper или напрямую FileLayout. Писал о них ранее тут и тут.
А вот как увидеть какой именно файл переопределения используется? Сколько их вообще есть и по каким путям идёт поиск макетов? Для этого есть метод debug() (и у LayoutHelper и у FileLayout).
<?php
/**
* Method to render a layout with debug info
*
* @param string $layoutFile Dot separated путь к файлу относитеьлно basePath
* @param mixed $displayData Объект с данными для рендера
* @param string $basePath Base path, где будет поиск файлов лейаутов
* @param mixed $options Дополнительные опции для FileLayout
*
* @return string
*
* @since 3.5
*/
public static function debug($layoutFile, $displayData = null, $basePath = '', $options = null)
{
// Так проще показать параметры метода.
}
То есть мы в можем проверить следующим образом:
<?php
/**
* Получаем параметры баннера
*/
$wt_custom_menu_item_banner = $menu->getParams()->get('wt_custom_menu_item_banner');
echo \Joomla\CMS\Layout\LayoutHelper::debug(
($wt_custom_menu_item_banner?->pluginlayout ?? 'default'),
['wt_custom_menu_item_banner' => $wt_custom_menu_item_banner],
JPATH_SITE.'/plugins/system/wt_custom_menu_item_banner/tmpl'
);
И увидим результат как на скриншоте в начале поста.
E-mail шаблоны Joomla 5: добавление и просмотр своих переменных
В Joomla 5 появились настраиваемые email-шаблоны, как системные, так и сторонних компонентов. Их нельзя (пока что) добавить самостоятельно, они добавляются расширениями при установке. Но их можно отредактировать в Система - Шаблоны - Шаблоны писем. В настройках шаблонов писем (кнопка настроек компонента в верхнем правом углу) мы выбираем формат писем текст или HTML. Тогда становятся доступны настройки макетов шаблонов писем Joomla. Эти глобальные параметры можно переопределить в каждом конкретном email-шаблоне. Таким образом для каждого из email-шаблонов можно указать свою вёрстку и настройки логотипа.
Это, конечно, требует отдельной подробной статьи...
Для разработчиков: как добавить свои переменные для e-mail шаблонов Joomla?
Полезны окажутся 2 триггера для плагинов: onMailBeforeTagsRendering и onMailBeforeRendering.
onMailBeforeRendering - триггер, который позволяет добавлять свои шорт-коды для строковой замены в плагине. Отдать туда надо массив вида [ variable_name => variable_value ]. Из админки свои переменные нужно добавлять уже с фигурными скобками: {variable_name} заменится на variable_value. Аргументом $event плагина является экземпляр класса BeforeRenderingMailTemplateEvent, в котором есть кроме прочих 2 метода: getTemplate() (получение объекта мейлера, куда можно добавлять свои данные) и getTemplateId() (получение id шаблона письма вида com_users.registration.admin.new_notification), по которому мы определяем нужный ли это для нас email-шаблон или нет. Аналогично контексту в контент-плагинах.
Также полезное свойство класса для передачи данных из плагина в лейаут письма для рендера - $layoutTemplateData. Это ассоциативный массив.
// Получаем текущий мейлер
$mailTemplate = $event->getTemplate();
$data = [
'variable_name' => 'variable_value'
];
// с Joomla 4 для всех типов писем. 2-й аргумент - plain - текстовый формат письма
$mailTemplate->addTemplateData($data, false);
// с Joomla 5.2 - для HTML-писем
$mailTemplate->addLayoutTemplateData($data);
// пример из ядра Joomla
// Add additional data to the layout template
$this->addLayoutTemplateData([
'siteName' => $app->get('sitename'),
'lang' => substr($this->language, 0, 2),
]);
onMailBeforeTagsRendering - триггер, который добавляет ваши переменные в список доступных переменных для замены в окне редактирования email шаблона Joomla. Отдать туда нужно массив с переменными, но без их значений.
Лучший кейс по MoonShine: время голосовать! 🗳
Привет, друзья! 👋
Наш конкурс кейсов использования MoonShine (админ-панели для Laravel) вышел на финишную прямую. Пришло время выбрать лучшего из лучших! 🏆
Оформлены кейсы:
Теперь слово за вами! 🚀 Голосуйте за самый интересный кейс. Победитель получит PHP-слоника 🐘. И звание "Герой MoonShine 2024"! 😜 Голосуем тут:
https://t.me/moonshine_ru/5/15535
📅 Голоса принимаются до 31 декабря в 12:00 (мск)!
Давайте вместе выберем самого креативного и талантливого автора-разработчика в нашем комьюнити!
🎉 Релиз MoonShine v3 админ панели для Laravel! 🎉
Друзья, у нас праздник!
10 декабря наконец-то зарелизили MoonShine v3 (open-source панели администратора для проектов на Laravel).
Кто не вкурсе, вот статьи:
Это было непросто. Пришлось отложить дату релиза, но зато успел всё сделать что запланировано. 🔥
Что было на стриме:
🕰 Краткая история создания MoonShine — от первых шагов до сегодняшнего дня.
🚀 Релиз на GitHub, деплой новой версии лендинга и документации.
🛍 Демонстрация маркетплейса приложений для MoonShine
Обязательно посмотрите запись стрима! Вы не только узнаете больше о MoonShine, но и вдохновитесь на свои проекты.
Немного выдохну, и сделаю подробный разбор по возможностям MoonShine v3.
Сайт проекта - https://moonshine-laravel.com/
Чат в телеграм - https://t.me/moonshine_ru
#MoonShine #релиз #CutCode