Есть в OctoberCMS такая полезная штука — бихевиор для ручной сортировки моделей. Например, чтобы перетаскиванием отсортировать категории по значимости (и вложенности). Использовать его для своих моделей — очень просто, вот страничка в документации. Подключаем бихевиор к классу-контроллеру, заполняем конфиг, а в модели используем трейт Sortable (или NestedTree). А что такое бихевиор, можно тоже прочитать в доках.

Но проблема в том, что из коробки можно заставить этот бихевиор работать только на одном уровне. Вот есть все экземпляры модели одного класса — можно их отсортировать. А мне нужно сделать интерфейс для сортировки фотографий, принадлежащих альбомам. То есть отсортировать только фотокарточки внутри отдельно взятого альбома, без всех остальных.

Бихевиор ReorderController для этого использовать не получится, придется строить сортировку вручную. Однако если покопаться, как устроен ReorderController, его шаблоны и трейт Sortable, можно сделать свою сортировку по аналогии и даже не дублировать какую-то часть кода. Об этом и поговорим.

В плагинах OctoberCMS обычно мы имеем дело с моделями. Допустим, есть у нас вот такой список моделей как на картинке. Это список моделей Photo, принадлежащих одной модели Album. Сделать такой список легко — пара строчек в контроллере и он создастся автоматически.

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

Список столбцов задается (по умолчанию) в файле columns.yaml для отображаемой модели. Туда можно добавлять новые столбцы, но их набор довольно ограничен. Зато, как написано на этой же странице документации, можно добавлять свои типы столбцов. И сейчас мы рассмотрим эту возможность, чуть-чуть подробнее, чем в доках.

В принципе, тесты в OctoberCMS устроены примерно так же, как и в Laravel. Но поскольку это CMS и у нее есть плагины — к ним можно писать отдельные тесты. Правда, документация по этому вопросу довольно лаконична.

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

$theme = Theme::load('test');
$page = Page::load($theme, 'index.htm');
$layout = Layout::load($theme, 'content.htm');
$controller = new Controller($theme);
$parser = new CodeParser($page);
$pageObj = $parser->source($page, $layout, $controller);
$manager = ComponentManager::instance();
$component = $manager->makeComponent('myComponent', $pageObj);

То есть, оказывается, нужна особая магия в виде создания сущностей из «тестовой» темы и генерации компонента с их помощью. Вот бы узнать, где можно почитать об этом, помимо исходников.

Кстати, третьим аргументом в makeComponent() можно передать массив свойств компонента. Поможет протестировать логику, когда свойства должны отличаться от дефолтных.

Как я уже писал раньше, в OctoberCMS из коробки работает фильтр Markdown, который можно применять практически везде. В плагине Blog текст каждой заметки проводится через фильтр перед сохранением, а сохраняется уже готовый html. Но при этом, по загадочным для меня причинам, excerpt (то есть анонс) заметки через фильтр Markdown не пропускается.

Из-за этого приходится либо для анонса переводить маркдаун в html вручную, либо при выводе анонса выводить его с фильтром {{ excerpt | md }}. Со вторым вариантом можно жить, но в сомнениях: ведь анонс каждого поста на странице будет обрабатываться фильтром при каждой загрузке ленты. Непорядок, надо же экономить электроэнергию-то!

Проблему можно решить аккуратно в несколько строчек кода. Раз плагин Blog не преобразует маркдаун в анонсе перед сохранением, поможем ему:

Post::extend(function (Post $model) {
  $model->bindEvent('model.beforeSave', function() use ($model) {
    $model->excerpt = Markdown::parse($model->excerpt);
  });
});

Здесь мы добавили для модели Post обработчик события model.beforeSave, которое происходит всякий раз перед созданием или обновлением заметки в блог. В обработчике мы просто пропускаем анонс через фильтр маркдауна (обратите внимание, для простоты здесь использован фасад Markdown).

Всё, теперь анонсы новых заметок будут обработаны фильтром маркдаун при сохранении. Для порядка можно еще разово обработать анонсы старых заметок. Сделать это нетрудно. Добавим новую команду artisan:

php artisan create:command AuthorName.MyPlugin MyCommand

И в теле метода fire() выполним код:

$posts = Post::where('excerpt', '<>', '')->get();
foreach ($posts as $post) {
  $post->save();
}

