Каково это для разработчика, переходящего на Wagtail из Drupal?

Прежде всего … Краткое введение в трясогузку и почему (хвост)

Wagtail — это CMS с открытым исходным кодом, написанная на Python и построенная на платформе Django. Созданный разработчиками для разработчиков, он предлагает быстрый привлекательный интерфейс для редакторов, где контент может быть создан и структурирован интуитивно.

Оригинал статей здесь.

Скорее всего, вы слышали о Drupal и WordPress. В прошлом я также использовал CodeIgnighter и Laravel, общим потоком здесь является PHP. Поэтому я должен сказать, что сначала я был несколько напуган, когда проверял Wagtail, в основном из-за Python. Я не занимался программированием в университете, поэтому Python всегда был мне немного страшен, но после этого он стал чертовски удивителен.

Действительно, выбор Wagtail, Drupal или WordPress должен и, вероятно, будет зависеть от того, что вы хотите построить. Это должен быть взвешенный выбор. Эти CMS можно использовать для построения всех видов сайтов, и при сравнении данных инструментов может возникнуть много плюсов и минусов, если вы хотите узнать больше, просто посмотрите Google Drupal против WordPress, и довольно скоро вы забудете, что вы собирались собирать, на первом месте. Моё новое эмпирическое правило: «Как это можно сделать простым?»

Итак, недавно я решил поднять сайт с Drupal 8 и переместить его в Wagtail, чтобы проверить воду. В конце концов, мне потребовались выходные, вот что мне понравилось.

1. Он ориентирован на публикацию

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

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

2. Он построен на Джанго

Я все еще изучаю, как все это устроено, но благодаря работе по разработке, которую я проделал, это возможность использовать Django на вашем сайте Wagtail. Для некоторых это может показаться очевидным, но для меня это не так. Я слышал много болтовни о том, что Symfony находится в Drupal 8, и о том, как это было удивительно, но если вы действительно не находитесь в глубине разработки, вам даже не нужно будет замечать Symfony. Принимая во внимание, что в Wagtail, если вы хотите что-то сделать в одном из своих приложений, вы можете использовать что угодно из Django (и вы, вероятно, будете это делать).

Если вы собираетесь отправиться в это путешествие самостоятельно, я бы порекомендовал также выполнить урок по Django, чтобы вы могли сами увидеть, как выглядит Django.

3. Это лучший опыт разработки

В Laravel мне очень понравилось то, как он справлялся с миграциями. В Drupal это осуществляется с помощью модуля функций и, в последнее время, импорта и экспорта конфигурации с помощью файлов .yaml. Laravel был асом, потому что вы записали свои «типы контента», а затем выполнили php artisan migrate (IIRC), и был сгенерирован код схемы. ACE. Не поймите меня неправильно, Drupal может хорошо справляться с некоторыми сложными настройками конфигурации, особенно с разделением конфигурации, но любой, кто читает это, кто должен был объединить конфликты функционального кода, почувствует мою боль.

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

Прощай интерфейс

Это не название причудливой новой интегрированной среды js, я имею в виду, что через пользовательский интерфейс не ведется разработка. Все, что вы (как разработчик) сделаете, будет в коде. Прекрасный код Python, больше без точек с запятой.

Есть огромные плюсы к этому. В основном, разработчики должны чувствовать себя разработчиками. По моему опыту, почти каждый разработчик предпочитает быть в коде. Но я также видел, что слишком много сайтов стали немного грубыми из-за того, что люди создавали и редактировали типы контента в Drupal, не зная связанных с этим рисков. Конечно, вы можете сказать: «Ну, это в дикой природе сейчас … будь что будет». Но вам действительно не нужно рисковать, что ваша работа станет вульгарной. Трясогузка не просто устраняет этот риск, она также говорит: «Вы беспокоитесь о публикации, а я беспокоюсь об остальном».

4. Хостинг может быть простым

