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

Допустим, мы хотим принять массив с переменным количеством элементов, а в каждом элементе чтобы были поля id и weight. Вот так:

[
  'items' => [
    ['id' => 1, 'weight' => 5],
    ['id' => 5, 'weight' => 4],
    ['id' => 7, 'weight' => 3],
    ['id' => 8, 'weight' => 2],
    ['id' => 9, 'weight' => 1],
    // ...
  ],
]

Тогда нам нужно, чтобы поле items в запросе — присутствовало и было массивом, а значения id и weight — присутствовали и были целыми числами. Валидируется это так:

$data = $request->validate([
    'items' => 'array|required',
    'items.*.id' => 'integer|required',
    'items.*.weight' => 'integer|required',
]);

Таким образом будет отсечено все кроме поля items, в котором во всех элементах останутся только поля id и weight. Если по какому-то из значений вложенных элементов будут ошибки, то в errors они попадут с ключами items.i.id и items.i.weight, где i — индекс элемента в массиве items.

На днях совершил над собой титаническое усилие и добавил-таки своему Netspark.ru английскую версию. Учитывая, что это по сути одностраничник (ну, плюс 404 и «Сайт на обслуживании») — можно было бы тупо скопировать и поменять текстики на английские. Тем более английскую версию поставил на другой домен. Но все же чтобы фронт-энд был одинаковый в обеих версиях — мало ли там, добавить чего, поменять — решил использовать возможности локализации. О чем и расскажу немного.

Локализация в OctoberCMS — примерно такая же, как в Laravel. Есть файлы с локализацией, например lang.php, из них возвращаются массивы, примерно так:

return [
    'messages' => [
        'my_message' => 'Hello world',
    ],
];

После чего используется фильтр trans в твиге, где обращение к строке происходит как author.pluginname::lang.messages.mymessage. Author и pluginname — это имя автора и плагина, чтобы было ясно, откуда брать строки. Соответственно, файлы локализации должны жить в плагинах.

Это нормально, если проект не совсем примитивный и в нём есть кастомный плагин для всяких там дополнений и расширений. Но в рассматриваемом случае проект совсем примитивный и кастомных плагинов в нём нет, соответственно, хранить переводные строки негде. В таком случае нужно использовать плагин Translate. Если он установлен, хранить переводы можно прямо в theme.yaml используемой фронт-энд-темы. Заинклудить отдельный ямл с переводами тоже можно, да.

В файле строки будут храниться вот так:

translate:
    en:
        nav.portfolio: 'Our works'
        nav.services: 'Services'
    ru:
        nav.portfolio: 'Наши работы'
        nav.services: 'Услуги'

А обращаться к строчкам во фронт-энде можно с помощью фильтра твига _, вот так:

{{ 'nav.portfolio'|_ }}

То есть даже неймспейс никакой соблюдать не надо.

В фильтр перевода можно передавать параметры для подстановки:

{{ 'There are :works works in portfolio'|_({works: 1000}) }}

Естественно, строчку There are :works works in portfolio тоже можно положить в ямл и заменить дескриптором.

Помимо фильтра перевода _, есть и фильтр __, вызывающий transchoice() и помогающий в правильном склонении множественных чисел.

Чтобы строки из yaml-файла попали в систему, нужно их сначала обнаружить плагином Translate. Для этого со страницы переводов нужно запустить сканирование сообщений и затем почистить кэш.

К слову, если пользоваться плагином Translate, хранить строки в yaml-файле вообще необязательно. Если подать любую строку во фронт-энде на фильтр перевода, она может быть отсканирована и переведена через админку плагина. Примерно как функция t() в Друпале — засунул в неё что-нибудь, и это что-нибудь стало можно перевести. Но что еще интересно, в отличие от Друпала, где системный язык всегда английский и мы переводим с него, в OctoberCMS с плагином Translate дефолтный язык — действительно дефолтный. То есть мы можем сделать сайт на русском, сделать русский дефолтным, и переводить строки с русского на французский, или китайский, вообще без какого-либо упоминания английского.

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

Напоследок приведу пример определения текущей локали в системе. Я просто добавил обработчик onStart() в лейаут, и страницам, использующим этот лейаут, стали доступны переменные switchLocaleName, switchLocaleFlag и switchLocaleLink.

