Друпалургия

Пример добавления для форматтера text_default функционала обрезки текста:

modulename.module

/** * Implements hook_field_formatter_third_party_settings_form(). */ function modulename_field_formatter_third_party_settings_form(FormatterInterface $plugin, FieldDefinitionInterface $field_definition, $view_mode, array $form, FormStateInterface $form_state) { $element = [];   if ($plugin->getPluginId() == 'text_default') { $element['max_length'] = [ '#type' => 'number', '#title' => t('Max length'),

Читать дальше →

Похожие записи:

• Drupal: Изменение свойств базовых полей
• Drupal: Расширить существующий виджет своим функционалом
• Drupal: Пустой форматтер для Field Group

Коллеги, поздравляю всех с Днем Победы!
По иронии этот текст был написан именно к 9 мая.

Полагаю, что сообществу будет интересен наш кейс, как мы пришли от хостинга к платформенным веб-решениям на Drupal.

Получилось “очень много букв”, но это про 5 лет работы с Drupal. Сложно написать одновременно кратко и емко.

Через терни к звездам...

Наша история началось аж в 2005, с хостинг-компании… Посчитав это направление интересным и перспективным мы с партнером вложились в свой первый бизнес.
Наивные, мы не понимали во что ввязались =) Следующие 2.5 года в качестве отдачи получали лишь только опыт.

При чем тут Drupal?
При том, что мы от незнания считали, что у нас есть выбор на чем делать себе проект. Мы прошли сложный пятилетний путь до Drupal.

Как и многие мы делали себе сайты на Joomla (Mambo), WP, Битрикс и в конце концов на Drupal. Пытались связать сайт с биллингом (чего только мы не использовали: WHMCS, Plesk, Billmanager и др.). Потом с 1С и другими решениями для автоматизации бизнес-процессов.

Наш сайт обрастал новым функционалом, были требования к SEO, к маркетингу, upsell, crossell и т.д. А ведь хостинг - это дешевая услуга, с низкой маржинальностью, поэтому было нужно еще больше клиентов и при этом не утонуть в операционке.

Ежедневные задачи: работа с тикетами, внутренними и клиентскими задачами, контроль качества работы сотрудников поддержки, обработка email, ведение и учет клиентов, работа с воронками, формирование финансовых отчетов, отправка email/sms-уведомлений и целевых рассылок… и еще куча всего.
У конкурентов были партнерки, продажа SSL, доменов, CMS-лицензий, услуги по администрированию, серверное железо и нам хотелось продавать это тоже. Это означало, что нам нужно еще более универсальное биллинг-решение.
Это далеко не полный список “must-have” для хостинговой инфраструктуры.

Арендовали кучу сервисов и пытались (< ключевое слово) их связать между собой, биллингом и сайтом. Про стабильность работы всей этой "системы" я промолчу. Вся структура была похожа один большой “костыль”. Да, мы знали все нюансы и косяки, предугадывали проблемы наперед. Но, назвать это комфортной работой было нельзя.
Еще раз повторюсь, чтобы хостинг окупался (речь не о прибыли) должно быть ОЧЕНЬ много клиентов. Технические риски росли по мере подключения нового функционала. Как масштабироваться с таким “вело-набором”? Очень большие риски.

Путь в никуда

Крупные конкуренты обладали ресурсами и работали на самописных решениях. У них были деньги на армию разработчиков, а у нас нет. Если бы мы наняли 3-4 разработчиков для написания сложного кастома, с нуля, то в случае, если кто-то из ниш решил бы уйти от нас - мы бы остались с кучей кода в котором вряд ли кто-то бы хотел разбираться. Пришлось бы писать новые костыли и повторить все круги ада. Этот путь проходили многие, мы знаем от коллег по веб-разработке и от клиентов.

Пришлось остановиться и хорошенько во всем разобраться. И вообще, больше ДУМАТЬ перед тем, как принимать решение и делать.

В наш “вело-набор” добавился сайт на Drupal. Мне нравилось то, можно было “накликать” новый функционал, при том получалось гибко и универсально. Сайт работал, развивался и мы все больше вникали в Drupal-принципы. Тогда я понял идею и перспективы. Я думал, что на Drupal можно создать решение для чего угодно.

“Безумству храбрых поем мы песню”

Прикинув возможности Drupal было предложено сделать все на нем, с нуля. Партнеру моя идея не понравилась =) Мы долго спорили, считали риски и в итоге не нашли консенсуса. Каждый пошел своей дорогой. Компанию перепродали крупному хостеру. А я остался с сотрудниками и решил все начать с нуля, а именно с создания комплексного решения на Drupal под новый хостинг-проект.

Для начала нужно было уменьшить количество интеграций (!) и связать все воедино. Очень хотелось стабильной и комфортной работы.

Целью - получить гибкую универсальную систему с централизованным управлением.
Для наших клиентов все должно было выглядеть как одно целое: сайт, личный кабинет, тикетница, формы и др. Требовалась единая среда, UI и принцип.

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

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

Вместе с командой разработчиков составили список необходимых нам решений с подробным описанием каждой функции.

Вот что получилось:

• Кросс-стандарты для front-end и back-end;
• Универсальный биллинг для “чего-угодно“ (взять лучшие решения у Plesk, WHMCS и др. и добавить в свое);
• Центральное управление хостинг-панелями из Drupal (ISPmanager, CPanel, SolusVM, Proxmox);
• Удобное и понятное отображение и управление товарами и услугами для клиентов;
• Регистрация и продление доменов, интерфейс управления DNS;
• Helpdesk (+тикетницу) и как минимум не хужче, чем это реализовано в WHMCS;
• CRM с системой уведомлений, воронками, канбаном, дэшбордами, realtime-аналитикой, группировкой клиентов по различным условиям, управлением задачами, учетом KPI сотрудников, интеграцией с 1С, трэкингом телефонии, обработкой email, сообщений из соц. сетей, мессенджеров и др.;
• Рекламные и персональные уведомительные рассылки;
• A/B тесты предложений на сайте;
• Сбор, хранение и управление данными о посетителях и клиентах (сейчас это модно называть "360 customers profile view");
• Личный кабинет: баланс (смешанный: для физ. и юр. лиц), бонусные баллы, нарастающие скидки и промо-коды;
• Партнерка (реферальные ссылки, промо-коды, суб-аккаунты, whitelabel);
• Онлайн-чат с возможностью приема оплат, выставлением счетов;
• Автоматика выставления счетов для юр. лиц (РФ) и формирования закрывающих документов;
• Простой учет и отображение доходов и расходов (в реальном времени);
• Менеджмент документов;
• Обучающие курсы для сотрудников и клиентов (в т.ч. с платным доступом);
• Интеграция эквайринга (прием платежей в РФ, Европе и США);
• Службы доставки (для физической доставки товаров);
• Собственные интеграции: DaData, Admitad, GA, Tagmanager, VoIP (UIS), Яндекс-сервисы и еще с десяток других;
• Маркетплейс товаров и услуг;

Мы начали разработку. Пропущу рассказ про новый опыт и “умывание кровью” на протяжении долгих месяцев, но мы знали, что все задуманное возможно. Даже несмотря на нашу небольшую команду.

Про время и деньги
Проект получился дорогой и долгий. Нужно было отбивать зарплаты и приходилось браться за некоторые клиентские проекты. Нам повезло запустить крупные ecommerce-сайты для нескольких известных брендов (Великобритания, Германия, Россия). Называть компании не буду (NDA), но уверен, что каждый читающий этот кейс что-то у них покупал =)
Кстати, задачи у наших клиентов были примерно похожи: от нас требовалось в максимально короткие сроки запустить достаточно сложный функционал с интеграциями 1C, SAP и кастомными корпоративными ERP. Наши универсальные наработки позволяли сократить сроки в 4, а то и 10 раз. Не скажу, что все было идеально, но на тот момент критичные задачи бизнеса решались. Искренне благодарен нашим клиентам за их веру и поддержку в нас в и Drupal!