Хорошо, это заставило мою голову вращаться немного больше. Что такое UWISGI, что такое Gunicorn. Ну, я все еще не на 100% в этом вопросе, но я начал искать, где принимать и как принимать, и, оказывается, мне не нужно было об этом знать на самом деле.

Естественно, я просто подключил докер к AWS, как обычно, с чем-то новым, но я столкнулся с вещами немного из-за своих технических возможностей. К счастью, я начал смотреть на то, как люди принимают Джанго и нашел Heroku. Как возвращение старого друга (с тех пор, как я делал приложения для Facebook), хостинг на Heroku довольно прост. Этот пост от Кайла Руттена просто восхитителен и поможет вам настроить сайт Wagtail на Heroku.

5. Документация — туз

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

6. Это Питон!

Перед тем, как заняться трясогузкой, я начал изучать немного языка Python, в основном через Treehouse, и некоторые небольшие личные проекты, такие как Squares . Существуют тонны ресурсов для изучения Python, учитывая его возраст и популярность, на самом деле речь идет о поиске метода, который работает для вас. Домик на дереве дал мне достаточно, чтобы начать. Стоит также проверить Flask , микро-фреймворк для Python.

Локально, я использовал Vagrant и Docker в прошлом. Вы можете использовать их с Wagtail и Django, но вы также можете использовать Virtualenv и более новый Pipenv . Мой любимый на данный момент Pipenv, он очень быстрый и простой в использовании. Но для этих действительно больших проектов Vagrant и полноценная виртуальная машина, вероятно, все еще будут лучшим решением.

В итоге

Как разработчик, это может быть пугающим шагом в другой мир, особенно такой, как Python. Но я рекомендую просто проверить это. У Wagtail и Django много интересного, я был очень удивлен тем, как легко было что-то сделать, а производительность потрясающая.

Как разработчик, я всегда пробую новые фреймворки и технологии, но у меня обычно есть надежная основа, к которой можно прибегнуть. Долгое время Drupal был моим ядром разработки, и я работаю с ним уже более 5 лет, от начала до конца. Конечно, я бы использовал новые технологии, такие как AngularJS или Vue.js, но я никогда не думал о совершенно новой среде. Я давно пользуюсь Drupal, так зачем мне менять такую ​​прочную основу? Ну, оказывается, это не так твердо …

Я работал на Torchbox, создатели трясогузки, в течение года на Drupal 7 и 8 проектов. Предстоящие изменения в ядре для Drupal 8 включали переход к развязке, использование существующих библиотек PHP, таких как Symfony, более плавный рабочий процесс публикации и улучшенное управление кодом. Ненавижу это говорить, но для меня поставка этих изменений несколько отстала от цели. В то время как сообщество разработчиков Drupal действительно получило большие изменения, стоимость была огромной. Изменения, в частности привлечение Symfony, были хорошим решением, но в результате всего за несколько месяцев опытные разработчики Drupal столкнулись с освоением нового способа работы с Drupal. И они должны были выучить это быстро. Это оставило разработчиков, клиентов и, в частности, разработчиков сайтов на Drupal почесывать головы больше, чем обычно. В подвешенном состоянии перехода с Drupal 7 на Drupal 8 мое любопытство к альтернативам увеличилось. Пришло ли время узнать что-то новое? Могу ли я принять что-то большее, чем создание веб-сайтов?

По сравнению с Drupal трясогузка молода, но она быстро растет. Если вы рассматриваете Drupal 8 как новую CMS (как и я), они уже примерно столько же времени, но фреймворк Django, на котором построен сам Wagtail, почти такой же старый, как Drupal. Это дает нам некоторые хорошие признаки … Он здесь, чтобы остаться, у него есть основная команда разработчиков, и у него есть документация. Итак, после того, как я перешел с сайта Drupal на Wagtail и увидел немедленные выгоды, почему я решил остаться с ним?

  • У трясогузки есть сообщество, в которое вы можете легко войти.
  • Для разработчиков Wagtail — отличный инструмент для добавления в ваш инструментарий для создания веб-приложений, а также изучение Python — это совершенно новый инструментарий, потому что он используется во многих отраслях, а не только в веб-разработке. Это действительно положительно для вашей карьеры разработчика
  • Список организаций по всему миру, которые независимо выбрали Wagtail для крупных проектов, впечатляет, и он быстро растет. Google, Nasa и Oxfam, чтобы назвать несколько.

