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

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

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

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

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

Отлично, нельзя не перепостить.

По рассылке пришел курс с видеокастами про кэширование, индексы и прочий eager-loading. В общем, оптимизация приложений на Laravel.

Так-то я видеоролики по программированию не очень люблю. Но вот этот можно и посмотреть. Курс бесплатный, для доступа требуется только подписаться на рассылку.

Курс Performant Laravel

In this post, we’ll make a toy posts app to show how Gate gives you liberty and decoupling. The web app will have two user roles (authors and editors) with the following permissions:

• Authors can create a post.
• Authors can update their posts.
• Editors can update any post.
• Editors can publish posts.

An Introduction to Laravel Authorization Gates

Полезно и наглядно.

Есть в OctoberCMS такая полезная штука — бихевиор для ручной сортировки моделей. Например, чтобы перетаскиванием отсортировать категории по значимости (и вложенности). Использовать его для своих моделей — очень просто, вот страничка в документации. Подключаем бихевиор к классу-контроллеру, заполняем конфиг, а в модели используем трейт Sortable (или NestedTree). А что такое бихевиор, можно тоже прочитать в доках.

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

Бихевиор ReorderController для этого использовать не получится, придется строить сортировку вручную. Однако если покопаться, как устроен ReorderController, его шаблоны и трейт Sortable, можно сделать свою сортировку по аналогии и даже не дублировать какую-то часть кода. Об этом и поговорим.

В плагинах OctoberCMS обычно мы имеем дело с моделями. Допустим, есть у нас вот такой список моделей как на картинке. Это список моделей Photo, принадлежащих одной модели Album. Сделать такой список легко — пара строчек в контроллере и он создастся автоматически.

Как можно заметить, список в данном случае не сильно удобный: у многих фотокарточек нет названия. Через это вообще невозможно понять, где какая фотография находится. В общем, хотелось бы, чтобы в таблице были картинки. Ну и заодно чтоб можно было отметить ту картинку, которая выбрана обложкой альбома.

Список столбцов задается (по умолчанию) в файле columns.yaml для отображаемой модели. Туда можно добавлять новые столбцы, но их набор довольно ограничен. Зато, как написано на этой же странице документации, можно добавлять свои типы столбцов. И сейчас мы рассмотрим эту возможность, чуть-чуть подробнее, чем в доках.

В принципе, тесты в OctoberCMS устроены примерно так же, как и в Laravel. Но поскольку это CMS и у нее есть плагины — к ним можно писать отдельные тесты. Правда, документация по этому вопросу довольно лаконична.

Вот, есть, например, в плагине компонент и на него нужно написать тесты. Чтобы это сделать, нам понадобится экземпляр класса компонента, но как его создать? Просто оператором new не получается. В общем, решение нашлось (не сразу) в дебрях тестов самого октября, привожу, вдруг кто еще искать будет:

$theme = Theme::load('test');
$page = Page::load($theme, 'index.htm');
$layout = Layout::load($theme, 'content.htm');
$controller = new Controller($theme);
$parser = new CodeParser($page);
$pageObj = $parser->source($page, $layout, $controller);
$manager = ComponentManager::instance();
$component = $manager->makeComponent('myComponent', $pageObj);

То есть, оказывается, нужна особая магия в виде создания сущностей из «тестовой» темы и генерации компонента с их помощью. Вот бы узнать, где можно почитать об этом, помимо исходников.

Кстати, третьим аргументом в makeComponent() можно передать массив свойств компонента. Поможет протестировать логику, когда свойства должны отличаться от дефолтных.

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

Находишь баг, думаешь: вот сейчас не буду кривляться, сделаю как надо — напишу тест на баг и по тесту буду чинить. Разбираешься, придумываешь тест, пишешь его, запускаешь. И внезапно понимаешь, что в тестируемом функционале есть ::orderBy(DB::raw('RAND()')) — mysql-зависимый запрос. А в Laravel тесты запускаются на sqlite.

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

You’ve created a new Laravel app for your client and deployed it on the production server. Everything was working fine till a customer has a problem with the app because of some buggy code. He immediately leaves the app, and the same thing happens with multiple customers before you know about the bug. You fix the bug, and then everything is on track.

But what if you were notified immediately through e-mail (or another service) about the bug and you fix it ASAP. In Laravel, this can be done easily and in this post, we’re going to learn how.

Learn How to Send an Email on Error Exceptions

Полезно.

Есть в Друпале широко известный модуль Geofield, полезный для хранения информации о местоположении. В смысле, широты и долготы того или иного объекта. Помимо просто хранения (например, для вывода на карту), модуль умеет и вычислять расстояние между двумя точками по широте и долготе. Для этого используется известная формула гаверсинусов, дающая вполне приемлемую погрешность для бытового применения.

Для вычисления расстояний имеется интеграция во Views, то есть можно выводить расстояния как поля вьюза, можно сортировать по расстоянию. Но что если нам нужно обойтись без Views и добавить расчет расстояния в собственный запрос? Чтобы не дублировать функционал, можно воспользоваться функцией geofield_haversine().

Функция генерирует SQL-формулу для вставки вычисления расстояния прямо в запрос. Вот пример кода для выборки nid материалов, отсортированных по возрастанию расстояния до заданной точки.

$query = db_select('node', 'n');
$query->fields('n', array('nid'));

$query->join('field_data_field_location', 'l', 'n.nid = l.entity_id');
$query->condition('l.entity_type', 'node');
$haversine_args = array(
  'earth_radius' => GEOFIELD_KILOMETERS,
  'origin_latitude'  => $lat,
  'origin_longitude' => $lon,
  'destination_latitude'  => 'l.field_location_lat',
  'destination_longitude' => 'l.field_location_lon',
);
$query->orderBy(geofield_haversine($haversine_args));
$nids = $query->execute()->fetchCol();

Код написан исходя из того, что координаты хранятся в поле field_location. В аргументах origin_latitude и origin_longitude передается широта и долгота заданной точки, а в earth_radius, конечно, радиус Земли. Передавать его нужно в тех единицах измерения, в которых хочется получить результат. В данном случае — в километрах, но в модуле geofield также заданы значения для метров, миль, ярдов, футов и морских миль.