Есть в Друпале широко известный модуль 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 также заданы значения для метров, миль, ярдов, футов и морских миль.

Как я уже писал раньше, в OctoberCMS из коробки работает фильтр Markdown, который можно применять практически везде. В плагине Blog текст каждой заметки проводится через фильтр перед сохранением, а сохраняется уже готовый html. Но при этом, по загадочным для меня причинам, excerpt (то есть анонс) заметки через фильтр Markdown не пропускается.

Из-за этого приходится либо для анонса переводить маркдаун в html вручную, либо при выводе анонса выводить его с фильтром {{ excerpt | md }}. Со вторым вариантом можно жить, но в сомнениях: ведь анонс каждого поста на странице будет обрабатываться фильтром при каждой загрузке ленты. Непорядок, надо же экономить электроэнергию-то!

Проблему можно решить аккуратно в несколько строчек кода. Раз плагин Blog не преобразует маркдаун в анонсе перед сохранением, поможем ему:

Post::extend(function (Post $model) {
  $model->bindEvent('model.beforeSave', function() use ($model) {
    $model->excerpt = Markdown::parse($model->excerpt);
  });
});

Здесь мы добавили для модели Post обработчик события model.beforeSave, которое происходит всякий раз перед созданием или обновлением заметки в блог. В обработчике мы просто пропускаем анонс через фильтр маркдауна (обратите внимание, для простоты здесь использован фасад Markdown).

Всё, теперь анонсы новых заметок будут обработаны фильтром маркдаун при сохранении. Для порядка можно еще разово обработать анонсы старых заметок. Сделать это нетрудно. Добавим новую команду artisan:

php artisan create:command AuthorName.MyPlugin MyCommand

И в теле метода fire() выполним код:

$posts = Post::where('excerpt', '<>', '')->get();
foreach ($posts as $post) {
  $post->save();
}

То есть находим все заметки, у которых задан анонс и просто пересохраняем их. При пересохранении выполнится наш обработчик события и анонс будет обработан фильтром Markdown.

Для удобства обработчик события и команда обработки старых заметок — добавлены в мой плагин BlogArchive.

Есть у Entity API в Drupal 7 такой любопытный хук — hook_entity_property_info_alter(). Он позволяет очень быстро добавить к любой сущности (например, к ноде) новое свойство, вычисляемое функцией, указанной в этом же хуке.

Допустим, у нас есть тип содержимого «фотоальбом» (album), а к нему через entity reference прикреплены материалы-фотографии. И нам нужно получить количество прикрепленных фотографий. Далее пример с кодом и пояснение, зачем это нужно

Многих интересует, а как в OctoberCMS расширять «чужие» модели и формы. Один из авторов системы, Сэмюэл Джорджс, показывает на пальцах как:

Вообще, я не большой фанат скринкастов о программировании. Но как автор обращается с мультикурсорностью — любо-дорого смотреть.

В OctoberCMS из коробки работает фильтр Markdown, он применяется почти везде и, к тому же, его можно легко применять к любому тексту вручную. И, что важно, фильтр автоматически применяется к записям плагина Blog перед сохранением готового к выводу html.

Если мы хотим применить к проходящему через Markdown тексту какие-то свои фильтры, можно прицепиться к событию markdown.parse. Это событие генерируется сразу после парсинга входящего текста самим фильтром. Подключимся к нему в методе boot() нашего плагина:

public function boot() {
  Event::listen('markdown.parse', 'Author\PluginName\Classes\MarkdownExtender@parse');
}

Теперь при каждом применении фильтра Markdown будет вызываться метод parse() класса MarkdownExtender, который должен находиться в author/pluginname/classes/MarkdownExtender.php. Код класса:

namespace Author\PluginName\Classes;

class MarkdownExtender {

  public function parse($text, $data) {
    // в $text находится оригинальный текст
    // а в $data->text - результирующий
  }
}

Производим все нужные манипуляции с текстом в $data->text и сохраняем результат обратно, сверяясь с оригиналом в $text при необходимости. Вот и всё.

С днем программиста, коллеги! Успехов в работе и интересных проектов!

Как известно из документации, OctoberCMS предоставляет для Twig ряд расширений. В том числе среди них есть тег {% placeholder %}, позволяющий собирать фрагменты разметки из разных шаблонов в один блок. Вот например есть у нас лейаут:

<html>
    <head>
        {% placeholder head %}
    </head>
    <body>
    ...
    </body>
</html>

Этот тег выведет вместо {% placeholder head %} всё, что будет добавлено туда в других шаблонах. То есть если мы в шаблоне с выводом блог-поста добавим

{% put head %}
  <meta name="title" content="Домовая страница | Graker.Ru">
  <meta name="author" content="Graker">
{% endput %}

а потом еще где-нибудь добавим

{% put head %}
  <link rel="icon" type="image/png" href="http://graker.ru/themes/grakerru/assets/images/icon.png" />
{% endput %}

то всё это попадет в head. Такая вот полезная фича.

P.S. Скрипты и стили вручную собирать в плейсхолдеры не нужно, для этого в October уже есть готовые {% scripts %} и {% styles %}. Но и к ним можно при желании добавить скрипт/стиль с помощью {% put %}.

Вообще, у OctoberCMS есть плагин Wysiwig Editors. С этим плагином можно из коробки получить для блог-постов поддержку TinyMCE, CKEditor и даже Froala. Но я все это попробовал и пришел к выводу, что мне встроенный Markdown-редактор как-то ближе — то ли ввиду чистоты HTML на выходе, то ли еще почему. Решил пока на нем остановиться.

Но есть у этого редактора недостаток: чтобы понять, как его расширить, надо покопаться в коде. Код чистенький, понятный, но покопаться надо. В общем, я покопался, теперь рассказываю, как добавить в Markdown-редактор новую кнопку на примере своего старого js-типографа.

TL;DR: рассматриваемый далее код можно опробовать в действии в составе плагина BlogArchive.

О настройке xdebug в PHPStorm уже написали три тыщи человек и еще xandeadx. А я только добавлю на память то, чего не хватает для проброса отладчика в IDE прямо из действующего контейнера docker.
Предполагается что в конфиге (например /etc/php5/mods-available/xdebug.ini) уже есть что-то вроде

zend_extension=/usr/lib/php5/20100525/xdebug.so
xdebug.remote_enable=1
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000

Тогда пробросить отладчик от действующему контейнера к IDE очень просто с помощью ssh-туннеля. Включаем внутри контейнера ssh, а с хоста (то есть не из контейнера) создаем туннель:
(здесь предполагается, что IP контейнера — 172.17.0.2)

ssh -R 9000:localhost:9000 username@172.17.0.2

Как только туннель будет налажен — можно начинать слушать PHP Debug connections в PHPStorm-е и запускать отладчик в браузере. Все должно подхватиться.

Все-таки, не люблю я их, особенно по программированию. Вот например Laracasts, кладезь полезной информации. Но как же, блин, неудобно. Берешь урок по каким-нибудь Middleware или по Eloquent — полезную информацию, будь она в текстовой форме со вставками кода, можно было бы извлечь за 2 минуты. Пробежал глазами ненужное, нашел нужное, прочитал, уяснил. Если ленивый — еще и код скопировал.

А видео? Сидишь перематываешь вперед-назад по минутке, как дурак, чтобы не пропустить, что ищешь. Находишь — смотришь код, слушаешь, что сказал автор. Код не скопировать и в гугл не воткнуть. Поиском не воспользоваться. Если надо второй раз послушать, перематываешь видео, вместо того чтобы проскроллить просто страничку. И думаешь в конце — а сколько всего за это время сделать-то можно было.