В OctoberCMS из коробки есть возможность импортировать (и экспортировать) модели из csv-файлов. Как подключить импорт-экспорт к своим моделям — можно прочитать в небольшом мануале. А я пока попробовал импортировать посты прямо с домовой страницы, благо в плагине Blog импорт-экспорт уже подключен.

Выглядит это примерно вот так:

Загружаем csv-файл, устанавливаем соответствие между столбцами файла (слева) и полями модели (справа) и нажимаем «Импорт». И посты импортируются.

В процессе выгрузки из Drupal 6 (с помощью Views data export) и загрузки в October обнаружил несколько небольших проблем, которые нужно было решить перед импортом.

В поставку OctoberCMS уже входят скрипты Prettify, но по умолчанию они применяются только в бэкенде. Впрочем, подключить их к постам фронт-энда не очень трудно.

Сначала нужно добавить в разметку соответствующие скрипты и стили, например, вкорячив их в scripts и styles, или просто рядом с остальными ассетами в лейауте:

{% styles %}
<link href="{{ [
            // ...
            '~/modules/system/assets/vendor/prettify/theme-desert.css',
            // ...
        ]|theme }}" rel="stylesheet">

{% scripts %}
<script src="{{ [
            // ...
            '~/modules/system/assets/vendor/prettify/run_prettify.js',
            // ...
        ]|theme }}"></script>

(многоточия приведены для иллюстрации, что в массиве можно передать и склеить много разных скриптов)

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

<div class="content">
{{ post.content_html | replace({'<pre>': '<pre class = "prettyprint">'}) | raw }}
</div>

А если html генерится не стандартным маркдауном, а как-то еще, то можно сразу в pre добавить класс prettyprint, и фильтр не понадобится.

Когда нет под рукой фотошопа, Gimp-а не хватает (тени плохо отображаются), а верстать надо — есть неплохой инструмент, Adobe Assets. Он и картинки из слоев нарезает, и CSS для текста, цвета, теней и скругленных уголков генерирует. Сам пользуюсь давно и с точки зрения «посмотреть как верстать» этот браузерный инструмент легко заменяет фотошоп.

Но блин, как же раздражает, когда в двух соседних вкладках открыты assets и верстаемый сайт, и ты нажимаешь «Обновить» не в той вкладке.

Смастерил тут небольшой модуль, интегрирующий в Drupal 7 отправку SMS через шлюз Quick Telecom. Из коробки есть вывод баланса, форма с настройками (логин-пароль), передача на выбор по HTTP/HTTPS (все разруливается через drupal_http_request), ввод имени отправителя и периода отправки, тестовая форма для проверки.

С SMS Framework пока не интегрировал, может потом. Пользоваться просто: включаем модуль, в админке вводим логин-пароль и шлем смски функцией:

quicktel_sms_send($phones, $message)

На случай если кому пригодится, делюсь. Брать можно прямо с гитхаба.

В прошлом году время от времени работал с фреймворком Laravel. Писал API для одного некоммерческого проекта, перевел на него (с голого PHP) один коммерческий. Понравилось, даже статейку небольшую написал. Однажды, в какой-то из новостных лент по теме, попалось упоминание October CMS. В упоминании говорилось, что у этой CMS под капотом как раз самый настоящий Laravel и есть, версии 5.0. Немедленно захотелось посмотреть, и вот на днях — удалось поставить, поиграться и даже написать пару небольших плагинов. Делюсь впечатлениями.

В процессе работы регулярно использую docker. Использую не по основному назначению, а в качестве инструмента быстрой и легкой виртуализации. То есть в контейнерах у меня сайты или веб-приложения, по одному на контейнер. Сервер и БД в контейнере, код подключен через volume, чтобы можно было редактировать сразу из IDE. Как выяснилось, это довольно удобно в работе — не нужно загаживать локальное окружение всяким софтом разных версий, все можно пихнуть в соответствующий контейнер. И на нотбук перекидывать несложно. Плюс сами контейнеры запускаются почти моментально. В общем, пользуюсь регулярно.

