Было сообщение, что Иван Абраменко @levmyshkin начал перевод User guide на русский язык, вместе с ним перевод координировал Сергей Трубицын. К ним присоединились несколько человек:
18 июля перевод был завершён. За 3 месяца ребята перевели 264 страницы! И всё это со 136 скриншотами из локализованного на русский язык Друпала. Актуальный на сегодняшний день PDF-файл переведённого руководства прикреплён к этой записи, а по ссылке можно найти HTML-версию на drupal.org.
PS. Ну и не забывайте, что на ДОРе тоже есть справка, которая доступна для правки всем желающим что-то написать или исправить.
ВНИМАНИЕ, данная статья подразумевает, что вы уже умеете пользоваться git, composer и drush
Хостинг компании ra-don.ru один из самых дружелюбных для Drupal 8 сайтов. Тут из коробки сразу есть:
Собственно для того, чтобы развернуть сайт на этом хостинге нужно:
Добавляем разнообразные компоненты Bootstrap на своем сайте на Drupal 8.
Содержание: инструменты разработчика в Chrome, мобильная версия сайта, гамбургер-меню, навигация для мобильного сайта, компоненты бутстрапа, модальное окно (Modals), отправка формы в модальном окне, вкладки (Togglable tabs), подсказки (Tooltips), сворачивающийся текст (Collaps), аккордеон (Accodion), слайдер с фотографиями (Carousel).
Хотите научиться делать сайты? Онлайн-курс Drupal School — то, что нужно!
Выполняйте задания по созданию сайта на Drupal и вскоре научитесь делать сайты самостоятельно. В каждом уроке вас ждет подробное описание и полезные ресурсы. Задания проверяются автоматически, а если остались вопросы — пишите в обсуждение: https://vk.com/topic-42625288_40095744
Не терпится начать? Поехали: http://drulabs.com/
Подписывайтесь на рассылку «Задания Drupal School», тогда вы точно не пропустите очередной урок: https://vk.com/app5728966_-42625288#114377
В моем предыдущем посте вы могли прочесть начало истории и том, как зарождалась идея создания собственной системы управления. Управление хостингом – сложнейший процесс, и в своих поисках идеального решения мы остановились именно на базе 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 для сайтов. Это истории обретения драгоценного опыта. И наш опыт подтверждал снова и снова идею о том, что разрозненность процессов в бизнесе – это большое зло. Очень большое.
Список длинный, поэтому я выделяю для вас основные проблемы:
Менять платформу каждые 2-3 года – бесперспективно. Мы предпочитаем один раз вложиться в правильный инструмент, стать профессионалами и гарантировать его работоспособность в перспективе. Мы чувствуем себя спокойно, и мы знаем, что будет с платформой через 5 лет. С Drupal все будет хорошо, и мы будем через пять лет еще более крутыми специалистами.
Мы свои выводы сделали, дело за вами.
ЦелиСнижение внутренних рисков
Масштабируемость
Бизнес-процессы
Мы имеем возможность воссоздавать аналогичные и дочерние проекты в десятки раз дешевле и быстрее.
Многие компании просто не реализуют свой бизнес-потенциал только потому, что создание даже одного профессионального сайта стоит кучи денег и сил, не говоря уже о системе автоматизации процессов. А финальным гвоздем в крышке гроба становится вопрос о том, как одновременно поддерживать несколько веб-проектов, если зачастую ресурсов едва хватает на один.
Наша идея, которая казалась сложной и даже невозможной стала реальностью. Да, мы потратили время и деньги, но это инвестиция, которая дает свои результаты.
Drupal дал нам свободу развития. И при всей его свободе мы избавлены от бесконечного допиливания и переделок решений, от причудливой архитектурную энтропии, от привязки к конкретным разработчикам. Мы контролируем систему сами.
Используемый функционалПродукты:
Автоматизация управления хостинг-панелями:
Управление доменами:
Центр поддержки:
Клиенты:
Маркетинг:
Заказы:
Партнерская система:
Бухгалтерия:
Сотрудники:
Front-end:
Коллеги, надеюсь, что наш кейс будет полезен не только в частном понимании применения Drupal, но и в качестве демонстрации его возможностей Вашим потенциальным клиентам. Несложно провести аналогию и представить, как будет работать любой другой веб-проект на базе Drupal или Drupal Flex.
Можно считать, что этот кейс про хостинг-проект является примером решения сложнейших задач. Этот вид бизнеса подразумевает применение комплекса сложных технологий, масштабируемость, скорость и непрерывность работы. Стоит ли сравнивать с разработкой даже крупных интернет-магазинов? =)
На своем примере мы просто демонстрируем технологические преимущества, которые важны для стратегии развития любой серьезной компании.
На какой раскрученной CMS или модном фреймворке писать сервис для нас не имело никакого значения: вся суть в стратегии, перспективах и конечной выгоде.
К сожалению, в России рынок enterprise веб-решений на Drupal пока не так развит, как в других странах (просто у Drupal нет масс-маркетинга, да и по-сути он не нужен, ведь кому надо – разберутся и будут пользоваться), но уверен, что в скором времени ситуация будет меняться кардинально быстрее. Когда до предпринимателей дойдет, что знания и технологии НУЖНО капитализировать, а не перебиваться времянками и “скакать” с платформы на платформу, потому что программист ушел =)
По всем вопросам можете обращаться в здесь в ЛС, skype: a.4477, telegram: alex4477
Коллеги, поздравляю всех с Днем Победы!
По иронии этот текст был написан именно к 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 лет для текущего и нескольких новых проектов. Применить свой опыт работы с другими системами, чтобы учесть все по-максимуму (взять лучшее и исключить посредственное).
Вместе с командой разработчиков составили список необходимых нам решений с подробным описанием каждой функции.
Вот что получилось:
Мы начали разработку. Пропущу рассказ про новый опыт и “умывание кровью” на протяжении долгих месяцев, но мы знали, что все задуманное возможно. Даже несмотря на нашу небольшую команду.
Про время и деньги
Проект получился дорогой и долгий. Нужно было отбивать зарплаты и приходилось браться за некоторые клиентские проекты. Нам повезло запустить крупные ecommerce-сайты для нескольких известных брендов (Великобритания, Германия, Россия). Называть компании не буду (NDA), но уверен, что каждый читающий этот кейс что-то у них покупал =)
Кстати, задачи у наших клиентов были примерно похожи: от нас требовалось в максимально короткие сроки запустить достаточно сложный функционал с интеграциями 1C, SAP и кастомными корпоративными ERP. Наши универсальные наработки позволяли сократить сроки в 4, а то и 10 раз. Не скажу, что все было идеально, но на тот момент критичные задачи бизнеса решались. Искренне благодарен нашим клиентам за их веру и поддержку в нас в и Drupal!
Мы получили новый опыт в крупном профессиональном ecommerce, протестировали систему на масштабируемость, погоняли под высокими нагрузками и улучшили имеющийся функционал, а также разработали много нового. Несмотря на срочность разработок мы как-то умудрились делать все без “костылей” и “времянок”, но сильно рисковали сроками.
День победы над Drupal =)Сейчас все хорошо. Мы реализовали все, что когда-то планировали. Протестировали систему на наших и на клиентских проектах. Система в боевом режиме, работает как часы. Разумеется highload.
Назвали детище "Drupal Flex" и во всю готовим его для публичного релиза. Пишем мануалы, оформляем сайт, доделываем всякую мелочевку.
Все функции изначально делались универсальными, поэтому система подходит для проектов различной направленности и сложности:
Если кому интересно, вот некоторые скриншоты вида “под капотом”:
Список реализованных функций с описанием (не полный, еще пишем).
Разумеется, мы буду рад продемонстрировать систему всем желающим. Пишите мне в ЛС и я отправлю доступы к инстансу.
ВыводыСуществует некая иллюзия “идеальной” 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, веб-разработчики часто выбирают другие системы, играя в короткую игру. Так проще и дешевле, но не перспективнее.
Я не преследую цели давать какую-либо оценку Drupal или убеждать в (не)правильности выбора. Изложенная информация для тех, у кого есть интерес к Drupal или кто сравнивает его с другими системами. Кто думает над тем, стоит ли вкладывать свое время и усилия в изучение и разработку на этой платформе.
Drupal – это о долгосрочных перспективах.
Желаю, чтобы как можно больше компаний в России начали применять Drupal и на достойном уровне. Так как это делается во всем остальном мире.
Все в наших руках, если очень захотеть =)
И еще раз всех с Победой!
Насколько критично: средне (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.
Месяц назад я подал заявление об уходе с текущей должности и, вдохнув весенний воздух и отряхнув пивную пену, могу подвести итоги для себя и поделиться опытом с почтеннейшей публикой.
Аккурат год перед тем я заступил на должность старшего Друпал-разработчика в рекламной компании “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, банков. Но переезжать из одного болота в другое - как говорится, плавали, знаем. Отдельным анекдотом мог бы рассказать историю про переговоры с Новартисом, но уже не буду. И так никто до конца не дочитал.
Так что будете у нас на Влтаве - заходите в гости, не будете - спрашивайте, что интересно.
Хочу представить новый модуль, который будет использоваться здесь, на друпал.ру в том числе.
Модуль называется Rules Telegram и позволяет отправлять уведомления в телеграм через правила модуля rules.
Идея модуля была взята из репозитория Алексея Дёмина. Основная фишка кроется в том, что модуль позволяет использовать прокси сервер, т.к. телеграм на территории РФ заблокирован или работает нестабильно.
На друпал.ру пока что модуль будет использоваться только для админов и модераторов. Возможно потом функционал отправки уведомлений в телеграм будет доступен и для пользователей
18 апреля командой безопасности Drupal были выпущены обновления, закрывающие критические уязвимости в ядре Drupal 7 и Drupal 8.
Необходимо в срочном порядке обновить ядро до версии 7.66, а также 8.6.15.
Переход с 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 можно ознакомиться на странице 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» из блога Дриса Бёйтарта.
Пробуем различные компоненты Bootstrap на своем сайте на Drupal 8.
Для развития нашего сообщества и популяризации Drupal в рунете активисты пишут статьи про Drupal и смежные темы, а также переводят на русский интересные и полезные материалы с других языков.
Подготовка качественного перевода — непростое дело. На помощь приходят сервисы управления и автоматизации переводов. Обычно их использование требует финансовых затрат, что может быть неудобно людям, делающим свой вклад безвозмездно.
С радостью сообщаю, что мы получили бесплатную open-source лицензию Crowdin для перевода документации и статей для нашего сообщества.
О платформе CrowdinCrowdin – инновационный облачный сервис для управления переводами и локализацией. Crowdin упрощает и ускоряет перевод, автоматизирует процесс локализации. Идеально подходит для agile-команд и локализации любого типа контента: программного обеспечения, мобильных и веб-приложений, видеоигр и веб-сайтов.
Факты о компанииЯ верю, что сотрудничество с Crowdin поможет нам значительно ускорить перевод документации Drupal и полезных статей на русский язык.
В течение ближайшего времени мы подготовим все необходимое для совместной работы над переводами и разместим отдельный пост с дальнейшей информацией.
Следите за новостями!
20 марта командой безопасности Drupal были выпущены обновления, закрывающие критические уязвимости в ядре Drupal 7 и Drupal 8.
Необходимо в срочном порядке обновить ядро до версии 7.65, а также 8.6.13.
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.ru и модерации теперь можно задавать в телеграм-бот @drupalrusupportbot.
Исходный код drupal.ru с момента его открытия размещался на GitHub, при этом в качестве инструмента CI использовался сервис zen.ci. К сожалению, некоторые технические моменты затрудняют деплой кода на dev- и live-серверы проекта.
Мы решили перенести репозиторий на GitLab и воспользоваться встроенным в него GitLab CI. В наших личных проектах Gitlab и его CI показали себя отлично!
Проект drupal.ru доступен по адресу https://gitlab.com/drupal.ru
Пробный импорт репозитория из GitHub в GitLab прошел успешно. Теперь мы ожидаем, что участники сообщества, авторы тикетов (issue) и комментариев, создадут учетные записи в GitLab. Затем, приблизительно через неделю, мы сделаем повторный импорт репозитория, чтобы в GitLab отразилось авторство тикетов и комментариев.
Если вы создавали тикеты и участвовали в дискуссиях в репозитории drupal.ru на GitHub, то, пожалуйста, зарегистрируйтесь в GitLab с теми же данными, что в GitHub.
20 февраля командой безопасности Drupal были выпущены обновления, закрывающие критические уязвимости в ядре Drupal и контрибных модулях.
Если вы используете модули RESTful Web Services, JSON:API, Link, вам нужно немедленно их обновить.
Также необходимо в срочном порядке обновить ядро до версии 8.6.10 или до версии 8.5.11 (если вы по какой-то причине не перешли на ветку 8.6)
Ядро Drupal 7 обновлять не нужно.
Всем привет!
С небольшим опозданием мы хотим поблагодарить участников за вклад, который они сделали в развитие нашего сообщества и Drupal в Рунете в 2018 году.
Развитие Drupal, как и любого другого программного обеспечения с открытым исходным кодом, очень зависит от вклада, который делает каждый участник сообщества. Прошедший год принес много положительного нашему сообществу. Каждый день вы безвозмездно делились своим опытом и знаниями: в статьях и комментариях на сайте, в наших телеграм-чатах, во время встреч и на митапах.
Мы хотим особенно отметить самых активных участников нашего сообщества и в знак признательности вручить памятные футболки.
АктивистыПри составлении списка учитывались опубликованные в 2018 году на нашем сайте статьи и комментарии, получившие наибольшее количество лайков, а также активность в основном телеграм-чате и чате для новичков.
Команда сайтаМы также хотим поблагодарить прошлых и нынешних участников команды drupal.ru за помощь в развитии сайта:
Будем надеяться, что ежегодное подведение итогов сообщества станет доброй традицией, а список активистов будет только пополняться.
Дизайн футболки:
Выражаем особую благодарность компании «Далее» за финансовую и организационную помощь в подготовке события! «Далее» — одно из ведущих digital-агентств России, активно поддерживает наше сообщество, и в частности, московскую drupal-группу, предоставляя свой офис для проведения встреч и мероприятий.
Прошу упомянутых участников написать мне в личку или в телеграм для уточнения размера футболки и адреса доставки.
Второе большое обновление темы коснулось базового шрифта, основного цвета, полей и отступов, отображения материалов и комментариев, а также списков материалов.
Из наиболее видимых изменений стоит отметить следующие:
Кардинальные изменения были внесены в php-, html- и lesscss-код шаблонов страниц, списков и элементов:
Sorry, your browser doesn't support embedded videos,
but don't worry, you can download it
and watch it with your favorite video player!
Sorry, your browser doesn't support embedded videos,
but don't worry, you can download it
and watch it with your favorite video player!
Список проблем и багов, а также статус их исправления можно отслеживать в нашем репозитории в issue https://github.com/DrupalRu/drupal.ru/issues/1276
Последние комментарии