use RainLab\Translate\Classes\Translator;
protected $translator;

function onStart() {
    $this->translator = Translator::instance();
    $switchLocale = ($this->translator->getLocale() == 'ru') ? 'en' : 'ru';
    $this['switchLocaleName'] = ($switchLocale == 'ru') ? 'Русская версия' : 'English version';
    $this['switchLocaleFlag'] = 'assets/img/flags/' . $switchLocale . '.svg';
    $this['switchLocaleLink'] = ($switchLocale == 'ru') ? 'https://netspark.ru' : 'https://netspark.pro';
}

Лично мне это пригодилось, чтобы построить свой переключатель языков, который направляет на другой домен, вместо изменения языка в URL.

Есть в Drupal такой модуль, S3FS, создает стрим-враппер s3:// для работы с файловыми бакетами на Amazon S3. Модуль в принципе удобный и работает, но вот только не все файловые функции умеют в такой стрим. Например, если мы хотим проверить, существует ли в бакете файл, то file_exists('s3://myfile.txt') всегда вернёт FALSE.

Если заглянуть в код класса S3fsStreamWrapper, то там для проверки используется $this->s3->doesObjectExist(). Можно было бы сделать красиво, вот так:

file_stream_wrapper_get_instance_by_scheme('s3')
  ->s3
  ->doesObjectExists('my-bucket', 'myfile.txt');

Только вот незадача: $this->s3 — клиент S3 Aws\S3\S3Client, вокруг которого работает стрим-враппер — это protected-свойство.

Пришлось ковыряться и делать некрасиво:

$config = _s3fs_get_config();
$s3 = _s3fs_get_amazons3_client($config);
$s3->doesObjectExist('my-s3-bucket', $filename);

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

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

Как я уже упоминал, в коробке Drupal 8 есть такой полезный модуль Content Moderation. Он позволяет модерировать материалы на базе редакций (revisions): материал может быть в состоянии (moderation_state) черновик, опубликован, или в архиве. Названия состояний можно менять, можно добавлять и новые состояния, и переходы между ними. При каждой смене состояния материала создается новая редакция. Благодаря этому можно, например, оставить проверенную редакцию опубликованной для всех пользователей сайта и, в то же время, работать с более новой редакцией в состоянии черновика.

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

Есть в Друпале такая полезная штука — редакции (которые revisions). На базе редакций работает, например, модуль Content Moderation, реализующий workflow для модерации контента с помощью состояний (черновик — опубликовано — в архив, и всё такое). Благодаря управлению состояниями через редакции, можно без труда реализовать такой сценарий:

1. Пользователь добавляет статью как черновик.
2. Модератор проверяет черновик и публикует статью.
3. Пользователь вносит правки.
4. Обновленная статья отправляется в черновики.
5. Но отмодерированная ранее статья остается опубликованной, пока модератор не примет новую версию.

Возможность оставить опубликованную версию видимой достигается за счет того, что редакция материала в состоянии «опубликовано» объявляется дефолтной (revision_default). Именно её будет по умолчанию загружать Друпал для отображения, в то время как при редактировании будет загружаться последняя редакция материала.

Так вот, нам может понадобиться проверить, является ли загруженная редакция сущности дефолтной. Для этого у контентных сущностей есть метод isDefaultRevision(). Вот только работает он иногда несколько неожиданно и может этим выклевать весь мозг. Оказывается, если вызвать этот метод, например, из hook_form_alter() при редактировании существующего материала (node/$id/edit) — он внезапно будет возвращать FALSE всегда. Независимо от того, дефолтную редакцию мы правим, или нет. Видимо, для редактирования Друпал заранее создает новую не-дефолтную редакцию и сущность готовит уже в этой редакции. Или типа того.

Так или иначе, поведение это совершенно контринтуитивное. Особенно учитывая, что если в этот момент запросить у сущности revision id — то вернётся как раз id дефолтной редакции (если редактируется она). Но isDefaultRevision() все равно будет FALSE.

Возможность выкрутиться из этой странной ситуации, тем не менее, есть — в виде метода wasDefaultRevision(), который проверяет, была ли эта редакция дефолтной при последнем сохранении сущности. Из hook_form_alter() этот метод отрабатывает ожидаемо — возвращая TRUE, если редактируется дефолтная редакция, и FALSE — если последняя не-дефолтная. Такие дела.