А тут второй раз уже встала нужда поднять в локальном окружении Solr для Drupal Search API. В первый раз поднялось как-то криво и я даже забыл, как. Так что теперь делаю правильно и записываю, чтоб больше не забывать.

Уже достаточно давно мы в NetSpark работаем над социальной сетью туристического толка ТурБаза. Сейчас можно, так сказать, поделиться промежуточным результатом.

Сделан сайт на Drupal 7, на заказ. Фич на сайте много, активно используется Solr, Message, OG, Gmap и много чего еще. Кастомного кода тоже немало. Краткий обзор функционала и ссылки на полезные статьи по теме можно найти в нашем портфолио. Если какие вопросы, можно писать в комментарии прямо тут.

Сегодня мы немного поразбираемся в библиотеке CasperJS. Что такое CasperJS? Аннотация на сайте говорит нам, что это navigation scripting & testing utility, то есть инструмент для написания сценариев навигации и для тестирования. Работает CasperJS с помощью безбашенного headless-браузера PhantomJS (Webkit), либо с помощью почти-headless-браузера SlimerJS (Gecko).

Так что же с помощью CasperJS можно сделать? Например, можно написать вот такой скрипт:

casper.test.begin('Testing my website', function suite(test) {
  casper.start();
  casper.thenOpen('http://mytestsite.ru', function() {
    test.assertHttpStatus(200, 'Homepage was loaded successfully.');
    test.assertExists('div#logo', 'Header link to the homepage is present.');
    test.assertExists('form#user-login-form', 'Login form is present.');
  });
  casper.run(function() {
    test.done();
  });
});

Этот скрипт автоматически зайдет на главную страницу заданного сайта и проверит, что http-response равен 200, а затем проверит, что на странице присутствует div с логотипом и форма логина.

В процессе доработки Cotranslate.Net столкнулся с любопытным багом пагинации во Views 2 (Drupal 6 т.е.), с которым раньше как-то не встречался.

Воспроизводится он так:

1. Делаем модуль, в нем создаем новую таблицу истории (лога) с разными записями о том, что происходило с материалом.
2. Дружим эту таблицу с Views. Поскольку данные таблицы актуальны только для материалов, делаем ее не базовой, а просто join-им с {node}.
3. Создаем представление на базе материалов, в котором выводим поля из таблицы истории, в представление добавляем пагинацию (хоть полную, хоть мини — не важно).
4. Пока выводятся записи для всех материалов, все нормально, пагер появляется и работает.
5. Теперь добавим в таблицу аргумент, либо просто фильтр по nid (чтобы вывести историю только для заданного материала).
6. Profit Пагер немедленно пропадает. Причем не только из вывода — даже в SQL-запросе представления нет никаких его следов. И без разницы как выводить: блоком, аттачем, страницей, программно — пагера все равно нет.

Видимо, Views 2 считает, что если базовое значение (материал) — одно, то и строить пагер незачем. Самый простой (и примененный мной) выход — интегрировать таблицу истории как базовую и построить вьюху относительно этой таблицы, с присоединением материала через relationship. Тогда работает.

Интересно, есть ли такой баг во Views 3? На уровне работы с полями и entityreference — не воспроизводится.

Как известно, всеми любимый блок логина в Друпале не появляется на страницах регистрации и восстановления пароля (user/register и user/password соотвественно). Объясняется это бессмысленное, на мой взгляд, ограничение обычным usability. В коде user.module, в котором оно реализовано, так и написано:

(это функция user_block_view)
Написано, правда, про то что не надо показывать две формы логина на одной странице, но паровозом к этому цепляется и регистрация с восстановлением.

// For usability's sake, avoid showing two login forms on one page.
if (!$user->uid && !(arg(0) == 'user' && !is_numeric(arg(1)))) {
  $block['subject'] = t('User login');
  $block['content'] = drupal_get_form('user_login_block');
}

А что если бы мы хотели избавиться от ограничения? Придется добавить немного костылей.

Противникам патчей ядра дальше читать не нужно.