PHP в Python 🐍

Первое, с чем нужно смириться, — это на самом деле писать Python и сколько кода вы будете писать. Вы больше не будете «строить» вещи в пользовательском интерфейсе. Это открывает для вас множество новых аспектов развития и будет отличаться в зависимости от вашего уровня квалификации, но для меня я никогда не был знаком с традиционными концепциями разработки, потому что Drupal обрабатывает многое для вас, и вы никогда этого не видите. Изучив основы языка, я нашел несколько отличных инструментов, которые помогут мне написать лучший код.

Трясогузка просит всех участников придерживаться руководства по стилю PEP8. Итак, хорошая привычка — писать код, соответствующий этому стандарту. На самом деле, я не собираюсь читать и запоминать новый стандарт кодирования, новый от PHP-лодки с полуколоннами для обуви. Мой коллега ( Рич ) предложил установить git hook перед фиксацией который использует Flake8 для проверки кода на соответствие стандартам PEP8, он улавливает такие вещи, как ошибки длины строки (E501, если вам интересно) и неиспользуемый импорт. Я не могу не подчеркнуть, насколько это хорошо, в основном потому, что, не зная об этом, вы начинаете небольшую игру, пытаясь побить Flake8, что приводит к лучшему коду. В VSCode вы также можете настроить запуск PEP8 при сохранении файла, и ошибки будут отображаться в выходных данных. Лично я предпочитаю git hook, потому что вы не сможете совершить коммит до тех пор, пока он не будет исправлен, и, хотя в напряженные времена это раздражает, это похоже на то, что вам лучше постучать по плечу, говоря: «Теперь, я знаю, что вы занят, но давайте сделаем это правильно ».

Приложения Wagtail (Django) похожи на модули Drupal

Вы, наверное, уже это знаете, но по сравнению с Drupal 8 это легче понять. Drupal 8 использует Symfony, Wagtail использует Django. В частности, Wagtail построен на веб-фреймворке Django. Поэтому, работая с Wagtail, вы будете работать с Django. Мне нравится думать о приложениях сообщества для Wagtail и Django как о модулях Drupal. Это решения, созданные сообществом для использования в вашем проекте, но когда ваш проект Wagtail станет более индивидуальным и сложным, вы, скорее всего, будете использовать часть Django вашего проекта. Существует множество приложений Django, которые вы можете использовать, но также есть и приложения Wagtail… просто посмотрите этот удивительный список в Springload .

Хороший редактор 📝

В Drupal я использовал IDE IntelliJ PHP Storm. Это потрясающе, и при разработке Drupal 8 Xdebug был необходим. Будучи поклонником продуктов IntelliJ, я попробовал PyCharm, но вы можете отлаживать только виртуальные машины с полной (платной) версией. Это потому, что отладка в IntelliJ потрясающая. Я спросил, что другие разработчики Wagtail использовали, и большинство из них были Sublime, VSCode и Vim. VSCode, похоже, больше походил на полноценную IDE, поэтому я попробовал это, и я очень доволен этим. Главным образом потому, что он легче, чем PyCharm, но также потому, что вы можете изменить его в соответствии со своим стилем. Этот пост — отличный урок о том, как похудеть.

Есть и другие приятные вещи … встроенный терминал — это замечательно, такие тонкие вещи, как разделение окон терминала и настройка ключей, действительно полезны, так как я обнаружил, что работаю в терминале гораздо больше с Wagtail. Также довольно легко настроить такие вещи, как обрезка пробелов, когда вы сохраняете файл и, поверьте мне, вы захотите это настроить!

Я настоятельно рекомендую потратить время на настройку вашего редактора и настройку зацепки после фиксации. Это очень помогает и заставляет что-то новое и незнакомое казаться немного менее пугающим.

