Когда делали Консерваторию, была задача сделать блок/страницу юбиляров. То есть выводить не просто людей, у которых скоро день рождения, а с круглыми значениями возраста. Заканчивающимися на 5 и 0. Сделать это чисто коробочными вьюзами не особо получается, поэтому пришлось написать немножко кода, о чем и расскажу.

Но сначала небольшое отступление. Как известно, в Drupal 8 модуль Views включили в ядро и это прекрасно. Действительно, контриб, который автоматически ставят во все проекты, не должен оставаться просто контрибом. Но некоторые вещи, сопутствующие включению/порту на D8, несколько раздражают.

Подробности далее.

Работу с AJAX в OctoberCMS я уже раньше немного затрагивал, но для бэк-энда. А теперь можно затронуть и фронт. В этой заметке мы сделаем кнопочку Load More, чтобы подгружала без перезагрузки страницы новые посты блога (из плагина RainLab.Blog).

На первый взгляд может показаться, что для этого нужно влезть в компонент Posts этого плагина, но на самом деле — вовсе не нужно. Дело в том, что раньше из документации можно было подумать, что обработчики AJAX-событий нужно описывать только в классе контроллера (если в бэк-энде), или компонента (если во фронте). И поэтому не очень было понятно, как быть, когда ты хочешь получить красивый ajax-пейджер для блога. То ли лезть в код чужого плагина, что влечет проблемы с обновлениями. То ли писать свой собственный компонент, из которого грузить компонент Posts программно. Что ведет к сомнениям в том, надо ли вообще такой негибкой CMS пользоваться.

У программистов есть такой специальный метод отладки, о котором часто шутят в фейсбуке. Метод резиновой уточки — когда ты объясняешь резиновому утенку, как работает код, в надежде, что кто-то из вас что-нибудь поймет.

У меня резинового утенка нет, но зато есть резиновый зомби. Он, как и утенок, ни фига не понимает, но если я буду плохо работать — он съест мои мозги.

Что мне всегда отдельно нравилось в Ларавеле — так это как там организована генерация тестовых материалов. Для этого используется мега-библиотека Faker, которая умеет практически всё, что может понадобиться при разработке. Годится как для автоматизированных тестов, так и для заполнения БД тестовыми данными.

В самом Ларавеле можно описать для моделей классы-factory и генерировать данные по ним, это описано в документации. В OctoberCMS про фабрики документация ничего не говорит, но можно обойтись и без них.

TL;DR: Далее несколько примеров генерации тестовых данных с помощью библиотеки Faker в OctoberCMS

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

Если исходить из того, что лого выводится в блоке Site branding, то вопрос решается вот таким небольшим кодом, размещенным в файле темы mytheme.theme:

/**
 *
 * hook_preprocess_block()
 *
 * @param array $variables
 */
function mytheme_preprocess_block(&$variables) {
  if ($variables['plugin_id'] == 'system_branding_block') {
    // определяем язык
    if (\Drupal::languageManager()->getCurrentLanguage()->getId() == 'ru') {
      $logo_name .= 'logo.svg';
    } else {
      $logo_name .= 'logo-en.svg';
    }
    $variables['site_logo'] = '/themes/mytheme/' . $logo_name;
  }
}

Файлы с логотипами, соответственно, хранятся в /themes/mytheme/logo.svg и /themes/mytheme/logo-en.svg. А если на странице несколько блоков с разными лого (например, в хедере и футере), различать их можно, проверяя содержимое $variables['elements']['#id'].

Вообще говоря, локализация интерфейса в OctoberCMS такая же как в Laravel. Есть файлы типа lang.php, разложенные по директориям, соответствующим языку, в них есть строки, их можно переводить. Неудобство лично для меня лишь в одном — когда нужно куда-то вставить локализованный текст, не видно самого текста, только идентификатор строки. В остальном, на мой взгляд, система эта несколько удобнее перевода интерфейса в Друпале.

Даже если поддерживать сайт или интерфейс на нескольких языках не нужно, с переводами можно столкнуться, например, при плюрализации, то есть склонении в зависимости от значения числа. Потому что в 2018 году уже как-то стыдно делать сайт, на котором написано «1 предложений», «22 предложений» и т.д. Надо склонять.

В Ларавеле это делается тривиально, для английского языка в lang.php пишем например:

return [
    'count' => [
        'offers' => 'offer|offers',
    ],
];

Тогда при вызове trans_choice('lang.count.offers', 10); выведется слово offers, а при trans_choice('lang.count.offers', 1); — offer.

И для перевода на русский достаточно добавить в соответствующий lang.php перевод:

return [
    'count' => [
        'offers' => 'предложение|предложения|предложений',
    ],
];

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

Но в OctoberCMS есть нюанс. Дело в том, что Ларавел поддерживает единую директорию lang для локализации всего проекта, поэтому туда можно складывать любые строки и обращаться тоже можно к любым строкам. А в Октябре у каждого плагина своя директория переводов, у ядра — своя директория переводов, а у используемой темы её и вовсе нет.

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

Note: For translating front-end content, there are plugins that can be used for this purpose.

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

На самом деле для обращения к строкам локализации из темы, то есть из шаблонов Twig, есть фильтры. Для обычного перевода — фильтр trans, а для плюрализации — transchoice. Его и нужно применить, чтобы получить склоняемое количество предложений:

