Для меня это тоже странно. Я на Хабр уже более года не заходил. Работаю на запад — тут Друпал цветет и пахнет, и разработчики активно переходят на Друпал. Я сам сейчас практически постоянно работаю с миграцией сайтов с других ЦПС на Друпал. Захожу в ХАБР — а тут похоронные песни Друпалу поют, очень странно. При чем, поют почему — потому что разработчики Друпала 7 делились своими предложениями. Переводчики взяли негатив, написали статьи на уровне желтой прессы. Я вижу смысл такое делать в политике. Но в веб-разработке — какой кайф?!
Когда продукт создается сильным сообществом, которое способно критиковать себя, выявлять и решать проблемы — это очень важный плюс такому сообществу. Например, самокритика проекта при создании Друпал 7 позволила сделать эту версию гораздо лучше всех предыдущих. А в 8 версии, Друпал бросает вызовам базовым ограничениям своего ядра и перебирается на Symphony в качестве движка. В 8 версию будет также включена новая система редактирования и управления контентом, с инлайн-редактированием Sparkle, и поддержка мобильных устройств в ядре. И вот в то время, как все затаив дыхание следят за тем что будет с Друпал 8, у на стут на хабре все еще жуют сопли из-за какой-то критики, которая была в разработке Друпал 7.
Это не совсем так. Авторы оставляют тот или иной модуль, если теряют к нему интерес. Сейчас, функционал по работе полей, особенно, унифицируется (был унифицирован уже в версии 7), и многие модули, которые были портированы из Друпала 6, стали ненужными, и их поддерживают минимально только чтобы обеспечить работу существующих сайтов с этими модулями.
Что касается архитектурных ограничений системы, то на самом деле, полировка тут не решает. Решает проблему переход на фреймфорк Symphony в качестве движка, который будет в Drupal 8. Это будет большой скачек, многое поменяется. И Друпал еще больше станет фреймоворком чем CMS. Но это то, чего разработчики хотят от Друпала — не просто готовую ЦМС-ку, а гибкуи и мощную систему, из которой можно собрать ЦМС-ку под нужды заказчика, и потом изменять ее, если потребудется.
Так тчо пока что Друпал развивается великолепно. Единственная возможная проблема — если переход на Symfony окажется неудачным, и система стант слишком большой или неповоротливой. Но вот разработчики уверяют, что как раз будет наоборот — система стант более ООП-шной, сдвинется сильно в сторону MVC, и станет еще более привлектельной для разработчиков.
Статья неверно передает и истолковывает факты в корне. Когда разрабатывается система, в ней всегда много багов, и они закрываются. Когда закрываются все критчиеские баги, и остаются только незначительные и неподтвержденные баги, или редкие баги, которые возникают только в лчень редких случаях, систему выпускают, и неокторое время обкатывают. Это нормально. И то, что Drupal продолжает активно расти на западе, и всё больше компаний переходят на Drupal — тоже это показывает.
Так вот теперь по сути, в чем собственно проблема? Проблема в том, что при разработке Drupal 7 вывились философские проблемы — низкоуровневый движок системы занимает слишком много времени разработчиков Drupal. Это решается в Drupal 8 переходом на фремворк Symphony 2 в качестве низкоуровневого движка. Вот это включение мощного ООП — корректного дижка как «драйвера» для Drupal, и решает те вопросы, которые были подняты. Насколько это будет успешно — посмотрим. Но сейчас, Drupal цветет и пахнет, и проекты во всем мире переходят на Drupal толпами. Я работаю сейчас день и ночь над миграцией в Drupal, отбоя нет.
Так это такая эволюция систем. От «легкого нового менеджера» до «интуитивной и полновесной рабочей среды, удовлетворяющей всем запросам пользователей».
Я пошел скачивать обновления и похоже, скачиваемый файл все еще старый — ubuntu-10.10-desktop-i386.iso Они обычно ставят соответствующие цифры версии в названии образа.
Получилось, что они разоврали договор в одностороннем порядке, не уведомив об этом заказчика, и нанесли ему материальный и моральный ущерб. Стоит проконсультироваться с юристами.
Спасибо. Я старался сделать стать как можно доступнее и проще, даже не смотря на то, что это создаст вопросы или даже возражения, типа «А где валидация?» «Почему форма всего лишь возвращает имя?» «А почему не проработан вариант без джаваскрипта?». С другой стороны, если сделать это, статья станет гораздо сложнее. Поэтому я все-таки выбрал вариант, в котором даются основы, в расчете на то, что при написании конкретного модуля человек будет строить уже дальше на этом примитивном основании. Мне в свое время именно такой примитивной статьи не хватало чтобы разобраться, понять суть процесса.
Речь идет в первую очередь о файлах с кодом на php. Это inc файлы в первую очередь. Друпал создает индекс функций и классов, что позволит улучшить работу кода в системе.
Спасибо за уточнение — я также подправил этот момент в статье.
Он же не только на среду разработчиков рассчитывает. Друпал 7 значитально проще в управлении для клиентов. А ведь это они часто решают, какая ЦМСка будет установлена на их сайте. «Мне трудно управлять Друпалом», «У него сложная админка» — это были частые жалобы в 5 и 6 версии. 7 версия в этом смысле гораздо проще.
Эта версия Друпала должна быть очень успешной:
1. Множество улучшений по безопасности, переделан заново слой абстракции БД.
2. Множество оптимизаций — по сокращений количества запросов БД и merge.
3. Куча улучшений ядра — в модули ядра перенесен функционал некоторых модулей (таких как создание дополнительных полей, SEO, блокировки спама и нежелательных IP).
4. Улучшение API — наработки после 6 версии, упрощения, новый функционал. Хотя API Друпала не полностью ООП, теперь оно стало на шаг ближе к ООП.
5. Улучшен движок тем. Более стандартизирован, раширен, и более понятен разработчикам из других ЦМС, которым приходится разрабатывать для Друпал тему.
6. Улучшен административных интерфейс. Теперь он реализован через AJAX.
7. Куча усовершенствований scalability, SEO, и accessibility.
Как-никак, несколько лет труда на эту версию ушло!
Когда продукт создается сильным сообществом, которое способно критиковать себя, выявлять и решать проблемы — это очень важный плюс такому сообществу. Например, самокритика проекта при создании Друпал 7 позволила сделать эту версию гораздо лучше всех предыдущих. А в 8 версии, Друпал бросает вызовам базовым ограничениям своего ядра и перебирается на Symphony в качестве движка. В 8 версию будет также включена новая система редактирования и управления контентом, с инлайн-редактированием Sparkle, и поддержка мобильных устройств в ядре. И вот в то время, как все затаив дыхание следят за тем что будет с Друпал 8, у на стут на хабре все еще жуют сопли из-за какой-то критики, которая была в разработке Друпал 7.
Что касается архитектурных ограничений системы, то на самом деле, полировка тут не решает. Решает проблему переход на фреймфорк Symphony в качестве движка, который будет в Drupal 8. Это будет большой скачек, многое поменяется. И Друпал еще больше станет фреймоворком чем CMS. Но это то, чего разработчики хотят от Друпала — не просто готовую ЦМС-ку, а гибкуи и мощную систему, из которой можно собрать ЦМС-ку под нужды заказчика, и потом изменять ее, если потребудется.
Так тчо пока что Друпал развивается великолепно. Единственная возможная проблема — если переход на Symfony окажется неудачным, и система стант слишком большой или неповоротливой. Но вот разработчики уверяют, что как раз будет наоборот — система стант более ООП-шной, сдвинется сильно в сторону MVC, и станет еще более привлектельной для разработчиков.
Так вот теперь по сути, в чем собственно проблема? Проблема в том, что при разработке Drupal 7 вывились философские проблемы — низкоуровневый движок системы занимает слишком много времени разработчиков Drupal. Это решается в Drupal 8 переходом на фремворк Symphony 2 в качестве низкоуровневого движка. Вот это включение мощного ООП — корректного дижка как «драйвера» для Drupal, и решает те вопросы, которые были подняты. Насколько это будет успешно — посмотрим. Но сейчас, Drupal цветет и пахнет, и проекты во всем мире переходят на Drupal толпами. Я работаю сейчас день и ночь над миграцией в Drupal, отбоя нет.
www.youtube.com/watch?v=GW0JjDeye6U
Спасибо за уточнение — я также подправил этот момент в статье.
Верно, fastcontact_ajax возвращает массив (так и должно быть).
Я дополнил статью, добавив в коце ссылку на архив с модулем. Архив с модулем. Надо было сразу рабочий пример выложить.
1. Множество улучшений по безопасности, переделан заново слой абстракции БД.
2. Множество оптимизаций — по сокращений количества запросов БД и merge.
3. Куча улучшений ядра — в модули ядра перенесен функционал некоторых модулей (таких как создание дополнительных полей, SEO, блокировки спама и нежелательных IP).
4. Улучшение API — наработки после 6 версии, упрощения, новый функционал. Хотя API Друпала не полностью ООП, теперь оно стало на шаг ближе к ООП.
5. Улучшен движок тем. Более стандартизирован, раширен, и более понятен разработчикам из других ЦМС, которым приходится разрабатывать для Друпал тему.
6. Улучшен административных интерфейс. Теперь он реализован через AJAX.
7. Куча усовершенствований scalability, SEO, и accessibility.
Как-никак, несколько лет труда на эту версию ушло!