Друпалургия

Добавляем разнообразные компоненты Bootstrap на своем сайте на Drupal 8.

Содержание: инструменты разработчика в Chrome, мобильная версия сайта, гамбургер-меню, навигация для мобильного сайта, компоненты бутстрапа, модальное окно (Modals), отправка формы в модальном окне, вкладки (Togglable tabs), подсказки (Tooltips), сворачивающийся текст (Collaps), аккордеон (Accodion), слайдер с фотографиями (Carousel).

Drupal 8

Bootstrap

Bootstrap 3

DrupalSib

0 Thanks

Часто возникает необходимость, чтобы ajax ссылка с классом use-ajax выполнила запрос ровно один раз, после чего прекратила реакцию на клики (например это ссылка загрузки контента в таб). Реализовать задуманное можно подменой функции Drupal.Ajax.prototype.eventResponse:

(function ($, Drupal) { /** * Override AJAX eventResponse function. */ var originalAjaxEventResponse = Drupal.Ajax.prototype.eventResponse; Drupal.Ajax.prototype.eventResponse = function (element, event) { var $element = $(element);

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

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

• Drupal: Открыть форму входа в диалоге
• Drupal: Как из Javascript выполнить ajax запрос с помощью Drupal Ajax API?
• Drupal: Динамический url ajax-ссылок

Управление бизнесом в единой среде

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

Drupal Flex изначально ориентировался, как универсальное и гибкое платформенное решение для различных отраслей e-commerce ("электронная коммерция" - это для широкого понимания). В том числе и для комплексной автоматизации хостинг-бизнеса.

В данном кейсе рассматривается одновременное кросс-управление несколькими хостинг-проектами. Drupal выступил в роли централизованной системы для организации хостинг-сервисов.

Стоимость решения: > $95 000 (не считая расходов на инфраструктуру).
Класс решения: enterprise.

Скринкаст

смотреть тут (англ. версия)

Результат

Один из наших хостинг-проектов: https://btrxboost.com

Предисловие

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

Наша цель, для достижения которой мы создали Drupal Flex - независимость от искусственных ограничений, от условий платных сервисов, от возможностей ПО для бизнеса. Максимальная гибкость и универсальность применения для решения бизнес-задач – вот что стало нашей главной ценностью.

Сравнение

Привожу в пример близкие по смыслу платформы для автоматизации хостинга: WHMCS, Plesk, BillManager. Все эти платформы мы использовали на своих проектах, сравнивали и сейчас я могу сказать, что их всех объединяет один большой недостаток – отсутствие универсальности и функциональной гибкости. Все будет работать только так, как было задумано (N-лет назад). При условии, что наша компания работает на одном из самых динамичных it-сегментов, то в первую очередь мы думаем о перспективах развития. Я имею в виду, что бизнес-модель работающая в рамках функционала сторонних компаний – это тупик. То, что могут все, становится неинтересно и бесперспективно.

Пример: в вышеперечисленных платформах нет и не будет поддержки омниканальной коммуникации, а о интеграции с telegram вообще можно не мечтать. Никогда не будет “бесшовной” среды (я имею в виду, что сайт и биллинг всегда будут разными и слабо связанными). Никогда не будет гибкости. Это сплошной логический dead-end. И для бизнеса это критичные аспекты, они определяют качество работы поддержки. Точнее, они определяют ее некачественность, увы. Мы же ставим своей целью гибкость, бесшовность, архитектурную целостность систем, и именно в этом видим перспективу – свою и клиентскую.

Разрозненность

Разрозненность – большое зло для любого бизнеса.

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

Мы все сталкиваемся с ситуациями, когда разработчик решения “улучшает” функционал на своей стороне, а на нашей стороне вовсе перестает работать что-то важное. Начинается выяснение причин, трата времени, бизнес-процессы стоят. А если в веб-проекте используется много внешних сервисов? Проще закрыть глаза на нестыковки и оставить все “как есть”, чтобы не рисковать с переносом процессов. И эта кажущаяся простота – стратегия страуса, прячущего голову в песок. Невидимые проблемы, скрытые в разрозненности процессов, неизбежно накапливаются и вскроются с очень большим грохотом. Компания не в силах предсказать процесс, который раньше ею не наблюдался. И таких процессов в разрозненных системах – масса. Критичные и мелкие, они копятся и угрожают стабильности. Вам это нравится? Нам решительно нет, и поэтому мы объединяем все в единую среду, прозрачную и наблюдаемую, в предсказуемое стабильное решение.

Опыт...

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

Наш личный ад с WHMCS (а именно с представительством из Украины) длился две недели, мы не получили за этот период ни копейки прибыли и, к тому же, достали немало средств из собственных кошельков, чтоб не потерять свой бизнес и сохранить бизнес наших клиентов. Вы легко можете представить звонки и письма от 100 негодующих клиентов, у которых в один час перестало работать ВСЕ. У нас же на тот момент их было 5000, и мы разрывались между попытками их успокоить и нечеловеческими усилиями, направленными на то, чтобы сподвигнуть разработчика устранить причину сбоя. Лучшее, что мы смогли придумать для быстрого снижения волны недовольств от клиентов – это работать бесплатно. Это стоило нам большого кассового разрыва, вложения личных средств, и, конечно, очень много нервов.
И если клиенты сохраняли остатки лояльности к нам за бесплатность “сервиса”, то штат сотрудников оставить без зарплаты было нельзя. Это были очень тяжелые две недели, с задачами на границе возможного, со звонками от клиентов, с безденежьем. Мы катились в пропасть и каждое утро начинали с мольбы в адрес WHMCS.

В чем же было дело? WHMCS не делали резервных копий своего собственного сервера лицензий, и даже не торопились это исправлять. Сервер лицензий чудным образом рухнул вместе с данными. Все потеряли доступ к своим оплаченным сервисам, не могли приобретать и продлевать хостинг, работать с данными. “Услуга” длилась две недели, которые понадобились вендорам решения для ручного ввода (по всей видимости) потерянных данных на новый сервер лицензий.
Наверное, вы думаете, что в итоге они потеряли много клиентов, в том числе и нас? Грустная правда в том, что мы и все клиенты остались, просто потому, что альтернатив на тот момент не было.

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

Я много чего могу рассказать и про другие решения от ISP и Plesk, да и про коммерческие CMS для сайтов. Это истории обретения драгоценного опыта. И наш опыт подтверждал снова и снова идею о том, что разрозненность процессов в бизнесе – это большое зло. Очень большое.

Список длинный, поэтому я выделяю для вас основные проблемы:

1. Технические поддержки сервисов не сообщаются между собой. Клиент разбирается самостоятельно. Надо делать бизнес, обслуживать клиентов, а владелец сидит в обнимку с айтишниками и ковыряется в особенностях работы сервисов. Аналогичное сравнение можно провести с предпринимателем, который первый раз открыл ООО и только успевает закрывать бухгалтерские задачи и отбиваться от проверок и штрафов. Есть риск разориться раньше, чем закончится аудит.
2. Отсутствие полностью готовых и гибких интеграций, нет возможности добавлять собственный функционал. Иногда я думаю, что они там сидели и думали так: “А зачем хостеру оказывать еще какие-то услуги кроме хостинга, если он хостер? Пусть делает только то, что мы решили, и хватит с него.”
3. Отсутствие личных настроек. Нам предлагают множество решений, которые невозможно полноценно брендировать. Чем я со своим сайтом и биллингом будут отличаться от конкурента? У него Billmanager с ошибками и у меня такой же с виду. Я хочу продавать лучшую клубнику в рестораны, но вынужден упаковывать ее в банки, такие же как у замороженного продукта пятилетней давности. Где же мне проявить свои преимущества и реализовать потенциал?
4. Разные интерфейсы и принципы работы. Пришел новый сотрудник, а у нас 4 сервиса с разными интерфейсами и дублированными функциями. Нужно садиться с новичком и объяснять все нюансы. И если назавтра что-то поменяется, то мы садимся снова за обучение, теряя время и, самое печальное, уверенность в достаточной подготовленности кадров.
5. Лишние и дублирующие функции сервисов. Не страшно, что за них нужно переплачивать, страшно то, что они могут конфликтовать друг с другом. Мы с этим сталкивались неоднократно и отловить конфликтующие сервисы сложнее, чем баги внутри одной системы. В этих случаях нужно тестировать всю цепочку сервисов, постепенно отключая каждый элемент (сервис) и проводить тесты. Решение может занять 5 минут, а на то, чтобы отловить проблему может понадобиться несколько дней. При том, в идеале тесты должны проводиться на полностью дублированной инфраструктуре, а не на боевом проекте. Как думаете, со всеми ли сервисами можно договориться, чтобы бесплатно дали свой продукт еще и на dev? Подскажу: далеко не со всеми.

Ценности Drupal

1. Долгосрочный горизонт развития.
2. Гибкость, а точнее ультра-гибкость.
3. Свобода от навязанных решений.
4. Фундаментальность принципов и логики (еще раз повторюсь, что Drupal - это не CMS, а логический принцип.)
5. Сообщество профессионалов. Самое большое из известных мне среди профессионалов open-source web-решений.

Менять платформу каждые 2-3 года – бесперспективно. Мы предпочитаем один раз вложиться в правильный инструмент, стать профессионалами и гарантировать его работоспособность в перспективе. Мы чувствуем себя спокойно, и мы знаем, что будет с платформой через 5 лет. С Drupal все будет хорошо, и мы будем через пять лет еще более крутыми специалистами.

Мы свои выводы сделали, дело за вами.

Цели

Снижение внутренних рисков

• Контроль качества программного продукта. Исключение миграции на другую платформу в случае изменений в команде разработчиков или ее полной замены.
• Минимизировать зависимость системы и бизнес-процессов от дочерних сервисов (минимум подключенных сторонних сервисов).
• Единая система управляющая всеми бизнес-процессами.

Масштабируемость

• Кросс-платформенные стандарты для back-end/front-end для упрощенного обновления всей группы сайтов по специализированным хостингам для CMS.
• “Бесшовный” интерфейс для клиентов (единый дизайн для сайта/биллинга/личного кабинета).
• Гибкий универсальный биллинг.
• Единый центр обслуживания клиентов по принципу омниканальности.

Бизнес-процессы

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

Профит

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

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

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

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

Используемый функционал

Продукты:

• Гибкая система тарификации хостинг-тарифов.
• Продажа услуг (администрирование, обслуживание).
• Продажа продуктов типа SSL-сертификатов, выделенных серверов, лицензий CMS.
• Установка наценок на продукты и их свойства (опции, атрибуты).
• Возможность указания цены товаров (включая опции и атрибуты) в иностранных валютах с автоматической конвертацией в рубли по текущему курсу ЦБ.
• Установка платежных циклов на основе атрибутов с возможностью добавления скидок за единовременную оплату больших циклов (например, скидка 10% при оплате за 12 месяцев хостинга). Смена платежного цикла из личного кабинета клиента.
• Включение режима демо-периода (триал) для услуги.
• SMS-верификация при оформлении триал-услуг.
• Выбор автоматической установки CMS при заказе продукта.
• Выполнение бизнес-процессов (например: создание тикета с отправкой уведомления в отдел) при заказе продукта.
• Разбивка продуктов в заказе на отдельные заказы.
• Трансляция данных о продукте в личный кабинет клиента.
• Внутренний интернет-магазин с возможностью покупки товаров за накопленные бонусные баллы.
• Полное управление продуктами из таблицы: тип продукта, название, категории, описание, атрибуты и опции, фото, наличие (остатки), наценки, валюты, метки, цены, бонусные баллы, промо-коды, ограничения по количеству единиц и времени, выбор родительской группы (промо-страницы с продуктами), рекомендации, аксессуары, запуск процессов, верификация при покупке, тип заказа (триал, без оформления, обычный), автопродление, изменение платежного цикла, выгрузки во внешние сервисы и др.
• Замена продукта и опций (при смене тарифного плана).
• Передача данных из опций атрибутов товара после завершения заказа в новый тикет (например, когда клиент оформил новый хостинг с миграцией сайта > автоматически создается тикет с данными доступа оставленными клиентом при заказе).
• Индивидуальные справочные материалы к продукту (индивидуальные блоки F.A.Q.).
• Смена тарифного плана (продукта) через промо-страницу (вместо неприглядного списка с тарифами, как в обычных биллингах). Заменяемый продукт временно маркируется для процесса для вывода вспомогательной информации на промо-странице (режим замены).
• Выбор опций генерации отчетных документов по продукту (период формирования актов, актов-сверок и др.).
• Экспорт продуктов в сторонние сервисы (например: Яндекс.Маркет, Google Merchant Center, Admitad и др.).
• Группировка продуктов по типам (product-kit).

Автоматизация управления хостинг-панелями:

• Управление аккаунтами в панелях Cpanel, ISPmanager (версии lite и pro), SolusVM, ProxMox (beta).
• Подготовленный API для интеграции с дата-центрами (для выделенных серверов), удостоверяющими центрами (SSL) и др.
• Универсальная форма авторизации (форма-посредник) в личном кабинете на сайте (с возможностью сброса/восстановления пароля).
• Менеджмент серверных парков (группы по типам серверов настроенных под определенные CMS).
• Индивидуальные логические сценарии для серверов разного типа (shared/vps/dedicated) и настроек под CMS: Битрикс, Drupal, WP и т.д. Например: для shared-хостинга под Битрикс по тарифу “N” при создании нового хостинг-аккаунта можно отправлять клиенту определенное email-сообщение с индивидуальным описанием и оформлением.
• Гибкость подстановки данных различного типа за счет использования дополнительных токенов (в шаблонах, в условиях (rules) и др.).
• Балансировка загруженности серверов для автоматизации процессов: на каком сервере создавать новый хостинг-аккаунт, уведомления о нагрузках свыше указанной нормы (штатная нагрузка не более 45%) и др.
• Логирование всех действий клиентов при работе с тарифами (апгрейд, блокировка, удаление, создание и т.д.).

Управление доменами:

• Reg Ru - поддержка регистрации менеджмента доменов в различных зонах (beta).
• Встраиваемая в ноды формы проверки доступности доменов (whois) с возможностью моментального оформления регистрации (beta).
• Редактирование DNS-записей (beta).

Центр поддержки:

• Универсальная справочная система с разграничением прав доступа к материалам (пользователи, клиенты, сотрудники). Категоризация и тегирование.
• Поиск по всем справочным материалам;
• Часто задаваемые вопросы с подсветкой вариантов по мере набора текста пользователем (клиентом);
• Тикет-система для клиентов с обновлением сообщений в реальном времени.
• Интерпретация тикетов в виде доски канбан, календарь и настраиваемыми списками.
• Гибкая настройка канбан-досок по статусам и на основе отделов поддержки в т.ч. по типам услуг и продуктов.
• Треккинг времени работы с тикетом.
• Внедрение форм и счетов на оплату в сообщение тикета.
• Автоназначение сотрудников поддержки в зависимости от установленных приоритетов по отделам и сотрудникам, а также по степени их загруженности (учет количества назначенных тикетов по определенным статусам).
• Проверка нахождения сотрудника online в системе при назначении тикета.
• Эскалация тикетов с трекингом в лог.
• Готовые шаблоны ответов (база ответов) для ускорения реакции поддержки по типовым вопросам.
• Автоматические ответы в случае задержки ответа.
• Отправка уведомлений сотрудникам поддержки в случае задержки реакции на тикет.
• Возможность публикации скрытых комментариев в тикетах (для общения в тикетах между сотрудниками).
• Форма согласия с условиями обращения в техническую поддержку перед созданием тикета.
• Онлайн-чат с поддержкой с возможностью приема/отправки файлов, проведения оплат и формирования тикетов из лога чатов.
• Скрытая капча (антиспам) для форм создания тикетов, обратных форм и онлайн-чата.
• Сортировка поступающих обращений в зависимости от уровня поддержки клиента (устанавливается в зависимости от статуса клиента).
• Импорт входящих email-сообщений в систему в реальном времени. Интерпретируются в тикеты. Ответы сотрудников дублируются на email клиента. Отметка о прочтении email приходит в сообщение тикета (скрытый пиксель).
• Возможность отправки ответа из тикета целенаправленно на email и/или sms. Хранение отметки о типе отправки.
• Импорт и экспорт сообщений из групп в социальных сетях (VK, Facebook, Instagram). Интерпретируются в тикеты. Ответы сотрудников дублируются в приватные сообщения клиентам в социальных сетях.
• Просмотр всех обращений от пользователя с фильтрацией по типам.
• Автоматическое определение устройства, IP-адреса, местоположения и другой информации.
• Трекинг входящих и исходящих звонков (VoIP) (beta).
• Трекинг временных затрат по каждому обращению.
• Построение отчетов для службы контроля качества (beta).

Клиенты:

• Установка статуса клиента в автоматическом режиме (на основе используемых способов оплаты).
• Установка статуса клиента в автоматическом режиме: в зависимости от купленных продуктов и/или пороговых значений LTV.
• Юридическое или физическое лицо.
• Смешанный баланс личного кабинета (баланс может пополняться как по безналичному расчету, так и по банковским картам и эл. деньгам от физического лица). В дальнейшем система учитывает эти особенности при формировании отчетных документов и очередности списаний.
• Сбор и хранение данных о пользователе (360 customers profile view).
• Автоматическая регистрация в системе при отправке сообщения в онлайн-чат, создание обращения через тикет (можно отправлять анонимам), email, социальной сети и заполнении форм.
• Сбор и конкатенация данных клиентов (телефоны, email, компания, Ф.И.О. и др.).
• Организация клиентских групп по признакам (organic groups).

Маркетинг:

• Бонусные баллы (кэшбэк) по индивидуальным настройкам каждого продукта.
• Оплата с баланса и/или бонусными баллами с указанием допустимой доли.
• Управление адресными рассылками (email, sms, внутренние в личном кабинете).
• “Нарастающие” скидки (как часть engagement-процессов).
• Ограничение по времени для возможности заказа продукта или пополнения баланса.
• Скидочный таймер под каждый продукт или группу продуктов с привязкой по уникальному ID и cookies.
• Скидки на опциях атрибутов товаров.
• Автоматическая генерация промо-кодов (например, за подписку на новости).
• Продажа подарочных сертификатов. Передача другому пользователю, применение подарочных сертификатов с авторегистрацией пользователя. Привязка к конкретной покупке, либо зачисление суммы сертификата на баланс ЛК.
• Продажа наборов продуктов (product kit) с общей скидкой.
• A/B тестирование промо-страниц.
• Назначение персональных скидок клиентам.
• Возможность управления рассрочкой для дорогих продуктов (beta).

Заказы:

• Возможность авансирования клиентов.
• Учет долговых обязательств клиента.
• Расчет остатка неиспользованных средств по услугам (при отмене услуги и возврате на баланс личного кабинета).
• Обработка и коррекция данных по ФИАС или КЛАДР.
• Виртуальный буфер корзины (когда требуется разделить набранные товары в корзину на несколько разных заказов в виду особенностей оплаты).
• Эквайринг Paymaster для резидентов РФ;
• Эквайринг Stripe для иностранных контрагентов (beta);
• Эквайринг PayPal (отключен, пока PayPal жестит с постоянными проверками);
• Shared-корзина (общая корзина на несколько сайтов на разных доменных именах).

Партнерская система:

• Привязка суб-аккаунтов (партнер вручную создает записи для своих клиентов);
• Аффилированная ссылка (классический учет привлеченных клиентов);
• Промо-коды со скидкой для клиентов (применение промо-кода связывает клиента с партнером);

Бухгалтерия:

• Генерация счетов и отчетных документов (актов и актов-сверок) для юр. лиц.
• Выгрузка готовых документов в СЭД (“Диадок”) для дальнейшего подписания и отправки (beta).
• Добавление в систему нескольких юр. лиц компании (часть услуг и продуктов мы предоставляем от своих дочерних структур).

Сотрудники:

• Расчет по KPI на основе скорости реакции на входящие заявки и качества их решения.
• Типизация задач с премированием за соблюдение установленных сроков выполнения.
• Единый интерфейс и логический принцип всех внутренних инструментов в системе.
• Разграничение прав доступа.
• Гибкая настройка уведомлений на основе приоритетов задач, загруженности сотрудников и отделов.
• Омниканальная система уведомлений сотрудников в случаях превышения установленного времени (задержки) реакции на задачу, инцидент или тикет.
• Просмотр назначенных тикетов и задач на сотрудника (виды: канбан, календарь, список).

Front-end:

• Стандартизация front-end. Исключение переписывания или перекрытия стилей в случае существенных изменений в дизайне.
• Ускорение оформления на 30% в сравнении с классическим написанием стилей на CSS.
• jFlex (см. видео-презентацию). Наша классоориентированная библиотека на SASS. Аналог bootstrap, но с более гибким управлением дизайном (микрошаблонизация) и функциональными возможностями (множество собственных и заимствованных jquery-плагинов с универсальным назначением).
• Адаптив + мобильная (отдельный рендеринг для мобильных устройств).

P.S.

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

Можно считать, что этот кейс про хостинг-проект является примером решения сложнейших задач. Этот вид бизнеса подразумевает применение комплекса сложных технологий, масштабируемость, скорость и непрерывность работы. Стоит ли сравнивать с разработкой даже крупных интернет-магазинов? =)

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

На какой раскрученной CMS или модном фреймворке писать сервис для нас не имело никакого значения: вся суть в стратегии, перспективах и конечной выгоде.

К сожалению, в России рынок enterprise веб-решений на Drupal пока не так развит, как в других странах (просто у Drupal нет масс-маркетинга, да и по-сути он не нужен, ведь кому надо – разберутся и будут пользоваться), но уверен, что в скором времени ситуация будет меняться кардинально быстрее. Когда до предпринимателей дойдет, что знания и технологии НУЖНО капитализировать, а не перебиваться времянками и “скакать” с платформы на платформу, потому что программист ушел =)

По всем вопросам можете обращаться в здесь в ЛС, skype: a.4477, telegram: alex4477

Есть вопрос

Выставка сайтов

2 Thanks

Пример добавления для форматтера 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