Если пишешь бэкэнд на Laravel, API какой-нибудь, то лучше конечно сопровождать все это дело тестами. Даже если ты не адепт TDD, написать в тесте

$response = $this->json('POST', '/api/my-resource', [
    'data' => $myData,
]);

и проверять $response — гораздо удобнее, чем вручную составлять запросы после каждого изменения.

Однако при написании таких тестов нужно помнить вот о каком нюансе. Обычно при тестировании запросов дополнительные сервисы имитируют. Например, если в реальном запросе у нас идет обращение к файлам на диске Storage::disk('files'), то в тесте мы используем mocking вот так: Storage::fake('files'), я об этом когда-то написал несколько букв. Соответственно, диск в тесте создается фейковый и тест не гарантирует, что в боевой ситуации реальный диск создастся и проинициализируется правильно. Что в общем-то касается и других фейковых объектов. А также подстановки csrf-токенов: при обращениях через $this->json() (или post(), или get() etc) csrf-токен подставится автоматически. Но это не гарантирует, что на продакшне клиент возьмет откуда-то этот токен и правильно его подставит.

Поэтому помимо обычных тестов может быть не лишним прикрутить тесты запросов «извне», например через cURL:

<?php

namespace Tests\Feature;

use Tests\TestCase;

class CurlRequestTest extends TestCase {

    /**
     * @test
     */
    public function user_can_curl_post_to_get_data() {
        $myData = 'Тестовая строка';
        $json = json_encode([
            'data' => $myData,
        ]);

        $ch = curl_init('http://localhost/api/my-resource');
        curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "POST");
        curl_setopt($ch, CURLOPT_POSTFIELDS, $json);
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
        curl_setopt($ch, CURLOPT_HTTPHEADER, array(
                'Content-Type: application/json',
                'Content-Length: ' . strlen($json))
        );
        $result = curl_exec($ch);

        $this->assertEquals(200, curl_getinfo($ch, CURLINFO_HTTP_CODE));
        $data = json_decode($result, TRUE);
        $this->assertEquals([
            'data' => 'Тестовая строка',
        ], $data['data']);
        curl_close($ch);
    }

}

Раньше не обращал внимания, а оказывается в Drupal 8 прикольно так сделана плюрализация в шаблонах. То, для чего раньше нужно было бы вставлять вызов format_plural(), в восьмерке можно сделать операторами твига:

{% set count = node.my_node_views_count %}
{% trans %}
    1 view
    {% plural count %}
    {{ count }} views
{% endtrans %}

Допустим, у нас есть модель Post и у неё есть теги Tag, множественная связь. И мы загрузили несколько моделей постов с тегами, например вот так:

$posts = Post::with('tags')->all();

В $posts находится, конечно, коллекция. Теперь, если нам нужно собрать со всех постов теги в одну коллекцию, причем чтобы не было дублей, можно это сделать вот так:

$posts = Post::with('tags')->all();
$tags = $posts->reduce(function (Collection $collection, Post $post) {
    $collection = $collection->merge($post->tags);
}, collect());

Feel da power of Laravel collections!

Время идет, часики тикают. И если пенсия от меня отдаляется, то почтенный возраст — наоборот, приближается стремительным домкратом. И подстилать соломку нужно уже сейчас.

В общем, смастерил на днях модуль для авторизации drupal-сайта в «Одноклассниках». Называется Social Auth Odnoklassniki, сделан на базе Social Auth, для которого все остальные более молодежные интеграции уже есть.

Модуль поддерживает авторизацию через ok.ru, с извлечением имени пользователя, имейла и юзерпика. После установки нужно создать приложение в ОК как написано тут и запросить разрешение на извлечение имейла (см. здесь).

Если какие вопросы, обращайтесь тут или в issues.

В Laravel довольно удобно сделана валидация данных, переданных в запросе (например, от формы). Достаточно написать в контроллере

$data = $this->validate($request,[
    'myvalue' => 'required|integer',
    'myfile' => 'file',
    // ...
]);

и в $data попадет отвалидированный массив данных, если все условия соблюдены. А если нет — будет возвращен код ошибки 422 с соответствующими сообщениями.

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

'myfile' => 'file|mimes:docx',

но на деле оказывается, что оно не работает.