Мы получили новый опыт в крупном профессиональном ecommerce, протестировали систему на масштабируемость, погоняли под высокими нагрузками и улучшили имеющийся функционал, а также разработали много нового. Несмотря на срочность разработок мы как-то умудрились делать все без “костылей” и “времянок”, но сильно рисковали сроками.

День победы над Drupal =)

Сейчас все хорошо. Мы реализовали все, что когда-то планировали. Протестировали систему на наших и на клиентских проектах. Система в боевом режиме, работает как часы. Разумеется highload.

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

• интернет-магазины
• провайдеры услуг и сервисов
• маркетплейсы
• продажа digital-контента
• online-образование

Если кому интересно, вот некоторые скриншоты вида “под капотом”:

Список реализованных функций с описанием (не полный, еще пишем).

Разумеется, мы буду рад продемонстрировать систему всем желающим. Пишите мне в ЛС и я отправлю доступы к инстансу.

Выводы

Существует некая иллюзия “идеальной” CMS среди их огромного множества. Если нужно создать масштабируемое решение с перспективой развития на несколько лет, то выбор сильно сужается до фреймворков и Drupal. Да, кстати, Drupal – это не CMS. Drupal – это логический принцип.

Drupal сегодня наилучшим образом подходит для построения платформ. Под платформами я имею в виду узкоспециализированные (целевые) CMS, конструкторы, CRM, биллинги, сервисы (SAAS-модель), хелпдески и др.
Drupal хорошо подходит для быстрого запуска сложных веб-проектов.
Drupal отлично подходит для сопровождения групп сайтов (применяя кросс-стандарты).
Drupal сложен для профессионального использования. Профессиональный разработчик скорее всего предложит “написать свое”, чем разбираться в особенностях Drupal.
Drupal – дорогое решение для небольших и средних веб-проектов из-за отсутствия целенаправленных готовых решений. О бесплатных билдах речи не идет, они чаще не адаптированы под конкретные задачи и представляют собой сборку модулей с так себе продуманной архитектурой.

Конечным потребителям:
Для создания простеньких сайтов лучше выбрать Joomla, WP или даже конструкторы типа WIX, Squarespace, uKit, A5. А для очередного мелкого интернет-магазина лучше купить CS-Cart, InSales, 1С Битрикс, UMI или же перебиваться на OpenCart.

Разработчикам:
Любой желающий не сможет “запрыгнуть” в профессиональный Drupal не преобразовав свою систему мышления. Потребуется затратить много времени и усилий. Не мудрено, что несмотря на огромный потенциал Drupal, веб-разработчики часто выбирают другие системы, играя в короткую игру. Так проще и дешевле, но не перспективнее.

P.S.

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

Drupal – это о долгосрочных перспективах.

Желаю, чтобы как можно больше компаний в России начали применять Drupal и на достойном уровне. Так как это делается во всем остальном мире.

Все в наших руках, если очень захотеть =)

И еще раз всех с Победой!

Есть вопрос

Обзоры и сравнения CMS

5 Thanks

Насколько критично: средне (14/25)

8 мая командой безопасности Drupal были выпущены обновления, закрывающие критические уязвимости в библиотеке typo3/phar-stream-wrapper.

Цитата специалиста по безопасности (google translate):

Чтобы перехватывать вызовы файлов, такие как file_exists или stat в скомпрометированных архивах Phar, необходимо определить и проверить базовое имя, прежде чем разрешить его обработку потоком PHP Phar. [...]
Текущая реализация уязвима для обхода пути, приводящего к сценариям, когда оцениваемый архив Phar не является фактическим (скомпрометированным) файлом.

Необходимо в срочном порядке обновить ядро до версии 7.67, а также 8.7.1 и 8.6.16.

Drupal 8

Drupal 7

FAQ

1 Thanks

Если роут ваш, то просто добавляем для него опцию _admin_route: TRUE:

modulename.routing.yml

modulename.example_route: ... options: _admin_route: TRUE

Если роут объявлен в другом модуле, то альтерим его в EventSubscriber-е:

src/EventSubscriber/ModulenameRouteSubscriber.php

<?php   namespace Drupal\modulename\EventSubscriber;   use Drupal\Core\Routing\RouteSubscriberBase; use Symfony\Component\Routing\RouteCollection;   class ModulenameRouteSubscriber extends RouteSubscriberBase {

Читать дальше →

Похожие записи:

• Drupal: Открыть форму входа в диалоге
• Drupal: Создание табличной формы с возможностью сортировки
• Drupal: Добавить вкладку/таб/локальную-задачу/local-task для определённого типа материала

Код добавляет необходимые атрибуты ссылке "Login" в "User account menu", чтобы форма входа открывалась в jQuery UI Dialog.

/** * Preprocess function for menu--account.html.twig. */ function THEMENAME_preprocess_menu__account(&$vars) { if (\Drupal::currentUser()->isAnonymous()) { $login_link_url = $vars['items']['user.logout']['url']; /** @var Url $login_link_url */ $login_link_url->mergeOptions([ 'attributes' => [ 'class' => ['use-ajax'], 'data-dialog-type' => 'modal', ], ]);

Читать дальше →

Похожие записи:

• Drupal: Открыть страницу или форму в диалоговом окне
• Drupal: Отправить контактную форму с помощью AJAX
• Drupal: Модуль Auto-Dialog — показываем контент и формы в jQuery диалоге

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

Аккурат год перед тем я заступил на должность старшего Друпал-разработчика в рекламной компании “Wunderman”, а именно, в её пражском отделении. Попал я туда на редкость неудивительным способом - рекрутер нашёл меня на LinkedIn, последовало тестовое задание (весьма меня удивившее своей примитивностью - я искал в этом скрытого смысла, но, как вы дальше увидите, зря), собеседование по Скайпу и предложение работы. Предложение не подкупало ни щедростью, ни возможностями, но я всё-таки решил поехать. Как говорил Наполеон, “ввяжемся, а там видно будет”. Привлекала возможность окунуться в другую среду - язык, культура, вот это всё. Дальше последовал несуразно продолжительный процесс получения рабочей визы, и таки месяцев через 7-8 после первого контакта с рекрутёром я занял своё место в опенспейсе на втором этаже офисного здания у Смиховского вокзала.

Несмотря на то, что я довольно много путешествовал по разным странам и континентам, опыта постоянной жизни в другой стране у меня не было. Вид изнутри, конечно же, отличается. Во-первых, иллюзия близости культуры и характера чехов к русским исчезла довольно быстро. Вообще, идея славянства довольно уникальна. Никому не придёт в голову уподоблять, скажем, норвежцев немцам, или итальянцев французам на том основании, что их языки относятся к одной языковой группе. Но про славян это не так - почему-то подразумевается, что народы, говорящие на славянских языках, что-то объединяет. Не объединяет, не обольщайтесь. Чехи довольно замкнутый и ксенофобный народ - это не плохо, это просто продиктовано их историей. Любой малый народ, не имевший своего государства, должен защищать свою идентичность. Так что в целом чехи не любят ни русских, ни немцев, ни американцев. Они любят собак, которым здесь можно всё - например, сидеть на стульях в кафе. Потом, языковой барьер. Если у вас есть иллюзия, что вы заговорите по-чешски за три месяца, подышав воздухом пражских садов, выбросьте её. Скорее всего, вы по-чешски не заговорите никогда. Это такой же иностранный язык, как, например, суахили, и если 20% слов напоминают на письме русские, то неизвестно ещё, это в помощь или во вред, потому что означают они не совсем то и употребляются по-другому. Плюс чешское произношение, самое утробное и адское из всех, которые я видел. Полно русских, которые живут здесь годами и чешским владеют, ну, так себе. Не говоря уж об американцах и прочих неславянах. Но те, кто дают себе труд, говорят - хоть турок, хоть швед, хоть китаянка. При этом Прага город хоть и маленький, но вполне космополитичный. Местные жители в большинстве неплохо владеют английским, а неместных в некоторых местах больше, чем местных. И мне пришлось переоценить свои требования к владению иностранными языками - мой английский в России считался вполне неплохим, плюс я могу читать и изъясняться на французском, и при надобности разобрать тексты ещё на паре языков. В русскоязычной среде, и при удалённом взаимодействии с зарубежными коллегами, это более чем. Но когда стоит вопрос о том, чтобы свободно излагать абсолютно всё, как на русском, с той же скоростью и оттенками смысла, и понимать не меньше - это совершенно другой уровень, и достичь его не так-то просто, даже живя в стране носителей этого языка.

Сама по себе Чехия, конечно, тоже не совпала с идиллической картинкой с ТрипАдвайзора. Такое ощущение, что в различных областях отстаёт от передового человечества от 20 до 200 лет. Страна, попросту говоря, деревенская. Чешская кухня - мясо, пиво, картофан. Даже пряности им неизвестны. Любимое развлечение - “гриловать” (то есть жарить на костре мясо) и ездить на свою “халупу” (это как дача, только они там ничего не выращивают) и собирать грибы. При этом народ спортивный: бегают, крутят педали, гребут в байдарках, лезут по скалам, играют во флорбол. Условия для всего - отличные. Люди сами по себе достаточно приветливые, но отстранённые и прохладные. Всё везде поделено, частная собственность - святое. Это очень непонятно и неприятно для русского. Несмотря на свою спортивность, в работе чехи несравненны в своей медлительности и каком-то таланте делать всё через одно место. Даже эскалатор в метро едет в 2 раза медленней, чем в Москве. Рабочий день кончается часов в 4-5 (начинают, правда, рано), в пятницу и того раньше.

Теперь про работу и Друпал. Эта часть рискует напомнить главу “Серп и Молот - Карачарово” поэмы “Москва - Петушки”, потому что, кроме мата, сказать особенно нечего. Вкратце говоря, такого позора Друпала я ещё не видел, хотя повидал всякое. Напомню, речь идёт о рекламном агентстве Вундерман. Не думаю, что раскрою какие-то коммерческие тайны в своём рассказе. Вундерман имеет пяцоттыщ сотрудников по всему миру и чёртову уйму офисов. Пражский офис включал несколько сот человек, из которых было примерно 10 разработчиков. Чем занимаются остальные - фиг пойми. За разработчиков-то я точно могу сказать, что мы не делали ровным счётом ничего. Остальные собирались чуть ли не с девяти утра в отгороженных стекляшках и дружно втыкали в экран или на доску. Структура отделения разработки непрерывно менялась, но примерно можно сказать, что была одна команда под названием “бэкенд” (непосредственно друпалисты), в момент расцвета включавшая 5 человек (2 русских, 2 чеха и один бельгиец) с тимлидом - итальянцем, и две примерно такого же размера и интернационализма команды фронтендеров (разве что там, как и в компании в целом, доминировали латиносы). Надо всем этим сидел такой добрый чувак лет 40, который всех сотрудников через пару месяцев начинал возбуждать просто хичкоковской тайной - а что он делает? Выяснить это не удалось ни самым решительным, ни самым умным, ни самым внимательным. Плюс приходилось взаимодействовать с некоторым количеством проектных менеджеров. Основным заказчиком для команды друпалистов выступал Нестле и бренд “Пурина” в частности. При этом наивно полагать, что мы могли сами взять и сделать сайт. В Нестле сидит своё подразделение бракоделов под гордым названием Digital Solutions Unit (вообще, как показывает опыт, чем помпезней название должности, тем больший идиот её занимает). Они испохабили профиль Lightning и сварга́нили своё произведение под названием Lightnest, добавив багов, присыпав несовместимостью версий и немного обернув в проблемы с доступом. Естественно, все клиенты Нестле должны разрабатывать сайты на основании этого г...на. Причём мы могли бы починить все их баги, привести в порядок сам процесс инсталляции (потому что они не осилили даже документацию к blt и вместо нормального запуска composer'а обошлись своим главным орудием - cut&paste), но нам было строго запрещено это делать. Сначала я этого не понимал, выступал с предложениями, как сделать нормальный процесс разработки, объяснял, что такое Drupal best practices, а потом понял. Понял, что главная задача нашего подразделения - ничего не делать. И наш тимлид достиг определённого мастерства в создании сложностей на ровном месте, хотя надо отдать должное его деловым партнёрам - все они окончили факультет переливания из пустого в порожнее с красным дипломом. Причём для людей, проводящих большую часть жизни в таких конторах, характерна позиция "все кругом п###расы, один я - д'Артаньян". Все жалуются на бестолковость кругом, бесконечные совещания, то что им не дают ничего сделать. Тем не менее, они иногда умудрялись. Например, тот самый тимлид однажды редактировал руками composer.lock и удивлялся, что не помогает. Уровень управления проектами - когда я ещё пытался объяснить людям, что к чему, что есть, например, работа с контентом, процессы, роли, ПМ Катерина посмотрела на меня как на идиота: "Контент же управляется из Друпала." Деплой через гит, перетаскивание базы руками, потому что южноафриканское подразделение не поняло, как поменять site uuid при работе с конфигом. Месяц созвонов слепого с глухим, чтобы выставить на стейджинге trusted_host_patterns. В самом процессе выкатывания сайтов (которым Друпал вообще нахрен не нужен, потому что это статические рекламные визитки) участвовало по крайней мере 3 подразделения с кучей менеджеров, программистов и диджитальных архитекторов: Южная Африка, которая из говна и палок накидала параграфов, сделав полностью непригодной админку (это произведение было гордо названо White Label и продано руководству как универсальное решение всех проблем); пражское подразделение, которое пыталось собирать сайты из этих параграфов (как правило, код писать было запрещено, поскольку это подразумевало последующее прохождение security scan'а - мануальной инспекции сайта на предмет безопасности несколькими неторопливыми идиотами в Швейцарии); и на последней ступеньке пищевой цепочки индусы в Бангладеш, которые получали в Экселе контент для этих сайтов и перетаскивали его.

Глубины идиотизма можно описывать бесконечно, но пора обедать, поэтому перейду заключениям. Дрис, конечно, молодец - он продал Друпал. Только, как это часто бывает, деньги приносят позор и профанацию. Это напоминает продажу цыганами жестянок с надписью "биткойн" доверчивым гражданам. Друпала там, ей-богу, не больше чем Биткойна в этих жестянках. Чем больше компания, тем больше разрыв между теми, кто принимает решения, и теми, кто их выполняет. Очень похоже на Россию во все времена, кстати. Какой-то супер-топ менеджмент Нестле принял решение, что все сайты теперь будут на Друпале. Единственная проблема в том, что никто в том Нестле понятия не имеет, что такое Друпал. Они набрали спецов по объявлению, пошли к своим старым друзьям типа Вундермана - “могёте Друпал?” - “Г...о вопрос!” И понеслась. Единственная надежда на то, что деньги у Нестле никогда не переведутся и они никогда не заинтересуются, сколько на самом деле стоила бы разработка их сайтов.

В конечном итоге, естественно, все хоть на что-то способные разработчики разбежались из этой конторы. Более того, за ними пошли и ветераны. "Я ж, - говорит, - начинал здесь как контент редактор. Всему научился, но сравнивать было не с чем. А теперь Дмитрий и Эдуардо объяснили мне, и я не могу больше." Учитывая то, что все эти Дмитрии и Эдуардо были привезены из далёких стран с визами и билетами, менеджменту компании можно поаплодировать. Я, впрочем, не сомневаюсь, что тот, кто принимал решение их привезти, пошёл на повышение. Да, и из последних новостей - фронтендера Макса, который ни одной строчки не написал на ПХП, назначили друпалистом вместо ушедших.

Я не скажу, что из первых, но понял, что пора валить, после визита большой делегации из Нестле, когда было просто запрещено обсуждать вопросы по существу. Казалось бы, вся чешская пресса пишет, что нехватка кадров в ИТ, полно вроде бы вакансий. Ну я пошёл посмотреть. Поржал. Во-первых, Друпала в Чехии нет. Все чешские друпалисты (все 6) работают по удалёнке на австралийскую контору, которую основал их соотечественник. В Чехии куда ни пойдёшь (по крайней мере в плане ИТ) - всё крупнейшее в Центральной Европе. Это примерно как в Воронежской области. Центральная Европа - это Чехия со Словакией, Польша, из которой после вступления в ЕС уехало на заработки всё что движется, Венгрия и Румыния, откуда уехало в ЕС всё что движется воровать у тех, кто уехал в ЕС из Польши на заработки. Всё это крупнейшее в Центральной Европе разрабатывается то на чердаке, то в гараже за зарплаты, которые тоже не впечатляют. Ну и сама по себе работа двигать таски - не очень. Бизнес решает, а ты сиди и латай дыры. Тем не менее, я сделал пару тестовых заданий ради интереса. Их даже не проверили. То в отпуске, то заболел, то некогда. Ну и излишне говорить, что во всех этих крупнейших в Центральной Европе разработках нет ни одной чешской кроны - всё это по большей части немецкое ну или ещё с примесями иностранного капитала. Либо же - Вундерман отнюдь не единственная международная корпорация в Праге - сияют стеклом и неоном офисы Johnson&Johnson, Oracl’a, Novartis’a, банков. Но переезжать из одного болота в другое - как говорится, плавали, знаем. Отдельным анекдотом мог бы рассказать историю про переговоры с Новартисом, но уже не буду. И так никто до конца не дочитал.

Так что будете у нас на Влтаве - заходите в гости, не будете - спрашивайте, что интересно.

Drupal 8

Разное непонятное

3 Thanks

Пример формы для сортировки нод по полю field_weight

class ExampleDraggableForm extends FormBase {   /** * {@inheritdoc} */ public function getFormId() { return 'example_draggable_form'; }   /** * {@inheritdoc} */ public function buildForm(array $form, FormStateInterface $form_state) { $form['table'] = [ '#type' => 'table', '#header' => ['Title', 'Weight'], '#empty' => 'Empty...', '#tabledrag' => [[ 'action' => 'order', 'relationship' => 'sibling', 'group' => 'node-weight',

Читать дальше →

Похожие записи:

• Drupal: Как создать свой составной элемент формы
• Drupal: Отключить автоматический аплоад файлов у определённого поля
• Drupal: Изменить тип всех кнопок с <input type="submit"> на <button type="submit">

Пример добавления вкладки для материалов типа page:

src/Controller/ModulenameController.php

class ModulenameController extends ControllerBase {   public function exampleTabContent(NodeInterface $node) { return ['#markup' => 'Tab content...']; }   public function exampleTabAccess(NodeInterface $node) { return AccessResult::allowedIf($node->bundle() === 'page'); }   }

modulename.routing.yml

entity.node.example_tab: path: '/node/{node}/example-tab' defaults:

Читать дальше →

Похожие записи:

• Drupal: Программно получить подпункты определённого пункта меню
• Drupal: Примеры кода для Drupal 8
• Drupal: Как создать свой составной элемент формы

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

Модуль называется Rules Telegram и позволяет отправлять уведомления в телеграм через правила модуля rules.

Идея модуля была взята из репозитория Алексея Дёмина. Основная фишка кроется в том, что модуль позволяет использовать прокси сервер, т.к. телеграм на территории РФ заблокирован или работает нестабильно.

На друпал.ру пока что модуль будет использоваться только для админов и модераторов. Возможно потом функционал отправки уведомлений в телеграм будет доступен и для пользователей

Drupal 7

Предлагаю решение

Программирование

0 Thanks

Пример создания элемента формы fullname с тремя полями - Фамилия, имя, отчество.

src/Element/FullnameElement.php

<?php   namespace Drupal\modulename\Element;   use Drupal\Core\Form\FormStateInterface; use Drupal\Core\Render\Element\FormElement;   /** * @FormElement("fullname") */ class FullnameElement extends FormElement {   /** * {@inheritDoc} */ public function getInfo() { $class = get_class($this);   return [ '#input' => TRUE, '#process' => [ [$class, 'processElement'], ],

Читать дальше →

Похожие записи:

• Drupal: Отключить автоматический аплоад файлов у определённого поля
• Drupal: Изменить тип всех кнопок с <input type="submit"> на <button type="submit">
• Drupal: Отправить контактную форму с помощью AJAX

18 апреля командой безопасности Drupal были выпущены обновления, закрывающие критические уязвимости в ядре Drupal 7 и Drupal 8.

Необходимо в срочном порядке обновить ядро до версии 7.66, а также 8.6.15.

Drupal 8

Drupal 7

Есть вопрос

FAQ

0 Thanks

Переход с Drupal 8 на Drupal 9 будет простым, если вы будете регулярно проверять и удалять устаревший код.

Drupal 9 планируется выпустить в июне 2020 года, поэтому многие люди задаются вопросом, что им нужно сделать, чтобы к этому подготовиться.

Хорошая и важная новость заключается в том, что переход с Drupal 8 на Drupal 9 должен быть действительно простым — кардинально более простым, чем переход с Drupal 7 на Drupal 8.

С единственной оговоркой, что необходимо будет внимательно проверить использование функций и кода, отмеченных как «устаревшие» и обновить их соответственно.

Если в модулях и темах на вашем сайте не используется устаревший код, который планируется удалить в Drupal 9, обновление до Drupal 9 будет очень простым. В действительности, это должно быть так же просто, как и обновление до минорной версии (например, с Drupal 8.6 на Drupal 8.7).

Почему код устаревает?

Код в Drupal помечается как «устаревший», когда он больше не должен использоваться. Как правило, код устаревает, потому что появляются более эффективные решения.

Например, в Drupal 8.0.0 мы отказались от \Drupal::l($text, $url). Вместо \Drupal::l() необходимо использовать Link::fromTextAndUrl($text, $url). Функция \Drupal::l() была отмечена к удалению в рамках работ по очистке кода, так как в Drupal 8 было слишком много способов генерировать ссылки.

Обычно устаревший код продолжает функционировать еще некоторое время, прежде чем он будет удалён окончательно. Например, функция \Drupal::l() по-прежнему доступна в Drupal 8.7, несмотря на то, что она была отмечена как устаревшая в Drupal 8.0.0 более трех лет назад. Это дает разработчикам модулей достаточно времени для обновления своего кода.

С релизом Drupal 9 наиболее устаревший код будет удален. Так, например, функция \Drupal::l() будет недоступна в Drupal 9.

Другими словами:

• Модули для Drupal 8, не использующие устаревший код, продолжат работать в Drupal 9.
• Модули для Drupal 8, использующие устаревший код, должны быть обновлены до выхода Drupal 9, иначе они перестанут работать в Drupal 9.

С более подробной информацией о политике депрекации кода в Drupal можно ознакомиться на странице https://www.drupal.org/core/deprecation.

Как узнать, что на сайте используется устаревший код?

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

Если вы разработчик сайта на Drupal, запустите утилиту drupal-check. Мэтт Гламан (Centarro) разработал инструмент статического анализа PHP под названием drupal-check, с помощью которого вы можете проверить кодовую базу сайта на наличие устаревшего кода. Я рекомендую сделать автоматический запуск drupal-check частью вашего процесса разработки.

Если вы веб-мастер или владелец сайта, установите модуль Upgrade Status. Этот модуль был разработан компанией Acquia. Модуль предоставляет графический интерфейс пользователя для утилиты drupal-check. С его помощью можно будет легко оценить готовность вашего сайта к переходу на Drupal 9.

Если у вас на поддержке имеются проекты на Drupal.org, включите тестовую инфраструктуру Drupal.org, чтобы обнаружить использование устаревшего кода. Есть два взаимодополняющих способа: вы можете запускать статический анализ кода и/или добавить в существующие тесты сбой при вызове устаревшего кода. Оба варианта можно настроить в конфигурационном файле drupalci.yml.

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

Насколько сложно обновить код?

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

В документации по API вы можете найти инструкции по обновлению кода.

Когда следует приступить к обновлению кода?

Я призываю вас начать прямо сегодня. Используя в модулях и темах новейшие версий API Drupal 8, вы сразу же получаете все преимущества от этих улучшений. Вовсе не обязательно ждать выхода Drupal 9.

Релиз Drupal 8.8.0 будет последним перед выходом Drupal 9. Но на данный момент список всех депрекаций еще не определен.

Сколько времени осталось на обновление кода?

Drupal 9 планируется выпустить в июне 2020 года, а разработка Drupal 8 будет прекращена в ноябре 2021 года.

Мы очень надеемся, что к июню 2020 года разработчики модулей избавятся от использования устаревшего кода в своих проектах, чтобы возможность обновить сайты до Drupal 9 появилась сразу в день его выхода.

Мейнтейнерам проектов на Drupal.org необходимо помнить о политике расширенного выпуска релизов безопасности, согласно которой Drupal 8.8 будет поддерживаться до тех пор, пока не будет выпущен Drupal 9.1. Для модулей и тем оформления, которые будут поддерживать как Drupal 8.8, так и Drupal 9.0, могут потребоваться отдельные ветви в репозитории Drupal.org.

Текущая ситуация с контриб-модулями

Дуэйн МакДэниел (Pantheon) проанализировал 7000 модулей для Drupal 8 утилитой drupal-check.

На сегодняшний день 44% модулей не имеют предупреждений об использовании устаревшего кода. Остальные 56% модулей нуждаются в обновлении, но в большинстве случаев анализатор выдает менее трех предупреждений об использовании устаревшего кода.

Перевод статьи «How to prepare for Drupal 9» из блога Дриса Бёйтарта.

Drupal 9

Drupal 8

Предлагаю решение

Свободные программы

6 Thanks

Пример выполнения ajax запроса на внутренний адрес path/to/controller:

var ajax = new Drupal.Ajax(false, false, { url: Drupal.url('path/to/controller') }); ajax.execute();

Контроллер должен вернуть набор команд ajax-фреймворка.

Комментарии

Похожие записи:

• Drupal: Динамический url ajax-ссылок
• Drupal: Отправить контактную форму с помощью AJAX
• Drupal: Добавить класс элементу пославшему друпаловский ajax запрос

После загрузки страницы для каждой ссылки с классом use-ajax создаётся объект Drupal.Ajax, в котором фиксируется адрес, на который по клику отправится ajax запрос. После создания этого объекта менять href ссылки уже бесполезно, надо вручную лезть в Drupal.ajax.instances и менять options.url у нужного объекта.

Ниже пример того, как можно перед отправкой ajax запроса автоматически менять его адрес на значение атрибута ссылки data-ajax-url:

(function ($, Drupal) {

Читать дальше →

Похожие записи:

• Drupal: Отправить контактную форму с помощью AJAX
• Drupal: Добавить класс элементу пославшему друпаловский ajax запрос
• Drupal: Открыть страницу или форму в диалоговом окне

Как установить Drush? composer require drush/drush
Подробнее Как обновить ядро друпала? Если друпал установлен с помощью composer, то:
composer update drupal/core --with-dependencies vendor/bin/drush updb

Читать дальше →

Похожие записи:

• Drupal: Автоматическое удаление файлов после удаления сущности
• Drupal: Отключить автоматический аплоад файлов у определённого поля
• Drupal: Анатомия блоков

Пробуем различные компоненты Bootstrap на своем сайте на Drupal 8.

Drupal 8.*

Bootstrap

Bootstrap 3

Предлагаю решение

DrupalSib

2 Thanks

Для развития нашего сообщества и популяризации Drupal в рунете активисты пишут статьи про Drupal и смежные темы, а также переводят на русский интересные и полезные материалы с других языков.

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

С радостью сообщаю, что мы получили бесплатную open-source лицензию Crowdin для перевода документации и статей для нашего сообщества.

О платформе Crowdin

Crowdin – инновационный облачный сервис для управления переводами и локализацией. Crowdin упрощает и ускоряет перевод, автоматизирует процесс локализации. Идеально подходит для agile-команд и локализации любого типа контента: программного обеспечения, мобильных и веб-приложений, видеоигр и веб-сайтов.

Факты о компании

• более миллиона зарегистрированных пользователей со 160+ стран мира;
• более 79 000 проектов локализации;
• основной инструмент компаний, которые хотят легко поддерживать свои продукты на нескольких языках и быстро добавлять новые;
• позволяет работать со штатными переводчиками, фрилансерами и профессиональными переводческими агентствами;
• поддерживает некоммерческие проекты с открытым исходным кодом;
• обеспечивает удобным функционалом как маленькие проекты так и проекты с более чем 10 000 переводчиками.

Я верю, что сотрудничество с Crowdin поможет нам значительно ускорить перевод документации Drupal и полезных статей на русский язык.

В течение ближайшего времени мы подготовим все необходимое для совместной работы над переводами и разместим отдельный пост с дальнейшей информацией.

Следите за новостями!

Предлагаю решение

Работа по переводам UI и документации

3 Thanks

20 марта командой безопасности Drupal были выпущены обновления, закрывающие критические уязвимости в ядре Drupal 7 и Drupal 8.

Необходимо в срочном порядке обновить ядро до версии 7.65, а также 8.6.13.

Drupal 8.*

Drupal 7.*

Есть вопрос

Безопасность

0 Thanks

14 марта командой безопасности Drupal были выпущены обновления, закрывающие критические уязвимости в ядре Drupal и контрибных модулях.

Если вы используете модуль Views на вашем Drupal 7 сайте, вам нужно немедленно его обновить.

Также необходимо в срочном порядке обновить ядро Drupal 8 до версии 8.6.11 или до версии 8.5.12 (если вы по какой-то причине не перешли на ветку 8.6)

Следом за ними 15 марта были выпущены версии 8.6.12 и 8.5.13

Ядро Drupal 7 обновлять не нужно.

Drupal 8.*

Drupal 7.*

Есть вопрос

FAQ

0 Thanks

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

Для связи с командой можно использовать личные сообщения. Ссылки на профили участников команды перечислены на странице «Контакты».

А вопросы по использованию сайта drupal.ru и модерации теперь можно задавать в телеграм-бот @drupalrusupportbot.

Предлагаю решение

Сайт и проект Drupal.ru

1 Thanks