3 июня 2012 в 16:47
таки состоялось! ветка ядра с Add a Drupal kernel; leverage HttpFoundation and HttpKernel
Бнчмарки показывают 10% потерю производительности в текущем состоянии - когда страое и новое живут одновременно http://drupal.org/node/1578090
Содержимое сайта публикуется на условиях CreativeCommons Attribution-ShareAlike 3.0 или более поздней версии. Программные коды в тексте статей — на условиях GNU GPL v2 или более поздней версии.
Документация по совместной работе с репозиторием drupal.ru – https://docs.drupal.ru/code
Drupal – торговая марка Дриса Бёйтарта
Поддерживать инфраструктуру Drupal.ru нам помогает компания ДАЛЕЕ
Комментарии
Да... Да это как утверждать что Symfony 2 медленней yii.
Или 7 медленее 6
А что с вьюсом ?
вьюс - отдельная иннициатива
А что это за ветка и какие она даёт преимущества, чем отличается от обычной? На английском по ссылке прочитал, но чёт всё-равно мало чего понял.
Это другое ядро, которое принимает и обслуживает запросы, вскоре будут заменены hook_menu и система роутинга
Ввели namespace, новую структуру папок, отдельные классы для каждой из сущностей, symfony autoloader
А я вот не могу понять - для чего это нашествие версий?
Есть недавно вышедший 7-й друпал.
К нему еще не все привыкли.
А уже готовится 8-й.
А при этом есть еще активно использующийся 6-й.
Чтобы пользователи и разработчики окончательно сошли с ума?
Вы наверное не разработчик
Нет. Я разработчикам задачи ставлю.
А это что-то меняет?
если следовать этой логике, то идеальным было бы остановиться на 4-й версии?
Идеальным было бы как-то простимулировать разработчиков модулей на 6-ке, дабы они "допилили" бы до приятного состояния модули на 6-ке.
А не заставлять их "распыляться" и на доработку по пожеланиям модулей и на 6-ке и на 7-ке.
Но это фанастика, понимаю.
и в результате приходится "допиливать" модули с drupal.org
Хотя... издержки open source, понимаю
Вышел то 7 даже очень давно, однако, из-за значительных различий в самих принципах работы с 6, сторонние модули(ибо делать сайт на чистом ядре это слишком круто, даже для джедаев, особенно если оно само немного глючит) более или менее стабильно работать стали действительно не давно(если сравнивать случай с 5 и 6, где по сути просто переработали API), вижу с 8ркой будет аналогичная история - ядро работать будет, а модули к нему портироваться еще несколько лет, т.е. год-два как минимум, после официального релиза, почти все будут сидеть на 7(так же как это было со всеми предыдущими версиями, причем не только Drupal, простейший пример - некоторые на Win7 с XP до сих пор отказывается переходить, хотя уже есть предрелизная 8рка(которая странным образом похожа на последнюю версию Ubuntu, хоть в нем и не пахнет КДЕ)
Вот и я об этом.
Мы в одном проекте попробовали 7-ку.
Да, прикольно, да интересно.
Но некоторых нужных модулей на тот момент - не было.
Сейчас посмотрел - появились. В качестве эксперимента решили один проект на 6-ке перевести на 7-ку.
Ну типо надо ведь двигаться рядом с прогрессом.
И только это собрались делать - и тут вижу новость про начало торжественного шествия 8-ки.
Как думаете, стоит экспериментировать с 7-кой, если уже накоплен некоторый опыт с 6-кой?
Или стоит сразу на 8-ку ориентироваться?
Интересно
Для многих задач Win7 по сравнению с XP многое дает
просто надо меньше разглагольствовать о херне всякой и больше дел делать - купишь себе и железо
правда мозги за лавэ не приобретешь - тут уж придётся довольствоваться тем что есть
маздай...... а что это?-))
тру кодеры работают только за еду!
где этих тру кодеров найти, не подскажете?
Конкретно 8 ориентирована на разработчиков. И вы глубоко заблуждаетесь если думаете что решить одну и ту же "Нестандартную" задачу Легче на 6 чем 7 или тем более 8.
Включение динамических запросов, сущностей, AJAX framework... ничего подобного (в плане разработки) в 6 даже не было, а время на создание собственных велосипедов ой как не хочется тратить.
Так разработка сайта на семерке сокращается порядка полутора раз (Чистое Ядро). А перевод ядра 8 пускай и только части на ООП парадигму включая интеграцию с Symfony. Позволит использовать всякие вкуснящки вроде TWIG, Dependency Injector, Doctrine без придумывания собственных костылей.
И надеюсь наконец добавят Stack Traces для обработки ошибок. И будем нам счастье.
вот один
вас обманули. шествие начнётся через полтора года
офигенно репрезентативная выборка , по которой можно делать какие то выводы .
Для маленьких и средних проектов экономически выгодно пропускать 1 версию про апгрейде.
Крупные сайты выгоднее не апгрейдить и поддерживать самим.
subscribe
Да о чем вы тут пишите!? Седня наши с Грецией играют!!! Выйдут ли наши в 8-ку сильнейших сборных Европы!? Вот о какой 8-ке нужно сейчас думать!!!
И как наши думы помогут футболистам?
Возникло три вопросоа.
1 Как понял будет использоваться конфигурация через XML
Это сделанно чтобы те кто знает только PHP изучали ещё и XML ?
Какой толк от конфигурации через XML? Это сделанно чтобы конфиги хранить не в базе а в XML ?
2 Почему не сделать перевод хранящимся не в базе а в файлах, к ак в большенстве движков, наримен SMF и так далее и прсото вызывать значение переменных в зависимости от языка.
3 Так как новая версия основанна на фреймворке то там будет очень много файлов инклуйлиться для генерации страницы. Это будет медленно. Будет ли какой-то функцонал компиляции?
Это всё написал потмоу что Drupal 8 по всей видимости будет очень похож на Magento. Оно тоже оснвоанно на фреймворке, толко на Zend, там тоже есть конфигурация через XML и из админки туда заносяться данные при изменении настроек.
Больше всего пугает большое количество файлов, и отсутствие кнопки компиляции. На Magento такая кнопка даёт прирост прмиерно в 3 раза, в зависимости от скорости жётских дисков хостера. Особенно это сказываетсь после долгого простоя, когда файлы из кэша в памяти удаляются и снова туда нужно загружать, после длительной неактивности сайта.
Так так оно наверное будет удобно для разработки, но что-то монстрозностью всё это пугает.
По поводу перевода в админке, почему тогда не сделать редактор файлов перевода в админке.
Пользователь заходит в раздел переводы, открываетсья редактор с переменными и можно самому писать туда текст.
Всё ровно думаю мало кто их тех, кто не сообразит как отредактировать тексовой файл занимаетсья переводом в админке.
Ведь модуль переводов утяжеляет работу сайта, все это знают.
По-моему фреймворк в Друпал 8 выбрали не просто так, а после многочисленных тестов и анализов, которые показали что с Symphony он работает вроде как быстрее и появляются ещё какие-то преимущества, поэтому выбор был обоснован именно улучшениями, а не монстрозностью, интерпрайзом и добавлением проблем разработчикам.
Безусловно ради изучения юзерами XML. Разве могут быть другие причины
Drupal растёт и потихоньку "набирается ума", используя проверенные техники, такие как нормальный шаблонный движок, например. Или тектовые конфиги, которые можно легко править, деплоить, отслеживать в VCS.
Потому что БД быстрее.
А APC и компания для чего нужны?
Да. На говнохостингах с минимумом памяти для MySQL. Drupal не слишком-то на них ориентирован.
Что мешает делать это сейчас с po-файлами?
К сожалению всё то, что вы написали не очень радует.
Но всё ровно СПАСИБО за ответ. От вас суть не зависит.
-
А APC и компания для чего нужны?
-
Мало где на хостинге есть подобное.
И во вторых, если сайт на виртуальном хостинге, то если сайт не активен какое-то время, всё это обнулиться даже если есть APC
И будет так. Псетитель придёт на сайт, и будет ждять 30 секунд пока откроеться главня, ну а потом будет нормально тыкать по страницам.
а если это будет поисковик то будет не хорошо.
////
Что мешает делать это сейчас с po-файлами?
-
Ничего. вопрос был в продолжение быстрости базы данных по сравнению с файлами. Можно посмотреть подробнее, где написано что перевод в базе быстрее чем на файлах?
////
А мне нравится такой шаблоный движок как сейчас на PHP
Не дай Бог, или кто угодно ещё, туда ещё Смарти доумяться прикрепить поддержки новомодности ради.
Тфу Тфу Тфу чтоб не накаркать....
Вот Смарти точно для изучения самого себя похоже нужен.
Не понимаю для кого это. проще уж PHP изучить на уровне правки шаблонов, чем Смарти изучать, чтоб писать прослойку.
Пока наивные рассуждают в блогах, может ли Друпал усидеть на 2 и более стульях, Дрис и Ко тащат его в "интирпрайз" семимильными шагами.
Так что фрилансерам-одиночкам и небольшим сайтам тут скоро станет ловить нечего.
А причём тут наивнсть?
Хотите сказать, что всё развитие данного двжка изначально за много лет задумывалось для того чтобы стать корпоративным монстном который для работы требует отдельного железного сервера?
Ну для интерпрайз есть Typo3 с его супер шаблонизатором с собственным языком с интерпретатором TypoScript...
Хотите сказать, что будет что-то подобное?
Ну, как-то савсем уж грустно.
Благо конкуренция вещь в чем-то всё-таки полезная, а движок данный стал тем чем он стал только благодаря своему сообществу.
Если он станет узконаправленным для имеющих понятия и кашелёк то движка данного как он есть сейчас больше не будет.
И это не наивное рассуждение.
Или вы хотите сказать что товарищи из коммерческих CMS побашляли разработчиков бесплатных решений, чтоб те не составляли такой конкуренции?
А причём тут маленькие сайты или большие, вся суть в бабле.
По вашей логике получаеться, что если сайт к прмиеру большой, и не коммерческий, так это уже для наивных?
Куда мир катется, все на бабле помешались.
Интересно посмотреть цифру которая являлась бы потолком.
Ещё раз - Drupal не ориентируется на хостинги за 30 рублей, хотя даже для них можно его подтюнить.
Если сайт посещают 2 раза в день, то может вообще его в статику сбросить через тот же буст или закэшировать через nginx, зачем сервер мучать?)
Не вижу ни одной причины, чтобы БД была _медленне_ файлов. А тесты я уже когда-то гонял. Меня устроил результат.
Смарти уже был.
Это пока не познаешь нормальные шаблонные движки)
Это не про вас. Просто часто встречаю на drupal.org посты типа "Сможет ли Друпал угодить и корпоративной аудитории и маленьким сайтам ?".
Да, Друпал уже давно не то(р)т.
Мне интересно другое.
Сможет ли интеграция Симфони и т.д. упростить Дру, уменьшить его собственный код.
Это, на самом деле, самый главный вопрос существования Дру как популярного, массового продукта.
Пока ставлю, что нет
А у меня есть сайт на Друпал6 на хостинге за доллар в месяц, и ничего прекрасно работает. Посешаемость человек 20 в сутки, и как раз как вы написали страницы закэшированны в статику так как это подобие сайта визитки.
Смарти был вроди как отдельный модуль для желающих, а при желании и по умолчанию использовались нормальные шаблоны на PHP которые более просты, логичны и понятны. А не наооборот что радовало.
По поводу интеграции с Симфони, это вопрос не ко мне, не пользовался данным, и подобным им фреймворком, но судя по Magento, которым пользовался могу дмать что скорее оно уменьшит затраты на поддержания части кода выполняющего рутинные операции чем упростит. Оно скорее удешевит саму разработку движка. Хотя это тоже смотря что задуманно. Если задуманно написать что-то по функциональности привлекательное, но не думать о бустродействии, то это упростит. Хотя по идее это наложит определенные ограничения.
С моей колокольни дело обстоит так, что у разработчиков не жватило ресурсов и желания написать что-то с нуля и они решили использовать часть готового.
Хотя это в больей степени правильно, так как велосипед изобретать не стоит.
Но с другой стороны делать надстройки над колёсами от велсипеда нужно с осторохностью, так как это всё-таки ограничения и определенная зависимость от сторонних разработчиков.
Хоть ЗендФреймворк и считаетсья вроди самым медленнм в мире, если не ошибаюсь, но у него всё-таки за спиной разработчики PHP.
Дык посмотри на текущие размеры дистров - 8-ка в 2.5 раза тяжелее 7-ки. Фигушки проще станет )
А если вычесть сторонний код ? Я так понимаю, туда запихнули все GPL-ное, что используется..не ?
Ещё по поводу ереводов в файлах а не в базе могу скзать вот такой пример.
Есть OpenCart перевод в файлах. У него нет своего АПИ, модули ставяться правкой ядра.
Есть PrestaShop по своей сути очень похож кстати на Drupal там тоже перевод в базе, модули используют хуки и заменяюь функции в ядре.
Разица в производительности, сужу по загрузке страницы очень велика. Но не на большом числе твоаров, но это суть уже в другом.
Хотя это не от переодов, но всё-таи есть тенденция, движки где перевод в базе более тяжёлые по своей логике, поэтмоу возникают определенные ассоциации.
Было бы интересно знать, что переводы в базе хотя бы не то что быстрее, а хотя бы не на порядок медленнее файлов.
Что быстрее - зависит от конкретных запросов.
Если нужно загрузить 5 строчек перевода - то база будет однозначно быстрее, чем парсить весь файл с 500 строчками.
Если нужно загрузить 500 строчек и все они в одном po файле - то файл быстрее.
Если нужно загрузить 500 строчек но все они раскиданы в 100 po файлах - то в этом случае мне кажется база будет быстрее.
Имхо база - более гибкое решение, а для увеличения производительности из базы можно всегда сделать выборку часто используемых строк и закешировать их в один дамп, грузить одним запросом.
Ведь если мы грузим файл, то чтобы найти строку с ключом "phrase" нам нужно подгрузить весь файл со всеми строками, сделать полный перебор каждой строки сверху вниз и сравнивать с ключом. А база делает тот же самый поиск по индексу, поэтому сделает поиск в разы быстрее по процессорному времени. Но при использовании базы ещё добавляются задержки на формирование и парсинг sql-запроса, передачу данных обратно в php и др, поэтому тоже всё зависит от случая. Но при огромном количестве строк мне кажется база всё же выиграет в производительности.
Например на моём сайте 18000 строк перевода, сколько займёт процессорного времени перебор этого массива чтобы найти определенный ключ и сколько - поиск по индексу в базе?
Также ещё стоит учесть, что при применении файлов - это всё будет подгружаться из сотни файлов, каждый из которых нужно подгрузить через file_get_contents, распарсить в массив - это тоже лишнее время и ресурсы. И ещё потом это всё загрузить в память - судя по объему текущей таблицы в mysql - около 4 мегабайт памяти оно смело откушает.
Переводы в базе -- это шляпа. Да, одну строку вытащить из базы -- это быстро. А если в процессе генерации страницы нужно перевести 100 строк, то 100 запросов будет медленнее.
Переводы нужно хранить в памяти или каком-то быстром key->value хранилище.
Переводы кешируются для каждой страницы, поэтому для анонимуса - они будут грузиться одним запросом, а 100 запросов будет делаться только после сброса кеша.
Возьмём реальный пример моего сайта: всего 18 тысяч строк перевода в базе, из которых нужно загрузить для одной страницы 100 строк.
При использовании базы:
1. Делаем 100 sql запросов, выполняется 100 поисков по масссиву из 18 тысяч строк с использованием индекса.
При использовании файлов:
1. Подгружаем все po-файлы в память - каждый файл читаем с диска, пробегаемся по каждой строчке файла и формируем PHP массив.
2. 100 раз обращаемся к этому массиву для поиска значения по ключу - т.е. 100 раз делаем полный перебор всех строк для поиска нужной (навряд ли php использует индекс для поиска по ключам массива).
В итоге имхо первый способ будет быстрее второго.
Вот кстати, то, что анонимам Друпал показывает одно, а залогиненым другое -- есть чистой воды мудизм. Нельзя делать разницу между анонимом и пользователями. И те и другие должны видеть актуальную информацию. Это идиотское правило, из-за него вся система кеширования Друпала построена чрез жопу.
Конечно, все зависит от конкретного случая.
Файлы переводов могут лежать на RAM-диске, скорость доступа к ним буде выше на порядки;
Переводы могут храниться как php-массивы вида "исходная строка"->"локализованная строка".
Разрабы любезно предлагают выносить переводы в settings.php
В большинстве сайтов анонимусы это 99% посетителей сайта, для них как раз система кеширования и сделана, поэтому она устроена просто и работает быстро.
А для сайтов где много зарегистрированных пользователей (социальные сети, порталы) - универсального решения не придумаешь, поэтому в таких случаях для кеширования нужно использовать дополнительные модули или кешировать вручную.
Я что-то ни одного хостинга не припомню где дают RAM-диск для переводов
А php-массив всё-равно нужно откуда-то загрузить (опять же из файла размером в 4 мегабайта) и потратить процессорное время на раскукоживание в пямять, даже если он через serialize записан. И после того как мы получили php-массив в оперативной памяти - поиск каждого ключа полным перебором 18 тысяч строк - никуда не делся, а он всяко медленней чем поиск по индексу.
И 18 тысяч строк - это не конкретный тяжелый случай, а обычный стандартный сайт на друпале с использованием около 10-20 дополнительных модулей.
А зачем вы всё в кучу ложите?
то есть всё в один файл?
Для каждого модуля может быть свой файт, как напрмиер в OpenCart вот прмиер
<?php// Heading
$_['heading_title'] = 'My Account'; // Text
$_['text_account'] = 'Account';
$_['text_my_account'] = 'My Account';
$_['text_my_orders'] = 'My Orders';
$_['text_my_newsletter'] = 'Newsletter';
$_['text_edit'] = 'Edit your account information';
$_['text_password'] = 'Change your password';
$_['text_address'] = 'Modify your address book entries';
$_['text_wishlist'] = 'Modify your wish list';
$_['text_order'] = 'View your order history';
$_['text_download'] = 'Downloads';
$_['text_reward'] = 'Your Reward Points';
$_['text_return'] = 'View your return requests';
$_['text_transaction'] = 'Your Transactions';
$_['text_newsletter'] = 'Subscribe / unsubscribe to newsletter';
?>
а в шаблоне вставляем 'text_newsletter' и так далее, а в зависимости от языка выбираетсья нужный файл, вернее нужная папка с файлами от каждого модуля. и всё.
открываетсья страница с набором модулей, беруться файлы по числу модулей, там строк перевода штук 20 и всё.
открываетья другая страница, там друой набор модулей, другие фалы перевода, и всё.
Зачем всё в один огромный файл.
а у каждого модуля свой масив, впернее свой файл с переменными который прикрепляется при вызове конкретного модуля.
так сделано было в osCommerce OpenCart, Даже в многострадальной Joomla так сделано.
Читал чо хранение переводов в базе сделанно только для того чтобы из админки можно было бы править перевод, а в первом сообщении написал, что при желании можно пристроить в админку редактор этих PHP файлов с переводом как это в Joomla сделано.
В opencart не знаю, а вот в Joomla схема реализация модулей совсем другая - там если грузишь страницу каталога, то грузится только модуль каталога.
А в друпале - все модули изначально грузятся, т.к. на странице может быть сразу и каталог и последние темы форума и форма обратной связи и т.п. Поэтому до того как всё на странице будет отрисовано - сам друпал не знает какие модули и переводы могут понадобиться.
Поэтому остаётся два пути - либо загрузить всё сразу, либо при каждом запросе на первод разбираться какой это модуль спрашивает, в какой папке и какой файл подгружать, потом подгружаем файл, парсим и выводим конкретную строку. Соответственно при каждом запросе будет тратиться время на все эти операции, а если запросов не 2-3 а более 100 - то это будет заметно медленнее, чем за раз подгрузить всё что может понадобиться, либо работать с базой.
В OpenCart тоже грузиться только то, что отображаеться.
А с чем явязано, что Drupal грузит все установленные модули?
Вы очень интересно написали про это. Не знал таких деталей.
Получаетсья что если например я установил модуль rules и сделал одно только правило на то, чтобы когда пользователь пожаловался на ссобщение форума то администратору приходило письмо.
Получаетсья при загрузке страниц, если не кто не что не нажимет всё ровно будет грузитьмя этот модуль?
или например если я установил модуль опросов quiz и quizreg от спам ботов и сделал опрос на отдельной странице. То при загрузке савсем других разделов всё ровно будет грузиться модуль quiz?
Примерно так же будет и в 8 версии?
При каждой загрузке грузится .module файл всех включенных на сайте модулей, где находятся хуки (перехватчики) всех нужных событий, без этого друпал не сможет понять что, например, модулю антиспама нужно слушать все события по выводу формы и добавлять туда свою защиту.
По-другому никак это особо и не реализуешь, ведь любой модуль в любой момент может запросить функцию другого модуля. Поэтому на этапе загрузки Drupal не может знать что может вдруг понадобиться для отрисовки страницы, поэтому и вынужден знать сразу обо всех доступных переводах.
По поводу Joomla - там всё это сделано намного хуже: в построении странице участвует только один модуль (который вызывается через url, например com_content), и он уже сам вынужден подгружать все остальные модули, которые ему понадобятся.
Поэтому если например на странице у нас есть статья, под ней - новые товары из магазина, справа - последние сообщения форума, слева - рейтинг пользователей, то соответственно подгрузятся переводы всех используемых на странице модулей. А если блока с товарами магазина нет, то в статье пользователь уже будет вынужден сам подгружать переводы для магазина ручками.
При загрузке страницы постоянно грузятся головные файлы каждого включенного модуля (там где реализованы хуки), а не прям "весь" модуль со всем функционалом.
Уже нечего. Трудозатраты охуенные, люди всё меньше понимают, за что платить, ведь есть жумла, вп
Друпал и не предназначен для небольших сайтов аля сайт-визитка или блог юного словоблуда, для этого есть вп и жумла. А такой гибкости и удобства в разработке сайтов как в Drupal - вордпрессу и жумле даже не снились. Да, за это приходится платить лишней нагрузкой на ресурсы, но по-другому никак - либо урезать возможности и ускоряться, либо расширяться и терять немного в производительности.
Это лишь ваше частное мнение. Многие с вами не согласятся..
Я имел в виду не то, что на нем сложно или невозможно сделать небольшой сайт, а о том - что это слишком функциональная и гибкая система, чтобы её использовать для простых сайтов, т.к. грузится 100% функционала, а используется тока 1-2%.
Поэтому если нужен простой сайт, который быстро работает и требует мизер ресурсов - для этого лучше использовать простую cms, где нет ни переводов ни хуков ни другого лишнего функционала, есть даже cms которые работают без бд! Такой сайт будет занимать мало места и быстро открываться даже на самом стрёмном хостинге.
А целевой сайт друпала - это всё же не простенький сайт, а сайт среднего уровня, где активно используется мощь друпала.
Конечно же специалистам по Друпалу проще и быстрее сделать и двухстраничный сайт на drupal, но с точки зрения ресурсоёмкости это не логично.
Ну наверное в 8-ой версии они как то от хучной системы будут уходить, она же процедурная, а симфони - ооп. Не смотрел правда.
Как это не предназначен? Еще как предназначен. Простые сайты на друпале само комфортно и делать. И этим готовы заниматься кто угодно, раз есть такая возможность. Прогать то на простом сайте не надо, а тыкать мышкой в админке научиться попроще будет.
Ну вот пока можно мышкой натыкать результат оно кое-как работает...а дальше случается "опаньки". И чем дальше с каждой новой версией Дру, тем это "опаньки" становится все более суровым ))
Murz, для простого сайта, визитки и т.д., на сайте включается кеш + буст и работает как миленький. Зато это друпал, с админкой друпал, модулями друпал, поддержкой друпал. А не какая то другая цмс.
с перспективой развития его до
Это проистекает из специфики БД. В основе любой БД лежит файловое хранилище. Между приложением и файлом есть прослойка ФС, которая кэширует и оптимизирует обращения к файлам. Однако только на доступ к самим файлам. Оптимизация доступа к содержимому файлов ложиться на приложение, в нашем случае - на систему gettext, которая компилирует файлы переводов в специальный формат .mo. То есть, по сути, она выполняет роль спец-СУБД, которая при запросе к ней "Дай мне перевод строки номе 17 из файла core.php" находит файл core.mo и вычепляет из неё строку номер 17. Притом для быстрого извлечения этой строки надо чтобы кэш ФС был "горячим", иначе стразу имеем тормоза на дисковых операциях.
Что происходит в случае с БД? Обращение к файлам БД идёт постоянно, поэтому они в кэше ФС будут с гораздо большей вероятностью, плюс БД кэширует запросы и - мало того - выполнение этих запросов. На нормальном хостинге половина БД будет постоянно в памяти висеть, что даст ощутимый выигрыш и при сотнях запросах.
При наличии большого объёма ОЗУ и БД очень хорошо оптимизируется, поэтому отпадает необходимость в настройках дополнительных хранилищ.
Ну вот чего ты троллишь-то? ) Сам прекрасно понимаешь, что можно всё гибко настроить и сбрасывать гибко кэши и давать анонимам видеть самую актуальную информацию, если это необходимо.
"Вот, мальчик, тебе делать нехрен - сиди и складывай!" (с)
Добавили дохрена всего и это всё теперь - ядро. И это всё теперь надо, по-хорошему, перелопатить, чтобы знать как работает новая версия. Причём различия от 7-ки принципиальные, что не радует в смысле прогнозов по времени
Архитектура такой. В случае наличия кэша опкода на это глубоко наплевать - оно и так в памяти сидеть будет.
А не надо включать лишние модули, тогда будет использоваться только необходимый минимум. А на небольших сайтах Drupal чует себя великолепно и это расхожее заблуждение про "не предназначен для небольших сайтов".
Печаль. С новомодными веяниями вроде тех что сайт по друпал way должен быть без своих написанных (под этот сайт) модулей, а только настройкой орг-овских модулей, сложно придумать мотив программисту разбираться во всем этом. Может кто знает?
Да собственно мотив тот же самый, что и всегда: быстрее и лучше делать свою работу. Если изучение поможет делать быстрее - надо изучать. Не поможет - не надо изучать.
Про семерку полтора года назад тоже куча стонов было, как все сложно, плохо, недоделано, семерка сырая, осваивать ее незачем, тем более осваивать так много...
Я освоил - почти всё делаю раза в полтора как минимум быстрее, чем на шестерке. И с восьмеркой будет то же самое. Если, конечно, она не убьет друпал
Не обращайте внимания на такие "веяния" - не стоит путать чьи фантазии с объективной реальностью. Те, кто хотят сами тыкая мышкой чего-то серьезного добиться - просто не наша аудитория
Где же оптимизм и уверенность в светлом будущем - вера творит чудеса
Я там смайлик поставил - не придумал, как лучше иронию изобразить
И соответственно дешевле в 1.5 раза?
Да - я по часам работу рассчитываю.
+ мультисайтинг
+ субтемы
+ большая скорость от старта проекта до запуска (конечно не 60/месяц, но много было проектов "за вечер", "за выходные"
+ дальнейшая перспектива легко начать развивать любой сайт дальше, если он не умрет с очередной неоплатой за домен.
+ сборки и выйдет по 60 в месяц - только клиентов находи
А вот это плохо.
Альтернатив друпалу нет, есть либо выше категорией, либо ниже.
Печаль.
Альтернативы ЕСТЬ. Для сложных сайтов я уверен, что стоимость разработки на фреймворках не выше, чем стоимость кастомизации Друпала под ТЗ.
Для простых сайтов полно альтернатив.
Проблема в том, что Друпал заполонил все своим булшит маркетингом и теперь уже заказчики как зомби больше ничего не хотят.
может бистрикс?
Если с Друпала уходить, то на CMS где свои модули можно продавать по модели аппстора. Или вообще в разработку софта уходить из веба.
А GPL это рабство и нищета разработчика.
Продавать свое время - самый ценный и невосполнимый ресурс - просто глупо.
Плохая шутка.
С ценой битрикса... шутить не стоит.
Вас только цена останавливает? )
Вроде бы, у Ливстрита такая модель -- почти все модули и темы платные, прямо как в аппсторе.
Просто сам принцип, что большинство пользователей анонимы -- идиотичен. Сейчас на любом нормальном сайте можно залогиниться в два клика через социалки или OpenID. В конце концов, девиз Друпала -- community pumbling -- построение сообщества. Что же это за сообщество, где все анонимы? Какой-нибудь двач?
Этот слоган давно уже неактуален. Да что там за примерами ходить - drupal.org и drupal.ru сплошные Not Invented Here.
Нету альтернатив.
Друпал и есть фреймворк, самый что ни есть настоящий.
В то и прелесть друпала, что он и фреймворк и в тоже время, визитку сделать, 15 минут.
Универсальный продукт, всегда лучше.
А для крупных проектов, где надо фреймворки типа yui, то уже отдельный разговор.
Универсальность имеет свою цену - часто это результат посредственного качества или слишком дорогой. Поэтому не всегда.
+100000
В случае друпала, минусов меньше, чем плюсов + минусы не значительные.
Такого класса продукта, я не знаю.
Опять же, про хайлевела сайты не говорим, ясень пень, фейсбук писать на друпале, будет только идиот.
Но в остальном, друпал молодец.
Сколько на Друпале сайтов-визиток ? Очень мало.
Несмотря на всю мощь Друпал-маркетинга, все же заказчики не делают визитки на друпале массово. Т.е. результат на Друпале возможен, но он все же не такой, какой нужен заказчику ?
Сравните кол-во сайтов на Вордпрессе и Друпале, опять же. Разница просто космическая..
-1000 а что вы предлагаете продавать? И что ещё можно продать кроме своего времени в (любом виде)?
Органы.
А что продают люди творческих профессий (каким, вообще-то, и является программист) - музыканты, писатели ? Результат своего труда. А не рабочие часы.
И у программистов есть такой путь - создание качественного проприетарного ПО, которое никуда не денется, несмотря на всю опенсорц революцию.
PVasili: продавать можно задёшево и задорого.
Да море... только 1 студия +60 в месяц делает...
~5 раз
Все то же время, только Цена (всегда) = время * X (где X - реклама/раскрученность/известность/модность/знания и т.д.)
Тут ни кто не спорит. см. выше. X там определяет цену
Уже больше.
http://w3techs.com/technologies/overview/content_management/all
А на самом деле, цифра то еще больше, если сравнивать в одном сегменте, т.к. не все Дру-сайты можно сделать на вордпрессе
Результат творческого труда можно создать 1 раз, а продать N раз. Рабочее же время продается раз и навсегда - это невосполнимый, нетиражируемый ресурс.
Если вы это не понимаете, то и спорить бесполезно.
imho она меньше, ибо большинство WP - типичные полу-заброшенные г.с. или сайты продающие/показывающие шаблоны.
Скорее всего вы всевышний
Про разницу в стоимости создания результата творческого труда и продажи говорить не приходится. Цена картины и принта с неё отличаются заметно
Спорить точно - бесполезно.
Давайте не будем подгонять факты под нужный результат..Как будто на Дру нет говносайтов. Да на нем даже дорвеи делают.
Никто и не говорит, что время не требуется для создания творческого продукта. Просто это всего-лишь ресурс, сырье. Не имеет значения, сколько времени было потрачено - оно лишь косвенно влияет. Да и как можно говорить о продаже времени, в творческом процессе ? Если музыкант создал отличную песню, может ли он создать N таких же хороших песен, потратив N* времени ? Бред, короче.
Вот мы и "вышли на дерибасовскую" :). Время такой же ресурс, который стоит денег.
В любом случае, на создание чего-то вам нужно время (в том числе и косвенно [ваше обучение, реклама, вдохновение и т.д.]).
А затраченное время - всегда можно выразить в деньгах (ну только если вы не коммунист или сектант).
Создав тиражный(ую)программу/сайт/шаблон и т.д. вам опять же нужно потратить кучу времени на её продвижение/рекламу/сопровождение и т.д.
Ну а как оценивать своё личное время - решать вам. Или это будет дорогое время, за интересным проектом или время на рекламу/саппорт/разборки с манагерами и т.д. вашего тиражного продукта.
А еще можно вместо букв писать друг другу двоичные коды, но все же буквами как-то удобнее. Так и в творческой работе оцениваются не затраченные ресурсы а конечный результат. Потому что это самая естественная и простая форма для нелинейного процесса с непредсказуемыми результатами.
Гы....
https://www.google.com/trends/explore#q=wordpress,drupal
Судя по цифрам, самый большой интерес к Друпал -
в Индонезии, почти папуасы
не, таки КубаРешил поставить себе dev версию, чтобы посмотреть, неужели всё так страшно, как написано. и чтобы делать собственный вывод.
Ставиться, последний шаг, написано всё готово, появляется ссылка на готовый сайт.
Тыкаю ссылку, страница не ткрываетсья, даже 404 ошибки нет. Прсото заблокирован ответ сервера. Удаляю файл setings.php установка снова начинается.
Думал всё дело в правах на файл setings.php и папку поставил 444 всё ровно картина та же.
Кто устанавливал, было ли такое?
Может у меня на ПК сервер криво настроен, хотя всё остальное нормально работает.
Думаю дело в правах или наличии какого-то файла который не прописал установщик.
Это похоже на то, что удалите категорию install без этого вы не может работать с сайтом. Но раньше такого не Drupal не видел.
А вообще думаю зря так все писсимистично настроенны.
Извините, опять Joomla вспомню, но помню когда был только выход 1.5 бета, то тестеры поскачали, понаписали истеричных статей, что 1.5 версия не работая вообще, что она убивает серверы, что это вообще тупик, что он для страницы грузит 1500 файлов с диска или как-то так.
Но сам я влез туда смотреть когда был уже релиз и не первый.
Скачал, поставил, удивился, по сравнению с 1.0, версия 1.5 стала работать быстрее. А следующие релизы стали ещё быстрее.
Так что думаю, что не всё так ужасно и всё будет нормально.
По бета версии, вернее даже не беты а альфы скорее не стоит такие паники поднимать и пессимистически мыслить.
Хотя действиельно не понятно зачем XML конфиги, потмоу что если setings.php написать в xml то толку от этого не будет. по крайней мере не все поймут.
Спасибо.
У меня тоже 8ка не устанавливается...
У меня устанавливается.
Попробую описать подробнее странное поведение.
Устанавливается, всё проходит без ошибок. Появляется сообщение, которое обычно появляется после успешной установки, пройдите на главную или в административный раздел.
Перехожу по ссылкам, не одна не открывается.
Удаляю конфигурационный файл, снова пытается ставиться.
Самое странное, что когда страницы не открываются, там нет никакого сообщения об ошибки. Смотрел заголовки HHTP там даже ответа и запроса в логах нет. Такое ощущение что защита от DDos срабатывает, или что-то вроде того.
Самое странное, что заметил. Добавляю к адресу сайта закорючки, то есть домен.ком/lijlkjoij
и чудесным образом открывается ошибка "страница не найдена"
Вверху видно админ меню, при попытки перейти туда опять не открывается ничего.
Взял другой браузер, не тот с которого устанавливал, там картина примерно такая же только без админ меню вверху.
Ссылка
/user/register работает
закарючки для получения 404 работают
Главная не открывается без всяких ошибок.
/user/password не работает, то есть опера пишет
Connection closed by remote server
От чего это может быть?
К вопросу о быстродействии могу сказать что 404 открываться нормально.
кто-нибудь может высказать идею, от чего может не открываться не одна страница кроме
404 и /user/register
Ещё под анонимам открывается
user/1 с сообщением Доступ запрещён. Под админом с браузера где ставил тоже нет ответа сервера по адресу user/1
Может что-то с сессиями, с временем на сервере и на ПК с которого открываю?
У меня ноутбук с Debian 6 там PHP 5.3.20 Drupal 7 ругаеться в статусе что на сервере время не правильно установлено, то есть временная зона. Может от этого так?
Но всё остальное работает хорошо.
8.x-dev стоит и работает, ковыряю потихоньку.
(зри логи, ищи причину, и честно ответь себе на вопрос: "оно тебе надо? оно того стоит?")
К сожалению в логах нет записей об ошибках.
Этого мало. Очищай files
Почему 444? Если проверять права, то надо ставить 777 на всё, а потом уже выставлять правильные.
Зачем на тестовом сервере ставить защиту от DDoS? Запрос должен быть - иначе на что должен отвечает сервер?
А если нет ответа - значит на серваке ошибка на уровне PHP, ответ в его логах.
Миллион причин, гадать можно бусконечно.
Вряд ли.
Никто тебе не поверит. И если нет ошибок, значит есть записи об успешной отдаче страницы. А в этом случае должны быть заголовки от сервера, а их нет
у меня на ит патруль ан тарфие эластик тоже не поставился ксти.
В логах нет ошибок и никаких записей, пока не наберёшь
www.drupal8-test.com/белиберда
Тогда появляется
-
192.168.1.2 - - [29/Jan/2013:10:04:10 +0400] "GET /core/themes/bartik/logo.png HTTP/1.1" 304 261
192.168.1.2 - - [29/Jan/2013:10:04:10 +0400] "GET /core/themes/bartik/css/layout.css?mh9yw1 HTTP/1.1" 304 284
192.168.1.2 - - [29/Jan/2013:10:04:10 +0400] "GET /core/misc/favicon.ico HTTP/1.1" 304 261
192.168.1.2 - - [29/Jan/2013:10:04:10 +0400] "GET /core/modules/system/system.base.css?mh9yw1 HTTP/1.1" 304 285
192.168.1.2 - - [29/Jan/2013:10:04:10 +0400] "GET /core/themes/bartik/css/style.css?mh9yw1 HTTP/1.1" 304 285
192.168.1.2 - - [29/Jan/2013:10:04:10 +0400] "GET /core/modules/system/system.theme.css?mh9yw1 HTTP/1.1" 304 285
192.168.1.2 - - [29/Jan/2013:10:04:10 +0400] "GET /core/themes/bartik/css/colors.css?mh9yw1 HTTP/1.1" 304 284
192.168.1.2 - - [29/Jan/2013:10:04:10 +0400] "GET /core/misc/modernizr/modernizr.min.js?v=2.6.2 HTTP/1.1" 304 284
192.168.1.2 - - [29/Jan/2013:10:04:10 +0400] "GET /core/themes/bartik/css/style.css?mh9yw1 HTTP/1.1" 304 285
192.168.1.2 - - [29/Jan/2013:10:04:10 +0400] "GET /core/modules/field/theme/field.css?mh9yw1 HTTP/1.1" 304 284
192.168.1.2 - - [29/Jan/2013:10:04:10 +0400] "GET /core/themes/bartik/css/colors.css?mh9yw1 HTTP/1.1" 304 284
192.168.1.2 - - [29/Jan/2013:10:04:10 +0400] "GET /core/modules/user/user.css?mh9yw1 HTTP/1.1" 304 284
192.168.1.2 - - [29/Jan/2013:10:04:10 +0400] "GET /core/themes/bartik/css/print.css?mh9yw1 HTTP/1.1" 304 284
192.168.1.2 - - [29/Jan/2013:10:04:10 +0400] "GET /core/themes/bartik/css/print.css?mh9yw1 HTTP/1.1" 304 284
192.168.1.2 - - [29/Jan/2013:10:04:10 +0400] "GET /core/themes/bartik/images/buttons.png HTTP/1.1" 304 261
-
Права поставил кругом 777
В папке /sites есть файл example.sites.php как понял это для мультисайтовости.
Но может с этим файлом что-то надо сделать?
http://drupal.org/node/158043
Наконец то заюзал дистрибутив. Пока что разницы с 7кой не увидел. Даже 7 ка больше нравится
А что ты искал в ней? UI там ещё особо не пилился, всё самое интересное - в коде. Ты смотрел код или просто тыкал в ссылки?
PS: А вот views теперь в ядре.
Я внешне оценил. Код меня мало интересует. Будем ждать релиза.
А у меня пока не получилось пока.
Как понял из текста статьи там написано, что это вывод и лог ошибок PHP.
Это у меня сделано. Там написано о белой странице. У меня не белая страница.
У меня подобие ошибки 404 но не она.
У меня в браузере написано "The connection was reset" и всё.
Так бывает когда в адресной строке наберёшь несуществующий адрес. Только тогда там написано "Server not found". Уже начал думать что я виртуал хост криво создал.
Всё удалил, создал по новой, почистил базу, установил, установилось и опять после установки The connection was reset.
Ещё внимательнее почитаю страницу по ссылке, но там вроде не про это.
Остановил сервер базы данных, появилась белая страница, запись в логах, включаю снова
==
The connection was reset
The connection to the server was reset while the page was loading.
The site could be temporarily unavailable or too busy. Try again in a few
moments.
If you are unable to load any pages, check your computer's network
connection.
If your computer or network is protected by a firewall or proxy, make sure
that Firefox is permitted to access the Web.
==
и всё, не ошибок, не логов.
iNFerNo пожалуйста, напишите, что у вас было?
Почему не устанавливалось?
Думаю нужно отладчиком просмотреть где ошибка, если это ошибка.
Пока не успеваю заниматься этим, но уже, раз оно так уперлось, то придёться соответствующе и копать.
Вроде нашёл где получиться ошибка
/core/vendor/symfony/class-loader/Symfony/Component/ClassLoader/UniversalClassLoader.php:299
в коде это
<?php// PEAR-like class name
$normalizedClass = str_replace('_', DIRECTORY_SEPARATOR, $class).'.php';
foreach ($this->prefixes as $prefix => $dirs) {
if (0 !== strpos($class, $prefix)) {
continue;
}
foreach (
$dirs as $dir) {$file = $dir.DIRECTORY_SEPARATOR.$normalizedClass;
if (is_file($file)) {
return $file;
}
}
}?>
Пока не докопался почему и не анализировал это программой.
У кого-нибудь есть идеи, от чего это?
Может это из за APC ?
Только в голову пришло, выключу, напишу.
Как ты локализовал проблему?
Установил xbebug
прописал в .htaccess
php_value xdebug.default_enable 1
php_value xdebug.var_display_max_depth 6
php_value xdebug.remote_enable 1
php_value xdebug.remote_host 192.168.1.2
php_value xdebug.remote_port 9000
php_value xdebug.profiler_output_dir /home/web/domains/drupal/drupal8-test/debug
php_value xdebug.trace_output_dir /home/web/domains/drupal/drupal8-test/debug
php_flag xdebug.auto_trace 1
php_flag xdebug.profiler_enable 1
получил файл с трассировкой и логом
в одном файле в конце написано cachegrind.out.7239
cfl=/home/web/domains/drupal/drupal8-test/www/core/vendor/symfony/class-loader/Symfony/Component/ClassLoader/UniversalClassLoader.php
cfn=Symfony\Component\ClassLoader\UniversalClassLoader->findFile
calls=1 0 0
250 197
во втором trace.2043925204.xt в конце написано
0.3652 6772500 -> strpos() /home/web/domains/drupal/drupal8-test/www/core/vendor/symfony/class-loader/Symfony/Component/ClassLoader/UniversalClassLoader.php:299
оба файл фактически завершаются на UniversalClassLoader
Как-то помню, что была программа которая обрабатывала логи и отчёты трассировки и показывала схему. Этим я баловался года 3 назад, где-то написано как это делать.
Как найду способ более подробно проанализировать отчёт, так будет яснее, потмоу что кто его знает. Ввполнение заканчивается на данной строке. но ошибка может и где-то раньше быть.
Выложил бы весь лог, да он длинный 4144 строки, и не думаю что это будет полезно.
Спасибо.
Может стоит обновить dev версию... там очень активно фиксятся баги, но это походу что-то с окружением связано.
Поставил себе Druapl 8
Packaged version: 8.x-dev
February 17, 2013 - 00:55
Установился без проблем. Покнопал, тоже норм.
Посмотрел что тама у него внутри... много интерсного.
Скажем так, приятно впечатлен
Парни, кто-то уже пробовал писать модули под D8?
Тоже обновил 8 друпал модулек один еще добавил...
это, у всех не показывается редактор в формах коментов и боди? устанавливаю... кнопку выбираю... а не показывается... даже поле для ввода текста не показывается...
9 ядро уже выложили на друпал орг