{{ "graker.touristic::lang.count.offers"|transchoice(quantity) }}

graker.touristic здесь — это обращение к плагину Touristic за авторством Graker: к сожалению, поскольку у темы нет своего файла локализаций, необходимые строки придется разместить в каком-нибудь плагине.

В Ларавеле вложенные (каскадные) отношения моделей — обычное дело. У автора есть записи, у записей есть комментарии, и так далее. Не менее обычное дело — необходимость удалять дочерние модели при удалении родителя. Самое первое, что приходит на ум — каскадное удаление моделей, которое включается при определении foreign-ключей и будет выполняться автоматически базой данных. Но у такого способа есть достаточно весомый недостаток: события deleting и deleted для удаляемых моделей не произойдут и их обработчики, соответственно, не будут вызваны. Ну, потому что удаление в БД происходит.

Поэтому, если существование обработчиков событий предполагается, лучше навесить удаление дочерних моделей на событие deleting модели родительской. Вот есть допустим модель Company и у нее множество моделей Contract, определенное вот так:

public function contracts() {
    return $this->hasMany('App\Contract');
}

Реализуем обработчик события deleting:

protected static function boot() {
    parent::boot();

    static::deleting(function (Company $company) {
        // здесь мы можем удалять контракты
    });

}

Но тут есть еще одна маленькая хитрость. Если мы напишем $company->contracts()->delete(), то контракты удалятся, но их события deleting и deleted тоже не произойдут. Дело в том, что contracts() возвращает нам не что иное, как Query Builder, и когда мы вызовем delete() — это будет обычный delete-запрос к БД. На эту тему даже иссуй есть.

Вызвать $company->contracts->delete() мы тоже не можем, потому что $company->contracts — это просто коллекция, нет такого метода у коллекции. Чтобы события сработали (например, чтобы удалить дочерние модели контрактов), нужно загружать каждую модель и вызывать delete() на ней. Примерно так:

static::deleting(function (Company $company) {
   $company->contracts->each(function (Contract $contract) {
       $contract->delete();
   });
});

Также подойдет метод Contract::destroy(), в который нужно передать массив с айдишниками контрактов — он сделает то же самое, что и приведенный выше код.

Допустим у нас есть форма и мы хотим в её интерфейс добавить какой-нибудь ajax-запрос к серверу. И Form API с его #ajax нам не поможет, потому что запрос происходит в каком-нибудь событии из сторонней библиотеки. В общем, надо сделать сервис и обратиться к нему через $.ajax(), или $.getJSON().

При этом, конечно, хотелось бы защитить сервис от CSRF. Ну и вообще, чтобы посторонние люди или боты не долбились по адресу сервиса без разрешения. Если бы запрос происходил через Form API, Друпал сделал бы всё за нас. Но и сами мы тоже можем, и на странице с формой для этого уже всё, что нужно — есть.

В Drupal 7 каждая форма защищена парой скрытых значений в $form['form_id'] и $form['form_token'], соответственно, мы можем их подобрать и использовать при отправке на сервер. Для простоты, сделаем эти значения частью пути к сервису.

var form = $('#my-custom-form');
var form_id = form.find('input[name="form_id"]').val();
var form_token = form.find('input[name="form_token"]').val();
var url = '/my-custom-service/' + form_id + '/' + form_token;
$.getJSON(url, function (data) {
    alert('Все готово!');
});

В hook_menu() пункт, отвечающий за генерацию ответа, оформим так:

$items['my-custom-service/%/%'] = array(
    'page callback' => '_my_custom_service',
    'access callback' => '_my_custom_service_access',
    'access arguments' => array(1, 2),
    'type' => MENU_CALLBACK,
);

То есть мы передаем в access callback эти два значения как аргументы. Тогда в функции, управляющей доступом, мы можем легко проверить валидность токена:

function _my_custom_service_access($form_id, $form_token) {
  return drupal_valid_token($form_token, $form_id);
}

И всё.

На днях понадобилось немного изменить структуру БД в проекте, так чтобы уже созданные модели не пропали. То есть скинуть все данные моделей куда-нибудь, потом сделать изменения, потом данные восстановить. Стал, в общем, писать небольшой бэкапчик, без особых изысков, просто чтоб работал.

В Ларавеле с моделями работать удобно и получить их данные в целом довольно просто.

$user = User::find(1);
$data = $user->toArray();

И все, у нас в массиве есть данные модели, можно их склеить в строку, например, и скинуть в файл. Но есть немного нюансов.

Рассмотрим вставку виджета внутрь сторонней бэкэнд-формы и обращение к вставленному виджету из JS для подгрузки контента. На этом примере мы узнаем:

• что такое виджет в OctoberCMS, зачем он и как его сделать;
• как прикрепить виджет к контроллеру, определенному в другом плагине;
• как пользоваться ajax-фреймворком в OctoberCMS.

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

• Form Widget, то есть для использования в формах, для манипуляции данными моделей,
• Report Widget для вывода полезных данных на панель управления в бэк-энде,
• и просто Widget — для использования в любом контроллере бэк-энда. Например, Media Manager, красивый диалог для вставки медиа-файлов в текст, реализован в OctoberCMS как виджет.

В данной заметке мы будем делать ajax-диалог (который потом превратится в диалог выбора фотографий и вставки специального маркдаун-кода выбранной фотографии в текст).