Недавно заметил, что в одном из проектов после экспорта-импорта переводов (через po-файлы) поломалась плюрализация. То есть вместо обычных 3-х форм перевода на русский, стали появляться английские две формы. Раньше, несколько лет назад, с таким уже сталкивался. Чтобы починить, нужно было экспортнуть файл с сайта, где работает нормальная русская формула и импортнуть на сломанный.

Но оказалось, что в Drupal 8 эта проблема начинается уже с экспорта. Экспортированный ru.po с сайта, где с плюрализацией всё в порядке, внезапно содержал дефолтную английскую формулу. Попытка выкачать и вставить нормальную формулу со старого сайта на Drupal 7 тоже не помогла. При импорте просто ничего не происходило, формула оставалась дефолтной.

Пришлось поковыряться в коде и оказалось что в Drupal 8 формула плюрализации хранится (в state) не в виде строки, а в виде массива вариантов. Пришлось сделать сначала

drush eval "print_r(\Drupal::state()->get('locale.translation.formulae', []));"

на нормальном сайте для получения русской формулы.

После чего оформить её в правильный массив и выполнить вот такой код:

$formula = Array(
  'ru' => Array(
    'plurals' => 3,
    'formula' => Array(
      1 => 0,
      2 => 1,
      3 => 1,
      4 => 1,
      21 => 0,
      22 => 1,
      23 => 1,
      24 => 1,
      31 => 0,
      32 => 1,
      33 => 1,
      34 => 1,
      41 => 0,
      42 => 1,
      43 => 1,
      44 => 1,
      51 => 0,
      52 => 1,
      53 => 1,
      54 => 1,
      61 => 0,
      62 => 1,
      63 => 1,
      64 => 1,
      71 => 0,
      72 => 1,
      73 => 1,
      74 => 1,
      81 => 0,
      82 => 1,
      83 => 1,
      84 => 1,
      91 => 0,
      92 => 1,
      93 => 1,
      94 => 1,
      101 => 0,
      102 => 1,
      103 => 1,
      104 => 1,
      121 => 0,
      122 => 1,
      123 => 1,
      124 => 1,
      131 => 0,
      132 => 1,
      133 => 1,
      134 => 1,
      141 => 0,
      142 => 1,
      143 => 1,
      144 => 1,
      151 => 0,
      152 => 1,
      153 => 1,
      154 => 1,
      161 => 0,
      162 => 1,
      163 => 1,
      164 => 1,
      171 => 0,
      172 => 1,
      173 => 1,
      174 => 1,
      181 => 0,
      182 => 1,
      183 => 1,
      184 => 1,
      191 => 0,
      192 => 1,
      193 => 1,
      194 => 1,
      'default' => 2,
    )
  )
);

\Drupal::state()->set('locale.translation.formulae', $formula);

Тогда нормальная формула вернулась на место.

На эту тему есть несколько ишью, залинкованных между собой, и пока не закрытых. Вот например. А пока — экспортируем и импортируем переводы осторожно.

Время от времени бывает необходимо организовать файловое хранилище за пределами /public. Например, для того, чтобы контролировать доступ к файлам (недоступным по прямой ссылке) по неким правилам.

Сходу из коробки в Laravel 6 такая фича на 100% не предусмотрена, но сделать её руками достаточно нетрудно.

Для начала разобьем задачу на части. Нам нужно:

1. Определить, где будут храниться файлы (private storage).
2. Прикреплять файлы к некой модели, чтобы на основе этой модели управлять доступом.
3. Обеспечить сохранение файлов в private storage.
4. Реализовать, собственно, контроль доступа и выдачу файлов по некоему пути.
5. На закуску добавим автоматическую генерацию миниатюр.

Далее мы разработаем приватное файловое хранилище с управлением файлами с помощью библиотеки spatie/laravel-medialibrary.

Несколько лет назад прикупил вместо поднадоевшего Нетбинса прогрессивную среду разработки под названием PHPStorm. С тех пор пользуюсь постоянно, и время от времени нахваливаю.

