Joomla Vs. Drupal: техническое сравнение лучших CMS с открытым исходным кодом

  • 04.08.2014

drupalvsjoomlaПеревод статьи разработчика сайтов Arash Arabi с сайта http://www.butterfly.com.au/

Пару недель назад, я должен был написать техническое сравнение Joomla и Drupal. Естественно я начал искать онлайн. Удивительно, но я не мог найти достойной технической оценки этих двух систем. Большая часть доступных материалов отражает поверхностные сравнения, написанные веб-мастерами и не-разработчиками. Были несколько статей, в которых сравнивали производительность, но ничего достаточно углубленного, чтобы оценить технические данные и внутреннюю работу PHP фреймворка CMS в деталях. Как разработчик, который работал как с Joomla, так и с Drupal, я решил, что пришло время написать хорошее техническое сравнение между Joomla и Drupal, и положить конец войне между ними.

 

mythbusted

Прежде чем мы начнем, мы должны прояснить специфическую CMS-терминологию:

Что в Drupal называется модулями очень похоже на компоненты в Joomla.

Что в Joomla называется модулями очень похоже на блоки в Drupal.

Удобство в использовании против сложности.

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

из коробки

С точки зрения перспективы вебмастера, поддерживать сайт в актуальном состоянии - это довольно точное предположение. Тем не менее, для разработки сайта, это не обязательно так - давайте выясним, почему.

Требования кнастройке

Немного о верхней диаграмме. Joomla проще в установке и настройке, чем Drupal. Кроме того, легче развивать пользовательские функции для Joomla по сравнению с Drupal и Wordpress.

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

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

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

Технические сравнение Joomla и Drupal

Как только программист открывает исходный код Drupal он сталкиваются с кошмаром. Программировать на Drupal не легко, так как он основан на плохо продуманном, процедурном фреймворке, в то время как Joomla основана на хорошо разработанном, объектно-ориентированном MVC фреймворке, который так-же реализует ряд шаблонов проектирования, таких как listener, и т.п.

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

1 База данных

  1. В Drupal, виды хранятся в базе данных. Это означает, что вы не можете поставить их под контроль версий (например SVN или GIT) и разработчики не могут сотрудничать при развитии видов.

  2. Каждый новый тип содержимого в Drupal создает пару таблиц базы данных. Это означает, что структура базы данных изменяется с течением времени, если вебмастер создает и изменяет типы контента. Это кошмар для разработчиков, которые хотели бы создать Entity Relationship Diagrams (ERD), при создании веб-приложения. Вы никогда не можете полагаться на ERD потому, что в следующий раз, когда вы посмотрите в базу, количество таблиц и схема базы будет отличаться.

  3. В Drupal, логи хранятся в базе данных. Все современные системы хранят логи в файлах. Хранение логов в базе данных означает, что к ним очень трудно получить доступ, анализировать и профилировать. Разработчик не может использовать инструменты Linux (такие как sed и т.д.) для обработки и анализа журналов. Процесс идет медленнее и занимает огромное количество дискового пространства (много гигабайт) для хранения баз данных. Это делает базу данных системы необоснованно большой и неэффективной. Для большого сайта с высоким трафиком это делает практически невозможым запросы и анализ логов. Кроме того, он не может поддерживать ротацию и архивирование старых логов. Кто в здравом уме будет хранить логи в базе данных?

2. Паттерны проектирования

Joomla является объектно-ориентированной, а Drupal основан на старом PHP 4 процедурном программировании (темные дни PHP).

php4

Drupal реализует устаревшие паттерны проектирования:

  1. Procedural

  2. Hooking

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

 

Однако Joomla реализует современные паттерны проектирования,  которые используются в лучших фреймворках, таких как Symfony 2, Zend и корпоративных языках программирования, таких как Java (включая Struts и Spring):

  1. Объектная ориентированность (включая полиморфизм, инкапсуляцию, наследование и т.д.)

  2. MVC (Model View Controller)

  3. Event Driven, Event Dispatcher, и Observer

  4. Singleton

  5. Factory

Некоторые из паттернов проектирования, реализованных в обоих CMS, таких как DBAL (Database Abstraction Layer) были сделаны лучше в Joomla. DBAL в Joomla почти так же хорош, как ORM (Object-relational mapping). И если вы действительно хотите использовать ORM Joomla, он легко интегрируется с Doctrine.

Реализация этих современных практик связано с непрерывным улучшением фреймворка Joomla и CMS, которые проведены за эти годы, в то время как Drupal стагнирует.

3 Архитектура ядра

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

древовидная иерархияВ Joomla у нас есть древовидная иерархия. Ствол является ядром Joomla. Он имеет ветки (API), к которым вы можете прикрепить несколько отростков (компоненты) или листьев (модулей или виджетов). Компонент может быть подключен, таким образом, чтобы интегрироваться с контролем доступа Joomla! (Access Control Levels) и функциями управления контентом. Будучи отростком, он может иметь подкатегории ветви и даже может иметь соединение с другим компонентом. Но в значительной степени, существует минимальный контакт между различными компонентами.

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

Для реализации Hooking в архитектуре Drupal используется call_user_func () и другие методы динамического вызова функций. Это означает то, что отладка Drupal с использованием современных инструментов отладки - это кошмар. Если вы хотите узнать больше о инструментах отладки вы можете прочитать: Как настроить VIM и PhpStorm с xDebug для отладки.

Кроме того, это означает, что вы не можете использовать клик по методу или свойству для перехода к его объявлению в вашей современной IDE, когда вы программируете. Также, если вы используете PhpStorm или другую современную IDE, инспекция и автоматическое завершение не будут работать, так как они не будут знать тип возвращаемого значения динамически вызываемых функций.

4. Стандарты кодирования

PSR -  PHP Specification Request является стандартом кодирования, принятым в большинстве современных корпоративных фреймворках, таких как Symfony 2 и Zend.

Joomla является PSR-0 совместимой и скоро станет PSR-1 совместимой. Drupal не соответствует любому стандарту PSR.