Запуск сайта

Для Drupal есть много способов начать свой проект локально. Вначале я фактически установил PHP и MySQL на своем локальном компьютере и использовал их, а затем MAMP, но в конечном итоге вы переключитесь на виртуальную среду с использованием Vagrant или Docker. Drupal VM , на мой взгляд, лидирует в разработке на Drupal, предлагая полный подход к Vagrant VM или Docker, а Drupal перечисляет множество способов настройки вашего проекта в документации https://www.drupal.org/ документы / разработка / локальный-сервер-настройка . Как и в случае с Drupal, у Wagtail есть решения Vagrant и Docker, которые выложены повсюду, чтобы помочь вам ( вот хороший пример ). Вы можете найти большинство из них на Github или через веб-поиск. Я думаю, что здесь есть ключевое различие между Wagtail и Drupal.

В Wagtail отправная точка в значительной степени остается открытой для вас как для разработчика (за что я также любил Laravel ). Это здорово, потому что это означает, что вы хотите, вы специально развиваетесь. Вы не манипулируете из коробки инструментами и не сгибаете вещи, чтобы они «как бы работали». Это делает рамки красивыми и легкими.

У Wagtail.io есть отличное 10-минутное руководство, чтобы начать работу, но, исходя из Drupal и используя виртуализацию, я не хочу устанавливать все зависимости на моем локальном компьютере … потому что, если я хочу работать над более старым проектом или другая версия Django? Вы по-прежнему можете использовать такие сервисы, как Docker или Vagrant, но Python предлагает собственное решение для этого, намного быстрее для начала работы. Вы можете использовать что-то вроде Pipenv . Существует также гораздо более устоявшаяся система Virtualenv для Python, но мне нравится Pipenv. Итак, вот модифицированная версия запуска вашего сайта Wagtail с Pipenv. Это создаст виртуальную среду и установит трясогузку со всеми ее требованиями. Поэтому теперь любые пакеты, которые мы добавляем во время работы над нашим проектом, привязаны к этой виртуальной среде.

В качестве бонуса вы можете указать, какой интерпретатор Python вы также используете в Vscode. Подробнее об этом в документации по VScode здесь .

Работа над проектом 📝

Так что теперь у меня есть хорошие настройки редактора, у меня есть изолированная среда, я перестал писать точки с запятой в конце каждой строки кода (ну почти), и после выполнения этой последней команды python manage.py runserver я вижу свою голую трясогузку сайт. Так как же на самом деле выглядит работа с Wagtail по сравнению с Drupal?

Структурно Потрясающе

Очевидно, что файловая структура будет другой, но для меня она была совсем другой. К счастью, все это хорошо документировано в документах Wagtail и Django, но когда речь идет о самом Django, существуют различные способы структурирования проекта, чтобы сделать его более понятным для вас и других. Я настоятельно рекомендую Две ложки Django, чтобы узнать больше об этом. Cookiecutter — отличный инструмент для создания проектов, если вы хотите автоматизировать свою собственную структуру или повторно использовать решения сообщества, такие как pydannys .

Самое приятное в структуре — это то, как приложения и шаблоны располагаются вместе. Шаблон для приложения находится в том же каталоге, что и код, его определяющий. Я открыл много проектов Drupal и видел до сотен файлов шаблонов в каталогах, которые могли бы иметь смысл. Кроме того, реальные имена шаблонов Wagtail просто более понятны, но вы также можете называть их как хотите. Я никогда не обнаруживал, что это является проблемой в Drupal, но я помню, сколько времени мне потребовалось, чтобы понять соглашение по именованию шаблонов в Drupal, потому что система шаблонов Drupal работает, переопределяя шаблоны, уже предоставленные ядром. Это хорошо для тех, кто хочет просто получить что-то «из коробки», но я всегдапришлось Google «переопределить шаблон X», потому что мой мозг отказался хранить эту информацию. Как новичок в Wagtail, даже наименование шаблонов кажется мне более интуитивным. Например:

узел — standard-page.html.twig # Drupal
standard_page.html # Wagtail

Существуют всевозможные преимущества наличия шаблонной системы, такой как Jinja2 или Twig, и хотя Drupal довольно поздно запустил эту вечеринку шаблонов, по крайней мере, она появилась в конце. Подход к шаблонам в Wagtail по умолчанию означает, что вы не ищете шаблоны для переопределения, вы пишете шаблоны, когда они необходимы. Это более приятный и более открытый способ работы, но это также означает, что разработка и планирование Front End может быть выполнено почти полностью отдельно от Back End.

Прекратите создавать типы контента и начните разрабатывать приложения

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

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

https://cdn-images-1.medium.com/max/2000/1*_7cdwtaf-F7gL7i4Wz43SA.jpeg

Добавление типа контента с одним полем

Это просто определение типа контента и поля. Мы еще ничего не экспортировали в код для отправки на наш производственный сайт. После этого мы создадим страницу просмотра для отображения сообщений в блоге. Обычно с пути / блогом…

https://cdn-images-1.medium.com/max/1750/1*SBuL-i2Di0n7WZkvwZSLHA.jpeg

Просмотр списка блогов Drupal

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

  1. Выполнить python manage.py startapp blog
  2. Добавьте новое blog приложение INSTALLED_APPS в mysite/settings/base.py.
  3. Напишите вашу модель с полями для даты, вступления и тела:

4. Запустите python manage.py makemigrations и python manage.py migrate.

По сравнению с Drupal эти 37 строк кода дают нам:

  • class BlogPage(Page) Тип содержимого сообщения блога, включая поля, которые должны быть проиндексированы для поиска.
  • class BlogIndexPage(Page) Страница просмотра списка блогов

def get_context Метод позволяет определить, что страница блога добавлен под индексом блога будет отправлен в шаблон. Более полный пример этого можно найти в Wagtail под руководством Учебное пособие по индексам блогов.

Что действительно хорошо в этом, так это то, что на шаге 4 генерируется код для создания необходимых таблиц базы данных, и хотя это то, что делает новое управление конфигурацией в Drupal 8, вместо массивной папки файлов yaml, мы генерируем код «миграции» для конкретного приложения./Тип содержимого. Если до этого момента вы использовали исключительно Drupal, рассмотрите здесь слово миграция. Трясогузка следует более традиционному подходу к «миграции данных» в процессе разработки. Если вы упомянули о миграции любому опытному разработчику Drupal, то, вероятно, вы будете говорить о миграции контента, которая является более конкретной.

Теперь он полностью переносим как одно приложение. Что еще лучше, что теперь… если мне нужно добавить поле, я просто изменить свою модель, добавить его в мой шаблон запуска makemigrations и migrate. Это гораздо лучший опыт для разработчиков.

Издатели публикуют, разработчики развивают.

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

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

Вот отличный модуль, помогающий создавать меню в Wagtail: https://github.com/rkhleics/wagtailmenus

Отладка 🐛

Одним из наиболее важных инструментов для разработчика является знание того, как отлаживать. Он не только помогает вам решить проблему, но и помогает узнать больше о фреймворке и даже самом коде. В Drupal у нас были Devel, Kint и Xdebug. Большую часть времени я обнаруживал, что он var_dump предоставляет большую часть того, что мне нужно, но Xdebug открыл лучшее понимание того, как работает Drupal 8.

Я ничего не знал об отладке в Python и большую часть времени все еще печатал переменные. Хотя есть несколько отличных инструментов, на данный момент я привыкаю к ​​использованию Pudb . Он похож на Xdebug в том, что он работает с точкой проверки / выполнения в вашем приложении, он откроет интерактивный терминал, когда точка будет достигнута, и вы сможете пройти и проверить. Просто вставьте следующее, где вы хотите проверить

из  pudb  import set_trace; set_trace ()

https://cdn-images-1.medium.com/max/1400/0*ItxrRU8Qmlb0DL6v.png

Pudb отладка

Помните, что мы используем Django, поэтому мы также можем использовать Django Debug Toolbar :