А недавно заметил, что некоторые фокусы, которые в PHPStorm (и других IDE этого производителя) мне уже привычны, для кого-то могут быть неочевидными. Все мы уже взрослые, опытные, образованные и поэтому мануалы читаем только когда что-нибудь уже сломалось. А то бы и так знали все эти мелочи, а не находили опытным путем, или подглядев у кого-нибудь.

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

Если есть что добавить, прошу писать в комменты, всем будет полезно.

Важное уточнение: если я говорю про хоткей (он же шорткат), то есть про комбинацию кнопок — она по умолчанию у вас может быть выключена. В таком случае нужно искать её в настройках IDE, благо там есть поиск по всем существующим настройкам.

В первой части статьи мы строили бэкенд на Laravel для вывода разнородных событий на календаре. В этой части мы рассмотрим построение фронт-энда на Vue.js с помощью FullCalendar, для которого есть интеграция fullcalendar-vue. Получится примерно как на картинке.

Что вообще должен делать наш фронт-энд?

Во-первых, загружать из бэк-энда события по созданному ранее пути /api/calendar.

Во-вторых, отображать эти события в соответствии с установленными для них датами.

В третьих, как-то визуально отличать одно событие от другого, чтобы было нагляднее.

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

Будем считать эти четыре пункта нашим ТЗ на фронт-энд и приступим к реализации.

В данной заметке из трёх частей рассматривается построение календаря, отображающего события, связанные с разнородными сущностями системы. Бэк-энд реализован на Laravel, фронт — на Vue.js. Календарь сделаем с помощью Full Calendar и соответствующей интеграции fullcalendar-vue.

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

В результате получится примерно вот так:

Когда-то давно, ещё в аспирантуре, один ученый муж всё время говорил мне: «Роман, делай правильно. Выполнил работу — оформи её. Напиши статью».

Прошло больше десяти лет, а я до сих пор считаю, что это прекрасный совет, пригодный не только в академической деятельности, а практически везде. Написание связного текста — это ведь не просто возможность потешить внутреннего графомана (что тоже важно). Это еще и прекрасный способ порефлексировать о только что проделанной работе.

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

Некоторое время назад обнаружил статью, где показывалось, что трейт RefreshDatabase в тестах позволяет им (тестам) работать с MySQL быстрее, чем с Sqlite в режиме memory. Это выглядело странно и почти немыслимо, но оказалось, что, действительно, так и есть. Перевёл в нескольких проектах юнит-тесты с Sqlite на MySQL, заменил трейт с DatabaseMigrations на RefreshDatabase, и полный пакет тестов стал выполняться в среднем на ~30% быстрее (плюс большая совместимость с реальной средой достигается).

Работает оно быстрее — потому что трейт позволяет не поднимать все миграции заново в каждом тесте, а просто очищать уже созданные один раз таблицы. Но у этого достоинства есть, конечно, и логическое продолжение. Очевидный недостаток в том, что один раз создать эти таблицы всё же нужно. И это будет точно медленнее, чем в sqlite.

Соответственно, если ты практикуешь TDD, то в ходе разработки гораздо чаще запускаешь не полный пакет юнит-тестов, а какой-то один тест, верифицирующий тот кусок функционала, над которым, собственно, ты работаешь. И тут, за счет скорости развертывания миграций, MySQL очень сильно проигрывает.

Решить эту проблему, однако, очень просто. Нужно в «режиме TDD», то есть при запуске отдельного теста, использовать другой конфиг. В котором вместо MySQL подставлен sqlite:

<env name="DB_CONNECTION" value="sqlite"/>
<env name="DB_DATABASE" value=":memory:"/>

И запускать тест так:

phpunit -c phpunit_sqlite.xml <путь к тесту>

А чтобы не обламываться, что приходится каждый раз набирать ключик и путь к конфигу, нужно заменить эту команду простеньким синонимом:

alias tdd="phpunit -c phpunit_sqlite.xml"

