Комментарии 68
Drupal это скорее CMF, звено между фреймворком и CMS.
Делать что-то более сложное на Wordpress-е чем бложик, это из разряда троллейбуса из буханки.
Делать что-то более сложное на Wordpress-е чем бложик, это из разряда троллейбуса из буханки.
Я с Вами не соглашусь. Как на drupal так и на wordpress можно построить достаточно не плохие сайты. Все зависит от знаний той или иной системы.
Я видел сайты по инвестиционно-банковским, брокерским услуги, услуги по управлению активами, и на drupal так и на wordpress. Делали сайт 2 разные команды. Результат не плох.
Я видел сайты по инвестиционно-банковским, брокерским услуги, услуги по управлению активами, и на drupal так и на wordpress. Делали сайт 2 разные команды. Результат не плох.
Dupal 7 сейчас не самая удачная точка входа в мир веб-разработки, учитывая что он потихоньку переходит в режим security-updates only и перестаёт активно развиваться, Drupal 8 построенный на Symfony компонентах с одной стороны даёт CMS на которой можно развернуть блог мышкой, с другой — возможность плавно переползти на Symfony если это потребуется в дальнейшем.
После базовой установки WP создаёт 11 таблиц БД, Drupal — более сотни (на первый взгляд это пугает, на второй тоже)
При установке стандартного профиля друпал создаст 74 таблицы, а при установке минимального — 49, что явно меньше сотни.
есть функция remove_action(), с помощью которой можно отменить хук другого модуля, а в Drupal такого механизма нет.
в друпале такой механизм есть — hook_module_implements_alter
В Drupal аналогов этим API нет.
Аналог WP REST API в друпале это модуль Serives и похожие. В восьмой версии функционал доступен из коробки.
Не так давно в Drupal появился Entity API
«Не так давно» это более 5 лет назад например =)
Спасибо за комменты (и за блог конечно).
Я имел ввиду просто drush dl drupal7 и enable самые обычные модули для разработки, которые обычно применяются почти всегда. Без попыток что-то специально оптимизировать. Вроде как будет около 100 или даже больше. Поупражняюсь еще.
Я думал он очерёдность вызова хуков регулирует.
Ок. Просто в WP это в ядре.
Да, согласен, быстро время идёт...=)
При установке стандартного профиля друпал создаст 74 таблицы, а при установке минимального — 49, что явно меньше сотни.
Я имел ввиду просто drush dl drupal7 и enable самые обычные модули для разработки, которые обычно применяются почти всегда. Без попыток что-то специально оптимизировать. Вроде как будет около 100 или даже больше. Поупражняюсь еще.
в друпале такой механизм есть — hook_module_implements_alter
Я думал он очерёдность вызова хуков регулирует.
Аналог WP REST API в друпале это модуль Serives и похожие.
Ок. Просто в WP это в ядре.
«Не так давно» это более 5 лет назад например =)
Да, согласен, быстро время идёт...=)
Хуков много в обеих системах (базовых в Drupal — около 350, в WP — около 250).
Про Drupal — не знаю, про WordPress — очень сильно занижено указанное количество.
800+ do_action() и 1650+ apply_filters() — и то, и другое является хуком, с разным предназначением.
Какой смысл обозревать старый Drupal 7, когда во всю уже 8 версия? А это «Две большие разницы».
Потому что очень много кто всё еще работает с Drupal 7 и не собирается переходить на Drupal 8.
На старых версиях Вордпресс тоже много сайтов осталось. Такое сравнение на мой взгляд не корректно. Если уж сравнивать, то последние актуальные версии обеих CMS.
Не согласен, потому что D-7 и D-8 — это совсем разные продукты, и развиваются, как две независимые линейки. Поэтому можно сравнивать «последний D-7» и «последний WP».
Поэтому можно сравнивать «последний D-7» и «последний WP».Последний D7 почти не отличается от первого. Drupal 7 разрабатывался в 2008 — 2011 годах. С тех пор в него в основном коммитили только багфиксы и небольшие улучшения в производительности. Для того, чтобы сохранить обратную совместимость всё новое добавлялось в следующую мажорную ветку (Drupal 8).
Ага есть даже 9-я версия. А толку. Это только для ознакомления, для работы — 7-я версия. Да и 6-я вполне приемлемый вариант. Сам работаю с Друпалом с 2007 года, волею судеб изначально удачно выбрал именно его. На Вордпрессе тоже приходилось. Но, увы, для того, чтобы на Вордпрессе сделать простой магазин приходится изощряться нереально. На Друпале подобная задача решается за пару-тройку вечеров. И так далее…
Статья, посвященная сравнению таких продуктов — дело тяжкое и не благодарное, это всегда повод спровоцировать срач между сторонниками той или иной системы управления
Статья, посвященная сравнению таких продуктов — дело тяжкое и не благодарное, это всегда повод спровоцировать срач между сторонниками той или иной системы управления
НЛО прилетело и опубликовало эту надпись здесь
Интересный у вас вариант сравнения. Вы по распространенности выбирали, или по тому, что на обоих с равными усилиями могли сделать одинаковые сложные веб-сайты/приложения?
По мне так вы заголовком предложили семерку BMW и Ладу сравнить.
По мне так вы заголовком предложили семерку BMW и Ладу сравнить.
BMW семёрка вероятно не последнего года выпуска, ей лет этак 15 =)
Да, технологии не равновелики, но это вполне реальный выбор при разработке сайта, не так ли? А недостатки у друпала есть, в первую очередь сложность. Чтобы сайт был сделан «Drupal way», нужно в основных API разобраться, а это не всегда на практике возможно тому, кто будет его саппортить и развивать.
Да, технологии не равновелики, но это вполне реальный выбор при разработке сайта, не так ли? А недостатки у друпала есть, в первую очередь сложность. Чтобы сайт был сделан «Drupal way», нужно в основных API разобраться, а это не всегда на практике возможно тому, кто будет его саппортить и развивать.
У BMW тоже есть такой «недостаток», она сложнее чем Запорожец ))) Исходя из вашей логики, проще всего пешком ходить.
нужно в основных API разобраться, а это не всегда на практике возможно тому, кто будет его саппортить и развивать.
Это не проблема Drupal а проблема разработчика, который не знает API той системы с которой взялся работать. Для администратора и контентщика достаточно инструментов в админке, кодить ничего ненужно.
Это не проблема Drupal а проблема разработчика, который не знает API той системы с которой взялся работать. Для администратора и контентщика достаточно инструментов в админке, кодить ничего ненужно.
Ну так сравнивать запорожец и танк, наверное, тоже можно, только задачи для них исходно разные. Если Drupal на мелких сайтах «не по калибру» использовать будет, то WP на крупных редко кто без напильника будет использовать. Ну, разве что из-за админки, если кому такое нравится.
Вылепить же веб-приложение в WP я бы не взялся. Сделать можно, но зачем?
Вылепить же веб-приложение в WP я бы не взялся. Сделать можно, но зачем?
А по моему отличная статья. Ещё бы в качестве третьего объекта сравнения была б Joomla, цены б статье не было.
Тогда уж и MODx ещё.
Та же мысль пришла в голову. Как минимум, напрашивается сиквел. =) Недавно стал экспериментировать с WordPress, так как дизайн многих сайтов на этой CMS странным образом притягивал взгляд. До этого вообще только Joomla и использовал, чтобы не распыляться. Когда увидел заголовок статьи, удивлен был, что в сравнении её нет… Тем не менее — общее положительное впечатление.
Отличный обзор!
По большему счету соглашусь практически со всем, что рассматривал ТС.
И соглашусь, что однозначно вп давно вырос из простого «движка для блогов» и догнал друпал, а возможно и перегнал. Все дело, по моему мнению в «привычке», но если в равной степени строить на друпале и на вп, то оба вполне устраивают и практически под любые задачи.
По большему счету соглашусь практически со всем, что рассматривал ТС.
И соглашусь, что однозначно вп давно вырос из простого «движка для блогов» и догнал друпал, а возможно и перегнал. Все дело, по моему мнению в «привычке», но если в равной степени строить на друпале и на вп, то оба вполне устраивают и практически под любые задачи.
Я вот никак не пойму чем так хорошо друпал7? какая-то фигня на функциональном программировании. В плане юзабилити вообще какая-то жуть.
Гибкостью своей архитектуры естественно — очень немного решений предоставляют механизмы для переопределения не только функциональности ядра но и других модулей — причем на всех уровнях от ajax ответов и клиентских скриптов (включая переопределение отдельных функций в рамках Drupal API) до темизации на всех уровнях — полей, страниц, форм, элементов с удобным механизмом зависимости темизации от контекста (который тоже можно переопределять). Ну и функциональщина в целом лучше других парадигм — ее проще отлаживать, хотя Drupal это не совсем функциональщина — слишком много магии
Спасибо за статью.
Возражу комментаторам, которые считают, что сравнение не актуально, или сравнивается несравнимое. Я Вас уверяю, некоторые из "не вас" действительно интересуются, как сделать выбор, и на основании чего. Таки да, профессионалы вырастают из тех, кто ищет ответы на то, чего — о, ужас — не знают! Рад за вас, что вы уже всё для себя решили, а я прочитал статью с удовольствием от начала до конца.
И не надо приводить в пример БМВ и Ладу. Для меня, например, БМВ не настолько лучше Лады, насколько он её дороже: его преимущества находятся за рамками моих актуальных потребностей. И именно это в статье есть: первичная обобщённая информация для того, чтобы преобразовать потребность (свою, не Вашу) в решение. Так что с Новым годом всех, и пусть каждый выберет себе по ЦМСке и по машине (а то и не по одной).
Интересно бы почитать сравнение вп с джумлой, друпал это все-таки нечто более толстого калибра.
Я бы ещё добавил про друпал что писать JavaScript там отдельное удовольствие всю функциональность приходится оборачивать специальными костыликами чтобы они второй раз не вызывались, и так далее всякие там new Drupal.ajax(… в итоге приходится искать Drupal frontend разработчиков, мне то в этом не сложно разобраться, но это даже не автобус из буханки а самолёт, потому что зачем.
Плюс опять же друпал старый и дряхлый как продукты жизнедеятельности тираннозавра, но не смотря на это пользоваться им неудобно объективно админка хуже разрабатывать на нем дольше на (практике проверялось не раз) модули менее готовы из коробки по сравнению с WordPress и их меньше, Drupal 8 призванный решить эти проблемы когда вышел то сохранил все наследие плохой админки и поломал совместимость с всем что сделало сообщество в направлении хоть какого то улучшения интерфейса, так же views который теперь включён в ядро лишился части своего админ интерфейса, что как то не укрепляет надежду на скорому улучшение ситуации.
Про модули, ну во первых тут либо много старых у Drupal 7 либо мало новых у Drupal 8, да еще ко всему все жесткие подходы к модерации модулей в репозитории Drupal не к чему не привели, достаточно посмотреть на Panels, Page Manager, Display Suite они все нормально не работают, поэтому среди разработчиков немногие делают новые проекты на восьмерке.
В итоге друпал дает ровно три вещи:
— много возни с админкой;
— структура html, не способствует быстрой верстке (не буду объяснять просто, всегда так было, легко убедиться);
— куча модулей который не подходят или не работают;
— нет надежды.
так что я не понимаю радости на счет друпала, наоборот в пору начать волноваться насчет него.
У этого BMW кузов повело.
Плюс опять же друпал старый и дряхлый как продукты жизнедеятельности тираннозавра, но не смотря на это пользоваться им неудобно объективно админка хуже разрабатывать на нем дольше на (практике проверялось не раз) модули менее готовы из коробки по сравнению с WordPress и их меньше, Drupal 8 призванный решить эти проблемы когда вышел то сохранил все наследие плохой админки и поломал совместимость с всем что сделало сообщество в направлении хоть какого то улучшения интерфейса, так же views который теперь включён в ядро лишился части своего админ интерфейса, что как то не укрепляет надежду на скорому улучшение ситуации.
Про модули, ну во первых тут либо много старых у Drupal 7 либо мало новых у Drupal 8, да еще ко всему все жесткие подходы к модерации модулей в репозитории Drupal не к чему не привели, достаточно посмотреть на Panels, Page Manager, Display Suite они все нормально не работают, поэтому среди разработчиков немногие делают новые проекты на восьмерке.
В итоге друпал дает ровно три вещи:
— много возни с админкой;
— структура html, не способствует быстрой верстке (не буду объяснять просто, всегда так было, легко убедиться);
— куча модулей который не подходят или не работают;
— нет надежды.
так что я не понимаю радости на счет друпала, наоборот в пору начать волноваться насчет него.
У этого BMW кузов повело.
НЛО прилетело и опубликовало эту надпись здесь
Восьмая версия пока в разработке, нападки на неё мне кажутся обвинением пятилетнего младенца в неспособности решать дифуры.
Чувак Drupal 8 уже где то года два как в стабильно релизнулся, я на вечеринке по этому поводу был, мне то не рассказывай про собственный путь друпала и про то что он так и задумывался
А да, забыл добавить. Если ваш вариант "не пробовал, но одобряю" то никаких проблем не у друпала не WordPress, и там и там все хорошо
НЛО прилетело и опубликовало эту надпись здесь
Да ладно вордпресс, как вы определяете когда, когда Drupal 8 можно будет считать готовым? Три года разрабатывался, дождались релиза, Drupal 9 начался, все ещё не готов продует, а шестеркой уже можно пользоваться не рано?
Вы приводите цифры которые не соответствуют действительности.
Не три а почти пять.
Чуть больше года.
Даты релизов:
Три года разрабатывался, дождались релиза
Не три а почти пять.
Чувак Drupal 8 уже где то года два как в стабильно релизнулся
Чуть больше года.
Даты релизов:
когда Drupal 8 можно будет считать готовым?Ответ всегда будет собъективным. Зависит от вас и ваших проектов. Правильнее спрашивать, когда вы будете готовы перейти на Drupal 8?
Некоторые начали делать сайты на нём еще до официального релиза, а другие собираются ждать ещё несколько лет, потому что не хотят тратить время на изучения чего то нового.
Я то все продукты привык считать готовыми с релиза, но тут в комментах другие мнения почему то. Мои вопросы были только к недоделаности и неудобности и архаичности
Наверно зависит от того, что называть продуктом. Если вам нужнен только сам Друпал, то его можно считать готовым с момента релиза. Если в «продукт» входят контриб модули, темы, документация, ответы на StackExchange и т.д., то придется подождать довольно долго.
Вот именно ждать придётся слишком долго, а нормальной админки и вовсе не дождутся и внуки, либо
- нам расскажут что это же друпал очень гибкий и мольный, поэтому админка и не нужна была изначально
А что не так с админкой?
- не самая понятная;
- если я отправил форму сабмит вполне может меня на пред предыдущий страницу, и назад уже никак не вернуться не пройдя всю цепочку по меню ;
- в мобильном или планшете, видно максимум левый верхний угол, если повезет, обычно же просто сразу приходится компьютер искать ибо с мобильного в админку заходить ничего хорошего не сулит;
- Если допустим мне нужно восстановить состояние ноды после ее неудачного редактирования, то неплохо бы мне перед тем как я редактировать неудачно собрался чекбокс активировать и ей еще название написать, в нормальных ситуациях это должно работать примерно как в гугл докс, то что сейчас в друпале есть разве что для отмазки на если в тз туманные формулировки годится, в некоторых других смс известных для работы с редакциями даже инструмент есть которые диф показывают, и он наверное во всех 100% случаев нужен;
- Если допустим я хочу ноду по редактировать и мой друг вася тоже захочет, то друпал даже не дернеца предотвратить такую оказию, не важно даже как бы хорошо это получилось, нет даже попыток в этом направлении
- вот допустим создаю я в друпале меню, добавление каждого пункта меню требует какого как минимум два раза страницу рефрешить, плюс все эти указания веса, выбор родительского пункта и прочее что там есть не самый удобный экспириенс каждый раз приходится контент менеджеру целый талмуд писать со скриншотами и вопросы все равно остаются, а документация и how to всякие как уже выше говорилось на stack exchange туда особенно клиента не оправишь посмотреть
- С блоками это просто содомия, сначала ты выбираешь в какой регион по всплывает монстроподобный popup ты там свой блок находишь, возможно даже через поиск, потом второй попап всплывает, там еще куча настроек, потом зачем то у каждого блока по умолчанию заголовок, как правило его нужно выключить, потом сохраняешь, потом страничка рефрешится (хотя казалось бы зачем если попап аяксовый был), потом выясняется что ты в неправильную позицию блок поставил потому что, идешь перетягиваешь потом листаешь портянку блоков вниз, сохраняешь, если кто-то хочет сказать что это удобно, то это он преувеличивает. А вот если у тебя друпал 8 и скажем firefox то может и popup не всплыть, потому что баг не всегда работает, ну вовсяком случае больше одного человека с этим сталкивались, ну это ладно допустим так надо с мобильных же не подредактируешь и с фаерфокса не надо заходить.
- Так же простой активацией двух взаимоисключающих Фитч можно сайт полностью запороть и потом долго искать причину, конечно друпалисты так не делаю, но люди попроще часто с таким встречаются, с плагинами тоже самое пару галочек не там и приплыли, долго возвращаешь как было, хну это допустим из за большой гибкости, можно не считать за большой косяк
- Или вот, сидишь такой в cck поле какое то хитрое долго настраиваешь уже на предпоследнем шаге, там миллион инпутов, и оп такой ширину 99 пикселей написал например, а максимальная 100 и сохранить нахал, все данный пропали, 99 красным посветило потому что налет у валидация в этом конкретном месте нет.
Экран редактирования ноды та же песня, вот хочешь дату поста отредактировать сразу идешь в пункт меню — Информация об авторе он еще в аккордеон свернут, что бы по полю вода даты никто не догадался сразу что она именно там вводится
Вообще во всех других CMS кроме наверное разве что дхумлы из коробки удобней сделано.
А вот если мне ко всему еще предлагается ко всему еще и удобную админку самому сделать, то я уж лучше возьму какой нибудь Фреймворк потому что не вижу тогда смысла в такой CMS где админка не фонтан, а на фронтенде все нудно особым образом делать, никаких готовых модулей особенно нету, а шаблоны красивые или премиальные которые можно купить не принято в принципе делать.
Для drupal 7 конечно все было, но все это модули, сказанное и для него актуально.
Ещё в других альтернативных CMS обычно интерфейс от версии к версии все же в лучшую сторону меняется, а вот друпалл стабилен, остается прмерно на уровне 2008 года.
Так что с админкой у Drupal 7 все в порядке, я просто не совсем уверен с выбором цвета получается.
Половину этих проблем я никогда не встречал почему то, а вторая половина это вкусовщина. Имхо. Мне админка нравиться, особенно в Drupal 8. Конечно, может просто привык к ней.
Единственная проблема это интерфейс для управления медиа файлами. В ядре его вообще нету, а тот который в модуле Media тормозной и не удобный.
Единственная проблема это интерфейс для управления медиа файлами. В ядре его вообще нету, а тот который в модуле Media тормозной и не удобный.
Я конечно все понимаю, но это как то больше смахивает на религию нежеле на какой то осмысленный выбор, хороший код да, круто я рад, недоделанный но зато написано красиво и управлять невозможно, если вы хотите сказать что там уязвимостей не было так, тоже нет были и это нестрашно потому что их фиксят, но хотелось бы чтоб релизы по мимо исправлений безопасности ещё что то содержали, а то в 2017 имеем модули которые либо не работают либо отсутсвует и админку в которой черт ногу сломит, и релизына которые никто не переходит потому что они не готовы, а больше и фитч от Cms и не требуется. Можно конечно долго друпал нахваливать но удовольствия с ним работать все меньше
НЛО прилетело и опубликовало эту надпись здесь
Шестёрка давно полностью готова к использованию, я понял, готовность к использованию примерно совпадает со сроком окончания поддержки пруф, благо хоть определились когда хорошо станет.
Я бы ещё добавил про друпал что писать JavaScript там отдельное удовольствие всю функциональность приходится оборачивать специальными костыликами чтобы они второй раз не вызывались
Оборачивать надо как раз чтобы второй раз вызывалось, например когда придёт новый кусок dom.
всякие там new Drupal.ajax(…
Если вы пишите в своём js коде «new Drupal.ajax», то вы уже что-то делаете не так.
А вы вордпресс смотрели? Особенно плагины, которые с каждым обновлением ломает сайт. А код? Спагетти из php-html-js в одном файле это нормально? Я работаю и с Drupal7, Drupal8 и wordpress.
А от Drupal.ajax их attachBehaviories я наоборот кайфую.)
А от Drupal.ajax их attachBehaviories я наоборот кайфую.)
в WordPress я волен писать скрипты удобным мне способом, если конкретно я будучи в добром здравии напишу плагин он будет скорее работать даже на старый дряхлых версиях 2.x и в будущем не сломает ничего, и мне для этого не нужно будет писать WordPress специфичный код если кто то даже этого не умеет сделать, это не значит что такому человеку будет attachBehaviories в радость, такие ребята обычно в друпале верстают внутри wysiwyg блоков, css там вставляют подключают скрипты с абсолютными путями.
От криворукости attachBehaviories не лечит и ядро WordPress еще реже деприкейтит что либо чем Drupal который между версиями несовместим.
Я таких универсальных разработчиков много раз по рукам бил и знаю как это происходит, те ребята что спагети пишут для WordPress Drupal просто уничтожают.
Так что не аргумент.
От криворукости attachBehaviories не лечит и ядро WordPress еще реже деприкейтит что либо чем Drupal который между версиями несовместим.
Я таких универсальных разработчиков много раз по рукам бил и знаю как это происходит, те ребята что спагети пишут для WordPress Drupal просто уничтожают.
Так что не аргумент.
Забыл главное сказать.
WordPress почти нет официального способа смешать код и стили или скрипты
wp_enqueue_style — через это подключают css
wp_enqueue_script — через это подключают js
wp_localize_script — пробрасывают переменную из php в javascript
Лапшу можно сделать через это
wp_add_inline_script
или
wp_add_inline_style
через эти функции можно вставить что либо инлайном, потому что иногда это бывает нужно ка ни крути а вот теперь покажите мне плагин который состоит из лапши потому что кто то использовал скажем wp_add_inline_style чтоб бы скриптов целую кучу стилей вписать в php.
На деле это так происходит:
так чего тогда от людей такого пишущих такое ожидать в Drupal он тоже самое в html.tpl.php вставляют еще бывает в блоки добавляют через админку дабы в таком случае даже поиск по файлам не даст результатов что еще хуже, в итоге так же плохо получается или еще хуже если 'повезет'.
Это все никак не зависит от используемого фремворка.
Другое дело что WordPress минимум в 6 раз более распространен чем Drupal и по статистике чтобы такое с последним сделать, его еще нужно где то найти, редкость использования это опять же одно из сомнительный достижений Drupal.
WordPress почти нет официального способа смешать код и стили или скрипты
wp_enqueue_style — через это подключают css
wp_enqueue_script — через это подключают js
wp_localize_script — пробрасывают переменную из php в javascript
Лапшу можно сделать через это
wp_add_inline_script
или
wp_add_inline_style
через эти функции можно вставить что либо инлайном, потому что иногда это бывает нужно ка ни крути а вот теперь покажите мне плагин который состоит из лапши потому что кто то использовал скажем wp_add_inline_style чтоб бы скриптов целую кучу стилей вписать в php.
На деле это так происходит:
print '<style type="text/css">
@font-face{font-family: '.$name.';
</style>';
так чего тогда от людей такого пишущих такое ожидать в Drupal он тоже самое в html.tpl.php вставляют еще бывает в блоки добавляют через админку дабы в таком случае даже поиск по файлам не даст результатов что еще хуже, в итоге так же плохо получается или еще хуже если 'повезет'.
Это все никак не зависит от используемого фремворка.
Другое дело что WordPress минимум в 6 раз более распространен чем Drupal и по статистике чтобы такое с последним сделать, его еще нужно где то найти, редкость использования это опять же одно из сомнительный достижений Drupal.
WordPress почти нет официального способа смешать код и стили или скрипты
Ядро — https://github.com/WordPress/WordPress/blob/master/wp-login.php
Присутствует всё в одном месте — html, php, css, script. Особенно приятно смотрится конец файла.
ну и? как это меня касается как разработчика? Обычный же Legacy может когда нибудь поправят, факт в том что при всем этом форма входа у WordPress нормальная и красиво смотрится на мобильном а в Drupal убогая и страшная не смотря на все это, как с этим всем разработчикам ядра трудно жить мне как консьюмеру не очень интересно, у них еще и подежка php 5.2 в ядре и им это чем то нормальным кажется.
Я когда соберусь модуль или тему писать, это редактировать не буду.
Как это разработчиков коснется.
Тем более это не значит что при обновлении, что то сломается потому что именно эта часть вообще не обновляется (кеп) вопрос был именно в этом, то что не красиво никто не спорит.
Будет неудобно когда начну хакать ядро что ли?
Я когда соберусь модуль или тему писать, это редактировать не буду.
Как это разработчиков коснется.
Тем более это не значит что при обновлении, что то сломается потому что именно эта часть вообще не обновляется (кеп) вопрос был именно в этом, то что не красиво никто не спорит.
Будет неудобно когда начну хакать ядро что ли?
НЛО прилетело и опубликовало эту надпись здесь
Таким в WP не пахнет до сих пор, насколько мне известно.Насколько мне известно для WP есть куча CCK плагинов. Так что как минимум пахнет.
ничего не сказано о Field API в Drupal
Сказано — см. раздел «Типы контента и поля». Там же про то, как это «пахнет» в WP.
Ничего не сказано и о качестве кода
Качество кода — вещь субъективная. А «чёткие Coding Standards» есть у большинства систем, что у WP, что у Joomla.
Ещё стОило бы указать, что обзор относится к 7-й версии Drupal.
Это сказано в первом же абзаце.
Не скажу за WordPress, с Drupal уже лет 6 работаю. Главное го преимущество — возможность кастомизации. Практически каждый модуль написан так, чтобы его можно было легко поменять под себя. Например, не нравится какие действия происходят при сабмите формы — можно поменять или добавить свои действия. И так почти во всем. Обратная сторона этого — многие сайты содержат сотню модулей, функционал которых не используется на половину.
Сила WP в гигантском количестве плагинов и тем — то есть по сути готовых решений.
Еще можно добавить, что есть куча готовых рецептов, которые до сих пор актуальны из-за хорошей совместимости.
Плюс дружелюбие редактора надо не забыть.
На этом я бы сказал все плюсы WP заканчиваются, так, как:
- Расширения в большинстве своем ужасны. То есть если взять популярные CMS и посчитать толковые расширения для них, их число будет примерное одинаковое для каждой из них.
- WP реальный тормоз, да его можно закостылить, но в целом, он тормоз из коробки, мне даже сложно это объяснить, так как по сути из коробки там же ничего нет.
- Чтоб довести его до вменяемого состояния, надо поставить десяток плагинов. Собственно наблюдая за разговорами WP по сути получается, что надо постоянно держать в голове пачку плагинов необходимых.
- Ужасный код… наверное самый ужасный из популярных CMS. Я понимаю, что совместимость, все дела… но правда смотришь и слезы наворачиваются, особенно на плагины.
Лично мое мнение WordPress можно называть универсальной CMS, но если реально взглянуть на него, то он все тот же блоговый движок, из которого решили сделать комбайн.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Drupal и WordPress — сравнение, аналогии, сходства, различия