Есть в 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',

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

Допустим, хотим мы добавить в формы нашего фронт-энда такой популярный плагин как datetimepicker. То есть красивый элемент для выбора даты и времени.

У Vue.js есть для этого несколько разных библиотек с компонентами, вот одна из них: Vue Bootstrap Datetimepicker. Данная библиотека при подключении позволяет использовать компонент date-picker. Компонент достаточно гибкий, с разнообразными настройками, можно выбирать дату, можно дату и время, поддерживаются форматы, используется moment.js, всё хорошо.

TL;DR: Далее рассматривается создание компонента-обертки, инкапсуляция настроек дейтпикера в нём, дополнительные настройки и пропы.

В документации на фреймворк я не заметил об этом ни слова. Но оказывается, в Ларавеле обновление моделей по $model->update() действительно происходит только если переданы данные, отличающиеся от уже сохраненных. А если данные переданы те же, никакого апдейта не случится, и даже updated_at останется тем же.

Заметил случайно, когда чесал репу — почему же я запускаю скрипт апдейта данных из внешнего реестра, а время в updated_at по-прежнему равно времени создания. Хотя и тесты проходят, и скрипт запускается без ошибок. А вон оно как.

Если все же нужно, чтобы время обновления поменялось даже если запроса не было, надо использовать метод $model->touch().

Мне кажется, такие вещи в документах нужно писать большими буквами рядом со счетчиком уже пострадавших программистов.