Понятно, работать будет не для всех случаев. Например, если какой-нибудь из пакетов (spatie/laravel-tags, скажем) использует нативную поддержку JSON в MySQL, тесты этого функционала в sqlite работать вообще не будут. Но в целом этот трюк на длинной дистанции (особенно, с не очень быстрым компьютером) сэкономит прилично времени.

Есть такая известная парадигма в ООП — сервис-контейнеры. Суть её в том, чтобы получать реализацию того или иного сервиса, который тебе зачем-то нужен, из некоего контейнера. То есть не задумываясь о деталях, о том, что это за класс и т.д. Обращаешься к контейнеру — а контейнер сам определит, что надо, и вернет нужный сервис. Очевидно, если заранее не знаешь, о чем речь, из такого пояснения ни фига толком не ясно. Обычно эти пояснения иллюстрируются примерами. В доках Ларавела, скажем, используется пример EventPusher-а и его реализации через Redis.

Слабое место подобных примеров, на мой взгляд, в том, что для начинающего разработчика, не очень знакомого с концепцией контейнера и dependency injection, идея замены одной реализации сервиса на другую не очень близка. В голову сразу приходит, что у меня-то сейчас один класс используется — вот этот. Когда надо будет другой, тогда и контейнер сделаю, а пока буду явно обращаться к данному классу. И это, как мне кажется, вполне нормальный ход мыслей.

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

Допустим, вы в своих проектах практикуете TDD. И у вас, помимо всех остальных тестов, проверяющих всё на свете, есть тест создания какой-нибудь модели через API Post, или просто через форму. И вот внезапно вам понадобилось подцепить на эту форму проверку reCAPTCHA против спаммеров. Реализовать саму логику работы во фронте (на Vue.js) и проверку полученного токена в бэке — нетрудно (вот пример).

А вот тест создания модели (и все связанные с этим роутом/формой тесты) — немедленно поломаются. Потому что где вы возьмете валидный ключ капчи для проверки, если он в тестовом режиме не прилетает из фронта?

Можно было бы попытаться организовать прохождение капчи для бэк-энд тестов (хотя я не совсем понял, как это именно в случае reCAPTCHA сделать). Но: — от этого нет пользы помимо тестирования; — у нас нет задачи тестировать гугл-капчу в каждом тесте бэкенда, который проверяет работу методов post/put у каждой защищенной капчей формы; — для тестирования внешнего сервиса достаточно одного теста интеграции — что мы верно всё подключили — а остальное есть забота разработчика внешнего сервиса; — если каждый тест формы будет проверять ключ капчи через сервис гугла, тесты внезапно станут значительно дольше работать.

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

Отношения в Laravel в принципе довольно удобно сделаны и работать с ними приятно. Но бывают ситуации, решения для которых находятся в поиске и доках не сразу. Приведу пару небольших примерчиков.

Метод morphWith

Конкретно этот метод есть в доках, но он появился совсем недавно, в версии 5.8.22 (а текущая — 5.8.25) и не сразу нашёлся именно поэтому. Суть вот в чем. Допустим, у нас есть модель Event, которая радостно полиморфирует с другими моделями. Для неё отношения описаны так:

class Event extends Model
{
    protected $with = ['parent'];

    public function parent() {
        return $this->morphTo();
    }

    // ...
}

Как мы видим, благодаря свойству $with модель будет сразу загружаться с родителем, независимо от того, что это за родитель. Однако что, если нам нужно разом загрузить и какие-то отношения этого (неопределенного пока) родителя с другими моделями. Допустим, модели Payment и Deadline связаны полиморфно с Event, и в то же время модель Payment связана с моделью Order, а Deadline — скажем, с моделью User. Примерно так:

class Payment extends Model
{
    public function events() {
        return $this->morphMany('App\Event', 'parent');
    }

    public function order() {
        return $this->belongsTo(Order::class);
    }

    // ...
}

// (в другом, конечно, файле)