https://cdn-images-1.medium.com/max/1400/1*LRqerYG7KbbpxtWWdaNFmg.png

Django Debug Toolbar

EntityQuery против QuerySet API 🔎

Мы можем получить контент в Drupal, используя что-то вроде EntityQuery. Это предпочтительный способ, но вы также можете использовать прямые запросы, вот пример получения узлов:

$ query = \ Drupal :: entityQuery (‘node’); 
$ query-> condition (‘status’, 1); 
$ query-> condition (‘type’, ‘blog’); 
$ entity_ids = $ query-> execute ();
// Делаем что-то с идентификаторами $ entity, например, загружаем несколько …

Мы должны были бы расширить это для полевой информации, но с Wagtail это намного проще, мы можем использовать Django QuerySet API

blog_posts = BlogPage.objects.live (). order_by (‘title’)

Это не просто приятнее писать и понимать, но на самом деле возвращает список (да, он упорядочен) объектов. В то время как наш запрос Drupal только что получил нам идентификаторы.

Для более сложных запросов, таких как извлечение содержимого из входных данных формы и диапазонов дат для событий, мы можем использовать объекты Django Q:

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

из django.db.models import Q


events = EventPage.objects.live (). order_by (‘title’)
events = events.filter (Q (event_date__range ([start_date, end_date])) | Q (event_is_daily = True))

Узнайте больше об API QuerySet в документации Django , также обязательно ознакомьтесь с Создание запросов и объектов Q

Перевод т () против _ 🌐

Drupal предлагает нам t()для перевода строк, а в Drupal 8 это все еще работает (вроде). Теперь это подключаемый сервис, короче говоря, вы должны использовать внедрение зависимостей для получения сервиса перевода. Для кого-то новичка в Drupal или даже новичка в написании кода, это не просто. Мне не стыдно признать, что мне потребовались усилия, чтобы понять внедрение зависимости.

Для трясогузки мы можем использовать перевод Джанго:

из django.utils.translation импортируйте ugettext_lazy как _

label = _ (» Переведите меня!»),

Сигналы, хуки и подписчики на события 📢

Хуки очень важны для фреймворка, позволяя разработчикам выполнять код в определенные моменты выполнения кода. У меня было то, что можно описать только как кошмар во время работы с крючками Drupal 8. Я не осознавал, насколько они были кэшированы в Drupal 8. Я бы сказал, что hook_node_view()теперь это в значительной степени бесполезно, потому что это кэшируется. С добавлением Symfony теперь возможно и гораздо предпочтительнее использовать EventSubscribeers в Drupal 8.

В Wagtail реализован диспетчер сигналов Django, а в документации Wagtail есть несколько замечательных примеров использования сигналов для таких вещей, как аннулирование кэша :

Более того, вы также можете зарегистрировать свои собственные функции, определив их в wagtail_hooks.pyфайле с помощью @hooks.registerдекоратора:

из  wagtail.core  hooks для импорта

@ hooks.register (‘name_of_hook’)
def my_hook_function (arg1, arg2 …)
    # ваш код здесь

Подводя итоги ️ Хорошая ли идея?

Для меня это легко. Да, и если вы тоже разработчик, я думаю, что переход на Wagtail заново определит причину, по которой вы были заинтересованы в разработке. Роль «Drupal Site Builder» постепенно устареет, так как становится лучшей практикой создавать функциональность в коде, а не использовать сотни модулей, так зачем ждать этого? Почему бы не переключиться на что-то, что не только уже делает это, но делает это в течение долгого времени? Переход к другому фреймворку оставит у вас вопросы, он представит концепции, которые вам понадобятся для понимания, которые вы раньше не рассматривали, а переход на Python может вызвать у вас головокружение на начальном этапе… Но придерживайтесь этого, не бойтесь, помощь доступна и все больше таких людей, как вы, делают это каждый день. Присоединяйтесь к Wagtail Slack и узнайте, как идут дела у людей.

Закладка Постоянная ссылка.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *