Fast Drupal Distribution [что скажет сообщество?]
Привет всем!
Возникла идея создать стартап.
Главным слоганом будет "Друпал с человеческим лицом".
Сейчас объясню подробнее. Все ведь знают такую конторку как Аквиа? Чем она занимается? Берется Друпал и расширяется дополнительными модулями, ну там CCK, Views, Image Field, и т.д. Все это дело распространяется отдельными дистрибутивами.
Я же предлагаю совершит обратное действие. Не расширять Друпал, а наоборот его урезать, упростить в угоду производительности.
Пока есть мысли отказаться от таких вещей, как:
Форматы ввода
Статистика
Может быть что то еще.
Возможно имеет смысл пересмотреть логику вывода материалов. Сделать несколько патчей ядра.
И конечно, ни каких Views и CCK.
Предполагаю сделать несколько, узко заточенных дистрибутивов: блог/коллективные блоги, сайт визитка, новостной сайт, интернет магазин и пр.
Что скажет сообщество по этому поводу? Имеет ли смысл? А если имеет, то какие именно аспекты нужно упрощать?
- Блог
- Войдите или зарегистрируйтесь, чтобы отправлять комментарии
Комментарии
Я думаю что стандартная поставка друпала вполне адекватна и сбалансирована. Я в друпале совсем чайник, коллективный блог/магазин я конечно не поднимал, но более-менее рабочий вариант сайта-визитки сделал за пару вечеров и часов 6 в сумме, начиная с поиска "на чем ваять" заканчивая функционалом и худо-бедно шаблоном. Чтобы все довести до победы уйдет, конечно, немало времени, но визитка на основе открытых шаблонов и модулей меня пока вполне устроит. Потом оценю вложения-отдачу и найму человека или фирму, чтобы сделала "как надо". Сейчас спасает знание английского и немного кодирования/верстки.
Сейчас я думаю, что основная проблема - это отсутствие пошаговых мануалов и описания самых необходимых модулей. В стиле "вам нужно это? тогда есть вот такой и такой модуль, нажмите сюда и сюда..." Для меня, например, проблема - хороший файловый менеджер, imce и webfm кривые какие-то и неудобные, альтернатив не знаю.
Еще будут полезны готовые стандартные профили, или как они называются... вобщем чтобы сразу ставился определенный набор модулей. И самое главное - вся инфа должна быть в одном месте, разделе, и, желательно, на этом сайте.
Это мое мнение, человека, которому нужно оперативно и быстро поднять простенький сайт, и самое главное - отсутствие времени на поиск информации. Так же я думаю, что такой подход будет очень полезен для сообщества с точки зрения маркетинга. Базовый функционал запускается самостоятельно, поддержка-доработка на стороне.
PS Дистрибутивы требуют затрат на сопровождение, не будете же вы просто их делать и не сопровождать? Иначе смысл в них. По моему, с точки зрения затрат сгруппированная информация в ввиде визарда тоже предпочтительней.
Вы хотите плодить аналоги дле-варезных сайтов?
Идея хорошая, но что мы получим в итоге? Кучу бесполезных сайтов, заваленных хламом, порно, баннерами и т.п. Это моё мнение и я его никому не навязываю, но я уже достаточно насмотрелся в инете.
К тому же, это лишает всех прелестей изучения друпала (по крайней мере, говорю про себя, как начинающего с друпалом)
Как показала практика, отмороженным челюскинцам нужен русский инсталлятор и чтобы номера версий совпадали. Бог в помощь, конечно.
Идея интересна, особенно если будут люди, поддерживающие эти дистрибутивы. Но работы очень много.
Статистику можно не включать просто. Форматы ввода восновном нужны. Ядро друпала итак стараются не раздувать, при этом сохраняя гибкость. Какие патчи имеются ввиду?
Как раз идея в том, что бы избавиться от гибкости в пределах разумного.
Ну а патчи разные. На этом сайте можно найти много патчей ядра, ускоряющих работу. Переделать систему кеширования и пр. Можно подготовить списочек, но пока некогда.
Поддержку продавать.
Интересно с точки зрения опыта сборки. Если будете делать - очень будет интересно узнать как и что.
Сейчас сам думаю о том, чтобы сделать свою сборку. У меня правда, немного другая идея компановки. Есть группа модулей, которые использую практически во всех проектах(и views и cck туда входят, как и bueditor,imagecache и др.). Пока просто времени нет глянуть на доки по сборке своего инсталлятора. Но думаю, через недельки две, как с текущими делами покончу, займусь. Я Вас в букмарки добавил, тогда отпишусь как начну делать и будет конкретика. Может чем друг другу поможем
А можно выкинуть поддержку языков. Метод я как-то тут описывал - проходим скриптом по ядру и подменяем t("") на статические строки с переводом. Получаем жёстко "локализованный" движок. Нужен другой перевод? Берём оригинальный код и снова проходим по нему скриптом, указав откуда брать переводы. Правда сложнее с параметрами передаваемыми в строках переводов, но тоже можно обойти.
Если создать такой модуль, то можно сберечь кучу ресурсов, ведь как раз на перевод функций t() тратится 70-80% ресурсов. Получается сразу выигрыш производительности в минимум 2-3 раза. И многие "тяжелые" модули будет "летать". Даже думал взять, эту тему как тему дипломной работы, только проблема сейчас на 4 курсе, а модуль нужен всем.
Может, всё выкинем, кроме readme? Будет очень быстро работать, багов не будет...
Дельная мысль!
Для блогов -- хорошая идея. Всё остальное, думаю, не надо, только плодить школиё, делающее сайты за еду.
Для блогов даже лучше что-то типа "Drupal Livejournal migration pack" -- для тех, кто валит с ЖЖ на стенделоун :). С фичами, характерными для ЖЖ -- похожие комменты, опенид, кросспостинг в ЖЖ для тех, кто не совсем свалил.
Спасибо всем, кто откликнулся.
Собратья! У меня просьба. Если у кого есть ссылки на патчи, которые ускоряют работу, то кидайте их тут в комментах.
Вячеслав, идею вашу целиком поддерживаю !
Кому-то нужна гибкость, чтобы сделать нестандартное решение - сборку. А кому-то, думаю что многим, нужна конкретная функциональность без заморочек - поставил и поехал.
Это примерно как с осью - кому нужно готовое решение - ставят винду, кому нет - сами знаете что ...
Как раз с готовыми решениями \ сборками у Друпала проблема, поэтому, на мой взгляд, будет очень здорово если таковые появятся.
Да - не поленитесь - выложите эту идею на Друпал.орг - посмотрите тамошнюю реакцию. Вообщем - за идею 5.
Убрать статистику и сделать жесткую локализацию - поддерживаю.
Да - отдельный вопрос - смогут ли такие урезанные сборки поддерживать:
Появятся еще мысли - обязательно поделюсь, это пока первая реакция.
Давайте только определимся - где это делать - в комментах сюда или иожет на форуме отдельную ветку создадим ?
Успехов !
Я бы многое хотел бы по этому поводу...
а) Оставить ноду только узлом с nid - все требуемые поля добавлять через CCK.
б) Полную поддержку многоязычности на уровне полей.
в) Оптимизировать структуру таблиц для полей ноды. Для каждого типа нод вести четыре таблицы для полей: однозначные-многоязычные (т.е. одинаковые для всех языковых версий ноды), однозначные-одноязычные, многозначные-одноязычные (т. е. для каждого языка свои) и многозначные-многоязычные. Это позволит выбирать всю информацию ноды максимум четырьмя запросами.
г) Тизеры и фулноды - фтопку: полностью настраивать с нуля представления ноды в любом количестве. Для каждого представления формировать сразу VIEW в БД и нужную информацию выбирать из него разом только по nid и идентификатору языка.
д) Убрать порочную практику использования строк в качестве первичных ключей в БД. Например языки.
г) Превратить таксономию в ноды - использовать nodereference для связи между нодами-категориями и нодами-материалами. Каменты модифицировать таким же образом.
Т.е «голый» друпал в таком случае должен представлять из себя только менюрутер и систему авторизации. Остальное настраивается с нуля.
Правда, без сборок тут уже не обойтись.
Не много ли я хочу?
имхо форки - это зло в чистом виде.
уверены, что не отстанете от паровоза? обычная судьба форков - потеря внимания общественности из-за плохой поддержки и отсутствия новых версий.
Понимаете, мне самому будет легче и быстрей поднимать сайты из таких сборок. Не говоря уже о том, что такие вещи легко монетизировать. По этому, новые версии это не проблема, а за поддержку можно и монетку брать.
Была идея на эту тему.
1. Готовые поставки - т.е. сборки оптимизированные под конечные задачи + инструкция. Установил - вот тебе сайт визитка, или готовый магазин - всё включено, осталось только добавить информацию. По общению с непрофильным народом (не программеры), многим такого не хватает. Делал под заказ такие сборки пару раз с инструкциями краткими.
2. 100% перевод всех модулей сборки.
3. Разбивка логики на 4 секции с возможностью разноса на разные серверы:
- Генерирующие блок
- Кэширующий (отдающий) блок (на подобии cacherouter в ядре)
- Файло-отдающий блок (для хранения статического контента)
- Распределяющий блок (с 3 уровневой програмной-авторизацией, на подобии кэша авторизации + авторизация Drupal (СТРИМ24 по подобной схеме авторизации работает, только он не на Drupal
4. Полный аудит кода + патчи для ускорения работы (на подобии - убить перевод и т.п.)
По идее такие форки будут работать быстрее но будут не такие гибкие как Drupal и их следует рассматривать не как форки, а как расширение линейки Drupal (на подобии Windows XP Home, Windows XP Pro).
У меня не стартап, самому это добро нужно будет.
Пока это всё в планах на осень 2009, пока некогда скины к Lazarus прикручиваю:)
Мне кажется
Не этим нужно заниматься.
Нужна нормальная документация на русском языке. Где бы доходчиво обьясняли как правильно работать с друпал. Тогда необходимости в таком велосипеде не будет.
Простите, документация тут не поможет (я имею ввиду ускорение Друпала).
Когда я смотрю сколько и какие запросы выполняются при генерации страницы у меня сердце кровью обливается.
>Demimurych
CMS Drupal 6 Pro Drupal Development
http://www.ozon.ru/context/detail/id/4231881/
Ожидаемая дата передачи в службу доставки 1 февраля.
Цена 539 рублей.
Кстати с новой книгой на русском языке!
угу - давно пора
Боюсь она будет такая же убогая как и первая. Посмотрел оглавление "ловушки, узлы, перехватчики" — ну что за бред?? Первая версия их так и не заставила пересмотреть терминологию.
Жене понравилось, как начинающему программеру. Правда она долго смеялась на переводом слова AJAX - переведено как: АНАН. Программисты Delphi - дельфисты, а програмисты АНАН - кто тогда?
а точно там AHAH был как перевод AJAX а не Asynchronous HTML and HTTP ?
Нормальная книга вроде. читаю. терминология.... кто из русского сообщества участвовал в написании книги? Хотя сам в терминологии на этом сайте не разобрался. Как по вашему надо быо перевести не "ловушки, узлы, перехватчики" а как то иначе? То как?
"хуки", "ноды" и "триггеры". Конечно есть люди, которые приведут аргументы о "чистоте русского языка". Но они в данном случае совсем не к месту по двум причинам:
1. Все разработчики, которых я знаю (а их немало), пользуются именно словами "нода", "хук" и т.п.
2. Когда потом программисту, выучившемуся на "ловушках" и "переключателях" надо будет найти на drupa.org информацию, он столкнется с баръером непонимания.
Посему, лучше уж с самого начала уяснить что означают эти термины, чем потом перебивать привычку.
penexe прав, это самостоятельный термин. На орге давно об этом говорят
Объективно, полезно просто сделать сборку ядра + перевод.
Предпочитаю хранить дампы установленных версий, разворачивать намного быстрее...
Сборка сама-по-себе - это не о чем. Модули довольно часто обновляются, а порой требуют изменений для корректной работы.
cck views и прочие, еще чистить и чистить (в плане перевода строк, не говоря уже о прилагаемых к ним html справках).
Что касается патчей-ускорителей - таких волшебных таблеток нет и быть не может, по одной простой причине - оптимизация каждого сайта отлична от других и, если уж найдена какая-то проблема или альтернативный путь, то это дело нужно на d.o посылать и там дискутировать.
Хорошая идея
Инициатива вещь хорошая, но.. думаю, не туда вы силы хотите бросить.
Зачем катить проект назад. Создавайте большее, не шагайте назад.
Прививайте людям стремление разбираться, развиваться, создавать что-то стоящее.
Помогайте в ЭТОМ. Не наоборот.
Предлагаю выносить на обсуждение самые глючные запросы в базу и общими силами с ними разбираться
Ага,полностью согласен! правильно! зачем переводить слова, которые были заимствованы не из русского языка.
Конечно легче, кто ж спорит?
Какие вещи? Зачем мрнетизировать?
Всё и вся монетизировать не наша задача.
По-моему, как раз проблема. Коммерческая поддержка ВАШЕГО продукта - дело ваше, но причём здесь Drupal сообщество?
"Давайте заоптимизируем код друпала так шобы он летал на narod.ru и не использовал БД в принципе (вот была бы вещь), а вы потом платите мне денюжку за поддержку"...
В инете и так полно воплей по поводу "кошмарной грузности и тяжёлости" Drupal - и это никак не мешает развиваться ни самому Drupal, ни сообществу, ни многочисленным известным сайтам, использующим Drupal.
Может стоит вырасти из уровня "монетизации и создания сайтов под сапу на говнохостингах ЗАДЁШЕВО" и поставить свои сайты на Drupal на нормальный хостинг или vds или dedicated (если сайтов много)?
Тогда и миграция с версии на версию, добавление новой функциональности, да всё что угодно, будет делом приятным, не отбременительным и совершенно бесплатным (если голова на плечах есть)
Вот за это я готов сказать "Благо Дарю" и opensource и Drupal и сообществу.
Пардонте, если резковато.
Да уж, есть немного
Однако Ваши высказывания имеют мало ценности. Знаете почему?
Что вы сами сделали для сообщества? Кроме того, что сказали "Благо Дарю"??
Много ли людей высказали благодарность именно Вам?
Идея сея возникала думаю у многих, но взвесив все за и против, получается против.
Как уже многие выразились, и я с этим соглашусь, что появится еще больше бессмысленных ресурсов, владельцы, которых все равно будут искать бесплатную поддержку на d.ru, а не стучать в вашу платную, потому как у них не серьезный интерес. А люди с серьезным интересом не будут парится и закажут все у какой-нибудь студии или фрилансера.
Для многих проще заказать сайт от и до и не мучится самомму. Кто захочет разбираться с движком да еще за деньги, когда можно один раз заплатить и спать спокойно.
документации много, но проблема в другом, люди не хотят читать маны, а предпочитают инструкции и при этом не хотят их искать. "Лень захватила молодое поколение!" ©
Вопрос, который задают после первого error message - это не вопрос, а нежелание что-то сделать самому.
Не надо разводить слухи и суеверия. Эти цифры значительно меньше.
Да, да, цифры действительно меньше.
Там сейчас на это дело кеш стоит. Однако какая то часть памяти и ресурсов тратится.
Проблемы перевода терминологии и вопросы облегчения Капли стары как мир.
Использую в основном для своих работ Joomla http://shalasha.net (1.0) http://khaber.ru (1.5), на Drupal делал один тестовый проект, специально без дополнительных модулей, на разных хостингах ставил, везде свои нюансы и если Joomla считающаяся тоже тормозом, ставится и работает почти без проблем, то здесь не всё так гладко, то памяти не хватает, то библиотеки нет.
В то же время разрабатываю новый проект на локальной машине именно на Drupal не из упрямства, что мол одолею я его или он меня, ни в коем случае это не так.
Именно возможность сваять то, что задумано, а не подстраивать свою идею под имеющиеся рамки как в Joomla, не смотря на то, что за это приходится платить более высокими требованиями к серверу -- главная ценность Drupal. Идею сделать облегчённую сборку считаю абсурдом. Для визиток есть другие инструменты, опытный Web мастер может выбрать пяток движков (инструментов) и не парится пытаясь одними пассатижами гвозди забивать, кусать проволоку и откручивать шурупы, проще всё же взять молоток отвёртку и бокорезы.
Хотя и у него есть рамки - API...
По-моему, бессмысленно "облегчать" Друпал. Для этого есть другие движки и их много.
Примерчик не подкините? Но только не забудьте про функциональность.
Основная идея была именно в отказе от функциональности ради скорости и снижения требовательности к ресурсам сервера.
Пример - NanoCMS или как её там, CMS от Ласто
Показывает свободные от оформления хтмэльки в нужном дизайне. Так же как и CMSimple, позволяет иметь отдельные дизайны хоть для каждой страницы.
Danneo, XOOPS, MODx. Правда, в последней много ручной работы требуется, но тоже приятная.
XOOPS, MODx -- пробовала — хавно, MODx и CMS назвать сложно! CMSimple... вроде тоже пробовала... или еще нет...
Короче сравниваем бегемота и кролика — глупо.
Работа над дистрибутивом уже идет полным ходом.
Кто поделится доменчиком?
Может просто попросит Акселя создать поддомен, ну типа mini.drupal.ru
Почему то пришла в голову мысль собирать код всех включенных модулей в один файл автоматом при включении\выключении модулей. И подключать его одним запросом.
Да, это может ускорить загрузку друпала, но в 6-ке реализована система так, что при запросе к серверу подключаются файлы, наподобие 'file' => 'taxonomy.pages.inc', в которых находится код, необходимый только на данных страницах, а на других он не нужен, как с ними тогда поступить? Не утяжелит ли наоборот это систему, если их все в один файл?
А почему бы не использовать конкретно под проект легкую CMS?
Моск уже выносит.
исправил common.inc
<?php
require_once './includes/theme.inc';
require_once './includes/pager.inc';
require_once './includes/menu.inc';
require_once './includes/tablesort.inc';
require_once './includes/file.inc';
require_once './includes/unicode.inc';
require_once './includes/image.inc';
require_once './includes/form.inc';
?>
Все это перенес в один файл и подключил одной командой.
Разницы ни какой!!!!!
Как было 25 - 30 миллисекунд так и осталось.
Больше всего бесит, что подключение через require_once всех включенных модулей у меня занимает половину от времени создания страницы 700 - 800 миллисекунд.
И причем самые "тормоза" это системные модули: user, node, comment, forum.
На эту четверку уходит ну одна треть времени точно. Всего модулей подключается 70.
Могу привести время подключения каждого файла.
Уже не знаю, может не запариваться со слиянием файлов в один???
Такое ощущение, что require_once отнимает не много времени, в основном время тратиться на парсинг.
Так ли это?
да, require_once затратная операция, намного менее затратна require либо include, попробуйте, но нужно следить, чтобы вызывалось в одном месте самому.
Пробовал и то и другое и пятое и десятое, все одно и то же.
Мне не понятно одно.
Почему 60 файлов модулей инклюдятся от 1 до 10 мс.
А 10 модулей инклюдятся за 50 - 100 мс.
От чего это зависит? От количества функций и переменных?
Посмотри отладчиком сколько циклов крутится и сколько раз в базу лезит...
В данном случае похоже что это локальная проблема
Вообще при установне APC eAccelerator - этих проблем не должно быть
Не, не APC, не eAccelerator нету.
А как можно столько модулей запускать без них? Это абсурд - половину времени обработки страницы будет уходить именно на компиляциюю скриптов...
Ага, так оно и есть. См. сюда: http://drupal.ru/node/25121
user,node - весят под сто килограм каждый. Все это процессорное время, парсинг функций, переменных. Размашистые комменты к каждому хуку/функции, набросанные щедрой рукой =)... Лучше конечно, eAccelerator поставить и не париться.
Думаю, это не разумно.
Я сюда пришёл после долгих выборов между различными способами построения сайта.
А читая Ваше предложение "облегчить друпал" может создаться мнение, что я сделал неправильный свой выбор на Друпал.
Не нужно "облегчать друпал", - нужно не жадничать на хостинг.
Сколько Вы платите за хостинг, на котором Друпал чувствует себя свободно?
1160 руб в год. FFMPEG не пользуюсь, причём это виртуальный хостинг, а не сервер -)
странненько. за такие деньги обычно предлагают хостинг похуже, чем обычный бесплатный
У меня работает всё, правда у меня всего 1гб места, но анлим трафик, доступ ко всем настройкам, CPanel, анлимы на базы, почту, фильтры
ОФФТОП
Господа, поймите правильно, к тому же, никого не хочу обидеть, но вот что я думаю.
Вы не изобретаете велосипед? Почему не взять какой-нибудь фреймворк и не написать проект на нём? Здесь, за время моего нахождения в сообществе Друпал.ру, я увидел кучу отличных программеров. Возьмите Зенд, КИ, Симфони (или кучу других), в которых есть ООП (!) и написание модулей не составляет для профи никакого труда.
По поводу сборки: из песни слов не выкинешь. Что-то доставить (или интегрировать своё) можно, но менее прожорливым Друпал не станет. Сделать сборку, которую можно поставить не подготовленному человеку не получится. В Друпал надо вникнуть и делается это не за один день. Вспомните вопросы в коммьюните "как поставить?"...
Ещё немаловажный момент:
каждый сайт на Друпале собирается под конкретные цели и является в каком-то смысле уникальным. Тот, кто собирает сайт, всё-таки смотрит на нагрузку сервера, соответственно, выбираются модули и пишутся свои с учётом нагрузки, времени исполнения. Так что в чём смысл сборки, которая не будет стартовым движком, например, для профи? Делать для полных профанов (простите, не нашёл другого слова) в Друпал, которые не скажут спасибо, я считаю верхом неуважения к самому себе.
Прошу не воспринимать это как критику на автора идеи и людей его поддержавшего, просто я не понимаю зачем.
P.S. Для меня работа с Друпалом какой-то культ, только под Друпал я пишу подробное ТЗ самому себе, чего никогда не делал под ВордПресс. С Друпалом интересно работать с нуля.
Не всем это интересно, многие просто привыкли — поставил —> работает —> забыл. Сборки рассчитаны на конечных пользователей, которые ничего кроме как пользоваться не будут.
Отсюда вытекает то, что программеру или тому, кому интересно самому — это не будет так же интересно.
Все придумано за нас Pressflow - люди просто делают, а не обсуждают