class Deadline extends Model
{
    public function events() {
        return $this->morphMany('App\Event', 'parent');
    }

    public function User() {
        return $this->belongsTo(User::class);
    }

    // ...
}

И мы хотим, чтобы платежи грузились с заказами, а дедлайны — с пользователями. Конечно, мы могли бы воспользоваться свойством $with для моделей Payment и Deadline. Но что если в Order и User уже используется свойство $with для загрузки платежей и дедлайнов? Тогда мы не сможем воспользоваться этим свойством, поскольку уйдем в рекурсию.

Тут-то и поможет нам метод morphWith():

$events = Event::query()
            ->with(['parent' => function (MorphTo $morphTo) {
                $morphTo->morphWith([
                    Payment::class => ['order'],
                    Deadline::class => ['user'],
                ]);
            }])
            ->get();

То есть что мы тут делаем? Мы вызываем для отношения MorphTo метод morphWith() и для каждого класса родителя, для которого нужно грузить его отношения, указываем массив из этих отношений. И они грузятся.

А что если надо отменить eager loading

Может возникнуть и прямо противоположная проблема. Допустим, мы автоматически грузим модель Payment из Order через свойство $with — это будет работать всякий раз, когда модель заказа загружается. Но что если нам в данном конкретном случае нужно автоматически загрузить заказы для группы платежей, и не попасть при этом ни в рекурсию, ни в «проблему N+1 запросов»?

Очевидно, нужно отключить eager-loading. Вот два примера, как можно это сделать.

1) Если может возникнуть рекурсия из-за $with, можно отключить автозагрузку прямо в объявлении отношения:

public function order() {
    return $this->belongsTo(Order::class)->setEagerLoads([]);
}

Здесь мы говорим, что при загрузке заказов для данных моделей, не нужно автоматически грузить никакие модели, связанные с заказами (и перечисленные в Order::$with). Кстати, вместо пустого массива мы можем передать массив из отношений, которые всё же нужно загрузить, ограничив таким образом автозагрузку заданным списком.

2) Если же мы прогружаем отношения явным образом с помощью метода load(), можно отключить автозагрузку вот так:

$payment->load(['order' => function ($query) {
    $query->setEagerLoads([]);
}]);

Напоследок замечу вот еще что. Хотя свойство $with и довольно удобно в целом, так как работает автоматически, бездумное его использование представляется частным случаем преждевременной оптимизации. Когда мы не знаем, как часто и какие зависимости нам потребуются, велик соблазн пихнуть их все в массив $with и забыть. Однако позже, при описании уже реальных кейсов, вполне может возникнуть ситуация, когда отношения, перечисленные в автозагрузке придётся удалять и переделывать одно за другим.

Не нужно, в общем, торопиться с оптимизацией.

Допустим, вы из контроллера возвращали коллекцию моделей в JSON, вот так:

public function index() {
    $posts = Post::all();

    // что-то делаем с постами

    return response()->json($posts, 200);
}

А на стороне фронт-энда работали с получившимся массивом, и всё было хорошо.

И вдруг в один не очень прекрасный день массив во фронт-энде внезапно превратился вот в такой объект:

{
    1: {id: 1, ...},
    2: {id: 5, ...},
    3: {id: 6, ...},
    4: {id: 12, ...},
    // ...
}

И всякие там posts.forEach() во фронт-энде сломались.

В первую очередь, нужно посмотреть на методы коллеций, применяемые к $posts. Если вы использовали filter(), или forget(), или возможно reject(), то эти методы сохраняют ключи элементов получившейся коллекции в тех значениях, что были до изменений. То есть индексированный массив превращается в ассоциативный. Вот чтобы сохранить эти ключи, в JSON и отправляется такой дурацкий объект.

А чтобы сбросить ключи и снова сделать массив индексированным, нужно воспользоваться методом values():

public function index() {
    $posts = Post::all();

    $filtered_posts = $posts->filter(function (Post $post) {
        return $post->published;
    });

    return response()->json($fitlered_posts->values(), 200);
}