Мы продолжаем приводить аргументы в пользу Drupal и привлекать для этого экспертов: руководителя отдела Drupal-разработки агентства «Далее» Виктора Степанькова, технического директора компании «РаДон» Александра Дубовского, автора блога niklan.net Никиты Малышева и сотрудников ADCI Solutions — технического директора Антона Шубкина и директора Александра Кузнецова.
В первой части мы обсудили преимущества Drupal перед другими CMS. Теперь пора разобраться, когда между Drupal и кастомной разработкой стоит выбирать первое, и когда пора привлекать специалистов веб-разработки, чтобы раскрыть весь потенциал этой CMS.
Drupal хорош, когда нужно быстро стартовать или когда неизвестны конечные требования к продукту (читай: отсутствует ТЗ). Я бы сказал, что Drupal является идеальным средством для прототопирования и последующего рефакторинга вкупе со своими возможностями «визуальной» сборки админок, системой алиасов, image styles и т. п. В любой момент можно заводить новые сущности, менять связи между ними, переносить данные.
На полностью кастомных разработках на сторонних решениях приходится сталкиваться с тем, что не реализованы самые базовые вещи, либо реализованы так, как посчитал нужным разработчик. Это, например, SEO, кеширование или обработка ошибок. Если нам недостаёт возможностей CMS, то под капотом есь компоненты Symfony и привычные механизмы по модификации бэкенд-логики.
Drupal можно отнести к low-code решениям — он позволяет собирать MVP без участия разработчиков, либо с их минимальным участием. По мере развития проекта и его потребностей это решение можно будет без проблем расширить или перенести «в код».
Drupal «из коробки» предоставляет множество различных решений, для которых в конкурирующих с Drupal системах вроде WordPress, Joomla и Bitrix уже ищут разработчиков и пишут код.
Drupal выигрывает у кастомной разработки за счёт скорости старта, меньшего бюджета на MVP или тестирование бизнес-идеи. Он дешевле для не особо больших проектов и проектов, состоящих из стандартных задач, которые легко решаются из коробки или контрибными модулями. И, естественно, он очень хорош для контентных сайтов.
Вообще, перед выбором инструмента надо понимать цели проекта и то, какие плюсы и минусы есть у одного и другого подхода. Старт на Drupal вовсе не значит, что нельзя переехать на кастомное решение в случае успешности проекта или если Drupal по какой-либо причине перестал удовлетворять прежним задачам и требованиям. Тут всё в руках команды разработчиков. Да и использовать оба подхода вместе ничего не мешает.
О Drupal часто говорят как о CMS, с которой можно справиться даже без знаний программирования. Отчасти это так, но где проходит граница, когда накликивания мышкой мало для того, чтобы сайт стал полноценным представительством бизнеса в интернете, и пора обратиться к команде специалистов?
Для решения части задач своими силами клиенту нужно будет разобраться, как устанавливать и обновлять ядро и модули, понять принцип таксономии, разобраться в типах материалов, полей и блоков. Это минимальный набор, использование которого рано или поздно приведёт к общению с разработчиками и привлечению их на задачи посложнее. Но спросите у себя честно, надо ли вам всё это? Каждый должен заниматься своими делами: бизнесмены — бизнесом, разработчики — разработкой.
Клиенту не стоит разбираться с Drupal самому в случае, если задача выходит за рамки управления сайтом и контентом. Drupal — это не про one-click решения по разворачиванию маркетплейсов с интегрированной социальной сетью, когда что-то скачал, где-то поставил галочку и готово. Нужно понимать, что ты делаешь и к чему это потенциально может привести.
Для того, чтобы набросать структуру контента или данных, их связи, выборки и фильтрации, не нужно быть даже middle-разработчиком — вполне хватит джуна, знакомого с базовыми понятиями.
Потребность в профессиональной помощи возникает тогда, когда у сайта кастомный дизайн, требования к функциональности не решаются модулями ядра или контрибными модулями и требуют кодинга, когда проект высоконагруженный и когда есть техническое SEO.
Способностей человека, не знакомого с кодом, не хватит, когда нужно выпустить продукт для drupal.org. Например, у вас платёжная система и вы хотите сделать универсальный модуль для Drupal-комьюнити. Также помощь профессионалов понадобится тогда, когда у вас коммерческий проект и вы до этого ни разу не работали с Drupal, а сроки поджимают. Но в целом вы можете сами начать прототипировать проект, скинув ваши размышления об архитектуре в специализированные Drupal-чаты в телеграме или в drupal.ru, и вам датут общие рекомендации, что лучше изменить в архитектуре.
Заключение
Если бы система Drupal была простой, как песня, ни мы, ни наши эксперты не занимались бы сайтами на Drupal профессионально. Но с 2007 года через ADCI Solutions прошли сотни проектов от простых сайтов с контентом до eCommerce и CRM. Мы делали сайты с нуля и совершенствовали уже готовые, но не выполнявшие своих задач, проводили редизайн и внедряли функциональность, повышающую удобство пользования и, как следствие, конверсию посетителей сайта в клиентов бизнеса. За подробностями приглашаем вас в наше портфолио на Рейтинге Рунета, а за консультацией по проекту обращайтесь по адресу [email protected].
Drupal - это машина времени, установил и ты уже в начале 2000-ых
Чувак! ты наёбал уже почти 20 сообщений под этим постом. Сходи чтоли прогуляйся, воздухом подыши. Потом открой гугл, посмотри что такое Композер, компоненты симфони, PSRы в конце концов почитай (для совсем несчастных они даже на русский переведены), поищи как все современные практики применяются в твоём любимом решете и когда проплачешься возвращайся и «пеши есчо».
Решето это Drupal я то помню вечные обновления безопасности причем в ядре, а composer прожорливое чудовище в контексте DrupalComposer благодаря этому многие бегут с вашего любимого Drupal и так будет и дальше. А симфония такой же никчемный продукт лягушатников как и Drupal
И только ядро вордпресса неуязвимо, правда, что там ничего и нет...
Ни тебе форм, ни тебе кеширования, ни ORM.
wp_query(), get_post(), wp_reset_query(), да hello_dolly(), что ещё нужно современному разрабу?
Зато какая благодать в плагинах, чего стоит только недавняя уязвимость с ElFinder, где в контрибе лет так пять пролежала уязвимая версия либы, а всё потому что автор плагина его ручками собрал, залил на вп.орг и забил.
https://github.com/Studio-42/elFinder/commit/f67ec9212839b5c74cd982a928bc57984cf4a873#diff-03fe27afac1d5412f4a7727058e318e7
Зато без мерссских композеров
ну конечно на каждом сайте надо все это и прочее aka форум
Скорее бы симфони украла важнейшие API-функции самого лучшего и гибкого движка.
https://developer.wordpress.org/reference/functions/hello_dolly/, ранее упоминал
https://developer.wordpress.org/reference/functions/disabled/, потянет на API форм, ага
https://developer.wordpress.org/reference/functions/antispambot/
https://developer.wordpress.org/reference/functions/capital_p_dangit/
https://developer.wordpress.org/reference/functions/__return_false/
https://developer.wordpress.org/reference/functions/__return_true/
Ну вот правда, вы защищаете вот эту кодовую базу?
Вопрос не кодовой базе а в том как инструмент решает задачи
Инструмент никак не решает задачи, ибо всегда является вспомогательным по своей роли, за любым инструментом всегда стоит исполнитель.
Вы тут уже столько накомментили, только непонятно зачем, если тот же Drupal никогда не претендовал на сегмент сайтов за 1000 баксов, собираемых одиночками и в билдерах, за который вы активно топите
Меня раздражают вот такие вот посты где пытаются возвысится за счет принижения достоинств других систем
Другие системы упомянуты только в цитате от Никиты Малышева.
Вы на неё так триггернулись?
Я прочитал и иные от ADCI Solutions и хотя реально с уважением отношусь именно к данной студии и их разработкам но в данных постах и комментариях неоднократно были упомянуты иные системы в негативном свете
так то даже drupal ru был сделан одним человеком еще в пик популярности этой системы