Комментарии 194
К сожалению все так и есть. Будем надеяться на следующие версии любимой многими cms. Спасибо
«не более 1000 посетителей в день» — гон какой-то. Я пару раз видел друпал, он отвечает гораздо быстрее чем 1 раз в минуту. Так медленно даже плон не работат.
абсолютно согласен. уж 1000 уников в сутки друпал точно выдержит
1000 гостей — да, у меня держит на простом shared и 2000 и 3000 гостей без малейших проблем (хостер ни разу не жаловался на загрузку), основные проблемы возникают когда зарегистрированных много, под них уже надо сайт оптимизировать отдельно.
Друпал не иделаен но мне увы стал теперь привычным.
Да нужен бубен, как без него.
Но работает он хорошо, стабильненько так :-)
Правда конечно у нас свои сервера и как бы проблем с производительностью у нас нет но наши проекты делаем на нём и pluser.ru не исключение.
Хотя и не показатель.
Просто сделан на друпале.
Короче для нас плюсов в нём хватает.
И я не уверен что мы с него слезем.
Хотя конечно и такой исход событий не исключение.
Да нужен бубен, как без него.
Но работает он хорошо, стабильненько так :-)
Правда конечно у нас свои сервера и как бы проблем с производительностью у нас нет но наши проекты делаем на нём и pluser.ru не исключение.
Хотя и не показатель.
Просто сделан на друпале.
Короче для нас плюсов в нём хватает.
И я не уверен что мы с него слезем.
Хотя конечно и такой исход событий не исключение.
Т.е. получается, что гости не ходят дальше главной страницы, а если 1000 пользователей — то всё падает? Можно её сделать статической в таком случае, будет держать ещё больше ;) Но о производительности движка стоит судить всё-таки не по скорости загрузки главной страницы.
Ходят и публикуют комментарии (гостям разрешено) и Drupal справляется без особых оптимизаций.
Day: 10 Dec 2008
Number of visits: 3225
Pages: 8460
Hits: 69439
Это без ботов, а на ботов приходится тоже очень много загрузок страниц.
Day: 10 Dec 2008
Number of visits: 3225
Pages: 8460
Hits: 69439
Это без ботов, а на ботов приходится тоже очень много загрузок страниц.
Тогда мне не совсем ясно, откуда появляется нагрузка «когда зарегистрированных много», что появляется необходимость в сильной оптимизации.
Там кеширование по другому начинает работать. Точнее для зареганных оно практически не работает :(.
Но думаю и на хабре например главную для зареганных кешировать нельзя — так как у каждого разное количество прочитанных\непрочитанных комментов.
Но думаю и на хабре например главную для зареганных кешировать нельзя — так как у каждого разное количество прочитанных\непрочитанных комментов.
Мне кажется, вы не очень хорошо знаете разные механизмы кэширования (это я заключаю, исходя из фразы о хабре).
Возможно, не эксперт :). Дополните или поправьте плиз…
Необязательно кэшировать готовую, отрисованную страницу со всем ее HTML'ем. Можно закэшировать непосредственно данные. Если друпал этого не умеет — это говорит об отсталости его механизмов кэширования.
Кажется мы говорим о разных вещах. Можно кешировать данные. Но при этом можно кешировать еще и саму сгенерированную страницу и не тратить время на выполнение скрипта.
Не всегда можно закэшировать готовую страницу или даже часть страницы. Если страница содержит персонализированные данные, бывает удобно закэшировать отдельно не-персонализированные данные и персонализированные: а потом, при сборке страницы, использовать данные из этого кэша. Пример — страницы хабра. Уверен, что все данные статей, подборок статей хранятся в кэше. Также в кэше хранятся данные о прочитанных пользователями статьях и комментариях. При сборке страницы эти данные сопоставляются и на выходе мы получаем персонализированную страницу для конкретного пользователя.
можно, а количество это не такой уж и большой запрос. главное определиться что именно кэшировать.
Сильная оптимизация и не нужна, надо просто «подкрутить гайки». Даже может не придется писать ни строчки кода, можно поставить модули чтобы улучшить кэширование. К примеру модули именно для производительности: drupal.org/project/Modules/category/123
Да и эта подкрутка заключается в приспособлении под хостинг, где-то mySQL «летает», а где-то стоит использовать дисковый кеш, а где то лучше Memcached.
А приходится это делать потому, что Drupal «из коробки» для зарегистрированных очень много берет мимо кэша.
Да и эта подкрутка заключается в приспособлении под хостинг, где-то mySQL «летает», а где-то стоит использовать дисковый кеш, а где то лучше Memcached.
А приходится это делать потому, что Drupal «из коробки» для зарегистрированных очень много берет мимо кэша.
О чём и речь, имхо можно было уже за время существования этих модулей сделать один «правильный», а может даже рекомендованный разработчиками движка или включить его в дистрибутив. Но в условиях open source каждый видимо тянет одеяло на себя, а тем временем выпускаются платные версии, наверняка лишённые этих недостатков :/
Acquia Drupal ( acquia.com/downloads ) — в ней платного то только поддержка.
А идеала в кешировании, на мой взгляд, просто невозможно найти, в том то соль, что на одной площадке одно кеширование лучше, а на другой другое. И Вы сами вольны выбрать что лучше для Drupal на конкретном хостинге.
А идеала в кешировании, на мой взгляд, просто невозможно найти, в том то соль, что на одной площадке одно кеширование лучше, а на другой другое. И Вы сами вольны выбрать что лучше для Drupal на конкретном хостинге.
Возьмите 50000 нод, и уже при 1000 гостей стандартный кэшак будет сдыхать, уже требуется оптимизация и по запросам и по кэшу. друпа хороша тем что на ней можно более менее быстро сделать проект, а когда проект заработает, уже можно друпу оптимизировать. И есть реальные сайты которые работают на обычных шаред хостингах.
Самое плохое в том, что автор действительно прав. Но это все из того что у Drupal Multi Controller & Multi Hooks архитектура. Никакого понимания понятия юзабилити.
И в то же самое время, на сегодня из бесплатных «универсальных» — Drupla лучший.
И в то же самое время, на сегодня из бесплатных «универсальных» — Drupla лучший.
НЛО прилетело и опубликовало эту надпись здесь
Швабршвабр приведён для примера + к нему есть подробный гайд как его повторить. А в остальном согласен!
вобще то сайт наса сделан на java иль на питоне если мне память не изменяет, но точно не на друпе.
НЛО прилетело и опубликовало эту надпись здесь
и дальше что? вылазит www.nasa.gov/offices/oce/appel/home/index.html
давай уж обьясняй. иль ты дал для примера что идет редирект?
давай уж обьясняй. иль ты дал для примера что идет редирект?
и кстати доктайп внимательно все смотрели?
<!DOCTYPE «xmlns:xsl='http://www.w3.org/1999/XSL/Transform'»><html xmlns:java_code=«xalan://gov.nasa.build.Utils2»>NASA —
Процессор Xalan
Использование
Расширения
Основные характеристики процессора:
*
Платформы: Java, C++.
*
Расширения: функции и элементы расширения.
*
Полнота реализации: один из наиболее проработанных процессоров.
*
Разработчик: Apache XML Project.
*
URL: xml.apache.org.
Xalan — это очень известный XSLT-процессор, созданный в рамках Apache XML Project для языковых платформ Java и C++. Xalan, как и остальные продукты Apache XML Project, поставляется с открытым исходным кодом и открытым API, что делает его очень привлекательным для интеграции в другие приложения.
прикольная друпа, хочу такую.
<!DOCTYPE «xmlns:xsl='http://www.w3.org/1999/XSL/Transform'»><html xmlns:java_code=«xalan://gov.nasa.build.Utils2»>NASA —
Процессор Xalan
Использование
Расширения
Основные характеристики процессора:
*
Платформы: Java, C++.
*
Расширения: функции и элементы расширения.
*
Полнота реализации: один из наиболее проработанных процессоров.
*
Разработчик: Apache XML Project.
*
URL: xml.apache.org.
Xalan — это очень известный XSLT-процессор, созданный в рамках Apache XML Project для языковых платформ Java и C++. Xalan, как и остальные продукты Apache XML Project, поставляется с открытым исходным кодом и открытым API, что делает его очень привлекательным для интеграции в другие приложения.
прикольная друпа, хочу такую.
странно, когда в последний раз работал с Дрюпалом, проблем с темизайией не замечал o_o
Ну, плюсом к описанному выше:
1. Функция drupal_get_form(), которая отдаёт готовую форму. Сама по себе это отличная приманка, для ничегонеделания и получения готовой формы и её обработчиков, но когда я пытался перегрузить её вывод сохранив при этом валидатор и сабмитер, то ничего не получилось.
2. template.php — контроллер (и иногда даже модель) в одном файле. Это конечно ещё и к безграмотной структуре Drupal'а относится, и всё же. Но суть в том, что с ним приходится много колдовать!
1. Функция drupal_get_form(), которая отдаёт готовую форму. Сама по себе это отличная приманка, для ничегонеделания и получения готовой формы и её обработчиков, но когда я пытался перегрузить её вывод сохранив при этом валидатор и сабмитер, то ничего не получилось.
2. template.php — контроллер (и иногда даже модель) в одном файле. Это конечно ещё и к безграмотной структуре Drupal'а относится, и всё же. Но суть в том, что с ним приходится много колдовать!
Только темизировать эту форму — это что-то с чем-то ))) сейчас вот сижу, пытаюсь темизировать форму, а не хочет… здесь же и проблема с кэшем вылазит. Но сама CMS мне нравится. И игратся с ней тоже нравится — много нового узнаешь ))
Посмотрите drupaldance.com/blog/%D1%82%D0%B5%D0%BC%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F-%D1%84%D0%BE%D1%80%D0%BC
Надеюсь, это не будет считаться пиаром, я в этом блоге лишь подписчик :)
Надеюсь, это не будет считаться пиаром, я в этом блоге лишь подписчик :)
Я, кстати, это читал но так и смог применить, хотя вроде толково описано.
Есть здравая инфа, но многое очень сомнительно. И про нагрузку (про 1000 посетителей смешно, у меня одна VPSка на 256мб держит уже около 6000 просмотров в день, а можно посмотреть и хотя бы на Drupal.ru), и про кэши (можно же разобраться, что там и как), и про размер модулей (их код обычно разбивается по файлам, это сделано в стандартных и рекомендуется для кастомных)
Просмотры и посетители разные вещи! =) Про организацию модулей согласен, можно, но тогда и за структурой придётся самому следить и, насколько помню, доп.файлы самому подключать.
С кэшем крутил и вертел много. Пример с Симфони приведён не зря, кстати. Им я хотел показать, что можно и нужно было в Drupal'е сделать точно так же!
С кэшем крутил и вертел много. Пример с Симфони приведён не зря, кстати. Им я хотел показать, что можно и нужно было в Drupal'е сделать точно так же!
виртуал сервак и шаред две разные вещи.
НЛО прилетело и опубликовало эту надпись здесь
Drupal иначе как кодо-венегретом назвать сложно. Слишком много кода, слишком много лишнего кода. От сюда и нагрузки большие на сервер и на БД.
Сейчас этим страдают многие похожие движки, к примеру WordPress, который с каждой версией становится все более ресурсоемким.
Что мне больше всего нравится, так это Joomla она тоже не без граблей, но работает побыстрей, да и работать с нею как по мне удобней.
Это мое субьективное мнение, не минусуйте=)
Сейчас этим страдают многие похожие движки, к примеру WordPress, который с каждой версией становится все более ресурсоемким.
Что мне больше всего нравится, так это Joomla она тоже не без граблей, но работает побыстрей, да и работать с нею как по мне удобней.
Это мое субьективное мнение, не минусуйте=)
с joomla удобно начинать, но работать с ней… сделал один сайт с форумом 2 года назад, 2 раза просто так упала база (crashed the table), модуль форума не обновляется, вышла на его основе новая версия, которая со старой не совместима. в итоге полный тупик
а еще меня жутко раздражают урлы в joomla, это просто туши свет
опять же, это мое имхо, на основе того с чем столкнулся
а еще меня жутко раздражают урлы в joomla, это просто туши свет
опять же, это мое имхо, на основе того с чем столкнулся
Урлы правятся. Новя джумла приятно выглядит…
2 года назад? С тех пор много чего изменилось, Joomla является победитем в множестве номинаций является одним из основных конкурентов Drupala, при этом у нее не такой тяжелый код, да и работает шустрее. Кроме того существует множество вариантов, это и SEO Joomla и Joostina и т.д.
2года назад — это 2006 год, тогда Joomla только начинала свою историю, вот история версий 2006 года:
15 января 2006: Выход Joomla! 1.0.6 [Sunscreen]
15 января 2006: Выход Joomla! 1.0.7 [Sunbolt]
26 февраля 2006: Выход Joomla! 1.0.8 [Sunshade]
5 июня 2006: Выход Joomla! 1.0.9 [Sunshine] (12 исправлений безопасности; более 160 исправлений общего характера; оптимизация)
26 июня 2006: Выход Joomla! 1.0.10 [Sundown] (9 исправлений безопасности, из которых 3 — критических; более 40 исправлений общего характера)
29 августа 2006: Выход Joomla! 1.0.11 [Sunbow]
12 октября 2006: Выход Joomla! 1.5 [BETA]
25 декабря 2006: Выход Joomla! 1.0.12 [Sunfire] (Данный релиз, позиционируется как стабильный: исправлено более 140 различных ошибок, несколько уязвимостей низкого уровня. Выполнен полный аудит безопасности всех SQL-запросов)
В Википедии можно узнать об остальных версиях.
2года назад — это 2006 год, тогда Joomla только начинала свою историю, вот история версий 2006 года:
15 января 2006: Выход Joomla! 1.0.6 [Sunscreen]
15 января 2006: Выход Joomla! 1.0.7 [Sunbolt]
26 февраля 2006: Выход Joomla! 1.0.8 [Sunshade]
5 июня 2006: Выход Joomla! 1.0.9 [Sunshine] (12 исправлений безопасности; более 160 исправлений общего характера; оптимизация)
26 июня 2006: Выход Joomla! 1.0.10 [Sundown] (9 исправлений безопасности, из которых 3 — критических; более 40 исправлений общего характера)
29 августа 2006: Выход Joomla! 1.0.11 [Sunbow]
12 октября 2006: Выход Joomla! 1.5 [BETA]
25 декабря 2006: Выход Joomla! 1.0.12 [Sunfire] (Данный релиз, позиционируется как стабильный: исправлено более 140 различных ошибок, несколько уязвимостей низкого уровня. Выполнен полный аудит безопасности всех SQL-запросов)
В Википедии можно узнать об остальных версиях.
ну это вы зря, лишнего кода и в joomla (я адепт джумла-движения) хватает, очень много ненужного удаляю. но про общее — верно, что джумла, что друпал — очень похожи на гигантские швейцарские ножи в которых разве что бензопила не встроена.
заострять на этом внимание тоже не стоит — если выбираешь универсальную CMS для сайта, знай, что впоследствие придется обламывать ненужные «лезвия»
заострять на этом внимание тоже не стоит — если выбираешь универсальную CMS для сайта, знай, что впоследствие придется обламывать ненужные «лезвия»
ну да- в друпе много букф, сложно да? не беда-запаситесь терпением и поймете в чем разница между джумлой и друпой. джумла тоже неплоха, но она намного корявее чем друпа.
CMS созданы не для программистов — они созданы для тех кто хочет открыть свой сайт…
Я думаю у каждого веб-программиста есть свой сайт, но не каждый у кого есть свой сайт — является программистом…
Лично я уже давно понял что лучше своего — ничего нет. Ну и странно мне читать о нагрузке того или иного движка, когда и так понятно что за универсальность нужно чем то платить… не бывает так — и рыбку съесть и н… дальше вы знаете :)
— Практика показывает, что у медали две стороны. Если бы всё было так плохо, то никто бы такой плохой штукой как Drupal и не пользовался бы
— Человек который загорелся открыть свой сайт, прочитал где то что DRUPAL это хороше, и по тутору установил его — даже понятия не имеет что такое запросы к базе и т.д. С чего бы это ему не пользоваться друпалом? Я думаю количество это еще не показатель «хорошего»
Ну и еще проблема в том что люди пытаются изучить ДРУПАЛ а не PHP — ну тогда о какой понимаемости кода и структуры можно говорить?
Я думаю у каждого веб-программиста есть свой сайт, но не каждый у кого есть свой сайт — является программистом…
Лично я уже давно понял что лучше своего — ничего нет. Ну и странно мне читать о нагрузке того или иного движка, когда и так понятно что за универсальность нужно чем то платить… не бывает так — и рыбку съесть и н… дальше вы знаете :)
— Практика показывает, что у медали две стороны. Если бы всё было так плохо, то никто бы такой плохой штукой как Drupal и не пользовался бы
— Человек который загорелся открыть свой сайт, прочитал где то что DRUPAL это хороше, и по тутору установил его — даже понятия не имеет что такое запросы к базе и т.д. С чего бы это ему не пользоваться друпалом? Я думаю количество это еще не показатель «хорошего»
Ну и еще проблема в том что люди пытаются изучить ДРУПАЛ а не PHP — ну тогда о какой понимаемости кода и структуры можно говорить?
Ну вы в данном случае немного не правы. В друпале применена откровенно странная на первый взгляд система (Таже таксономия), и без чтения мануалов там не особо разберешься.
Что сложного в таксономии? Только слово, тогда замените его для себя на классификация.
Вроде все логично, прозрачно и к месту
Почитайте: ru.wikipedia.org/wiki/%D0%A2%D0%B0%D0%BA%D1%81%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D1%8F
Вроде все логично, прозрачно и к месту
Почитайте: ru.wikipedia.org/wiki/%D0%A2%D0%B0%D0%BA%D1%81%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D1%8F
Я не говорил, что это недоступно для понимания. Я говорил, что есть не очевидные вещи. Только и всего.
Ну да, многие вещи после их изучения становятся очевидными и понятными. Странно что их не используют другие и часто не использовал раньше и сам как само собой разумеющееся.
Отсюда(в том числе и из-за лени в изучении) начинается изобретение своих велосипедов и кривых костылей. Или в худшем случае охаивание чужого.
з.ы. филосовствования не в ваш счет ;)
Отсюда(в том числе и из-за лени в изучении) начинается изобретение своих велосипедов и кривых костылей. Или в худшем случае охаивание чужого.
з.ы. филосовствования не в ваш счет ;)
> з.ы. филосовствования не в ваш счет ;)
Обратите внимание, ниже практически идентичный комментарий, с положительной оценкой.
Обратите внимание, ниже практически идентичный комментарий, с положительной оценкой.
Василий- ты чего с ним споришь то? ну не понять ему сам смысл классификации, подрастет поймет что есть такое библиотека и откуда ноги растут у слова незнакомого такого как таксономия. терпение и поймет, ты ведь тож не сразу узнал про это.
В этом то и проблема, что при создании CMS о программистах, котрые быдут программировать под эту CMS не подумали!
полностью согласен с вами. Люди часто путают CMS и CMF — это очень разные вещи.
Все CMS существуют для быстрой разработки сайта, потому что большинство вещей уже реализовано.
Если человек очень много работает с CMS «напильником», пишет много кода и т.д., то нужно переходить к CMF. Поймите, нереально создать CMS, которая будет всем нравится, нельзя подстроится под всех.
Для этого существуют CMF(фреймворки), в которых реализована вся низкоуровневая часть кода(работа с дб, роутинг и много полезных вещей). И не нужно будет писать велосипеды.
Вывод: если вы слишком много переписываете CMS, пора переходить на CMF. Нужно забыть о Joomla, Wordpress, Drupal.
Автор сравнивал Drupal и Symfony, что я считаю некорректным. Тем хто устал от переписывания кода, предлагаю познакомится со следующими фреймворками — CodeIgniter(Kohana), Symfony, Zend Framework.
Еще достаточно интересным и перспективным я вижу Yii.
Все CMS существуют для быстрой разработки сайта, потому что большинство вещей уже реализовано.
Если человек очень много работает с CMS «напильником», пишет много кода и т.д., то нужно переходить к CMF. Поймите, нереально создать CMS, которая будет всем нравится, нельзя подстроится под всех.
Для этого существуют CMF(фреймворки), в которых реализована вся низкоуровневая часть кода(работа с дб, роутинг и много полезных вещей). И не нужно будет писать велосипеды.
Вывод: если вы слишком много переписываете CMS, пора переходить на CMF. Нужно забыть о Joomla, Wordpress, Drupal.
Автор сравнивал Drupal и Symfony, что я считаю некорректным. Тем хто устал от переписывания кода, предлагаю познакомится со следующими фреймворками — CodeIgniter(Kohana), Symfony, Zend Framework.
Еще достаточно интересным и перспективным я вижу Yii.
Не для программистов? Скажите что вы шутите. Именно для программистов создавалась архитектура, которая позволячет изменять поведенение любого модуля не изменяя код самого модуля. Именно в этом сола друпала для программиста. Для пользователя он привлекателен только таксономией, с которой далеко не каждый пользователь разберется.
Именно для программистов создавалась архитектура, которая позволяет изменять поведение любого модуля не изменяя код самого модуля.Нельзя на каждый чих создавать хук, так что наверняка есть места, для изменения которых без патчей не обойтись :) На холивар не напрашиваюсь, но не стоит завышать прогресс Друпала в этом направлении.
Именно, на каждый чих — хук. Да, это не эффективно, но именоо это позволяет потом обносить core без лишнего гемороя. На дупале (помимо мелочи) поднимались два довольно таки крупных проекта. Патч был всего один и то стороннего модуля (birthday).
На этих проектах нам аутсорсили разработку на друпале и контролировали качество. Любое изменение кода core модуля — расстрел на месте, community модуля — ссылка без прав переписки )
Буквально на днях моя фирма потеряла заказ из-за некачественно выполненного мной тестового задания — вместо следования философии друпала экономил на запросах. В результате, полсе code review на строне заказчика нам сказали что «Things were architected in a fashion outside of drupal». Вывод — это у нас почему-то принято экономить на стоимости хостинга, а не на стоимости разработки и поддержки, но такая ситуация только у нас )
На этих проектах нам аутсорсили разработку на друпале и контролировали качество. Любое изменение кода core модуля — расстрел на месте, community модуля — ссылка без прав переписки )
Буквально на днях моя фирма потеряла заказ из-за некачественно выполненного мной тестового задания — вместо следования философии друпала экономил на запросах. В результате, полсе code review на строне заказчика нам сказали что «Things were architected in a fashion outside of drupal». Вывод — это у нас почему-то принято экономить на стоимости хостинга, а не на стоимости разработки и поддержки, но такая ситуация только у нас )
Мне как минимум пришлось встретиться с одним местом: нельзя подменить выводимое имя пользователя(нужно было разделить логин и имя, которое выводится на страницах). Оказалось, что написания theme_userneme, остаются ещё в некоторых местах выводы именно $user->name, а его изменять нельзя, иначе все формы редактирования перестанут работать, там автор ищется в БД именно по имени. Честно говоря не верю, что это можно решить «красивее», хотя другие варианты могут быть. Плюс из замеченного мной тогда, имена в ссылках обрезаются по 15 символов, и это прописано в ядре. И это в 6й версии, где по сообщениям разработчиков многое было переписано. Так что имхо развиваться ещё есть куда :)
И всё-таки, мы живём пока что в России и приходится мириться с местными бюджетами и ценами на хостинг.
И всё-таки, мы живём пока что в России и приходится мириться с местными бюджетами и ценами на хостинг.
Скажите. Автомобиль создан для кого — для водителей или для механиков?
В данном случае автомобиль — конечный продукт — это сайт. Он создан для пользователей. А вот гаечный ключ — drupal — для механиков.
Drupal — это и есть готовый сайт, и уж ни как не гаечный ключ. А то что люди с ним делаеют — это уже тюнинг нашего автомобиля.
Неправильная у вас аналогия. Автомобиль — это заказ сайта на друпале у профессионала. Кроме того, что-то мне подсказывает, что базовой комплектации вам будет недостаточно )
Представьте что вы купили себе шкаф. Вам его доставили в разобраном виде и дальше уже ваше дело — собирать его самому или заплатить за сборку.
Если вы решите собирать сами и слепите все детали жвачкой, то ваш шкаф не выдержит нагрузки. Если соберете так, что двери будут открыватся внутрь — вам неудобно будет им пользоватся.
Представьте что вы купили себе шкаф. Вам его доставили в разобраном виде и дальше уже ваше дело — собирать его самому или заплатить за сборку.
Если вы решите собирать сами и слепите все детали жвачкой, то ваш шкаф не выдержит нагрузки. Если соберете так, что двери будут открыватся внутрь — вам неудобно будет им пользоватся.
Шкафом в разобранном виде еще можно как-то обозавать например фреймворки… но друпал — это готовая система, что бы вы мне не доказывали тут.
Система идет со своей уже готовой базой данных, со своим инсталлятором.
То что кому то не хватает базовой установки — не делает из друпала инструмент для разработки. Это готовая CMS. То что ковыряние в коде для подгонки под себя или установку плагинов кто то называет разработкой… то уж извините меня…
Если для вас drupal это гаечный ключ… что же у вас ассоциируется с php, MySQL?
Система идет со своей уже готовой базой данных, со своим инсталлятором.
То что кому то не хватает базовой установки — не делает из друпала инструмент для разработки. Это готовая CMS. То что ковыряние в коде для подгонки под себя или установку плагинов кто то называет разработкой… то уж извините меня…
Если для вас drupal это гаечный ключ… что же у вас ассоциируется с php, MySQL?
друпа это конструктор а не сайт
«реально же Drupal может держать не более 1000 посетителей в день»
ну ну, перегруженный всякими ненужными функциями и абсолютно неоптимизированный venividi.ru сейчас спокойно держит 1800-1900 при 6.500 тысяч просмотра страниц. И тормозов даже близко не видно.
«где это видано, чтобы html отдавался из функции»
дак это, вы из каждого модуля можете так же отдавать переменные, и не писать код внутри. Переменные прочитаются в шаблоне модудя .tpl.php
«К сожалению TinyMCE пришлось ещё и оставить потому, что модуль для вставки картинок, который умеет их ресайзить (Imagepicker) работает только с ним.»
в своем случае (venividi.ru я прикрутил FancyUpload, делается несложно.
«В случае самого страшного и огромного файла это 3000 строчек кода. Возможно ли читать и/или управлять таким кодом?»
Дак выносите функции в inc файлы, вот пример:
$items['admin/build/menu'] = array(
'title' => 'Menus',
'description' => «Control your site's navigation menu, primary links and secondary links. as well as rename and reorganize menu items.»,
'page callback' => 'menu_overview_page',
'access callback' => 'user_access',
'access arguments' => array('administer menu'),
'file' => 'menu.admin.inc',
И второе — кто мешает использовать обычные пхпшные функции для подгрузки внешних php если вам неужобно все в одном файле.
В общем — если и переходить с Друпала на что-то, то это уже на Zend или начинать понемногу все писать под себя с нуля.
ну ну, перегруженный всякими ненужными функциями и абсолютно неоптимизированный venividi.ru сейчас спокойно держит 1800-1900 при 6.500 тысяч просмотра страниц. И тормозов даже близко не видно.
«где это видано, чтобы html отдавался из функции»
дак это, вы из каждого модуля можете так же отдавать переменные, и не писать код внутри. Переменные прочитаются в шаблоне модудя .tpl.php
«К сожалению TinyMCE пришлось ещё и оставить потому, что модуль для вставки картинок, который умеет их ресайзить (Imagepicker) работает только с ним.»
в своем случае (venividi.ru я прикрутил FancyUpload, делается несложно.
«В случае самого страшного и огромного файла это 3000 строчек кода. Возможно ли читать и/или управлять таким кодом?»
Дак выносите функции в inc файлы, вот пример:
$items['admin/build/menu'] = array(
'title' => 'Menus',
'description' => «Control your site's navigation menu, primary links and secondary links. as well as rename and reorganize menu items.»,
'page callback' => 'menu_overview_page',
'access callback' => 'user_access',
'access arguments' => array('administer menu'),
'file' => 'menu.admin.inc',
И второе — кто мешает использовать обычные пхпшные функции для подгрузки внешних php если вам неужобно все в одном файле.
В общем — если и переходить с Друпала на что-то, то это уже на Zend или начинать понемногу все писать под себя с нуля.
В общем я перешёл на Symfony.
Надеюсь через год не появится статья — что Symfony это г.
А в общем и целом я согласен с автором, особенно в плане изучения Друпала. На РИТ слушал доклад про друпал — на выделенном сервере держал 7000 пользователей в день. Серьезной нагрузкой назвать это сложно. По словам автора доклада на РИТ иногда для построения страницы надо было по 200 запросов к базе.
В общем — пока нагрузка небольшая и руки готовы с напильником по коду ходить — велком.
А в общем и целом я согласен с автором, особенно в плане изучения Друпала. На РИТ слушал доклад про друпал — на выделенном сервере держал 7000 пользователей в день. Серьезной нагрузкой назвать это сложно. По словам автора доклада на РИТ иногда для построения страницы надо было по 200 запросов к базе.
В общем — пока нагрузка небольшая и руки готовы с напильником по коду ходить — велком.
ИМХО
Нагруженные серверы все же лучше писать с нуля, так как в эт
Нагруженные серверы все же лучше писать с нуля, так как в эт
мне нравится что у вас рейтинг только плюс +!!! ;)
а сайт если честно тормозной, вам бы webo.in подружится
а сайт если честно тормозной, вам бы webo.in подружится
мне понравилось, что доктайп strict drupal ставит.
То, что нет ООП это плохо? Друпал тем и хорош, что в нем нет закрученного ООП с дикой иерархией классов. Все просто и понятно — на каждое действие хук. Проблема с базой данных решается очень просто — патчем функции локализации на использование gettext. Devel вообще много с кем конфликтует — это проблема девела а не друпала.
А что до symfony, то это фрэймворк, а не CMF.
А что до symfony, то это фрэймворк, а не CMF.
И вам повторю: пример приведён для того чтобы показать как надо было делать именно в части кэширования и настроек в принципе. Я не сравниваю Drupal и Symfony ни в коем случае
А чем вам так не нравится ООП?
Ну проблемма с базой нерешается переделкой локализации.
Согласитесь, drudal way это нечто вроде
1. выбрать все nid для отображения
2. для каждого из nid вызвать node_load
Приэтом node_load это как мнимум 3 запроса из самого node.module, ну а дельше все зависит от того сколько nodeapi навешено. При большом количестве модулей количество запросов получается просто невменяемое.
Согласитесь, drudal way это нечто вроде
1. выбрать все nid для отображения
2. для каждого из nid вызвать node_load
Приэтом node_load это как мнимум 3 запроса из самого node.module, ну а дельше все зависит от того сколько nodeapi навешено. При большом количестве модулей количество запросов получается просто невменяемое.
А что, с ООП и ORM как то иначе получается? :)
Что до кол-ва запросов друпала, то вами описанные выборки в 90% случаях производятся по ключам и не грузят базу. Базу грузят локализации и кэш, т.к. там идут выборки по строковым значениям. Вы промеряйте «тяжелость запросов» хотя бы тем-же devel-ом и все увидите.
Что до кол-ва запросов друпала, то вами описанные выборки в 90% случаях производятся по ключам и не грузят базу. Базу грузят локализации и кэш, т.к. там идут выборки по строковым значениям. Вы промеряйте «тяжелость запросов» хотя бы тем-же devel-ом и все увидите.
CMF == Content Management Framework?
Или я в чём-то ошибаюсь?
Или я в чём-то ошибаюсь?
Самые лучшие CMS — построенные поверх фреймворков.
А какие, например?
Я знаю только ожидаемую в скором времени ExpressionEngine 2.0, которую поверх Code Igniter строят…
Я знаю только ожидаемую в скором времени ExpressionEngine 2.0, которую поверх Code Igniter строят…
Ещё MaxSite. Тоже на КодеПоджигателе стоит :). Сравнивать, конечно, с Друпалом не уместно, проекты разных масштабов.
«К сожалению TinyMCE пришлось ещё и оставить потому, что модуль для вставки картинок, который умеет их ресайзить (Imagepicker) работает только с ним.»
— Вот читаю я статью, вроде и умно так написано, но вот этой строчкой увы — вы убили последнюю надежду на то что вы действительно хоть немного программер… ну ни как эта строчка не вяжется с вашим высказыванием:
«Будучи разработчиком, который любит творить»
Простите меня грешного, но ресайз картинок на голом php пишется не более 10 минут, со всеми там пропорциями кропом и т.д.
— Вот читаю я статью, вроде и умно так написано, но вот этой строчкой увы — вы убили последнюю надежду на то что вы действительно хоть немного программер… ну ни как эта строчка не вяжется с вашим высказыванием:
«Будучи разработчиком, который любит творить»
Простите меня грешного, но ресайз картинок на голом php пишется не более 10 минут, со всеми там пропорциями кропом и т.д.
Скажите, Вы писали под Друпал?
Да, пишется за десять минут. А потом приходится проводить многие часы, занимаясь интеграцией этого кусочка кода с другими модулями (в примере — с модулем для той же TinyMCE), и отхватывая различные грабли.
И личного опыта говорю — может, у кого-то он другой. :)
Да, пишется за десять минут. А потом приходится проводить многие часы, занимаясь интеграцией этого кусочка кода с другими модулями (в примере — с модулем для той же TinyMCE), и отхватывая различные грабли.
И личного опыта говорю — может, у кого-то он другой. :)
Это я к тому, что в итоге проще уж воспользоваться сторонним модулем, что большинство и делает…
А какой интеграции c модулями вы говорите если ключевое слово тут ТОЛЬКО?
«который умеет их ресайзить (Imagepicker) работает только с ним»
Я уже давно отошел от работы с CMS-ками… но не верю я что человек знающий php и понимающий что он пишет тратит 5 часов на интеграцию какого то модуля…
«который умеет их ресайзить (Imagepicker) работает только с ним»
Я уже давно отошел от работы с CMS-ками… но не верю я что человек знающий php и понимающий что он пишет тратит 5 часов на интеграцию какого то модуля…
Никак не за 10 минут, так как ресайз картинок это не только серверная сторона а еще как правило JS интерфейс, к тому же есть частные случаи вроде работы с bmp.
JS то тут каким боком? Ресайз — это только серверная сторона… об интерфейсе тут ни кто не говорил…
А ну да, какой-то абстрактный ресайз с абстрактными параметрами может и пишется 10 мин.
Мне даже стало интересно какой же такой вам особенный модуль резайза нужен?
Да в самом навороченом классе ресайза по моему ну больше 10ти параметров ну ни как не придумаешь.
Все чего мне хватает это указание в параметрах:
$max_width
$max_height
$use_crop
$use_ratio
$take_thumb
Неужели так сложно написать PHP скрипт для этого? Вы пробовали писать? Не тупо копировать код с туторов — а самому сесть и написать? Использование GD делает нашу жизнь очень простой… а Imageshack еще проще
Да в самом навороченом классе ресайза по моему ну больше 10ти параметров ну ни как не придумаешь.
Все чего мне хватает это указание в параметрах:
$max_width
$max_height
$use_crop
$use_ratio
$take_thumb
Неужели так сложно написать PHP скрипт для этого? Вы пробовали писать? Не тупо копировать код с туторов — а самому сесть и написать? Использование GD делает нашу жизнь очень простой… а Imageshack еще проще
У меня очень много сайтов на базе Друпал с кучей написанных под себя модулей. Шаред хостинг держит до 5-6 тысяч уников в день. Выделенный держал 20 тысяч идальшеб мог, если бы рос.
Касательно ООП, а чего вы к нему прицпепились то все? ООП не более чем удобная организация функций и данных, в Друпал это реализуется общими правилами создания функций, к примеру, если модуль называется simpleone, то все функции в нем начинаются на simpleone_, например simpleone_test(), simpleone_image() и т.д. Что тут неудобного то?
По поводу разбивки файлов правильно написал Cher, в больших модулях правильная практика разбивать куски на мелкие файлы и именно так и делается.
Запросы к базе. Да тут их много, бывает часто даже лишних. Основная проблема — SEO url path, хотя они проблема в любой CMS, в той же джумле это вообще кошмар, и не факт, что вы реализуете лучше на Симфонии или ещё где.
Шаблоны. По моему удобнее PHPTemplate нет ничего. Если у Вас трудности кастомизировать что-либо спросите меня, объясню принцип.
Кэширование. Написали, что дикое кэширование, новые функции не всегда сразу работают. По всей видимости вы говорите о том, что привязывается к путям и пунктам меню. Такое положение вещей не чисткой кэга решается, а ребилдом страницы модулей. Заходите в модули и жмете сохранить. Всё, теперь будет работать. Обусловлено это тем, что все модули заносят свои пути и функции которые по ним вызываются в некий меню-кэш, очень удобно.
Логика разработки и прочее. Я уважаю отечественного программиста, который радует за свое, флаг вам в руки, если вы сделаете кмс в одиночку лучше чем огроное коммьюнити черепов-программеров со всего мира, которые уже сколько лет вылизывают готовое решение. Друпал отличная база для своих разработок.
Вобщем тут как всегда, одни изобретают велосипеды, ставят им костыли и нервно минусуют, другие берут от open source все, настраивают, доделывают под себя и рубят бабло.
Удачи.
Касательно ООП, а чего вы к нему прицпепились то все? ООП не более чем удобная организация функций и данных, в Друпал это реализуется общими правилами создания функций, к примеру, если модуль называется simpleone, то все функции в нем начинаются на simpleone_, например simpleone_test(), simpleone_image() и т.д. Что тут неудобного то?
По поводу разбивки файлов правильно написал Cher, в больших модулях правильная практика разбивать куски на мелкие файлы и именно так и делается.
Запросы к базе. Да тут их много, бывает часто даже лишних. Основная проблема — SEO url path, хотя они проблема в любой CMS, в той же джумле это вообще кошмар, и не факт, что вы реализуете лучше на Симфонии или ещё где.
Шаблоны. По моему удобнее PHPTemplate нет ничего. Если у Вас трудности кастомизировать что-либо спросите меня, объясню принцип.
Кэширование. Написали, что дикое кэширование, новые функции не всегда сразу работают. По всей видимости вы говорите о том, что привязывается к путям и пунктам меню. Такое положение вещей не чисткой кэга решается, а ребилдом страницы модулей. Заходите в модули и жмете сохранить. Всё, теперь будет работать. Обусловлено это тем, что все модули заносят свои пути и функции которые по ним вызываются в некий меню-кэш, очень удобно.
Логика разработки и прочее. Я уважаю отечественного программиста, который радует за свое, флаг вам в руки, если вы сделаете кмс в одиночку лучше чем огроное коммьюнити черепов-программеров со всего мира, которые уже сколько лет вылизывают готовое решение. Друпал отличная база для своих разработок.
Вобщем тут как всегда, одни изобретают велосипеды, ставят им костыли и нервно минусуют, другие берут от open source все, настраивают, доделывают под себя и рубят бабло.
Удачи.
например simpleone_test(), simpleone_image() и т.д. Что тут неудобного то?
— Ну я думаю так как минимум красивее :)
$simpleone->test();
:)
— Ну я думаю так как минимум красивее :)
$simpleone->test();
:)
А что могут пользователи на ваших сайтах? Поподробнее здесь пожалуйста. Если они просто заходят и смотрят странички, то тут понятно что будет держать.
По поводу шаблонов: как изменить выводимый html функции drupal_get_form?
По поводу шаблонов: как изменить выводимый html функции drupal_get_form?
могут: регистрироваться, аккаунты, закладки, комментарии, добавление контента. Впринципе стандартный набор. Ну социальную сеть на шареде вы не развернете естественно.
Если форма стандартная друпаловская (ну или любая своя), то через:
function hook_form_alter(&$form, $form_state, $form_id) {
if ($form['#id'] == 'id формы') {
тут переопределяем, добавляем поля.
}
}
вместо hook подставляем название модуля или пишем прямо в template.php если модуля нет, а нужно просто быстро изменить/подправить. В книжке Drupal Pro Development которую Вы читали подобное описано, плюс drupal.org/handbooks Вам в помощь там многое разжевано, плюс lullabot.com — сайт создателей Drupal, там много типсов в регулярных подкастах и видеокастах.
Если форма стандартная друпаловская (ну или любая своя), то через:
function hook_form_alter(&$form, $form_state, $form_id) {
if ($form['#id'] == 'id формы') {
тут переопределяем, добавляем поля.
}
}
вместо hook подставляем название модуля или пишем прямо в template.php если модуля нет, а нужно просто быстро изменить/подправить. В книжке Drupal Pro Development которую Вы читали подобное описано, плюс drupal.org/handbooks Вам в помощь там многое разжевано, плюс lullabot.com — сайт создателей Drupal, там много типсов в регулярных подкастах и видеокастах.
Оценить хороший коммент — это не только плюсонуть, но и добавить его в избранное! :) (+ от меня как только наберу заряду для голосования)
OOP это не только методы (в вашей терминологии функции)
это ещё и свойства, это ещё и 3 парадигмы: наследование, инкапсуляция, полиморфизм.
начнём со свойств: как в случае замены полноценного ООП функциями ваши функции обмениваются данными?
далее парадигмы: как отнаследовать «класс» в вашем случае и изменить поведение одного из методов (функций)?
в случае с ОО-кодом, когда можно передать объект, который будет отображать какую-либо сущность предметной области — как вы будете это же осуществлять?
это ещё и свойства, это ещё и 3 парадигмы: наследование, инкапсуляция, полиморфизм.
начнём со свойств: как в случае замены полноценного ООП функциями ваши функции обмениваются данными?
далее парадигмы: как отнаследовать «класс» в вашем случае и изменить поведение одного из методов (функций)?
в случае с ОО-кодом, когда можно передать объект, который будет отображать какую-либо сущность предметной области — как вы будете это же осуществлять?
Цель любой программы или скрипта — это не наследовать классы и передавать объекты, а производить некий полезный функционал. Например, отображать страничку веб-сайта.
Так вот этот функционал совершенно точно реализуется как в ООП-варианте, так и без ООП вообще. Другой вопрос, что использование ООП может некоторые задачи реализовать проще и нагляднее. Но если жизнь загонит программиста в угол, то он сможет решить любую прикладную задачу без какого либо ООП в принципе.
Так вот этот функционал совершенно точно реализуется как в ООП-варианте, так и без ООП вообще. Другой вопрос, что использование ООП может некоторые задачи реализовать проще и нагляднее. Но если жизнь загонит программиста в угол, то он сможет решить любую прикладную задачу без какого либо ООП в принципе.
А мне в друпале очень нравится наличие xmlrpc, мне это позволяет быстро развертывать бизнес приложения. Уже 2ое приложение для клиентов пишу на базе Drupal xmlrpc + xml-rpc.net. Очень доволен как получается :)
НЛО прилетело и опубликовало эту надпись здесь
Ну тысяча посетителей в день — это не предел для VPS и круче, а для виртуального хостинга — да, согласен.
Про то, что весь код модуля в одном файле — можно во время разработки юзать инклуды, да, костыль, но работает.
ООП — штука хорошая, но не единственная, имеющая право на существование. Мне кажется наиболее читаемым процедурный подход. Ну это предпочтения уже…
Про то, что весь код модуля в одном файле — можно во время разработки юзать инклуды, да, костыль, но работает.
ООП — штука хорошая, но не единственная, имеющая право на существование. Мне кажется наиболее читаемым процедурный подход. Ну это предпочтения уже…
Тоже чтоли написать «Почему я не люблю Oracle»… Я рассмотрел уже 5 обложек книг по ораклу
Про кеш я прочитал в первой книге, которая мне попалась по друпал (автор выше ответил на эту тему, я бы лучше не смог).
Темизация очень удобна, на мой взгляд. Не понимаю вашей реакции…
Посмотрите структуру какого-нибудь развитого модуля для друпал (CCK, Views, ...). Вы увидите нечто большее там, нежели указанные вами 3 файла.
Темизация очень удобна, на мой взгляд. Не понимаю вашей реакции…
Посмотрите структуру какого-нибудь развитого модуля для друпал (CCK, Views, ...). Вы увидите нечто большее там, нежели указанные вами 3 файла.
Почему я не люблю дифуры?
— Сложны в изучении
— Высокая нагрузка на мозг
— Сложны в изучении
— Высокая нагрузка на мозг
Я с Друпалом работал с версии 3.2, если мне память не изменяет… Изначальная концепция мне очень нравилась: ноды, таксономия, грамотная работа с RSS-каналами, все просто, прозрачно и изящно (unixway в чистом виде)… по тем временам просто супер. Чего не хватало — дописывалось без проблем…
Но к моменту выхода 6-й версии Друпал сильно растолстел и оброс всякими приблудинами и рюшечками, которые вроде дают нужный функционал, и ты сначала радуешься, что что-то не прийдется писать с нуля, но на этапе конфигурирования модулей начинается череда граблей, которая может растягивать проект на недели. И всех граблей запомнить невозможно, потому что они постоянно меняются, перемещаеются и т.п. — Drupal-то очень бурно развивается, один раз на один и тот же баг не наткнешься. Каждый раз как новичок себя чувствуешь, и, честно говоря, в какой-то момент меня это достало… я зарекся им пользоваться…
Но к моменту выхода 6-й версии Друпал сильно растолстел и оброс всякими приблудинами и рюшечками, которые вроде дают нужный функционал, и ты сначала радуешься, что что-то не прийдется писать с нуля, но на этапе конфигурирования модулей начинается череда граблей, которая может растягивать проект на недели. И всех граблей запомнить невозможно, потому что они постоянно меняются, перемещаеются и т.п. — Drupal-то очень бурно развивается, один раз на один и тот же баг не наткнешься. Каждый раз как новичок себя чувствуешь, и, честно говоря, в какой-то момент меня это достало… я зарекся им пользоваться…
сложность изучения по моему вообще не является критерием качества cms/cmf. для того, чтобы делать сложные вещи, надо много учиться и много знать. это факт.
К вопросу о генерации html модулями: есть еще Overriding themable output.
Знаю несколько ресурсов на Друпал с 14-15к суточного трафика. И работой до 30-40 человек онлайн одновременно. Но, правда, друпал не для нубов в PHP.
НЛО прилетело и опубликовало эту надпись здесь
Прочитал очень внимательно, ибо у меня у самого множество претензий к друалу.
Из всего прочитанного сделал один вывод — все проблемы автора исключительно от отсутствия опыта разработки на друпале.
Друпал позволяет в оень короткие сроки поднять сайт с приличным набором функционала, а когда проект будет запущен уже заниматься оптимизацией. Высокую нагрузку с БД в плане кэша позволяет снять использование memcached — переезд осуществлеяется в течение 3 минут. Большой объем .module файлов в 6 друпале отлично решается выносом тем и коллбэков меню в отдельные файлы встроенными средствами друпала, в Д5 отсутствие встроенных средств так же особо не машало этим заниматься — главное захотеть.
По поводу ООПа — достаточно посмотреть тесты прироста производительности ООПной системы хупс и функционального друпала чтобы понять одну из причин news.php.net/php.internals/36484
Из всего прочитанного сделал один вывод — все проблемы автора исключительно от отсутствия опыта разработки на друпале.
Друпал позволяет в оень короткие сроки поднять сайт с приличным набором функционала, а когда проект будет запущен уже заниматься оптимизацией. Высокую нагрузку с БД в плане кэша позволяет снять использование memcached — переезд осуществлеяется в течение 3 минут. Большой объем .module файлов в 6 друпале отлично решается выносом тем и коллбэков меню в отдельные файлы встроенными средствами друпала, в Д5 отсутствие встроенных средств так же особо не машало этим заниматься — главное захотеть.
По поводу ООПа — достаточно посмотреть тесты прироста производительности ООПной системы хупс и функционального друпала чтобы понять одну из причин news.php.net/php.internals/36484
Это не простой темизатор вывода текста, Drupal — среда разработки. C++, Delphi в больших проектах в файле может быть и более 30 000 строк кода, просто всё зависит от удобства и желания разбивать файл на куски. Поработайте в больших проектах, почитайте книг и Вы поймёте что Drupal — это больше фреймворк чем CMS, что в больших проектах удобней.
Сам никогда с Drupal`ом не работал, но по просьбе друга, имеющего определенный опыт работы, публикую его «скромный» комментарий
Если не против, то я буду комментировать текст автора…. Потому что со многим, а практически со всем не согласен…
«Прошло три месяца с того момента, как я начал изучать Drupal.»
На этом месте я понял, что мне линк кинули зря, и что я только разозлюсь еще одним дилетантским выпадом, по поводу того «ой, ноготок сломался….»
«В процессе изучения я прочитал книги
1. «Building Powerful and Robust Applications with Drupal 6»,
2. «Learning Drupal 6 module development» и
3. «Pro Drupal Development. 2nd Edition»,
также во время пользования
4. часто приходилось обращаться к документации Drupal'а и его API.»
Пробежимся по пунктам….
«1. Building Powerful and Robust Applications with Drupal 6»
Хм… Информация о книженции:
Language English
Paperback 362 pages [191mm x 235mm]
Release date April 2008
ISBN 1847192971
ISBN 13 978-1-847192-97-4
Author(s) David Mercer
Другая книженция:
«2. Learning Drupal 6 module development»
Language English
Paperback 310 pages [191mm x 235mm]
Release date May 2008
ISBN 1847194443
ISBN 13 978-1-847194-44-2
Author(s) Matt Butcher
«3. Pro Drupal Development. 2nd Edition»
Paperback: 704 pages
Publisher: Apress; 2 edition (August 20, 2008)
Language: English
ISBN-10: 1430209895
ISBN-13: 978-1430209898
Того получается, что автор за три месяца прочел порядка 1300 страниц (но это не так, так как автор отметил, что он так и не дочитал…, но все равно посчитаем), полностью в них вник и разобрался, с учетом того что книги на англ – то это дается легко только при профессиональном английском…. Далее, что хочется отметить… даже если разделить 1300 страниц на 90 дней – получается, что в день он прочитывал по 14 страниц…. Ладно, посмотрим на вещи более серьезно. Треть нашей жизни мы спим – значит на изучение ушло 2 месяца. Получается что в день у него по 21 странице. Вычтем время на универ, еду, девушку (если таковая имеется), на личные увлечения, на ту же самую хабру – получается – месяц. Получается в день по 40 страниц… Ну беря во внимание, что кроме чтения – у него еще и эксперименты есть – то пол месяца -, даже треть на прочтение отводится… то есть в день он читал по 130 страниц… Честно говоря – как то невнимательно…. Особенно, если изучаешь что-то.
Потом, мы не учитывали чтение документации по само друпалу и АПИ…. Ну и бо с ними, оставим. Только констатируем факт, что АВТОР НЕ В ТЕМЕ. И опустим этот раздел. Временно….
«Где-то в конце сентября я прочитал лекцию «Drupal» на веб-семинаре в родном университете, где рассказал о том, что такое Drupal, что он может и что я уже научился в нём делать.»
Если учесть, что автор три месяца изучает друпал, то это начала сентября – середина декабря… Получается что у него доклад низкопрофильный был, так что хвастаться этим не надо было.
«Во-многих источниках я натыкался на фразы и диаграммы, суть которых сводилась к тому, что вот ещё чуть-чуть и Drupal станет ну просто идеальным средством для разработки… Не дождался, задолбало!»
Мда, долго же он ждал…. Гребанных 3 месяца, которые еще и не понятно чем занимался…. Вот у меня вопрс – а вы привыкли к готовым решениям? Так почему же возмущаетесь по поводу друпала? Друпал – это НЕ готовое решение. Это я отмечу позже.
«Уже когда я читал доклад на семинаре, я выделил пару проблем Drupal'а, о которых пишут и говорят многие, это: сложность изучения и высокая нагрузка на базу данных. На моём докладе присутствовал человек, который уже успел до этого с ним повозиться около года и невзлюбить очень сильно. Он сказал, что нагрузка на базу данных чуть ли не самый худший параметр Drupal'а, в котором он проигрывает практически всем. А все красивые числа о большом количестве пользователей преувеличены, реально же Drupal может держать не более 1000 посетителей в день. На моё замечание по поводу drupal.org он лишь посмеялся, сказав, что в drupal.org уже столько патчей напичкано, что от drupal'а в нём только название то и осталось.»
Нагрузка на базу… Так так так. Давайте разберемся. Вследствие чего эта нагрузка производилась, автор не отметил. То ли это ядро друпала, толи кривые модули, толи его модули, толи, что… не понятно… цифры собственно считать нет смысла, ибо опять же, обоснования им нет. Поэтому эту часть также опускаем в связи с низким профессионализмом автора. К тому же… Где данные тестирования и тп???? И вы на слово вот так верите? А если я напишу, что вчера летал на луну, вы мне тоже поверите????
«Но мне предстояло закончить проект на Drupal'е и поэтому пришлось продолжить трепыхания.»
По моемы, автор тогда только раскачивался…. А трепыхания были внутри…типа:
«отчего же я такой уродился
Что понять ничерта не могу
Ой ну как же я разозлился
А ну все нафиг, пойду пива попью»
« По мере углубления я стал замечать, что проблем в Drupal'е гораздо больше, чем мне казалось тогда, когда я делал доклад. Первой и самой порой выводящей из колеи стал Drupal'овский кэш. Я так и не понял как он работает.»
А он даже и не пытался понять. Ибо если пытался – то нашел бы пункт в документации….
«К примеру, я изменяю функцию в модуле, и она может выполниться, а может и не выполниться. Это всё при том, что все доступные из админского интерфейса настройки кэша были выключены.»
А ВОТ ТУТ АВТОР ОЧЕНЬ СЛЬНО ПРИВИРАЕТ
«Ещё хуже ситуация обстоит с добавлением и удалением функций в модуль. Если при добавлении ещё иногда достаточно просто обновить «любимый» кэш, то вот при удалении какой-нибудь функции порой выскакивает fatal error. Лечить его получается далеко не всегда, а зачастую приходится уже ручками удалять все данные кэша из базы данных.»
Сразу напросился вопрос. А как автор все проделывал. Как НАДО или как душе угодно было. Мне кажется второе тут…. Вообще, меня очень забавляет такой подход… это типа при написании кода на, допустим, пхп…… написать «а ну-ка выведи мне слово «привет»», и удивиться, а почему это пхп ругается. И палку я не перегнул. Если что-то делаете, а тем более на подобных системах – будьте делать все по правилам. Все-таки когда кто либо пишет свои решения, то он не плюется на то, какие стандарты есть, он просто им подчиняется. А то, что автор этого не делает – он тут и доказал… Собственно читаем дальше и наслаждаемся сказкой на ночь….
«Забегая вперёд скажу, что в Симфони, который я сейчас изучаю, этой проблемы не существует. В нём есть Environment'ы (по-русски наверное это будет «окружения», но возможно официально переводится не так, поправьте, если что!), грубо говоря каждое окружение — это определённая конфигурация сайта. По-умолчанию, имеются окружения dev и prod (есть ещё и test, если что) соответственно development и production (т.е окружения для разработки и при релизе). В dev'е почти все кэширования отключены, и не нужно лишний раз рвать на себе волосы, пытаясь угадать что произошло: синтаксическая ошибка или кэш не обновился.»
А не надо себе рвать волосы… Надо просто знать что делаешь, за чем автор не следил. Опять же – низкий профессионализм. Сразу вспоминается такая ситуация: 2 мальчика сидят и делают себе рогатки…. Тут один смотрит как его сосед делает, а сосед смотрит как другой… и начинается… сначала не получается, потом выяснение отношений…. А нет бы самому все сделать…. Не поняли к чему это я? Закройте страницу и выброситесь с балкона. А если нет балкона – броситесь под машину… одним дебилом меньше станет…
«Отступление, имеющее место: Вообще, наверное, ни сказанное выше, ни сказанное ниже не может быть единственно верной истиной. Негатив с Drupal'ом в моём случае связан ещё и с некоторыми сопутствовавшими его изучению факторами: я стал изучать Drupal 6, по которому в настоящий момент написано мало книг, а часть документации пишется исходя из того, что ты уже знаком с Drupal 5; я не доизучал книги до конца, т.к. внезапно навалился проект, и стало не до углубленного ковыряния.»
Ага…. То есть это он прочитал введение, и закрыл, мол и так разберусь….))))) Ну удачи)))) Удачи)))
«Вторая проблема Drupal'а — это кастомизация шаблонов. Мне она представлялась такой: даётся набор переменных, которые нужно вставить в соответствующие места в вёрстке. Но это оказалось не совсем так.»
Еще бы)) Вы же не дочитали документацию… А это рассматривается там практически с самого начала….
«Во-первых, каждый модуль Drupal'а умеет и отдаёт свой html код, который зачастую меня не устраивает. Несмотря на то, что в Drupal'е есть так называемые функции темизации (т.е возможности перегрузки стандартного вывода), не всегда так просто докопаться до них, потому что во-вторых, иногда к моменту запуска конечной функции (т.е функции, которая отдаёт содержимое) часть html'а уже сидит в переменных. Ну и в-третьих, где это видано, чтобы html отдавался из функции? В итоге получается абсолютно нечитабельный код.»
Правда? Вы серьезно??????
«Отдельное слово стоит сказать о модулях в Drupal. У стандартного модуля структура такая:
module_name.info (тут хранится инфа о модуле)
module_name.install (тут хранится инфа как ставить модуль)
module_name.module (тут хранится код модуля; ВЕСЬ!)»
По поводу последнего….
Там хранится основной код. А вот то что второстепенное – умными людьми выносится отдельно…. Да и как же тогда, если все в одном файле, производить интеграцию с другими модулями? Батенька, да вы не задумывались….
«Размер файла module_name.module колеблется в диапазоне от 1 до 109 (в моём случае) килобайт. В случае самого страшного и огромного файла это 3000 строчек кода. Возможно ли читать и/или управлять таким кодом? И такая структура принята стандартом для данной CMF'ки.»
Возможно…. Вполне возможно.
«Это лишь начало тех проблем, которые подстерегали меня на пути работы с Drupal'ом. Следующей проблемой стала несовместимость модулей. Понятно, что ожидать совместимости от модулей, которые написаны пионерами и нерекомендованы сообществом не стоит. Но я ставил вполне отработавшие и зарекомендовавшие себя модули:
Devel — набор полезностей для разработчиков (Devel от Development), в частности внедряет в менюшку кнопку очистки кэша (см. выше зачем это нужно)
FCKeditor — WYSIWYG редактор
TinyMCE — ещё один WYSIWYG редактор, зачем мне их два читайте ниже
Localization Client — удобный Ajax-клиент для локализации интерфейса, т.к нормального перевода на русский у Drupal'а нет
Ubercart — интернет-магазин»
На этой части остановлюсь отдельно…. Вообще – Друпал – это как бы не готовое решение. Друпал + модули – это уже не друпал =) Это его модификация) Да да да. И не надо мне вопить, про то, что если машине глушак прикрутить другой – то это машиной и остается… Это типа если к концу шланга прикрепить такую бакланку с дырками, под напором из которой вода будет течь струйками. Именно так. Большинство модулей – это решения, которые нацелены на решения определенных задач для определенных людей. НО НЕ ДЛЯ ВАС. Все модули кто-то сначала писал для себя, потом выложил и что то по поводу того, что кому то его решение не подойдет – его вообще не волновало. Если не подходит под вас – это ВАШИ проблемы и не надо пинать за это друпал. Не в вашей компетенции. Особенно после трех месяцев изучения и слов васи пупкина, который привык к готовым решениям и не хочет думать головой. Разработчики друпала дали безумно хороший АПИ, что собственно мне позволяет реализовать все что я захочу и которые не то чтобы ограничивают мои возможности, нет они наоборот, их не ограничивают, а меня растравливают написать самому что-нибудь еще…. Людей тысяци, тысячи задач и универсального для все — просто нет. Не устраивает – пишите сами… Ах да, вы же не смогли там документацию дочитать, что уж говорить про написание самому что-нибудь…. Мы вообще о чем тут?
И еще…. А вы искали перевод? Да и почему вы считаете, что вы – пуп земли, и что для вас отдельно должны переводить?
«Окончательно уйти от использования Drupal я решил познакомившись с Symfony. Будучи разработчиком, который любит творить, в Drupal'е большую часть времени я пытался закрутить болты велосипеда, чтобы у него крутилось третье колесо, а цепочка была из платины. Также мне очень не нравится, что несмотря на то, что версия 6 была выпущена в этом году в ней даже не пахнет ООП. Разработчики объясняют это очень просто, буквально говоря следующее:
«Да, в Drupal'е нет ООП, но многие его принципы были реализованы нами, и в принципе вы будете себя свободно чувствовать». Но разница всё-таки сильно ощутима. Иначе зачем нужно было бы пользоваться калькулятором, ведь счёты давно уже изобретены!»
А вот тут я вообще хотел набить морду этом автору только потому что он не разработчик, а полнейший дилетант, а при этом называет себя разработчиком. Во первых. Что ВЫ САМИ РАЗРАБОТАЛИ? А точнее на чем? ПХП – Вы его не разработали, вы его использовали…. Мускл – вы его не разработали, вы его использовали. Апач – вы его не разработали, вы его эксплуатировали… Хм… Друпал – вы опять же там ничего не разрабатывали и не пытались… Вы только попытались чужое решение прикрутить себе, при этом надеясь отверткой закрутить гвоздь. Не глупо ли вы смотритесь в этой ситуации? Кто мешал вам разрабатывать? Вот лично по себе скажу – я сейчас на заказ разрабытываю сайты на друпале… Друпал + jQuery + руки + мозги – получаются сайты, ктороые выдерживают по 700 – 1500 онлайн как раз плюнуть. Про то, сколько людей на сайты там заходит за сутки – я вообще молчу… Как это получается? Да легко! Использование аякса позволяет снять с друпала 70% его лишней работы для генерации статичных модулей, то есть блоков, которые достаточно одиныжды загрузить…. А вы об этом не знали? Да тогда что вы тут делаете? А то, что вы использовали чужие решения – это говорит только о том, что вы не творческая личность….
«Эта статья является личным мнением автора по поводу CMF Drupal, а также подытоживанием опыта работы с ним. Не пинайте, если кого обидел»
Я тебя те то, чтобы запинать, я тебя прирезать хочу, как и кучу подобных шакалов, которые нихрена не знают и лезут как затычка в каждую дырку. Молодой человек, скажите нам пожалуйста, а вы изучали, как можно кешировать данные, как апач крутится с друпалом. Как можно качественно использовать nginx наконец то… Как работает ядро, как работают алиасы… И тд и тп…
Мне вообще интересны были камменты выше… А вы бы написали сначало что сделали и как сделали…… Если уж мериться пиписьками – то у меня при 200 – 300 мелких модулей (широкая SN) друпал генерирует страницу в 70кб при переходе на другую страницу и скорость генерации – 0.0813 сек. Достигните того же самого…. А потом будем уже говорить о минусах друпала……
По поводу жумлы. Засуньте это г себе…. Да да да. Именно туда и засеньте, а потом еще 3 раза проврните и напишите мне о своих ощущениях….
«upd: Спасибо за плюсик в карму, чуть-чуть не хватало чтобы в блог Drupal перенести»
Промолчу….
Отдельное спасибо Tim_Andersson и Cher, так как они единственные на момент прочтения компетентные люди. Вот руку с удовольствием вам бы пожал….
Создайте топик.
Эмоций много у друга, но всё высказанное верно.
olegbl4, какой подход — такой и результат. Дочитайте книжки/документацию.
olegbl4, какой подход — такой и результат. Дочитайте книжки/документацию.
эмоционально, конечно, но дело говорит
Спасибо за хороший комментарий. Я вынужден оговориться, что статью начал писать в октябре и абзац не про «Прошло три месяца» не стал исправлять.
Что уж меряться пиписьками, я не отрицаю, что если сесть, зарыться по уши в учебники физики на год, то через год будешь хорошим физиком. Только вот время не стоит на месте, а движется неумолимо и приходится выбирать: копать или искать решение лучше, которое можно освоить быстрее.
Многое же из вами сказанного по поводу меня (прямые вопросы, угрозы и прочее) строится на догадках. Между тем, лучше бы не занимались херней, пытаясь рассчитать сколько страниц нужно читать в день и не придирались бы к мелочам. А чтобы было совсем не сладко: английский изучаю и знаю с 6 лет, учился в специализированной школе, к сожалению сейчас не имея практики подзабыл разговорный, но читаю на английском с такой же скоростью что и на русском. И в задницу летят ваши догадки и рассчёты!
А вообще мне очень нравится, что когда говоришь: эта штука не взлетит, то найдётся человек, который обязательно скажет обратное и будет рьяно это доказывать, но я то блин знаю, что она не взлетит… в моих руках не взлетит, потому что у меня руки одной нет и многим уже поотрубало, а лететь то надо! Флаг вам в руки, что вам нравится использовать Drupal, вам же больше достанется!
Что уж меряться пиписьками, я не отрицаю, что если сесть, зарыться по уши в учебники физики на год, то через год будешь хорошим физиком. Только вот время не стоит на месте, а движется неумолимо и приходится выбирать: копать или искать решение лучше, которое можно освоить быстрее.
Многое же из вами сказанного по поводу меня (прямые вопросы, угрозы и прочее) строится на догадках. Между тем, лучше бы не занимались херней, пытаясь рассчитать сколько страниц нужно читать в день и не придирались бы к мелочам. А чтобы было совсем не сладко: английский изучаю и знаю с 6 лет, учился в специализированной школе, к сожалению сейчас не имея практики подзабыл разговорный, но читаю на английском с такой же скоростью что и на русском. И в задницу летят ваши догадки и рассчёты!
А вообще мне очень нравится, что когда говоришь: эта штука не взлетит, то найдётся человек, который обязательно скажет обратное и будет рьяно это доказывать, но я то блин знаю, что она не взлетит… в моих руках не взлетит, потому что у меня руки одной нет и многим уже поотрубало, а лететь то надо! Флаг вам в руки, что вам нравится использовать Drupal, вам же больше достанется!
=)
Заранее извиняюсь за длинный пост – всем читать не обязательно (читать – по желанию), посвящено сугубо топикстартеру.
Olegbl4, Понимаете, перед тем, как что-либо сделать — подумайте. Показывая то. что вы не понимаете суть вопроса — вы только ударили в грязь лицом и впредь я лично буду на вас смотреть с другой стороны. Это как клеймо — раз заработали, и на всю жизнь. Ваши слова – как лепет первоклассника, разбившего цветок и пойманного классным руководителем. Ну не будем об этом.
Догадки. А вы нам ничего другого не позволили. Ничего не сказали, а потом еще вот так распинаетесь… По поводу лучше и быстрее – хм. Быстрее – значит проще? Проще – значит меньше? Меньше – значит менее функционально? А так как базовый функционал должен быть внедрен, иначе не привлечешь пользователей… Тогда тут 2 ситуации… Либо ущемлена пользовательская часть, чего допускать ни в коем случае нельзя, либо пробел в безопасности, что ни в коем случае нам не нужно… Так как пользователей ущемлять не собираются, то получается – будет пробел в безопасности. А это будущий геморрой… А оно мне надо? Получится в итоге, что я больше времени проведу изучая как это меня ломанули и как же надо извернуться, чтобы поднять систему обратно…тем более, если это не домашний блог, а сайт какой-нибудь компании, для которых по их требованию я делал сайт…. А это неустойки, удар по репутации…. Тем более, если все на лету, то система не рассчитана на сложную структуру и при росте могут появиться сильные сбои и непредсказуемые последствия, а это еще одна головная боль. То есть получается – хочешь геморроя – ищи простые решения. Не знаю… Как то так получается, что чем дольше живу, тем больше понимаю, что в жизни ничего простого не бывает, и что обязательно, если где-то все в медку, то в каком то месте закопалась ложка дегтя, которая обязательно проявится… И если вы этого не учли, то это ваши проблемы. А перед тем, как садиться программировать – советую не учить книжки по программированию сразу, а прочитать психологию программирования, а только потом уже учебники программирования читать… Поймете много приколов и допускаемых ошибок…
По поводу занятия херней – вообще то я показал вам ваш уровень доклада и хождение по поверхности, а вы вместо того, чтобы принять к сведению мою насмешку над вами – стали, извините, бычиться, и закрылись, пытаясь оправдаться…. Вы не попытались отстоять свою точку зрения – а собственно – вы отказались от своих слов и в итоге еще больше ударили в грязь своим лицом… Да, по поводу языков… Хм… я конечно понимаю, что люди разные бывают… но я вот в школе учил сначало несколько лет немецкий язык, потом, когда перевелся в другую школу – стал учить англ язык и в итоге – знаю 2 языка и свободно на них общаюсь и свободно читаю, и все равно, какой бы уровень английского у вас небыл – в документации, а особенно в такой литературе зачастую бывают авторские обороты, которые не всегда сходу корректно поймешь, и видно вы этого не знаете… значит все-таки я был прав… А то что вы щас оправдались – опять как то глупо выглядит. По поводу штуки – которая не взлетит – то когда слепо доказывают, да смешно, а когда доказывают обосновано, с фактами и это дело можно пощупать – то может стоит извиниться… Все таки необдуманно и дерзко написали… Мне то в принципе без разницы на то, что вы там не можете себя пересилить и что вы лентяй, но при этом гадить с высокой колокольни (да, да, вы свысока, почему-то, на людей смотрите)… А это уже необоснованно… Вообще – после дискуссии с несколькими людьми, мы пришли к выводу, что у топика название не «почему я не люблю друпал», а «очередное проявление моей лени и глупости»… и не надо предо мной оправдываться, мне на это пофигу, и не надо на меня наезжать – вы не правы. Надеюсь данный топик послужит многим уроком и, как сказал, VladimirVV, гонение за «хабраплюсами не совсем хорошо». Я могу ответить за каждое свое слово, а вы – нет, вы даже в ответ на мой выпад свои слова откатывать стали… что же вы за профессионал такой… Ведь у профа багги – это не багги, он не подгибает хвост и не скулит… он говорит, что это фичи и идет дальше с высоко поднятой головой до угла, потом быстро исправляет имеющуюся багу и потом говорит, что ту фичу, что все недавно видели, он немного модернизировал и она немного по другому себя ведет…. Разницу чувствуете?
Повторюсь еще раз – если говорите, что вам что-то не нравится – говорите, что вам не понравилась организация, а не говорите, что это минус системы. Вы – никто, и собственно никто не будет под вас программировать. Назвали себя разработчиком – разрабатывайте, а если не сделали систему лучше той, что имеется – не доказывайте, что она плоха только, потому что не подходит вашим запросам. Может быть просто вы плохи для данной системы?
Не отписался от своего лица – так как нет акк =) Так что извиняйте.
Спасибо за внимание, надеюсь друг друга поняли….
>>> если сесть, зарыться по уши в учебники физики на год,
>>> то через год будешь хорошим физиком.
Как физик скажу Вам сразу — года мало:) Некоторым мало и жизни.
Но по сути Вашего топика — Лично я достаточно давно присматриваюсь к Друпалу и мне понятны те проблемы которые Вы подняли. Он сложен для первого знакомства. Скажем так — нужно понять его общую методологию и тогда он становится прозрачней и предсказуемей. Понимание методологии Друпала приходит не сразу. Но логика в обработчиках-хуках железная. Не потому ли ядро Друпала содержит в 5 раз меньше кода чем например в той же Джумле? Именно «плотное» ядро — его основной плюс.
ООП — это вообще не является показателем качества продукта. ООП хорош, когда привязан к предметной области задачи. А предметная область web-портала вполне прозрачно реализуется не только средствами ООП. Вы не получите ни экономии кода, ни выигрыша в скорости исполнения.
Вот если Вы программируете проект на основе фреймворка — тогда ООП позволит Вам упростить решение.
Так что согласен по поводу «высокого входного барьера» Друпала, для новичка он действительно непривычен. Но кто говорил, что web-порталы насыщенные функциональностью должны клепаться за 5 минут? ;) Любой нагруженный проект требует активной мозговой деятельности.
>>> то через год будешь хорошим физиком.
Как физик скажу Вам сразу — года мало:) Некоторым мало и жизни.
Но по сути Вашего топика — Лично я достаточно давно присматриваюсь к Друпалу и мне понятны те проблемы которые Вы подняли. Он сложен для первого знакомства. Скажем так — нужно понять его общую методологию и тогда он становится прозрачней и предсказуемей. Понимание методологии Друпала приходит не сразу. Но логика в обработчиках-хуках железная. Не потому ли ядро Друпала содержит в 5 раз меньше кода чем например в той же Джумле? Именно «плотное» ядро — его основной плюс.
ООП — это вообще не является показателем качества продукта. ООП хорош, когда привязан к предметной области задачи. А предметная область web-портала вполне прозрачно реализуется не только средствами ООП. Вы не получите ни экономии кода, ни выигрыша в скорости исполнения.
Вот если Вы программируете проект на основе фреймворка — тогда ООП позволит Вам упростить решение.
Так что согласен по поводу «высокого входного барьера» Друпала, для новичка он действительно непривычен. Но кто говорил, что web-порталы насыщенные функциональностью должны клепаться за 5 минут? ;) Любой нагруженный проект требует активной мозговой деятельности.
Да ладно вам. Видели бы, как я с NetСat разбирался xD
Люди, дайте другу persei инвайт. А то я свой уже отдал.
сквозит некомпетентностью из текста, автор.
по-подробнее нужно тему изучать перед тем как давать комментарии по поводу Drupal в такой категоричной форме.
по-подробнее нужно тему изучать перед тем как давать комментарии по поводу Drupal в такой категоричной форме.
все CMS — отстой, Drupal — всего лишь меньший отстой, чем прочие. (с) не мой
Это классика, перефразированная автором и основателем Drupal: www.flickr.com/photos/pvasili/520349185/
НЛО прилетело и опубликовало эту надпись здесь
имхо, три месяца мало для изучения друпала
Топик-ответ:
habrahabr.ru/blogs/drupal/46899/
habrahabr.ru/blogs/drupal/46899/
Автор не изучал drupal 3 месяца а читал обзоры про него.
Ржал про макс 1000 уников — автору респект за «компетентность» в этом вопросе.
Верте этому человеку он гофорит прафду больше 1000 ни-ни.
a drupal.ru в >2000 а rb7.ru >4000 (и ещё 3 страницы печчатного текста сайтов с >2000 уникофф) это уже не drupal шоли?
Я за три месяца обучаю среднестатистическую домохозяйку делать сайты класса яху.
Если вы (автор) так блещите знанием ООП, то расскажите мне тупому ламеру где в в архитектуре i386 сказано про ооп.
А если не сказано мож тогда это «эмуляция удобного програмирования» не имеющая отнощения к качеству продукта.
В системе drupal есть очень много минусов но вы почему-то их не указали а указали какую-то чушь цитируя таких же професи-Аналов.
Видно что задача набрать «хабраплюсов» за псевдообъективный обзор.
Ржал про макс 1000 уников — автору респект за «компетентность» в этом вопросе.
Верте этому человеку он гофорит прафду больше 1000 ни-ни.
a drupal.ru в >2000 а rb7.ru >4000 (и ещё 3 страницы печчатного текста сайтов с >2000 уникофф) это уже не drupal шоли?
Я за три месяца обучаю среднестатистическую домохозяйку делать сайты класса яху.
Если вы (автор) так блещите знанием ООП, то расскажите мне тупому ламеру где в в архитектуре i386 сказано про ооп.
А если не сказано мож тогда это «эмуляция удобного програмирования» не имеющая отнощения к качеству продукта.
В системе drupal есть очень много минусов но вы почему-то их не указали а указали какую-то чушь цитируя таких же професи-Аналов.
Видно что задача набрать «хабраплюсов» за псевдообъективный обзор.
тот же самый опыт, ещё правда в древнем 2006 году… подняли сайт на joomla.
Сейчас мне ОЧЕНЬ нравится Mediawiki, даже не смотря на то, что она заточена под энциклопедию. Такого ровного кода я не видел ни в одной Open Source CMS.
Единственная проблема — очень мало скинов. Но разобрался за неделю, что к чему в скинах. Очень-очень удобная штука, поверьте мне. И нагрузку выдерживает нормально. 1000 хитов конечно нет ещё в день на том сайте… Да и не будет. Хостинг виртуальный на мастерхосте. Посмотрим как дальше будет.
Сейчас мне ОЧЕНЬ нравится Mediawiki, даже не смотря на то, что она заточена под энциклопедию. Такого ровного кода я не видел ни в одной Open Source CMS.
Единственная проблема — очень мало скинов. Но разобрался за неделю, что к чему в скинах. Очень-очень удобная штука, поверьте мне. И нагрузку выдерживает нормально. 1000 хитов конечно нет ещё в день на том сайте… Да и не будет. Хостинг виртуальный на мастерхосте. Посмотрим как дальше будет.
из всех фришных CMS ов друпал имеет наиболее продвинутую архитектуру БД, идея нод и их связей и расширений кажется мне идеальной для универсальной ЦМС, просто каша в бд вознкиает когда натягиваются внешние модули не входящие в ядро, но даже в этом случае все достаточно логично и нормально, нагрузки на бд вызваны гибким легко расширяемым функционалом, за универсальность нужно платить (производительностью), конечно узко заточенные системы куда лучше и быстрее справляются со своими задачами чем универсальные.
У меня наверное похожая ситуация с автором статьи. Изучал Drupal, делал небольшой сайт для организации. С одной стороны интересная система, с другой настолько своеобразная и запутанная, что тушите свет… Порой, чтобы сделать какие-то банальные вещи приходилось по полдня искать ответ в немногочисленных форумах и коммьюнити по этой безусловно замечательной, но чрезвычайно громоздкой CMF.
Однако, признаю, что я Drupal не осилил, я отказываюсь принять его логику построения сайта. Сделать работающий сайт со стандартными функциями на нем легко, но если хочется сделать что-то по своему, то без полнейшего понимания всей его сути там делать нечего!
Вот уже думаю переходить на какой-нибудь из фреймворков вроде Zend, CodeIgniter, Yii, Symphony… Какой из них выбрать бы…
Однако, признаю, что я Drupal не осилил, я отказываюсь принять его логику построения сайта. Сделать работающий сайт со стандартными функциями на нем легко, но если хочется сделать что-то по своему, то без полнейшего понимания всей его сути там делать нечего!
Вот уже думаю переходить на какой-нибудь из фреймворков вроде Zend, CodeIgniter, Yii, Symphony… Какой из них выбрать бы…
незнаю поднимаю щас проект с кучей функционала, без проблем все укладывается да вначале потратил около 3 дней на разбирания с модулем VIEW и системой шаблонов, сейчас все отлично система полностью поддается кастомизации, когда заказчик просит чтото сделать я сразу представляю куда и зачем нужно лезть и что менять чтоб получить результат очень логичная система просто нестандартная архитектура и функциональная реализация но это на самом деле такие мелочи…
Чушь!
Откуда столько плюсов у топика? (Нет, ну правда… )
Откуда столько плюсов у топика? (Нет, ну правда… )
человек не понявший друпал, читает лекции и делает выводы :)
Почему я не люблю Drupal — потому что меня заставляют работать на этой ужасной глючной системе.
поставил модуль Devel, дааа конечно количество запросов поражает: для главной это 280, для внутренней страницы 210 (после оптимизации для модуля Path), но вобщемто глядя на эти запросы сразу понятно как это все оптимизировать, около 40 запросов из модуля локаль, и около 40 кеш гетов от lookup path уже избавился их было около 90)
думаю что если заменить половину блоков на снипеты то можно будет свести все к 30-50 запросам, к томуже как я считаю снипеты более полезны нежели модули потому как модули с большим опозданием выходят для обновлений ядра а снипеты которые писались своими же руками легко обновляются. К томуже большая часть запросов это очень легкие запросы.
у меня возникло несколько вопросов к автору:
1) вы разрабатывали свои модули для друпала?
2) вы реализовывали свои хуки?
3) вы интегрировали опять же свои модули с views и cck?
4) вы создавали собственные типы нод?
если нет то тогда о чем речь в этом топике?
1) вы разрабатывали свои модули для друпала?
2) вы реализовывали свои хуки?
3) вы интегрировали опять же свои модули с views и cck?
4) вы создавали собственные типы нод?
если нет то тогда о чем речь в этом топике?
понимаю, каждый имеет право на свое мнение, но чем писать такой пост лучше описать конкретные проблемы на drupal.ru или drupal.org, уверен, и там и там помогут разобраться
У drupal'а есть одна главная поблемма. И это даже не проблемма самой CMS, а тех, кто его пытается использовать. Если вы собаираетесь реализовывать свой проект на drupla'е, вы должны изначально знать с чем вам прийдется работать и строить архитектуру исходя из этого. Иногдв двже прийдется сказать заказчмку «Это не drupal way. Если вы хотите именоо такой фьючер, давайте рассматривать реализацию. с нуля/на базе друггого движка».
И эти ограничения не есть зло — друпал и так универсален по максимуму. Просто нужно понимать, ели вы хоитте использовать готовый функционал, то будут и ограничения.
И эти ограничения не есть зло — друпал и так универсален по максимуму. Просто нужно понимать, ели вы хоитте использовать готовый функционал, то будут и ограничения.
Очень большой минус Drupal использование ВЕЗДЕ call_user_func.
Дебажить его просто невозможно.
Дебажить его просто невозможно.
Печально, когда некомпетентный человек пишет такие «статьи». Автор, что вы делали эти три месяца? Пиво пили или действительно читали перечисленные вами книги?
LOL, со статьи. Как вообще сей опус мог попасть на хабровщину? Даже на холивар средней руки не тянет :)
Поддержу solarwind, не только печально но и грустно читать «измышления» человека который очень поверхностно «знаком» с системой и не удосужился прочесть хотя бы основы(я не говорю о книгах, украденных на торрентах).
Как то уже даже не смешно, когда на фоне бренда Drupal пытаются рекламировать какую-то поделку — Симфонию :). Это как выдавать за Valentino китайский хирпотреб.
Ни одного довода или сколь либо заслуживающих тестов и сравнений. Все сведено к стилю: ткул в кнопку — не заработало как хочу — в топку…
Совет к автору: — прежде чем о чем то писать — попробуйте обратиться к специалистам, они помогут вам хотя бы с основами (такими как настроить FCKeditor). А то вы ругаете то, с чем в чём не разобрались даже с основами.
з.ы. могу пару ссылок дать где 3000 уников даже без включенного кеширования легко работает на обычном шаред хостинге…
Поддержу solarwind, не только печально но и грустно читать «измышления» человека который очень поверхностно «знаком» с системой и не удосужился прочесть хотя бы основы(я не говорю о книгах, украденных на торрентах).
Как то уже даже не смешно, когда на фоне бренда Drupal пытаются рекламировать какую-то поделку — Симфонию :). Это как выдавать за Valentino китайский хирпотреб.
Ни одного довода или сколь либо заслуживающих тестов и сравнений. Все сведено к стилю: ткул в кнопку — не заработало как хочу — в топку…
Совет к автору: — прежде чем о чем то писать — попробуйте обратиться к специалистам, они помогут вам хотя бы с основами (такими как настроить FCKeditor). А то вы ругаете то, с чем в чём не разобрались даже с основами.
з.ы. могу пару ссылок дать где 3000 уников даже без включенного кеширования легко работает на обычном шаред хостинге…
Ох как бы все матерились еслибы Хабр был сделан на друпале:))
про 1000 в сутки очень страно, у нас даже горемычный bitrix на 15 000 юникалов в сутки живет.
Вы просто не умеете его готовить или называете проблемами друпала, то что его проблемами не является. Был случай в моей практике когда человек кинулся на друпал, сделал сайт, взял под это дело vps, не самый слабый, у миндхоста за 1300р в месяц, в итоге главная страница грузилась полторы минуты. После чего было сказано: «Друпал — УГ!». Потом оказалось, что сервер был криво настроен. Друпал очень хорошая система, не без недостатков конечно, но половина проблем озвученных автором, явно относятся к кривым рукам
Спасибо. Возникло строгое ощущение, что меня только что спасли от отрубания головы.
Картина получилась ясная.
Drupal стОит того, чтобы за него побороться.
Я поставил себе цель освоить Drupal хотя бы на среднем уровне — и я это сделаю.
Drupal стОит того, чтобы за него побороться.
Я поставил себе цель освоить Drupal хотя бы на среднем уровне — и я это сделаю.
По итогам прочтения могу предложить изменить заголовок на «Почему я не люблю Drupal? — потому что я о нем ВООБЩЕ ничего не знаю». Все буквы ниже, можно смело удалять.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему я не люблю Drupal