5 Производительность и кэширование

Drupal в среднем составляет 100 запросов к базе данных на странице (для простых страниц). Из-за этого и других проблем с производительностью, связанных с Hooking архитектурой, все должно быть сильно абстрагированно и кэшироваться, что создает дополнительную сложность и требования к аппаратной составляющей ресурсов. Joomla является гораздо более легкой и оптимизированной. Она имеет намного более быстрее ядро. В Joomla рекомендованный лимит памяти составляет 512 МБ, а в Drupal - 2 ГБ.

Большинство тестов согласны, что без кэширования Joomla является более быстрой и менее ресурсоемкой, чем Drupal. Однако некоторые тесты считают Drupal быстрее, когда кэширование включено. Но если кэширование Joomla устанавливается экспертами и настроено она может превзойти Drupal даже когда кэширование включено. Также кэширование в Joomla намного проще и менее ресурсоемко, чем в Drupal, что делает Joomla проще в использовании, обновление, и настройке.

В то время как у вас есть Solr в Drupal, чтобы увеличить производительность для веб-сайтов с большими базами данных и большим количеством пользователей, в Joomla у вас есть Sphinx, который написан на родном C ++ и работает быстрее и проще, чем Solr. Нам просто не нужно устанавливать Sphinx на большинстве веб-сайтов, потому что Joomla быстра и достаточно мощна из коробки и имеет возможность работать с очень большими базами данных под интенсивным трафиком. Однако при необходимости Sphinx может обеспечить огромный прирост производительности на Joomla, делая ее во много раз быстрее, чем Drupal с Solr.

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

То, что эксперты делают

Одним из многих успешных известных сайтов Joomla является linux.com. Люди, которые работают в linux.com известны своей одержимостью качеством кода и являются лучшими и умнейшими программистами. Независимо от того, сколько правительственных сайтов, сделанных на Drupal вы можете найти, то, что linux.com находится на Joomla перевешивает их всех.

В защиту Drupal, в Linux Foundation, организации linux.com, также работает несколько небольших сайтов на Drupal (например video.linux.com). Но то, что они используют Joomla, а не Drupal для их основной функциональности на тяжелом сайте (linux.com), для меня большой плюс в пользу Joomla.

Также стоит отметить, что  контрибьюторы Linux Foundation дали Joomla рейтинг пять звезд, в то время как они-же дали Drupal только три звезды.

Если вы заинтересованы, вы можете прочитать интервью с Дэном Лопес, веб-архитектором linux.com о том, почему он выбрал Joomla.

Экономическое обоснование

Хотя Drupal обеспечивает наибольшую гибкость к вебмастеру, его администрирование очень сложное и имеет очень высокий порог вхождения. Клиенты должны будут нанять эксперта-вебмастера Drupal, а обычные пользователи не могут просто натренироваться, чтобы использовать Drupal, так-же как они могут быть обучены использовать Joomla. По сравнению с Joomla, административная консоль в Drupal является приборной панелью реактивного истребителя.

С точки зрения сообществ, поддерживающих CMS, Joomla имеет гораздо большее сообщество разработчиков по сравнению с Drupal. Это признак того, что разработчики предпочитают работать на Joomla.

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

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

Drupal может улучшиться в будущем

Говорят, что новый Drupal 8, который будет выпущен в ближайшее время (пока нет официальной даты релиза) массивно усовершенствован и много проблем и ошибок исправлено. Ядро Drupal была полностью переработано и перестроено и, как предполагается, много позаимствовано из фреймворка Symfony 2.

Тем не менее, до тех пор, пока Drupal 8 не будет выпущен, даже не стоит рассматривать использование Drupal в реальных проектах.

После того, как Drupal 8 будет выпушен я готов вновь посетить мир Drupal и сделать проект на нем, но я почти уверен, что к этому времени Joomla улучшится еще больше. Мы, возможно, даже получим полную поддержку TDD на Joomla (TDD или Test Driven Development является лучшей методологией разработки в мире).

Заключение

В заключение, если вы все еще сомневаетесь по этому поводу, поверьте разработчику, который имеет опыт работы как с Joomla, так и с Drupal. Joomla лучше чем Drupal. И это верно независимо от размера и требований к сайту.

Если у вас нет не-технических причин (например, мои пользователи уже знают, как использовать Drupal) я всегда рекомендую создавать сайт на Joomla.

Если вы где-то читали в Интернете, что Drupal лучше, чем Joomla для сложных крупномасштабных проектов, просто проверьте их показания. В тестах были рассмотрены технические детали и работы фреймворков и пришли к выводу, основанному на технических деталях? Или просто заявлено, что они считают, без всяких доказательств или ссылок в исходный код CMS?

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

Это интересно:

Комментарии  

Дмитрий Рекун
+4 # Дмитрий Рекун 05.08.2014 13:24
Спасибо за перевод. Интересное чтиво. Не думал, что Друпал настолько "тяжелый".
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Аркадий Седельников
+2 # Аркадий Седельников 05.08.2014 18:38
Я много читал всякого про код друпала, везде пишут что программирование для него - сущий ад из-за сильной зависимости модулей друг от друга. Эта статья прибавила уверенности в правильности моеговыбора CMS. Хотя когда я делал выбор программировать я не умел совсем. Я собрал магазин на друпале (ubercart) но когда кончились мануалы осталось много недоделанного и никакого понимания что дальше делать. Затем я собрал магазин на Джумле (виртуемарт 1.0.13), там оказалось все гораздо проще, по этому и остался.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Вадим Куницын
-1 # Вадим Куницын 05.08.2014 19:46
Ну вообще если обратить внимание на их форумы, они сразу с ходу рекомендуют VDS для сайта. Плюс по сути без системы кеширования сайт вообще ходит пешком. В то время, как у меня многие сайты на Joomla вообще без кеша.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Sulpher
-4 # Sulpher 06.08.2014 14:28
Аркадий, спасибо за перевод, полезная статья!
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Аркадий Седельников
-4 # Аркадий Седельников 06.08.2014 18:51
На Здоровье! :-)
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Руслан
-3 # Руслан 07.08.2014 13:19
Спасибо!
Очень полезная статья.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
zniki.ru
+4 # zniki.ru 07.08.2014 21:50
Чтобы не начинать Холивар:
1) В Друпал есть свои стандарты кодирования (www.drupal.org/.../)
2) Для сравнения производительности нужны числа, графики. Слов недостаточно.
3) Друпал подходит, при работе в индустриальной манере, когда в месяц создается более 500 сайтов.
4) Запись логов в БД сделан для удобства, его очень просто отключить и влючить запись логов в файлы.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Вадим Куницын
-4 # Вадим Куницын 08.08.2014 12:31
Цитирую zniki.ru:
Чтобы не начинать Холивар:
1) В Друпал есть свои стандарты кодирования (www.drupal.org/.../)
2) Для сравнения производительности нужны числа, графики. Слов недостаточно.
3) Друпал подходит, при работе в индустриальной манере, когда в месяц создается более 500 сайтов.
4) Запись логов в БД сделан для удобства, его очень просто отключить и влючить запись логов в файлы.

1. А что такого уникального в этих стандартах? Там собственно все как обычно. Стандарт на оформление кода, не может исправить отсутствие ООП. Хотя многие считают, что ООП это ненужная фича :-)
2. Ну по поводу производительности графиков тут действительно нет, но это перевод и лучше задавать вопрос не переводчику, а непосредственно автору. Хотя судя по форуму того же Drupal.ru можно сходу брать VDS.
3. Ээээ... а знаете как для этого подходит любая другая CMS? На том же WP можно клепать по 10-20 сайтов в одного в день. При этом учиться даже этому не надо, я уж не говорю про cms которые занимаются массовой генерацией сателлитов. Где у Drupal тут промышленное производство сайтов?
4. А вообще нафига забивать базу данных такой информацией как логи? Пользы от этого ноль. Вред особенно на высоко-нагруженных проектах очевидный.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
gladiatorhl2
+12 # gladiatorhl2 09.02.2015 06:02
Здравствуйте,
Много уже неактуально, Drupal написан на PHP5, есть библиотеки jqeury, элементы ajax. Логи хранятся в базе по умолчанию, но это только для начинающих сайтов, данную функцию можно отключить и сохранять в syslog. Откуда Вы взяли эти графики?!
Вы замучаетесь на Joomla строить очень сложный сайт, причём пока что разберётесь, как запрограммировать то, что нет в компонентах, век пройдёт.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Lol
0 # Lol 24.10.2015 23:53
Много уже неактуально - угу, особенно компоненты в Друпале которые НЕ ОБНОВЛЯЮТСЯ.
очень сложный сайт - Поподробнее охарактеризуйте пожалуйста. Если идет речь про что-то вроде ввконтакте, то с этим и друпал едва ли справится. Такие сложные проекты одним пхп как правило не ограничиваются. Если речь идет о пресловутой cck , то у джумлы есть компонент аналог Seblod.
Drupal написан на PHP5 - как понимаю слова о ООП вы сознательно опустили...
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Andrey
+4 # Andrey 10.02.2015 22:50
Автор как-то не убедил в своей опытности, по крайней мере, в Друпал. Первым недостатком заявлено, что виды хранятся в БД и не могут быть помещены в контроль версий. Даже начинающий друпалер знает, что виды можно сохранять в виде файла, при этом ни слова, о том, какие возможности дает этот модуль, не знаю есть ли что-нибудь подобное в Джумле (не специалист)
Да согласен, Друпал очень много чего хранит в БД, но это сделано с целью повышения гибкости, чем больше раздроблены сущности (поля, теги и проч), тем более мелкую мозаику мы можем собрать с помощью видов.

Паттерны проектирования это вообще ни к селу ни к городу. Это имеет отношение к фреймворкам, а не к CMS. Абсолютно не имеет значения какие паттерны реализованы в CMS, потому что вам ничего программировать не надо, есть ядро и набор модулей. Если ваш сайт нельзя на этом сделать, добро пожаловать на фреймворк.

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

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

Экономическое обоснование ни о чем, бравые программисты Джумла на своих крутых паттернах и ООП, пишут самые нужные и сложные плагины для Джумла и предлагают их за деньги, но если вдруг захочется добавить изюминку в этот плагин, то лезь в красиво написанный код и правь его сам. В Друпал ВСЕ модули абсолютно бесплатны.

По поводу производительности ничего сказать не могу, но оф сайт Drupal.org имеет более 1,150,000 зарегистрированных пользователей из 229 стран мира, на сайте представлено более 10 000 модулей с документацией и другого контента и он не виснет.

Я не холиварю, я просто указываю на однобокость статьи и голословных утверждениях. Предполагаю, что автор не справился с Друпал и нашел более легкий путь и это его выбор
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Вадим Куницын
+2 # Вадим Куницын 13.02.2015 20:48
Я лишь сталкивался с Drupal, не могу сказать что я много на нем чего делал.
Но могу сказать одно... это общее впечатление, ну как будто чувство прекрасного что ли, только в сайто-строении. Так вот это чувство прекрасного у меня не возникало с Drupal. Я могу сказать, что чувство прекрасного возникало в WP (хотя как разработчик я с ужасом смотрю на WP), но как пользователь я могу сказать, что я испытывал чувство упоения работая с ним. И таких примеров у меня много с другими CMS, но с Drupal у меня такого не было. Можете сказать, что это бред, но для меня это важный параметр.

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

Хочется много сказать конечно, по поводу программирования и разработки... Но одно хочется отметить забавную игру которую практикуют в Drupal. Когда им хочется выпятить функциональность они говорят, что Drupal это CMF (типа фреймворк), а как до дела доходит и спрашивают, а почему как фреймворк то он слаб, оказывается, что это все таки CMS. И может быть по этому основой кодовой базы пожертвовали в версии 8, и перешли на zend? А Joomla хоть и CMS идет наоборот собственной качественной кодовой базе и создает собственный фреймворк. Так что видится мне, прав был автор говоря про качество кода.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
gladiatorhl2
+1 # gladiatorhl2 14.02.2015 00:09
Цитирую Вадим Куницын:
А Joomla хоть и CMS идет наоборот собственной качественной кодовой базе и создает собственный фреймворк. Так что видится мне, прав был автор говоря про качество кода.

Откуда Вы это взяли, вообще непонятно.

Фреймворком Drupal является это точно, потому что практически всё, что угодно можно запрограммировать и прикрутить к нему. Со слабыми программистам что-то Вы общаетесь, пообщайтесь с теми, кто действительно специализируется на Drupal.

Чувства прекрасного у Вас не возникло, потому что Drupal очень многофункциональная платформа и надо разбираться и сидеть, что да и как работает. У многих годы уходят, чтобы стать разработчиком сайтов с помощью данной платформы. С WordPress вообще можно за пару недель всё понять. С Joomla подольше, всё же посложнее CMS, наверное, по сложности после Drupal будет идти.

Хотите сделать более-менее простой сайт без особого программирования, то выбирайте Joomla, если что-то посложнее да пофункциональнее, точно времени сэкономите при разработке на Drupal при условии освоения данной платформы.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Вадим Куницын
+2 # Вадим Куницын 14.02.2015 14:29
Потому, что я разрабатываю под Joomla от туда и взял :)
Joomla последние годы идет именно от CMS к полноценному Фреймворку, который кстати лежит в основе CMS. Чтоб не быть голословным почитайте framework.joomla.org/ .
Я то что сложная и функциональная, это очень плохо. Допустим чтоб начать что-то делать Yii мне потребовалось несколько часов, это хороший Фреймворк, так как понятен четко структурирован. И так с любым другим Фреймворком и хорошей CMS максимум за неделю, ты должен понять принципы и уже освоить полноценную работу на нем. Если на освоение инструмента требуются годы... это уже повод отказаться от использования такого инструмента. Это я при условии, что ты уже владеешь аналогичными инструментами.
Простой пример... Я умею копать лопатой, и тут мне дали культиватор, и вдруг оказывается, что научиться им пользоваться надо год, и скорость вскапывания будет, как лопатой. Угадайте, что я выберу.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Andrey
0 # Andrey 15.02.2015 02:11
Почитал по вашей ссылке. Вывод, такой, что устав бесконечно грызть ядро, наконец поняли, что пора бросать этот чемодан без ручки и писать фреймворк, а на его базе некую реализацию cms. Ну пошли по пути, по которому Drupal идет уже лет 10. Я так понял у них это пока еще только в планах
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
gladiatorhl2
0 # gladiatorhl2 15.02.2015 05:15
Ниже человек написал толковую вещь, что Joomla придёт к такому же культиватору, к которому уже давно пришёл Drupal. Ну и программируйте на Yii, только вот Вы будете программировать один хороший и сложный сайт в раза 2 дольше, чем сделать его на Drupal. Поэтому и нужно ему научиться, чтобы потом скорость построения сайтов была. Культиватором поначалу будет сложно, а потом зато и лопаты не понадобится.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Andrey
+3 # Andrey 15.02.2015 01:44
Абсолютно неважно, на каких принципах программирования написана cms, если этот вопрос встал ребром, значит вы уже на пользуетесь cms, а кардинально ее перелопачиваете. И странно, что вам не приходит в голову, что фреймворк (cmf) как раз дает вам возможность кодить свою структуру и функционал в любую сторону под конкретную задачу на любимом ООП, а не грызть бесконечно это ядро. Если вы просто прикручиваете расширения, то какая вам разница как написано это ядро. Кстати, более или менее функциональные расширения, видимо требуют столько усилий при написании, что они становятся платными

При установке Drupal там предлагается на выбор два варианта стандартный и минимальный Вот минимальный это фреймворк, а стандартный это уже с набором модулей для типового блога, форума можно подшивку типа книги сделать с другим полезным функционалом, например пользовательские типы контента, мощная система управления правами доступа для пользователей.
Насколько умно построена архитектура ядра, я описал ниже в другом комменте. Ничего выпячивать не нужно, эта функциональность просто на поверхности. Ядро Drupal как бы говорит, эй парни, я не знаю что вам придет в голову, но я предоставлю вам нужные библиотеки, логику обработки запроса и расставлю в контрольных точках крючки, цепляйтесь в нужных местах и воплошайте любые свои причуды. А ядро Joomla говорит, вот типовой функционал, а если не нравится, копайтесь в моем красивом ООП с MVC паттерном и делайте такие же малопригодные к дальнейшему расширению функционала приложения.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Антон
-1 # Антон 04.01.2016 21:19
"Но все таки надо признать, что в конечном итоге подход Joomla к кодовой базе ядра победил и в Drupal. То есть Drupal 8 делается по стандартам ООП."
Передергивание. С какого момента времени Джумла запатентовала ООП. Развитие друпала идет своим эволюционным ходом. Это утверждение сровни - "У меня сосед Вася написал на ООП рассылку. Его рассылка победила Друпал. Теперь, его ядро тоже на ООП"
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Вадим Куницын
+1 # Вадим Куницын 04.01.2016 21:53
Я помню Drupal 6... когда друпалеры говорили что ООП хрень, хуки это хорошо. Заметьте Joomla 1.5 уже была полностью ООП. Когда вышел Drupal 7 история повторилась... Теперь вышел Drupal 8 и я вижу, что ООП в нем позиционируется как преимущество системы.

По этому я и говорю, что подход Joomla все таки победил, просто на понимание, что надо двигаться по этому пути потребовалось лет 8.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Аркадий Седельников
0 # Аркадий Седельников 13.02.2015 21:17
Цитирую Andrey:
Автор как-то не убедил в своей опытности, по крайней мере, в Друпал. Первым недостатком заявлено, что виды хранятся в БД и не могут быть помещены в контроль версий. Даже начинающий друпалер знает, что виды можно сохранять в виде файла
То, что мух можно хранить рядом с котлетами - уже большая беда.Цитирую Andrey:


По поводу ядра на уродливом коде спагетти, а какого черта вообще надо лезть в ядро?
хотя-бы для того, чтобы понять как оно работает, и что нужно ему дать, чтобы твое расширение заработало.Цитирую Andrey:

Предполагаю, что автор не справился с Друпал и нашел более легкий путь и это его выбор
ну это вы зря. Я думаю что тут сыграла специфика - если вы привыкли создавать сайты мышкой - вам понравится друпал, но если вы понимаете в php, то на джумле все будет гораздо проще.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Andrey
+2 # Andrey 15.02.2015 00:29
Не понимаю, что за беда такая хранить в базе данных виды, чем они хуже того, что вы считаете нужным в ней хранить. С точки зрения паттерна MVC может и беда, так Drupal не следует этому паттерну. Ну если корежит, так что кушать не могу, сохраните в файле.

В ядро Drupala не надо лезть потому, что оно само практически обработкой запроса не занимается. это всего лишь набор библиотек для взаимодействия с базой данных, перевод между языками, санирование пользовательских данных и прочее, за процесс обработки запроса отвечают модули. Внутри заложена логика обработки запроса и после наступления каждого шага, ядро предлагает одному или нескольким модулям выполнить обработку запроса с помощью объявления хука (типа события) модуль который хочет поучаствовать в этом шаге, реализует этот хук (функция названная в соответствии с заданным шаблоном) и производит свои действия. Так до конца цикла запроса все модули поучаствуют в нужное время в течении процесса, после чего ядро выдаст ответ пользователю. Поэтому достаточно посмотреть в API ядра (перечень хуков с описанием на каком шаге он объявлен) и реализовать любой функционал, зацепившись за хук в нужном месте. поэтому по большому счету разработчик сам строит ядро, путем наращивания функционала с помощью модулей (а вот в joomla там ядро так ядро :P ). Мало того, модули могут сами объявлять хуки и тем самым предлагать другим модулям добавить свой функционал, на базе уже имеющегося в них. И зачем ковырятся в ядре, ну если это, не Joomla конечно, зато там все в соответствии с паттерном, ковыряться одно удовольствие, правда больше эстетическое, полюбоваться.

А теперь показываю на пальцах что это дает. Есть такая нужная штука, как создание пользовательских типов контента с нужным набором полей для каждого типа. Суть проблемы в том, что есть нода (материал) с постоянным набором полей (автор, заголовок, дата и проч) и к ней нужно прикрутить поля, которые нужны только для конкретного типа.

Решение в Joomla забыть и наплевать что написано в ядре, потому что там уже прописан куцый функционал, потом написать что-то свое, попутно постараться напихать туда всего как можно больше, Seblod вам в пример. Там просто предлагается около 50 полей типа на все случаи жизни, выбираешь 5-10 нужных, а остальные в нагрузку, перед тем как его ставить надо хорошо подумать, потому что если надумаете его отключить, то придется вырывать с мясом.Кроме этого там еще напихано фишек а-ля Drupal (те же фильтры - жалкое подобие видов)
Решение Drupal. Есть модуль Field API, который решает одну единственную задачу присоединять любое пользовательское поле к ЛЮБОЙ сущности (не только к ноде). есть модуль Field SQL Storage который позволяет управлять полями сущностей. Наконец, для тех, кто тычет мышкой, есть модуль Field UI, чтобы присоединять поле в интерфейсе. Осталось только определить типы полей, для каждого типа поля есть свой модуль. Этим набором вы в интерфейсе создаете сами любой тип контента с необходимым количеством и типами полей, а не отмечаете из 50 предложенных. Ну как то так.

Ну и если вы отлично разбираетесь в php, то вам не Joomla, во фреймворк ну хотя бы в YII
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
gladiatorhl2
0 # gladiatorhl2 14.02.2015 00:01
Аркадий Седельников

Вы, наверное, вообще не программировали в Drupal, раз так рассуждаете. В любых CMS сложно запрограммировать что-то самостоятельно, причём сложность зависит от того, что Вы хотите и где запрограммировать. Где-то будет полегче в Joomla, где-то в Drupal.

То, что Drupal более мощная платформа, наверное, спорить не стоит. В некоторых областях Joomla ещё как-то может посоперничать с Drupal, но в основном проигрывает по функциональности, хотя действительно попроще её освоить, а вот найти расширения, причём бесплатные, точно намного сложнее, чем в Drupal. Так что во многих случаях и взаправду придётся самому программировать в Joomla при создании чего-то очень сложного, а в Drupal уже будут модули и не надо ничего программировать.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Аркадий Седельников
-1 # Аркадий Седельников 16.02.2015 20:28
Цитирую Andrey:
joomla там ядро так ядро :P ). Мало того, модули могут сами объявлять хуки и тем самым предлагать другим модулям добавить свой функционал, на базе уже имеющегося в них. И зачем ковырятся в ядре, ну если это, не Joomla конечно, зато там все в соответствии с паттерном, ковыряться одно удовольствие, правда больше эстетическое, полюбоваться.
Вы прямо таки описали архитектуру Joomla в терминологии Drupal. Обработка хуков (в Joomla - tigger) ведется плагинами, в них можно объявлять свои триггеры,так-же как и в любых других сущностях Joomla.
Цитирую Andrey:
Ну и если вы отлично разбираетесь в php, то вам не Joomla, во фреймворк ну хотя бы в YII
YII смотрел, сложного ничего, все примерно так-же как и в джумле, переходить на фреймворк мешает лень, все-таки масса примочек, облегчающих жизнь есть в cms.
Цитирую Andrey:
Решение в Joomla забыть и наплевать что написано в ядре, потому что там уже прописан куцый функционал, потом написать что-то свое, попутно постараться напихать туда всего как можно больше, Seblod вам в пример.
У меня есть свой велосипед. Легкий и гибкий ыо фронтенде до безобразия. argens.ru/upravlenie-kontentom/17-plagin-kontent-konstruktora-minicck-dlya-kontenta-joomla, так-что ни каких проблем. Кстати первый экземпляр этого велосипеда сделал за 2 дня, это к слову о скорости разработки.Цитирую gladiatorhl2:
Вы, наверное, вообще не программировали в Drupal, раз так рассуждаете. В любых CMS сложно запрограммировать что-то самостоятельно, причём сложность зависит от того, что Вы хотите и где запрограммировать. Где-то будет полегче в Joomla, где-то в Drupal.
Не программировал. Мое знакомство ограничилось сборкой магазина ubercart, после этого начал знакомиться с джумлой, первый маг был виртуемарт, оказалось что с ним гораздо проще и функциональнее.

А вообще самой гибкой системой и при этом очень логичной и понятной из того, что я видел является hostcms :-)
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
gladiatorhl2
+1 # gladiatorhl2 23.02.2015 06:21
Цитирую Аркадий Седельников:
Цитирую Andrey:
joomla там ядро так ядро :P ). Мало того, модули могут сами объявлять хуки и тем самым предлагать другим модулям добавить свой функционал, на базе уже имеющегося в них. И зачем ковырятся в ядре, ну если это, не Joomla конечно, зато там все в соответствии с паттерном, ковыряться одно удовольствие, правда больше эстетическое, полюбоваться.
Вы прямо таки описали архитектуру Joomla в терминологии Drupal. Обработка хуков (в Joomla - tigger) ведется плагинами, в них можно объявлять свои триггеры,так-же как и в любых других сущностях Joomla.
Цитирую Andrey:
Ну и если вы отлично разбираетесь в php, то вам не Joomla, во фреймворк ну хотя бы в YII
YII смотрел, сложного ничего, все примерно так-же как и в джумле, переходить на фреймворк мешает лень, все-таки масса примочек, облегчающих жизнь есть в cms.
Цитирую Andrey:
Решение в Joomla забыть и наплевать что написано в ядре, потому что там уже прописан куцый функционал, потом написать что-то свое, попутно постараться напихать туда всего как можно больше, Seblod вам в пример.
У меня есть свой велосипед. Легкий и гибкий ыо фронтенде до безобразия. argens.ru/.../..., так-что ни каких проблем. Кстати первый экземпляр этого велосипеда сделал за 2 дня, это к слову о скорости разработки.Цитирую gladiatorhl2:
Вы, наверное, вообще не программировали в Drupal, раз так рассуждаете. В любых CMS сложно запрограммировать что-то самостоятельно, причём сложность зависит от того, что Вы хотите и где запрограммировать. Где-то будет полегче в Joomla, где-то в Drupal.
Не программировал. Мое знакомство ограничилось сборкой магазина ubercart, после этого начал знакомиться с джумлой, первый маг был виртуемарт, оказалось что с ним гораздо проще и функциональнее.

А вообще самой гибкой системой и при этом очень логичной и понятной из того, что я видел является hostcms :-)


В ubercart можно сделать только страницы-продукты, лучше бы попробовали commerce, он пофункциональнее будет ubercart. В принципе тогда и можно будет как-то сравнивать с Virtuemart. Попрограммируйте в Drupal, тогда наверняка взгляды изменятся, нормальный CMS и очень функциональный.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Andrey
0 # Andrey 17.02.2015 00:49
Аркадий, вы меня троллите что ли? Или действительно не понимаете? Давайте еще раз попробую пояснить о чем речь, но последний раз.
На примере вашего легкого и гибкого до безобразия велосипеда. Ваш велосипед такой же негибкий, хотя может и легкий, как и все другие, написанные по одному и тому же поводу, что и ваш, Вас, как адепта ООП, не смущает такое положение дел, десяток уже существующих велосипедов никак не могут удовлетворить все потребности и появляется ну очень гибкий и до безобразия простой 11-й по счету.
Вообще-то ООП предполагает некий уровень абстракции, по крайней мере, в вашем велосипеде явно просматривается необходимость абстрагировать механизм присоединения полей, чтобы было неважно какие поля и к чему присоединять. Обратите внимание как прямо на глазах повышается гибкость, любое поле к любой сущности. Поясняю, не как в вашем велосипеде 9 типов полей к одной сущности — контенту, а любого поля к любой сущности. Такая штука в Drupal называется модуль Field API, по названию, наверное, догадались, что он снабжен программным интерфейсом, т. е. его можно интегрировать в общую систему. В Drupalе API это набор хуков. Пока это фреймворк получился, но добавив к нему FieldUI, абстракция которого заключается в том, что ему не важно какое поле и с какой сущностью соединять в графическом интерфейсе с помощью мышки. И, наконец, сами типы полей это отдельные модули на каждый тип, в которых можно предусмотреть любые настройки и форматы необходимые для данного типа поля. Все ваши велосипеды + еще неограниченное количество велосипедов делаются на ходу в процессе разработки сайта, при этом есть возможность простым перетаскиванием менять их последовательность и чередовать. Фильтрация это самая незначительная часть функционала модуля Views (Виды), да и та, как вы уже догадались на порядок гибче, потому что он построен так, что ему пофигу по каким полям фильтровать, вот какие есть на сайте по любому и фильтруй. Фильтрация по аргументу вам такое и не снилось, когда фильтр становится динамическим, такого велосипеда вы и не видели. Открываете профиль пользователя а там список всех его статей, фильтр один, а в качестве аргумента ID пользователя, взятый из URL (только не плачьте, и в качестве аргумента можно использовать любое поле). А как вам такая фича? Вы делаете фильтр, а потом используете его в качестве поля в какой-нибудь сущности.
И я не понял при чем тут триггеры, триггер это вкл/выкл и кто их включает и выключает и по какому поводу? Хук (зацепка) это просто приглашение зацепиться в определенном месте и поучаствовать в обработке запроса, Если это логика Joomla терминами Drupal, то я что-то не понимаю вы зачем такие велосипеды пишите?
Насчет простоты YII, я вам скажу так, он и не должен быть трудным, весь вопрос насколько вы верно себе представляете работу веб приложения на более низком уровне, ведь вам его строить с нуля. И в этом смысле, Drupal дает более верное представление и поэтому он же и фреймворк.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Аркадий Седельников
+1 # Аркадий Седельников 18.02.2015 06:56
Андрей, вы опять меня не поняли. Не буду вдаваться в подробности вашего объяснения, а:
1. Посыл моего первого поста о том, что друпал для любителей тыкать мышкой вы подтвердили еще раз в этом посте.
2. Почему вы придрались к слову триггер? Это всего лишь название, такое-же что и хук, у хука еще более нелогичный перевод.
3. По поводу гибкости тоже не соглашусь, гибкость написания кода не сравнится ни с какой гибкостью кликания мышкой, и тут вы меня не переубедите никогда.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Александр Духновский
+1 # Александр Духновский 17.02.2015 10:55
Пустой спор. По причине своей стопроцентной бесполезности. Тем более, что это лишь перевод. Несогласные могут пойти к Арашу Араби и заявить "Мужик, ты не прав!" Вместо этого будем здесь доказывать и обосновывать, опровергать и подвергать критике. Смысл? Да и "здесь" - это joomlaportal, а не drupalportal например. Ребята пришли джумлаводам рассказать о том, какой хороший друпал что-ли? Самим не смешно еще? Вообще фанатизм не самое лучшее явление. Говорит об узком кругозоре зараженного.

Есть такой момент, для хорошего разработчика не имеет значения CMS. Могут быть предпочтения, но они так и называются, ибо основаны на персональном удобстве.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Andrey
+2 # Andrey 17.02.2015 13:47
Ну, во-первых, спор не пустой, потому что спор не с целью победить, а с целью узнать что-то новое, вот вы предпочли высказаться не по сути, а выставить свою оценку. А, во-вторых, если на портале для Joomla написали чушь про Drupal, оставить тех, кто поверил в приятном для себя неведении? Так рождаются секты и спор идет не о том что лучше а что хуже, а о том что на самом деле есть в той или иной cms. Меня интересуют разные cms и фреймворки, вот начал знакомиться с Joomla (поэтому я на портале Joomla) и вижу что люди заблуждаются, ведь в споре можно узнать много чего полезного от оппонентов, чего не сразу понятно из документации. От вас я узнал, что вам смешно от меня и вы повесили на меня ярлык зараженного с узким кругозором. Очень познавательно. Только не подумайте, что я обиделся, читал про себя и похлеще. :-)
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Вадим Куницын
+2 # Вадим Куницын 17.02.2015 22:02
Спор пустой, так как одна из сторон не хочет приходить к консенсусу, в плане терминологии.
Если мы говорим, о Drupal как о фреймворке, то он безусловно проиграет почти любому PHP фрейморку.

Если говорим как о CMS, то сейчас CMS делают расширения. Тогда я могу привести пример Joomla + Seblod и получу нормальную архитектуру плюс все возможности Drupal и наверное даже больше.

Что касается чуши, то кроме возгласов, что так не может быть. И указаний на несколько нюансов опровержения нет.

Доводы типа, спагетти код есть, но нам на него пофиг, не принимаются :)

Понимаете это вопрос восприятия, я уже писал о чувстве прекрасного, но вы вряд ли поняли о чем я.
У автора такое восприятие, и в принципе я с ним согласен. У вас другое, я за это вас не виню, но не пытайтесь говорить другим, что их восприятие это чушь. Тем более недостатки у CMS действительно есть, и в переводе статьи лишь некоторые из них.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Александр Духновский
0 # Александр Духновский 19.02.2015 14:58
Секты рождаются иначе jurgenm.livejournal.com/.../

Да и не в ту сторону смотрите. На друпаловских ресурсах часто встречаются представители других cms, с пеной у рта что-то доказывающие? Агрессивный фанатизм - вот первый признак заражения :)

Лично от меня в этих комментариях Вы вряд ли что-нибудь узнали. Хотя бы по той простой причине, что с моей точки зрения, абсолютно любая cms является нерациональной в разработке. Можно использовать только в личных целях, если есть на то желание.

Зачем вообще что-либо доказывать? Спор не рождает никаких истин, вопреки расхожему мнению. Тут обычный холивар и не более.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Александр Духновский
0 # Александр Духновский 19.02.2015 15:01
Не хочу никого обидеть, но почитайте. На мой взгляд дело как раз в этом.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Sergey
0 # Sergey 18.03.2015 17:35
Ни одной цифры, доказательства и т.д. Друпал сложней выучить, а на джумле написано много модулей. А все остальное - с потолка.

Я как-раз ищу магазин для джумлы - вроде много - не то...


Кстати - на друпале вывод в файл включается одним движением.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Вячеслав
+4 # Вячеслав 22.05.2015 12:16
Внесу свои пять центов. У меня есть магазин на joomla и два на Drupal Commerce (Drupal Ubercart, даже не успел изучить, как появился Commerce. Сборка от Волосюги - не понравилась).

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

Что касается модулей - поначалу изучения, предпочтения отдавал им, сейчас исключительно стараюсь API.

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

Поля и Views - это ВСЕ! Да, кстати, магазин интегрирован еще с двумя ресурсами на Drupal, Форумом PHPBB и будет интеграция еще с несколькими - все они работают на разных доменах второго уровня. Единая авторизация, пользователи - разные права :) (это сделано специально). Разные базы данных и файлы системы у каждой CMS, общие объединенные только те файлы и данные в базе, которые необходимы. Сделано это было с расчетом того, что все в дальнейшем будет разнесено по отдельным серверам, т.е., архитектура планировалась изначально.

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

Насчет производительности :), был сразу установлен Solr Apche и реализован мультиядерный (МультиядрЁный:)) поиск? сейчас, практически все, что только можно, выводится именно при помощи Solr - он тоже планируется на отдельный ресурс в дальнейшем. Скорость потрясающая, при том, что Solr ни только для поиска настроен. Сделано много фич самостоятельных - все легко и быстро. Очень много таких извращений, когда модули типа colorbox и т.п. - просто не нужны. Чистый шаблон HTML и под него полностью заточенная система. даже сложнейшие многофункциональные слайдеры, предпросмотры товара и ит.п., чуть ли ни на уровне темизации field.tpl - такого даже в переводах решений не находил.

В общем я не знаю, что умеет жумла такого, что могло бы меня отвернуть от Drupal. У меня друг, запустил в течении года два средних проекта на Joomla/ Он давно не занимается программированием и поэтому да, на этом движке, ему было быстрее и проще, но вот за это, он заплатил отсутствием гибкости и настройкой всего до мельчайших деталей. На мой вопрос про жумлу, ответил, что ему надо было быстро и он понимает, что она не совершенна и было бы больше времени - обратил внимание на Drupal.

Я перепробовал все российски cms, joomla, WP, Typo3 и еще ряд иностранных. Собирал сайты, переписывал готовые. Отказался от всех, в пользу исключительно гибкости Drupal.

Что касается документации - это забавно. я всего наверно один-два поста разместил на Drupal.org - если вообще задавал вопросы. Один раз обратился непосредственно к разработчику модуля commerce fancy attribute? он подправил там баг и наверное все :) Я столько инфы, как по Drupal, еще никогда не видел при том, что я никогда не программировал раньше :) только немного на Pascal.

Самое сложное на мой взгляд, всегда было и будет (независимо от того, программирование это, или строительство) - это проектирование, моделирование и тестирование модели, как до начала разработки, так и постоянно в процессе. Отсюда наверное и многие нелестные отзывы. Когда в Drupal, ты можешь не заморачиваться и пойти в любом направлении - это тоже сложность гибкости :) надо выбирать не среди закрытых дверей открытую, а среди открытых дверей - лучшее пространство за ней, ибо потом, можно понять, что это не самая лучшая дверь была :)

Пока я не встречу чего-то более революционного - я с Drupal :)
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Вадим Куницын
+3 # Вадим Куницын 23.05.2015 12:35
Попробуйте компонент для Joomla - Seblod :-) Я думаю его возможности вас, как любителя Drupal удивят, кстати его выходцы из Drupal разрабатывают.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
greg
0 # greg 21.06.2016 09:06
На дворе 2016 и linux.com уже работает на Drupal, с чем я их и поздравляю :)
Как бывший любитель джумлы всем советую все-таки освоить Drupal и радоваться жизни.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
lol
0 # lol 21.06.2016 09:59
Цитирую greg:
На дворе 2016 и linux.com уже работает на Drupal, с чем я их и поздравляю :)
Как бывший любитель джумлы всем советую все-таки освоить Drupal и радоваться жизни.

И что? Национальное агенство по преступности Англии работает на joomla. Это не говорит о превосходстве какого-либо движка, а лишь о неумении работать с каким-нибудь из них. По сути вы просто сказали, что не умеете работать с joomla.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
noktorn
0 # noktorn 17.07.2016 17:34
вот так оно и работает
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Сергей
0 # Сергей 03.03.2017 17:53
Полностью согласен с выводами автора.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Алекесй
0 # Алекесй 14.08.2017 16:14
"Бред сивой кобылы"
слез с джумлы на друпал и очень рад этому
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Вадим Куницын
+1 # Вадим Куницын 14.08.2017 18:21
Не расскажите общественности почему вы рады?
Я вот преимуществ друпала так и не разглядел за все эти годы. Имхо если хочется как на Друпал есть Seblod.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
gladiatorhl2
-3 # gladiatorhl2 14.08.2017 18:58
Seblod ? :o По-видимому, руки растут из одного места, поэтому и не разглядели.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
Вадим Куницын
+2 # Вадим Куницын 18.08.2017 01:38
Просто надо инструменты выбирать под задачу :-) Фанатизм это всегда плохо... я просто лишь привел Seblod, как аналог функционала Drupal на Joomla...
Есть более удачные реализации механизмов используемых в Drupal, плюс гораздо более производительных. Так в чём преимущество?? В том что это друпал?
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору
gladiatorhl2
0 # gladiatorhl2 21.08.2017 16:02
Судя по Вашим комментариям Вы вообще особо не пользовались Drupal, сядьте и сделайте пару сложных сайтов и все тогда поймете. Невозможно будет легко на Joomla или вообще на каком-то малоизвестном Seblod сделать некоторые вещи, не прибегая к программированию. Если бы было все прекрасно с Seblod, то по крайней мере уже бы многие о нем знали, как о Wordpress, Joomla или Drupal. Все, что делает Joomla, можно сделать на Drupal, но не наоборот. Отличия будут лишь в дизайне и здесь у Joomla есть тоже минусы. Обычно сайты, сделанные на Joomla, все же чем-то напоминают друг друга, а вот на Drupal они практически всегда уникальны, хотя можно и на Joomla тоже сделать очень хорошовыглядящие сайты.
Ответить | Ответить с цитатой | Цитировать | Сообщить модератору

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

Обновить
Защитный код

Joomla!® CMS — пожалуй, лучшая система управления контентом с открытым исходным кодом

Joomla! — это больше, чем просто программное обеспечение, это люди, включающие разработчиков, дизайнеров, системных администраторов, переводчиков, копирайтеров, и, что самое главное — простых пользователей.

Мы рады пригласить вас в ряды нашего сообщества!

Скачать Joomla! 3 Документация Joomla! CMS Свернуть

Новости портала

Новое в блогах

Видео