Есть в Друпале такая полезная штука — редакции (которые 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().

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

First, I want to admit that there are a lot of ways to implement or even think about multi-tenancy. For more thoughts on this, I recommend a wonderful presentation called Multi-Tenant Laravel by Tom Schlick. In this article, I will show multi-tenancy based on single database and Laravel Global Scopes.

Now, let’s add multi-tenancy to our database entries. Let’s imagine we have DB table called posts, and we want each user to see only their own posts.

Use Laravel Observers and Global Scopes to Create User Multi-Tenancy

Через один observer куда элегантнее, чем пихать сохраненение user id (или другой сущности-владельца!) в каждый контроллер.

В Drupal 8 у дефолтного поиска отсутствует возможность исключить из индексации тот или иной тип содержимого. Иссуй есть, а возможности — нет.

Можно сразу удариться в Search API, но для небольших сайтов может быть проще добавить ограничение по типам. Это не так уж трудно. Есть способ, подразумевающий вставку условий через хук query_alter по тегу search_node_search, добавляемому в поисковые запросы. Правда, тогда материалы не будут выводиться, а индексироваться — будут.

Но можно и запретить индексацию. Посколько D8 весь оопнутый и прогрессивный, отбросим теплые ламповые хуки и сделаем свой нанотехнологичный плагин поиска, унаследовав его от дефолтного NodeSearch.

Для этого создадим новый класс в нашем модуле в mymodule/src/Plugin/Search/NodeRestrictedSearch и наследуем его от уже существующего плагина. Это удобно, не нужно копировать ничего лишнего, достаточно добавить новое свойство, перечисляющее типы, которые мы ограничиваем (в данном примере это ноды типа store и secret_content):

<?php

namespace Drupal\mymodule\Plugin\Search;

use Drupal\Core\Access\AccessibleInterface;
use Drupal\node\Plugin\Search\NodeSearch;
use Drupal\search\Plugin\SearchIndexingInterface;

/**
 * @SearchPlugin(
 *   id = "node_restricted_search",
 *   title = @Translation("Content Restricted")
 * )
 */
class NodeRestrictedSearch extends NodeSearch implements AccessibleInterface, SearchIndexingInterface {

  protected $restrictedTypes = ['store', 'secret_content'];

И переопределить пару методов. Во-первых, метод, отбирающий ноды для индексации — мы скопируем код метода из родителя и добавим проверку типа материала:

  /**
   * {@inheritdoc}
   */
  public function updateIndex() {
    // Interpret the cron limit setting as the maximum number of nodes to index
    // per cron run.
    $limit = (int) $this->searchSettings->get('index.cron_limit');

    $query = $this->database->select('node', 'n', ['target' => 'replica']);
    $query->addField('n', 'nid');
    $query->leftJoin('search_dataset', 'sd', 'sd.sid = n.nid AND sd.type = :type', [':type' => $this->getPluginId()]);
    $query->addExpression('CASE MAX(sd.reindex) WHEN NULL THEN 0 ELSE 1 END', 'ex');
    $query->addExpression('MAX(sd.reindex)', 'ex2');
    $query->condition(
      $query->orConditionGroup()
        ->where('sd.sid IS NULL')
        ->condition('sd.reindex', 0, '<>')
    );
    // ПРОВЕРКА ТИПА:
    $query->condition('n.type', $this->restrictedTypes, 'NOT IN');
    $query->orderBy('ex', 'DESC')
      ->orderBy('ex2')
      ->orderBy('n.nid')
      ->groupBy('n.nid')
      ->range(0, $limit);

    $nids = $query->execute()->fetchCol();
    if (!$nids) {
      return;
    }

    $node_storage = $this->entityManager->getStorage('node');
    foreach ($node_storage->loadMultiple($nids) as $node) {
      $this->indexNode($node);
    }
  }

Во-вторых (для порядку), переопределим метод, который показывает в админке, сколько материалов проиндексировано и сколько осталось:

  /**
   * {@inheritdoc}
   */
  public function indexStatus() {
    $total = $this->database->select('node', 'n')
      ->fields('n', ['nid'])
      // ПРОВЕРКА ТИПА:
      ->condition('n.type', $this->restrictedTypes, 'NOT IN')
      ->countQuery()
      ->execute()
      ->fetchField();

    $query = $this->database->select('node', 'n');
    $query->distinct()
      ->fields('n', ['nid'])
      ->leftJoin('search_dataset', 'sd', 'sd.sid = n.nid AND sd.type = :type', [':type' => $this->getPluginId()]);
    // ПРОВЕРКА ТИПА:
    $query->condition('n.type', $this->restrictedTypes, 'NOT IN');
    $query->condition(
      $query->orConditionGroup()
        ->where('sd.sid IS NULL')
        ->condition('sd.reindex', 0, '<>')
    );
    $remaining = $query->countQuery()->execute()->fetchField();
    return ['remaining' => $remaining, 'total' => $total];
  }

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