То есть находим все заметки, у которых задан анонс и просто пересохраняем их. При пересохранении выполнится наш обработчик события и анонс будет обработан фильтром Markdown.

Для удобства обработчик события и команда обработки старых заметок — добавлены в мой плагин BlogArchive.

Многих интересует, а как в OctoberCMS расширять «чужие» модели и формы. Один из авторов системы, Сэмюэл Джорджс, показывает на пальцах как:

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

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

Если мы хотим применить к проходящему через Markdown тексту какие-то свои фильтры, можно прицепиться к событию markdown.parse. Это событие генерируется сразу после парсинга входящего текста самим фильтром. Подключимся к нему в методе boot() нашего плагина:

public function boot() {
  Event::listen('markdown.parse', 'Author\PluginName\Classes\MarkdownExtender@parse');
}

Теперь при каждом применении фильтра Markdown будет вызываться метод parse() класса MarkdownExtender, который должен находиться в author/pluginname/classes/MarkdownExtender.php. Код класса:

namespace Author\PluginName\Classes;

class MarkdownExtender {

  public function parse($text, $data) {
    // в $text находится оригинальный текст
    // а в $data->text - результирующий
  }
}

Производим все нужные манипуляции с текстом в $data->text и сохраняем результат обратно, сверяясь с оригиналом в $text при необходимости. Вот и всё.

В процессе миграции домовой страницы с Drupal 6 на OctoberCMS, написал несколько плагинов. Первым из них стал плагин BlogArchive и в этой заметке я немного о нем расскажу.

Изначально плагин я написал, чтобы сделать архив постов по месяцам, примерно как было на старом сайте, только лучше. Архив реализован через компонент blogArchive, он работает, можно пользоваться. Компонент даже умеет количество комментариев из Disqus подгружать (если Disqus включен).

Функционал OctoberCMS, как и любой другой CMS, можно расширять. Единицей такого расширения является плагин. В этой заметке я расскажу немного о том, что такое плагин для OctoberCMS, как его сделать, из чего он состоит и что куда класть внутри.

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

Как известно из документации, OctoberCMS предоставляет для Twig ряд расширений. В том числе среди них есть тег {% placeholder %}, позволяющий собирать фрагменты разметки из разных шаблонов в один блок. Вот например есть у нас лейаут:

<html>
    <head>
        {% placeholder head %}
    </head>
    <body>
    ...
    </body>
</html>

Этот тег выведет вместо {% placeholder head %} всё, что будет добавлено туда в других шаблонах. То есть если мы в шаблоне с выводом блог-поста добавим

{% put head %}
  <meta name="title" content="Домовая страница | Graker.Ru">
  <meta name="author" content="Graker">
{% endput %}

а потом еще где-нибудь добавим

{% put head %}
  <link rel="icon" type="image/png" href="http://graker.ru/themes/grakerru/assets/images/icon.png" />
{% endput %}

то всё это попадет в head. Такая вот полезная фича.

P.S. Скрипты и стили вручную собирать в плейсхолдеры не нужно, для этого в October уже есть готовые {% scripts %} и {% styles %}. Но и к ним можно при желании добавить скрипт/стиль с помощью {% put %}.

Давно вынашивал планы взять и все тут переделать немного по-другому, да на чем-нибудь новом, чтобы освоить заодно. На Drupal 7 не хотелось — скучно, думал, сделаю на Drupal 8. А потом так вышло, что под руки попался OctoberCMS. Так что решил сделать новую версию домовой страницы на нем. Ну и делал потихоньку в свободное время.

И вот сделал, наконец. Материалы перенесены, комментарии (нативные, из Drupal 6) ловко мигрировали в Disqus, редиректы с некоторых старых линков — созданы. Осталось вернуть фотокарточки в галерею, да один новый раздельчик заполнить. Но лично мне уже сейчас значительно удобнее, чем было раньше.

Конечно, какие-то шероховатости остались. Например, контент я переносил автоматизированно, через импорт. Так что если потерялся полезный материал, мертвая ссылка где-то осталась, код не так отформатировался, или еще какой глюк — скажите мне, пожалуйста.

В процессе создания пришлось написать несколько своих плагинов (и чуть-чуть поучаствовать в разработке чужих). Все они попали в гитхаб, подробнее я о каждом из них расскажу чуть позже. Если какие вопросы про впечатления от переезда на October есть — пишите, постараюсь ответить.