Новое ядро Drupal 8 - Drupal kernel!

Аватар пользователя andypost@drupal.org andypost@drupal.org 3 июня 2012 в 16:47

таки состоялось! ветка ядра с Add a Drupal kernel; leverage HttpFoundation and HttpKernel
Бнчмарки показывают 10% потерю производительности в текущем состоянии - когда страое и новое живут одновременно http://drupal.org/node/1578090

Комментарии

Аватар пользователя Murz Murz 4 июня 2012 в 11:59

А что это за ветка и какие она даёт преимущества, чем отличается от обычной? На английском по ссылке прочитал, но чёт всё-равно мало чего понял.

Аватар пользователя andypost@drupal.org andypost@drupal.org 4 июня 2012 в 20:46

Это другое ядро, которое принимает и обслуживает запросы, вскоре будут заменены hook_menu и система роутинга

Аватар пользователя Shok211 Shok211 4 июня 2012 в 20:59

Ввели namespace, новую структуру папок, отдельные классы для каждой из сущностей, symfony autoloader

Аватар пользователя yexel yexel 12 июня 2012 в 14:02

А я вот не могу понять - для чего это нашествие версий?
Есть недавно вышедший 7-й друпал.
К нему еще не все привыкли.
А уже готовится 8-й.
А при этом есть еще активно использующийся 6-й.

Чтобы пользователи и разработчики окончательно сошли с ума? Smile

Аватар пользователя yexel yexel 15 июня 2012 в 20:47

Shok211 wrote:
Вы наверное не разработчик

Нет. Я разработчикам задачи ставлю.
А это что-то меняет?

Аватар пользователя xxandeadxx xxandeadxx 12 июня 2012 в 17:59

"yexel" wrote:
Есть недавно вышедший 7-й друпал.
К нему еще не все привыкли.
А уже готовится 8-й.
А при этом есть еще активно использующийся 6-й.

если следовать этой логике, то идеальным было бы остановиться на 4-й версии?

Аватар пользователя yexel yexel 15 июня 2012 в 20:52

xxandeadxx wrote:

если следовать этой логике, то идеальным было бы остановиться на 4-й версии?

Идеальным было бы как-то простимулировать разработчиков модулей на 6-ке, дабы они "допилили" бы до приятного состояния модули на 6-ке.
А не заставлять их "распыляться" и на доработку по пожеланиям модулей и на 6-ке и на 7-ке.
Но это фанастика, понимаю.
и в результате приходится "допиливать" модули с drupal.org
Хотя... издержки open source, понимаю Smile

Аватар пользователя sg85 sg85 14 июня 2012 в 10:09

"yexel" wrote:
Есть недавно вышедший 7-й друпал.
К нему еще не все привыкли.
А уже готовится 8-й.
А при этом есть еще активно использующийся 6-й.

Вышел то 7 даже очень давно, однако, из-за значительных различий в самих принципах работы с 6, сторонние модули(ибо делать сайт на чистом ядре это слишком круто, даже для джедаев, особенно если оно само немного глючит) более или менее стабильно работать стали действительно не давно(если сравнивать случай с 5 и 6, где по сути просто переработали API), вижу с 8ркой будет аналогичная история - ядро работать будет, а модули к нему портироваться еще несколько лет, т.е. год-два как минимум, после официального релиза, почти все будут сидеть на 7(так же как это было со всеми предыдущими версиями, причем не только Drupal, простейший пример - некоторые на Win7 с XP до сих пор отказывается переходить, хотя уже есть предрелизная 8рка(которая странным образом похожа на последнюю версию Ubuntu, хоть в нем и не пахнет КДЕ)

Аватар пользователя yexel yexel 15 июня 2012 в 20:45

sg85 wrote:

... более менее стабильно работать с 7-кой стали действительно не давно

Вот и я об этом.
Мы в одном проекте попробовали 7-ку.
Да, прикольно, да интересно.
Но некоторых нужных модулей на тот момент - не было.

Сейчас посмотрел - появились. В качестве эксперимента решили один проект на 6-ке перевести на 7-ку.
Ну типо надо ведь двигаться рядом с прогрессом.
И только это собрались делать - и тут вижу новость про начало торжественного шествия 8-ки.

Как думаете, стоит экспериментировать с 7-кой, если уже накоплен некоторый опыт с 6-кой?
Или стоит сразу на 8-ку ориентироваться?

Аватар пользователя xxandeadxx xxandeadxx 15 июня 2012 в 17:52

"inza" wrote:
Для многих задач Win7 по сравнению с XP ничего не дает

Для многих задач Win7 по сравнению с XP многое дает

Аватар пользователя drupby drupby 15 июня 2012 в 20:05

"inza" wrote:
Просто у меня железо дохлое.

просто надо меньше разглагольствовать о херне всякой и больше дел делать - купишь себе и железо
правда мозги за лавэ не приобретешь - тут уж придётся довольствоваться тем что есть

Аватар пользователя yexel yexel 15 июня 2012 в 20:53

xxandeadxx wrote:
тру кодеры работают только за еду!

где этих тру кодеров найти, не подскажете? Smile

Аватар пользователя Shok211 Shok211 15 июня 2012 в 21:12

Конкретно 8 ориентирована на разработчиков. И вы глубоко заблуждаетесь если думаете что решить одну и ту же "Нестандартную" задачу Легче на 6 чем 7 или тем более 8.

Включение динамических запросов, сущностей, AJAX framework... ничего подобного (в плане разработки) в 6 даже не было, а время на создание собственных велосипедов ой как не хочется тратить.

Так разработка сайта на семерке сокращается порядка полутора раз (Чистое Ядро). А перевод ядра 8 пускай и только части на ООП парадигму включая интеграцию с Symfony. Позволит использовать всякие вкуснящки вроде TWIG, Dependency Injector, Doctrine без придумывания собственных костылей.

И надеюсь наконец добавят Stack Traces для обработки ошибок. И будем нам счастье.

Аватар пользователя xxandeadxx xxandeadxx 15 июня 2012 в 21:21

"yexel" wrote:
начало торжественного шествия 8-ки.

вас обманули. шествие начнётся через полтора года

Аватар пользователя drupby drupby 15 июня 2012 в 21:47

"inza" wrote:
У полруги рядом на столе стоит современный комп с высокочастотным процем и мамой - постоянно глючит сбоит и вырубается. 3-4 часа стабильной работы в сутки.

офигенно репрезентативная выборка , по которой можно делать какие то выводы .

Аватар пользователя Crea Crea 15 июня 2012 в 23:09

Для маленьких и средних проектов экономически выгодно пропускать 1 версию про апгрейде.
Крупные сайты выгоднее не апгрейдить и поддерживать самим.

Аватар пользователя humorist humorist 16 июня 2012 в 13:28

Да о чем вы тут пишите!? Седня наши с Грецией играют!!! Выйдут ли наши в 8-ку сильнейших сборных Европы!? Вот о какой 8-ке нужно сейчас думать!!!

Аватар пользователя Dan Dan 16 июня 2012 в 13:46

"humorist" wrote:
Вот о какой 8-ке нужно сейчас думать!!!

И как наши думы помогут футболистам? Smile

Аватар пользователя WadimKo51 WadimKo51 11 января 2013 в 2:50

Возникло три вопросоа.

1 Как понял будет использоваться конфигурация через XML
Это сделанно чтобы те кто знает только PHP изучали ещё и XML ?
Какой толк от конфигурации через XML? Это сделанно чтобы конфиги хранить не в базе а в XML ?

2 Почему не сделать перевод хранящимся не в базе а в файлах, к ак в большенстве движков, наримен SMF и так далее и прсото вызывать значение переменных в зависимости от языка.

3 Так как новая версия основанна на фреймворке то там будет очень много файлов инклуйлиться для генерации страницы. Это будет медленно. Будет ли какой-то функцонал компиляции?

Это всё написал потмоу что Drupal 8 по всей видимости будет очень похож на Magento. Оно тоже оснвоанно на фреймворке, толко на Zend, там тоже есть конфигурация через XML и из админки туда заносяться данные при изменении настроек.

Больше всего пугает большое количество файлов, и отсутствие кнопки компиляции. На Magento такая кнопка даёт прирост прмиерно в 3 раза, в зависимости от скорости жётских дисков хостера. Особенно это сказываетсь после долгого простоя, когда файлы из кэша в памяти удаляются и снова туда нужно загружать, после длительной неактивности сайта.

Так так оно наверное будет удобно для разработки, но что-то монстрозностью всё это пугает.

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

Аватар пользователя Murz Murz 11 января 2013 в 10:13

WadimKo51 wrote:
3 Так как новая версия основанна на фреймворке то там будет очень много файлов инклуйлиться для генерации страницы. Это будет медленно. Будет ли какой-то функцонал компиляции?

Это всё написал потмоу что Drupal 8 по всей видимости будет очень похож на Magento. Оно тоже оснвоанно на фреймворке, толко на Zend, там тоже есть конфигурация через XML и из админки туда заносяться данные при изменении настроек.

Больше всего пугает большое количество файлов, и отсутствие кнопки компиляции. На Magento такая кнопка даёт прирост прмиерно в 3 раза, в зависимости от скорости жётских дисков хостера. Особенно это сказываетсь после долгого простоя, когда файлы из кэша в памяти удаляются и снова туда нужно загружать, после длительной неактивности сайта.

Так так оно наверное будет удобно для разработки, но что-то монстрозностью всё это пугает.


По-моему фреймворк в Друпал 8 выбрали не просто так, а после многочисленных тестов и анализов, которые показали что с Symphony он работает вроде как быстрее и появляются ещё какие-то преимущества, поэтому выбор был обоснован именно улучшениями, а не монстрозностью, интерпрайзом и добавлением проблем разработчикам.

Аватар пользователя Dan Dan 11 января 2013 в 3:52

"WadimKo51" wrote:
1 Как понял будет использоваться конфигурация через XML
Это сделанно чтобы те кто знает только PHP изучали ещё и XML ?
Какой толк от конфигурации через XML? Это сделанно чтобы конфиги хранить не в базе а в XML ?

Безусловно ради изучения юзерами XML. Разве могут быть другие причины Smile
Drupal растёт и потихоньку "набирается ума", используя проверенные техники, такие как нормальный шаблонный движок, например. Или тектовые конфиги, которые можно легко править, деплоить, отслеживать в VCS.

"WadimKo51" wrote:
2 Почему не сделать перевод хранящимся не в базе а в файлах, к ак в большенстве движков, наримен SMF и так далее и прсото вызывать значение переменных в зависимости от языка.

Потому что БД быстрее.

"WadimKo51" wrote:
3 Так как новая версия основанна на фреймворке то там будет очень много файлов инклуйлиться для генерации страницы. Это будет медленно. Будет ли какой-то функцонал компиляции?

А APC и компания для чего нужны?

"WadimKo51" wrote:
Ведь модуль переводов утяжеляет работу сайта, все это знают.

Да. На говнохостингах с минимумом памяти для MySQL. Drupal не слишком-то на них ориентирован.

"WadimKo51" wrote:
Пользователь заходит в раздел переводы, открываетсья редактор с переменными и можно самому писать туда текст.

Что мешает делать это сейчас с po-файлами?

Аватар пользователя WadimKo51 WadimKo51 11 января 2013 в 8:17

К сожалению всё то, что вы написали не очень радует.
Но всё ровно СПАСИБО за ответ. От вас суть не зависит.

-
А APC и компания для чего нужны?
-
Мало где на хостинге есть подобное.
И во вторых, если сайт на виртуальном хостинге, то если сайт не активен какое-то время, всё это обнулиться даже если есть APC
И будет так. Псетитель придёт на сайт, и будет ждять 30 секунд пока откроеться главня, ну а потом будет нормально тыкать по страницам.
а если это будет поисковик то будет не хорошо.

////

Что мешает делать это сейчас с po-файлами?
-
Ничего. вопрос был в продолжение быстрости базы данных по сравнению с файлами. Можно посмотреть подробнее, где написано что перевод в базе быстрее чем на файлах?
////

А мне нравится такой шаблоный движок как сейчас на PHP

Не дай Бог, или кто угодно ещё, туда ещё Смарти доумяться прикрепить поддержки новомодности ради.
Тфу Тфу Тфу чтоб не накаркать....
Вот Смарти точно для изучения самого себя похоже нужен.
Не понимаю для кого это. проще уж PHP изучить на уровне правки шаблонов, чем Смарти изучать, чтоб писать прослойку.

Аватар пользователя Crea Crea 11 января 2013 в 8:32

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

Аватар пользователя WadimKo51 WadimKo51 11 января 2013 в 9:05

А причём тут наивнсть?
Хотите сказать, что всё развитие данного двжка изначально за много лет задумывалось для того чтобы стать корпоративным монстном который для работы требует отдельного железного сервера?

Ну для интерпрайз есть Typo3 с его супер шаблонизатором с собственным языком с интерпретатором TypoScript...
Хотите сказать, что будет что-то подобное?
Ну, как-то савсем уж грустно.

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

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

И это не наивное рассуждение.

Или вы хотите сказать что товарищи из коммерческих CMS побашляли разработчиков бесплатных решений, чтоб те не составляли такой конкуренции?

А причём тут маленькие сайты или большие, вся суть в бабле.

По вашей логике получаеться, что если сайт к прмиеру большой, и не коммерческий, так это уже для наивных?

Куда мир катется, все на бабле помешались.
Интересно посмотреть цифру которая являлась бы потолком.

Аватар пользователя Dan Dan 11 января 2013 в 9:13

"WadimKo51" wrote:
Мало где на хостинге есть подобное.

Ещё раз - Drupal не ориентируется на хостинги за 30 рублей, хотя даже для них можно его подтюнить.

"WadimKo51" wrote:
И будет так. Псетитель придёт на сайт, и будет ждять 30 секунд пока откроеться главня, ну а потом будет нормально тыкать по страницам.

Если сайт посещают 2 раза в день, то может вообще его в статику сбросить через тот же буст или закэшировать через nginx, зачем сервер мучать?)

"WadimKo51" wrote:
Ничего. вопрос был в продолжение быстрости базы данных по сравнению с файлами. Можно посмотреть подробнее, где написано что перевод в базе быстрее чем на файлах?

Не вижу ни одной причины, чтобы БД была _медленне_ файлов. А тесты я уже когда-то гонял. Меня устроил результат.

"WadimKo51" wrote:
Не дай Бог, или кто угодно ещё, туда ещё Смарти доумяться прикрепить поддержки новомодности ради.

Смарти уже был.

"WadimKo51" wrote:
Не понимаю для кого это. проще уж PHP изучить на уровне правки шаблонов, чем Смарти изучать, чтоб писать прослойку.

Это пока не познаешь нормальные шаблонные движки)

Аватар пользователя Crea Crea 11 января 2013 в 9:15

Quote:
А причём тут наивнсть?

Это не про вас. Просто часто встречаю на drupal.org посты типа "Сможет ли Друпал угодить и корпоративной аудитории и маленьким сайтам ?".

Да, Друпал уже давно не то(р)т.

Аватар пользователя Crea Crea 11 января 2013 в 9:20

Мне интересно другое.
Сможет ли интеграция Симфони и т.д. упростить Дру, уменьшить его собственный код.
Это, на самом деле, самый главный вопрос существования Дру как популярного, массового продукта.
Пока ставлю, что нет Smile

Аватар пользователя WadimKo51 WadimKo51 11 января 2013 в 10:19

А у меня есть сайт на Друпал6 на хостинге за доллар в месяц, и ничего прекрасно работает. Посешаемость человек 20 в сутки, и как раз как вы написали страницы закэшированны в статику так как это подобие сайта визитки.

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

По поводу интеграции с Симфони, это вопрос не ко мне, не пользовался данным, и подобным им фреймворком, но судя по Magento, которым пользовался могу дмать что скорее оно уменьшит затраты на поддержания части кода выполняющего рутинные операции чем упростит. Оно скорее удешевит саму разработку движка. Хотя это тоже смотря что задуманно. Если задуманно написать что-то по функциональности привлекательное, но не думать о бустродействии, то это упростит. Хотя по идее это наложит определенные ограничения.

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

Хоть ЗендФреймворк и считаетсья вроди самым медленнм в мире, если не ошибаюсь, но у него всё-таки за спиной разработчики PHP.

Аватар пользователя Dan Dan 11 января 2013 в 10:21

"Crea" wrote:
Сможет ли интеграция Симфони и т.д. упростить Дру, уменьшить его собственный код.

Дык посмотри на текущие размеры дистров - 8-ка в 2.5 раза тяжелее 7-ки. Фигушки проще станет )

Аватар пользователя Crea Crea 11 января 2013 в 11:42

Dan wrote:
"Crea" wrote:
Сможет ли интеграция Симфони и т.д. упростить Дру, уменьшить его собственный код.

Дык посмотри на текущие размеры дистров - 8-ка в 2.5 раза тяжелее 7-ки. Фигушки проще станет )

А если вычесть сторонний код ? Я так понимаю, туда запихнули все GPL-ное, что используется..не ?

Аватар пользователя WadimKo51 WadimKo51 11 января 2013 в 10:25

Ещё по поводу ереводов в файлах а не в базе могу скзать вот такой пример.
Есть OpenCart перевод в файлах. У него нет своего АПИ, модули ставяться правкой ядра.
Есть PrestaShop по своей сути очень похож кстати на Drupal там тоже перевод в базе, модули используют хуки и заменяюь функции в ядре.

Разица в производительности, сужу по загрузке страницы очень велика. Но не на большом числе твоаров, но это суть уже в другом.

Хотя это не от переодов, но всё-таи есть тенденция, движки где перевод в базе более тяжёлые по своей логике, поэтмоу возникают определенные ассоциации.

Было бы интересно знать, что переводы в базе хотя бы не то что быстрее, а хотя бы не на порядок медленнее файлов.

Аватар пользователя Murz Murz 11 января 2013 в 10:40

WadimKo51 wrote:
Было бы интересно знать, что переводы в базе хотя бы не то что быстрее, а хотя бы не на порядок медленнее файлов.

Что быстрее - зависит от конкретных запросов.

Если нужно загрузить 5 строчек перевода - то база будет однозначно быстрее, чем парсить весь файл с 500 строчками.

Если нужно загрузить 500 строчек и все они в одном po файле - то файл быстрее.

Если нужно загрузить 500 строчек но все они раскиданы в 100 po файлах - то в этом случае мне кажется база будет быстрее.

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

Ведь если мы грузим файл, то чтобы найти строку с ключом "phrase" нам нужно подгрузить весь файл со всеми строками, сделать полный перебор каждой строки сверху вниз и сравнивать с ключом. А база делает тот же самый поиск по индексу, поэтому сделает поиск в разы быстрее по процессорному времени. Но при использовании базы ещё добавляются задержки на формирование и парсинг sql-запроса, передачу данных обратно в php и др, поэтому тоже всё зависит от случая. Но при огромном количестве строк мне кажется база всё же выиграет в производительности.

Например на моём сайте 18000 строк перевода, сколько займёт процессорного времени перебор этого массива чтобы найти определенный ключ и сколько - поиск по индексу в базе?

Также ещё стоит учесть, что при применении файлов - это всё будет подгружаться из сотни файлов, каждый из которых нужно подгрузить через file_get_contents, распарсить в массив - это тоже лишнее время и ресурсы. И ещё потом это всё загрузить в память - судя по объему текущей таблицы в mysql - около 4 мегабайт памяти оно смело откушает.

Аватар пользователя kyky kyky 11 января 2013 в 10:38

Переводы в базе -- это шляпа. Да, одну строку вытащить из базы -- это быстро. А если в процессе генерации страницы нужно перевести 100 строк, то 100 запросов будет медленнее.
Переводы нужно хранить в памяти или каком-то быстром key->value хранилище.

Аватар пользователя Murz Murz 11 января 2013 в 10:45

kyky wrote:
Переводы в базе -- это шляпа. Да, одну строку вытащить из базы -- это быстро. А если в процессе генерации страницы нужно перевести 100 строк, то 100 запросов будет медленнее.
Переводы нужно хранить в памяти или каком-то быстром key->value хранилище.

Переводы кешируются для каждой страницы, поэтому для анонимуса - они будут грузиться одним запросом, а 100 запросов будет делаться только после сброса кеша.

Возьмём реальный пример моего сайта: всего 18 тысяч строк перевода в базе, из которых нужно загрузить для одной страницы 100 строк.

При использовании базы:
1. Делаем 100 sql запросов, выполняется 100 поисков по масссиву из 18 тысяч строк с использованием индекса.

При использовании файлов:
1. Подгружаем все po-файлы в память - каждый файл читаем с диска, пробегаемся по каждой строчке файла и формируем PHP массив.
2. 100 раз обращаемся к этому массиву для поиска значения по ключу - т.е. 100 раз делаем полный перебор всех строк для поиска нужной (навряд ли php использует индекс для поиска по ключам массива).

В итоге имхо первый способ будет быстрее второго.

Аватар пользователя kyky kyky 11 января 2013 в 11:01

"Murz" wrote:
Переводы кешируются для каждой страницы, поэтому для анонимуса - они будут грузиться одним запросом, а 100 запросов будет делаться только после сброса кеша.

Вот кстати, то, что анонимам Друпал показывает одно, а залогиненым другое -- есть чистой воды мудизм. Нельзя делать разницу между анонимом и пользователями. И те и другие должны видеть актуальную информацию. Это идиотское правило, из-за него вся система кеширования Друпала построена чрез жопу.

"Murz" wrote:
Возьмём реальный пример моего сайта:...

Конечно, все зависит от конкретного случая.
Файлы переводов могут лежать на RAM-диске, скорость доступа к ним буде выше на порядки;
Переводы могут храниться как php-массивы вида "исходная строка"->"локализованная строка".
Разрабы любезно предлагают выносить переводы в settings.php

Аватар пользователя Murz Murz 11 января 2013 в 11:29

kyky wrote:
"Murz" wrote:
Переводы кешируются для каждой страницы, поэтому для анонимуса - они будут грузиться одним запросом, а 100 запросов будет делаться только после сброса кеша.

Вот кстати, то, что анонимам Друпал показывает одно, а залогиненым другое -- есть чистой воды мудизм. Нельзя делать разницу между анонимом и пользователями. И те и другие должны видеть актуальную информацию. Это идиотское правило, из-за него вся система кеширования Друпала построена чрез жопу.

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

kyky wrote:
"Murz" wrote:
Возьмём реальный пример моего сайта:...

Конечно, все зависит от конкретного случая.
Файлы переводов могут лежать на RAM-диске, скорость доступа к ним буде выше на порядки;
Переводы могут храниться как php-массивы вида "исходная строка"->"локализованная строка".
Разрабы любезно предлагают выносить переводы в settings.php

Я что-то ни одного хостинга не припомню где дают RAM-диск для переводов Wink
А php-массив всё-равно нужно откуда-то загрузить (опять же из файла размером в 4 мегабайта) и потратить процессорное время на раскукоживание в пямять, даже если он через serialize записан. И после того как мы получили php-массив в оперативной памяти - поиск каждого ключа полным перебором 18 тысяч строк - никуда не делся, а он всяко медленней чем поиск по индексу.

И 18 тысяч строк - это не конкретный тяжелый случай, а обычный стандартный сайт на друпале с использованием около 10-20 дополнительных модулей.

Аватар пользователя WadimKo51 WadimKo51 11 января 2013 в 11:50

А зачем вы всё в кучу ложите?
то есть всё в один файл?

Для каждого модуля может быть свой файт, как напрмиер в 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 сделано.

Аватар пользователя Murz Murz 11 января 2013 в 11:57

WadimKo51 wrote:
А зачем вы всё в кучу ложите?
то есть всё в один файл?

Для каждого модуля может быть свой файт, как напрмиер в OpenCart вот прмиер
так сделано было в osCommerce OpenCart, Даже в многострадальной Joomla так сделано.


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

Поэтому остаётся два пути - либо загрузить всё сразу, либо при каждом запросе на первод разбираться какой это модуль спрашивает, в какой папке и какой файл подгружать, потом подгружаем файл, парсим и выводим конкретную строку. Соответственно при каждом запросе будет тратиться время на все эти операции, а если запросов не 2-3 а более 100 - то это будет заметно медленнее, чем за раз подгрузить всё что может понадобиться, либо работать с базой.

Аватар пользователя WadimKo51 WadimKo51 11 января 2013 в 13:04

В OpenCart тоже грузиться только то, что отображаеться.
А с чем явязано, что Drupal грузит все установленные модули?

Вы очень интересно написали про это. Не знал таких деталей.

Получаетсья что если например я установил модуль rules и сделал одно только правило на то, чтобы когда пользователь пожаловался на ссобщение форума то администратору приходило письмо.
Получаетсья при загрузке страниц, если не кто не что не нажимет всё ровно будет грузитьмя этот модуль?

или например если я установил модуль опросов quiz и quizreg от спам ботов и сделал опрос на отдельной странице. То при загрузке савсем других разделов всё ровно будет грузиться модуль quiz?

Примерно так же будет и в 8 версии?

Аватар пользователя Murz Murz 11 января 2013 в 13:40

WadimKo51 wrote:
В OpenCart тоже грузиться только то, что отображаеться.
А с чем явязано, что Drupal грузит все установленные модули?

Вы очень интересно написали про это. Не знал таких деталей.

Получаетсья что если например я установил модуль rules и сделал одно только правило на то, чтобы когда пользователь пожаловался на ссобщение форума то администратору приходило письмо.
Получаетсья при загрузке страниц, если не кто не что не нажимет всё ровно будет грузитьмя этот модуль?

или например если я установил модуль опросов quiz и quizreg от спам ботов и сделал опрос на отдельной странице. То при загрузке савсем других разделов всё ровно будет грузиться модуль quiz?

Примерно так же будет и в 8 версии?


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

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

По поводу Joomla - там всё это сделано намного хуже: в построении странице участвует только один модуль (который вызывается через url, например com_content), и он уже сам вынужден подгружать все остальные модули, которые ему понадобятся.

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

Аватар пользователя natbampo natbampo 11 января 2013 в 13:17

"WadimKo51" wrote:
А с чем явязано, что Drupal грузит все установленные модули?

При загрузке страницы постоянно грузятся головные файлы каждого включенного модуля (там где реализованы хуки), а не прям "весь" модуль со всем функционалом.

Аватар пользователя volocuga@drupal.org volocuga@drupal.org 11 января 2013 в 13:24

"Crea" wrote:
Так что фрилансерам-одиночкам и небольшим сайтам тут скоро станет ловить нечего.

Уже нечего. Трудозатраты охуенные, люди всё меньше понимают, за что платить, ведь есть жумла, вп

Аватар пользователя Murz Murz 11 января 2013 в 14:00

<a href="mailto:volocuga@drupal.org">volocuga@drupal.org</a> wrote:
"Crea" wrote:
Так что фрилансерам-одиночкам и небольшим сайтам тут скоро станет ловить нечего.

Уже нечего. Трудозатраты охуенные, люди всё меньше понимают, за что платить, ведь есть жумла, вп

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

Аватар пользователя Crea Crea 11 января 2013 в 16:07

Murz wrote:

Друпал и не предназначен для небольших сайтов аля сайт-визитка или блог юного словоблуда

Это лишь ваше частное мнение. Многие с вами не согласятся..

Аватар пользователя Murz Murz 11 января 2013 в 16:19

Crea wrote:
Murz wrote:

Друпал и не предназначен для небольших сайтов аля сайт-визитка или блог юного словоблуда

Это лишь ваше частное мнение. Многие с вами не согласятся..

Я имел в виду не то, что на нем сложно или невозможно сделать небольшой сайт, а о том - что это слишком функциональная и гибкая система, чтобы её использовать для простых сайтов, т.к. грузится 100% функционала, а используется тока 1-2%.

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

А целевой сайт друпала - это всё же не простенький сайт, а сайт среднего уровня, где активно используется мощь друпала.

Конечно же специалистам по Друпалу проще и быстрее сделать и двухстраничный сайт на drupal, но с точки зрения ресурсоёмкости это не логично.

Аватар пользователя natbampo natbampo 11 января 2013 в 15:17

"Murz" wrote:
По-другому никак это особо и не реализуешь, ведь любой модуль в любой момент может запросить функцию другого модуля.

Ну наверное в 8-ой версии они как то от хучной системы будут уходить, она же процедурная, а симфони - ооп. Не смотрел правда.

"Murz" wrote:
Друпал и не предназначен для небольших сайтов аля сайт-визитка или блог юного словоблуда

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

Аватар пользователя Crea Crea 11 января 2013 в 16:06

Ну вот пока можно мышкой натыкать результат оно кое-как работает...а дальше случается "опаньки". И чем дальше с каждой новой версией Дру, тем это "опаньки" становится все более суровым ))

Аватар пользователя natbampo natbampo 11 января 2013 в 17:00

Murz, для простого сайта, визитки и т.д., на сайте включается кеш + буст и работает как миленький. Зато это друпал, с админкой друпал, модулями друпал, поддержкой друпал. А не какая то другая цмс.

Аватар пользователя drupby drupby 11 января 2013 в 17:06

"natbampo" wrote:
Murz, для простого сайта, визитки и т.д., на сайте включается кеш + буст и работает как миленький. Зато это друпал, с админкой друпал, модулями друпал, поддержкой друпал. А не какая то другая цмс.

с перспективой развития его до
"Murz" wrote:
сайт среднего уровня, где активно используется мощь друпала.

Аватар пользователя Dan Dan 11 января 2013 в 17:59

"WadimKo51" wrote:
Было бы интересно знать, что переводы в базе хотя бы не то что быстрее, а хотя бы не на порядок медленнее файлов.

Это проистекает из специфики БД. В основе любой БД лежит файловое хранилище. Между приложением и файлом есть прослойка ФС, которая кэширует и оптимизирует обращения к файлам. Однако только на доступ к самим файлам. Оптимизация доступа к содержимому файлов ложиться на приложение, в нашем случае - на систему gettext, которая компилирует файлы переводов в специальный формат .mo. То есть, по сути, она выполняет роль спец-СУБД, которая при запросе к ней "Дай мне перевод строки номе 17 из файла core.php" находит файл core.mo и вычепляет из неё строку номер 17. Притом для быстрого извлечения этой строки надо чтобы кэш ФС был "горячим", иначе стразу имеем тормоза на дисковых операциях.
Что происходит в случае с БД? Обращение к файлам БД идёт постоянно, поэтому они в кэше ФС будут с гораздо большей вероятностью, плюс БД кэширует запросы и - мало того - выполнение этих запросов. На нормальном хостинге половина БД будет постоянно в памяти висеть, что даст ощутимый выигрыш и при сотнях запросах.

"kyky" wrote:
Переводы в базе -- это шляпа. Да, одну строку вытащить из базы -- это быстро. А если в процессе генерации страницы нужно перевести 100 строк, то 100 запросов будет медленнее.
Переводы нужно хранить в памяти или каком-то быстром key->value хранилище.

При наличии большого объёма ОЗУ и БД очень хорошо оптимизируется, поэтому отпадает необходимость в настройках дополнительных хранилищ.

"kyky" wrote:
Вот кстати, то, что анонимам Друпал показывает одно, а залогиненым другое -- есть чистой воды мудизм. Нельзя делать разницу между анонимом и пользователями. И те и другие должны видеть актуальную информацию. Это идиотское правило, из-за него вся система кеширования Друпала построена чрез жопу.

Ну вот чего ты троллишь-то? ) Сам прекрасно понимаешь, что можно всё гибко настроить и сбрасывать гибко кэши и давать анонимам видеть самую актуальную информацию, если это необходимо.

"Crea" wrote:
А если вычесть сторонний код ? Я так понимаю, туда запихнули все GPL-ное, что используется..не ?

"Вот, мальчик, тебе делать нехрен - сиди и складывай!" (с) Smile
Добавили дохрена всего и это всё теперь - ядро. И это всё теперь надо, по-хорошему, перелопатить, чтобы знать как работает новая версия. Причём различия от 7-ки принципиальные, что не радует в смысле прогнозов по времени Sad

"WadimKo51" wrote:
В OpenCart тоже грузиться только то, что отображаеться.
А с чем явязано, что Drupal грузит все установленные модули?

Архитектура такой. В случае наличия кэша опкода на это глубоко наплевать - оно и так в памяти сидеть будет.

"Murz" wrote:
Друпал и не предназначен для небольших сайтов аля сайт-визитка или блог юного словоблуда, для этого есть вп и жумла. ....Я имел в виду не то, что на нем сложно или невозможно сделать небольшой сайт, а о том - что это слишком функциональная и гибкая система, чтобы её использовать для простых сайтов, т.к. грузится 100% функционала, а используется тока 1-2%.

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

Аватар пользователя natbampo natbampo 11 января 2013 в 18:10

"Dan" wrote:
Добавили дохрена всего и это всё теперь - ядро. И это всё теперь надо, по-хорошему, перелопатить, чтобы знать как работает новая версия. Причём различия от 7-ки принципиальные, что не радует в смысле прогнозов по времени :(

Печаль. С новомодными веяниями вроде тех что сайт по друпал way должен быть без своих написанных (под этот сайт) модулей, а только настройкой орг-овских модулей, сложно придумать мотив программисту разбираться во всем этом. Может кто знает?

Аватар пользователя graker graker 11 января 2013 в 18:20

natbampo wrote:
Печаль. С новомодными веяниями вроде тех что сайт по друпал way должен быть без своих написанных (под этот сайт) модулей, а только настройкой орг-овских модулей, сложно придумать мотив программисту разбираться во всем этом. Может кто знает?

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

Про семерку полтора года назад тоже куча стонов было, как все сложно, плохо, недоделано, семерка сырая, осваивать ее незачем, тем более осваивать так много...
Я освоил - почти всё делаю раза в полтора как минимум быстрее, чем на шестерке. И с восьмеркой будет то же самое. Если, конечно, она не убьет друпал Smile

Аватар пользователя Crea Crea 12 января 2013 в 15:24

natbampo wrote:

Печаль. С новомодными веяниями вроде тех что сайт по друпал way должен быть без своих написанных (под этот сайт) модулей, а только настройкой орг-овских модулей, сложно придумать мотив программисту разбираться во всем этом. Может кто знает?

Не обращайте внимания на такие "веяния" - не стоит путать чьи фантазии с объективной реальностью. Те, кто хотят сами тыкая мышкой чего-то серьезного добиться - просто не наша аудитория Smile

Аватар пользователя sas@drupal.org sas@drupal.org 12 января 2013 в 9:16

"graker" wrote:
Если, конечно, она не убьет друпал :)

Где же оптимизм и уверенность в светлом будущем - вера творит чудеса Smile

Аватар пользователя graker graker 12 января 2013 в 13:01

<a href="mailto:sas@drupal.org">sas@drupal.org</a> wrote:
"graker" wrote:
Если, конечно, она не убьет друпал :)

Где же оптимизм и уверенность в светлом будущем - вера творит чудеса :)

Я там смайлик поставил - не придумал, как лучше иронию изобразить Smile

Аватар пользователя natbampo natbampo 12 января 2013 в 10:52

"graker" wrote:
Я освоил - почти всё делаю раза в полтора как минимум быстрее, чем на шестерке

И соответственно дешевле в 1.5 раза? Smile

Аватар пользователя graker graker 12 января 2013 в 12:58

natbampo wrote:
"graker" wrote:
Я освоил - почти всё делаю раза в полтора как минимум быстрее, чем на шестерке

И соответственно дешевле в 1.5 раза? :)

Да - я по часам работу рассчитываю.

Аватар пользователя PVasili PVasili 12 января 2013 в 12:45

"Dan" wrote:
А на небольших сайтах Drupal чует себя великолепно

+ мультисайтинг
+ субтемы
+ большая скорость от старта проекта до запуска (конечно не 60/месяц, но много было проектов "за вечер", "за выходные" Smile )
+ дальнейшая перспектива легко начать развивать любой сайт дальше, если он не умрет с очередной неоплатой за домен.

Аватар пользователя graker graker 12 января 2013 в 13:01

PVasili wrote:
"Dan" wrote:
А на небольших сайтах Drupal чует себя великолепно

+ мультисайтинг
+ субтемы
+ большая скорость от старта проекта до запуска (конечно не 60/месяц, но много было проектов "за вечер", "за выходные" Smile )
+ дальнейшая перспектива легко начать развивать любой сайт дальше, если он не умрет с очередной неоплатой за домен.

+ сборки и выйдет по 60 в месяц - только клиентов находи Smile

Аватар пользователя Епсилон Епсилон 12 января 2013 в 13:00

"Crea" wrote:
Так что фрилансерам-одиночкам и небольшим сайтам тут скоро станет ловить нечего.

А вот это плохо.
Альтернатив друпалу нет, есть либо выше категорией, либо ниже.
Печаль.

Аватар пользователя Crea Crea 12 января 2013 в 15:32

Епсилон wrote:
А вот это плохо.
Альтернатив друпалу нет, есть либо выше категорией, либо ниже.
Печаль.

Альтернативы ЕСТЬ. Для сложных сайтов я уверен, что стоимость разработки на фреймворках не выше, чем стоимость кастомизации Друпала под ТЗ.
Для простых сайтов полно альтернатив.
Проблема в том, что Друпал заполонил все своим булшит маркетингом и теперь уже заказчики как зомби больше ничего не хотят.

Аватар пользователя Crea Crea 12 января 2013 в 15:28

natbampo wrote:
"Епсилон" wrote:
Альтернатив друпалу нет

может бистрикс?

Если с Друпала уходить, то на CMS где свои модули можно продавать по модели аппстора. Или вообще в разработку софта уходить из веба.

А GPL это рабство и нищета разработчика.
Продавать свое время - самый ценный и невосполнимый ресурс - просто глупо.

Аватар пользователя Dan Dan 12 января 2013 в 14:33

"Епсилон" wrote:
С ценой битрикса... шутить не стоит.

Вас только цена останавливает? )

Аватар пользователя kyky kyky 12 января 2013 в 16:10

"Crea" wrote:
Если с Друпала уходить, то на CMS где свои модули можно продавать по модели аппстора.

Вроде бы, у Ливстрита такая модель -- почти все модули и темы платные, прямо как в аппсторе.

"Dan" wrote:
Ну вот чего ты троллишь-то? ) Сам прекрасно понимаешь, что можно всё гибко настроить и сбрасывать гибко кэши и давать анонимам видеть самую актуальную информацию, если это необходимо.

Просто сам принцип, что большинство пользователей анонимы -- идиотичен. Сейчас на любом нормальном сайте можно залогиниться в два клика через социалки или OpenID. В конце концов, девиз Друпала -- community pumbling -- построение сообщества. Что же это за сообщество, где все анонимы? Какой-нибудь двач?

Аватар пользователя Crea Crea 12 января 2013 в 16:18

kyky wrote:

Просто сам принцип, что большинство пользователей анонимы -- идиотичен. Сейчас на любом нормальном сайте можно залогиниться в два клика через социалки или OpenID. В конце концов, девиз Друпала -- community pumbling -- построение сообщества. Что же это за сообщество, где все анонимы? Какой-нибудь двач?

Этот слоган давно уже неактуален. Да что там за примерами ходить - drupal.org и drupal.ru сплошные Not Invented Here.

Аватар пользователя Епсилон Епсилон 12 января 2013 в 16:14

"Crea" wrote:
Альтернативы ЕСТЬ. Для сложных сайтов я уверен, что стоимость разработки на фреймворках не выше, чем стоимость кастомизации Друпала под ТЗ.
Для простых сайтов полно альтернатив.
Проблема в том, что Друпал заполонил все своим булшит маркетингом и теперь уже заказчики как зомби больше ничего не хотят.

Нету альтернатив.
Друпал и есть фреймворк, самый что ни есть настоящий.
В то и прелесть друпала, что он и фреймворк и в тоже время, визитку сделать, 15 минут.
Универсальный продукт, всегда лучше.
А для крупных проектов, где надо фреймворки типа yui, то уже отдельный разговор.

Аватар пользователя Crea Crea 12 января 2013 в 16:47

Епсилон wrote:

Универсальный продукт, всегда лучше.

Универсальность имеет свою цену - часто это результат посредственного качества или слишком дорогой. Поэтому не всегда.

Аватар пользователя volocuga@drupal.org volocuga@drupal.org 12 января 2013 в 16:52

"Crea" wrote:
А GPL это рабство и нищета разработчика.
Продавать свое время - самый ценный и невосполнимый ресурс - просто глупо.

+100000

Аватар пользователя Епсилон Епсилон 12 января 2013 в 16:57

"Crea" wrote:
Универсальность имеет свою цену - часто это результат посредственного качества или слишком дорогой. Поэтому не всегда.

В случае друпала, минусов меньше, чем плюсов + минусы не значительные.
Такого класса продукта, я не знаю.
Опять же, про хайлевела сайты не говорим, ясень пень, фейсбук писать на друпале, будет только идиот.
Но в остальном, друпал молодец.

Аватар пользователя Crea Crea 12 января 2013 в 17:11

Епсилон wrote:

Но в остальном, друпал молодец.

Сколько на Друпале сайтов-визиток ? Очень мало.
Несмотря на всю мощь Друпал-маркетинга, все же заказчики не делают визитки на друпале массово. Т.е. результат на Друпале возможен, но он все же не такой, какой нужен заказчику ? Smile
Сравните кол-во сайтов на Вордпрессе и Друпале, опять же. Разница просто космическая..

Аватар пользователя PVasili PVasili 12 января 2013 в 16:58

"Crea" wrote:
Продавать свое время - самый ценный и невосполнимый ресурс - просто глупо.

-1000 а что вы предлагаете продавать? И что ещё можно продать кроме своего времени в (любом виде)?

Аватар пользователя Crea Crea 12 января 2013 в 17:06

PVasili wrote:
"Crea" wrote:
Продавать свое время - самый ценный и невосполнимый ресурс - просто глупо.

-1000 а что вы предлагаете продавать? И что ещё можно продать кроме своего времени в (любом виде)?

Органы.

А что продают люди творческих профессий (каким, вообще-то, и является программист) - музыканты, писатели ? Результат своего труда. А не рабочие часы.
И у программистов есть такой путь - создание качественного проприетарного ПО, которое никуда не денется, несмотря на всю опенсорц революцию.

Аватар пользователя PVasili PVasili 12 января 2013 в 17:57

"Crea" wrote:
Сколько на Друпале сайтов-визиток ? Очень мало.

Да море... только 1 студия +60 в месяц делает...

"Crea" wrote:
Разница просто космическая..

~5 раз

"Crea" wrote:
А что продают люди творческих профессий (каким, вообще-то, и является программист) - музыканты, писатели ? Результат своего труда. А не рабочие часы.

Все то же время, только Цена (всегда) = время * X (где X - реклама/раскрученность/известность/модность/знания и т.д.)

"<a href="mailto:volocuga@drupal.org">volocuga@drupal.org</a>" wrote:
продавать можно задёшево и задорого.

Тут ни кто не спорит. см. выше. X там определяет цену

Аватар пользователя Crea Crea 12 января 2013 в 18:23

PVasili wrote:
~5 раз

Уже больше.
http://w3techs.com/technologies/overview/content_management/all
А на самом деле, цифра то еще больше, если сравнивать в одном сегменте, т.к. не все Дру-сайты можно сделать на вордпрессе

PVasili wrote:
Все то же время, только Цена (всегда) = время * X (где X - реклама/раскрученность/известность/модность/знания и т.д.)

Результат творческого труда можно создать 1 раз, а продать N раз. Рабочее же время продается раз и навсегда - это невосполнимый, нетиражируемый ресурс.
Если вы это не понимаете, то и спорить бесполезно.

Аватар пользователя PVasili PVasili 12 января 2013 в 18:57

"Crea" wrote:
А на самом деле, цифра то еще больше,

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

"Crea" wrote:
Результат творческого труда можно создать 1 раз, а продать N раз. Рабочее же время продается раз и навсегда - это невосполнимый, нетиражируемый ресурс.
Если вы это не понимаете, то и спорить бесполезно.

Скорее всего вы всевышний Smile Ибо творческий труд у вас не занял время, не говоря уже о времени на обретение и повышение вашего "творческого" уровня.
Про разницу в стоимости создания результата творческого труда и продажи говорить не приходится. Цена картины и принта с неё отличаются заметно Smile
Спорить точно - бесполезно.

Аватар пользователя Crea Crea 12 января 2013 в 19:20

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

Давайте не будем подгонять факты под нужный результат..Как будто на Дру нет говносайтов. Да на нем даже дорвеи делают.

Никто и не говорит, что время не требуется для создания творческого продукта. Просто это всего-лишь ресурс, сырье. Не имеет значения, сколько времени было потрачено - оно лишь косвенно влияет. Да и как можно говорить о продаже времени, в творческом процессе ? Если музыкант создал отличную песню, может ли он создать N таких же хороших песен, потратив N* времени ? Бред, короче.

Аватар пользователя PVasili PVasili 12 января 2013 в 19:32

"Crea" wrote:
Просто это всего-лишь ресурс, сырье.

Вот мы и "вышли на дерибасовскую" :). Время такой же ресурс, который стоит денег.
В любом случае, на создание чего-то вам нужно время (в том числе и косвенно [ваше обучение, реклама, вдохновение и т.д.]).
А затраченное время - всегда можно выразить в деньгах (ну только если вы не коммунист или сектант).
Создав тиражный(ую)программу/сайт/шаблон и т.д. вам опять же нужно потратить кучу времени на её продвижение/рекламу/сопровождение и т.д.
Ну а как оценивать своё личное время - решать вам. Или это будет дорогое время, за интересным проектом или время на рекламу/саппорт/разборки с манагерами и т.д. вашего тиражного продукта.

Аватар пользователя Crea Crea 12 января 2013 в 20:22

Quote:
А затраченное время - всегда можно выразить в деньгах (ну только если вы не коммунист или сектант).

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

Аватар пользователя WadimKo51 WadimKo51 17 января 2013 в 19:10

Решил поставить себе dev версию, чтобы посмотреть, неужели всё так страшно, как написано. и чтобы делать собственный вывод.
Ставиться, последний шаг, написано всё готово, появляется ссылка на готовый сайт.
Тыкаю ссылку, страница не ткрываетсья, даже 404 ошибки нет. Прсото заблокирован ответ сервера. Удаляю файл setings.php установка снова начинается.
Думал всё дело в правах на файл setings.php и папку поставил 444 всё ровно картина та же.
Кто устанавливал, было ли такое?
Может у меня на ПК сервер криво настроен, хотя всё остальное нормально работает.
Думаю дело в правах или наличии какого-то файла который не прописал установщик.
Это похоже на то, что удалите категорию install без этого вы не может работать с сайтом. Но раньше такого не Drupal не видел.

А вообще думаю зря так все писсимистично настроенны.
Извините, опять Joomla вспомню, но помню когда был только выход 1.5 бета, то тестеры поскачали, понаписали истеричных статей, что 1.5 версия не работая вообще, что она убивает серверы, что это вообще тупик, что он для страницы грузит 1500 файлов с диска или как-то так.
Но сам я влез туда смотреть когда был уже релиз и не первый.
Скачал, поставил, удивился, по сравнению с 1.0, версия 1.5 стала работать быстрее. А следующие релизы стали ещё быстрее.

Так что думаю, что не всё так ужасно и всё будет нормально.
По бета версии, вернее даже не беты а альфы скорее не стоит такие паники поднимать и пессимистически мыслить.

Хотя действиельно не понятно зачем XML конфиги, потмоу что если setings.php написать в xml то толку от этого не будет. по крайней мере не все поймут.

Спасибо.

Аватар пользователя WadimKo51 WadimKo51 27 января 2013 в 10:02

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

Самое странное, что когда страницы не открываются, там нет никакого сообщения об ошибки. Смотрел заголовки 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 ругаеться в статусе что на сервере время не правильно установлено, то есть временная зона. Может от этого так?
Но всё остальное работает хорошо.

Аватар пользователя multpix multpix 27 января 2013 в 15:09

"WadimKo51" wrote:

8.x-dev стоит и работает, ковыряю потихоньку.
(зри логи, ищи причину, и честно ответь себе на вопрос: "оно тебе надо? оно того стоит?")

Аватар пользователя Dan Dan 28 января 2013 в 10:30

"WadimKo51" wrote:
Удаляю файл setings.php установка снова начинается.

Этого мало. Очищай files

"WadimKo51" wrote:
Думал всё дело в правах на файл setings.php и папку поставил 444 всё ровно картина та же.

Почему 444? Если проверять права, то надо ставить 777 на всё, а потом уже выставлять правильные.

"WadimKo51" wrote:
Смотрел заголовки HHTP там даже ответа и запроса в логах нет. Такое ощущение что защита от DDos срабатывает, или что-то вроде того.

Зачем на тестовом сервере ставить защиту от DDoS? Запрос должен быть - иначе на что должен отвечает сервер? Smile
А если нет ответа - значит на серваке ошибка на уровне PHP, ответ в его логах.

"WadimKo51" wrote:
От чего это может быть?

Миллион причин, гадать можно бусконечно.

"WadimKo51" wrote:
У меня ноутбук с Debian 6 там PHP 5.3.20 Drupal 7 ругаеться в статусе что на сервере время не правильно установлено, то есть временная зона. Может от этого так?

Вряд ли.

"WadimKo51" wrote:
К сожалению в логах нет записей об ошибках.

Никто тебе не поверит. И если нет ошибок, значит есть записи об успешной отдаче страницы. А в этом случае должны быть заголовки от сервера, а их нет Smile

Аватар пользователя WadimKo51 WadimKo51 29 января 2013 в 10:42

В логах нет ошибок и никаких записей, пока не наберёшь
www.drupal8-test.com/белиберда
Тогда появляется
-

192.168.1.2 - - [29/Jan/2013:10:04:09 +0400] "GET /ljh HTTP/1.1" 404 2438
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 как понял это для мультисайтовости.
Но может с этим файлом что-то надо сделать?

Аватар пользователя iNFerNo iNFerNo 31 января 2013 в 10:06

Наконец то заюзал дистрибутив. Пока что разницы с 7кой не увидел. Даже 7 ка больше нравится Lol

Аватар пользователя Dan Dan 31 января 2013 в 10:36

А что ты искал в ней? UI там ещё особо не пилился, всё самое интересное - в коде. Ты смотрел код или просто тыкал в ссылки?

PS: А вот views теперь в ядре.

Аватар пользователя WadimKo51 WadimKo51 1 февраля 2013 в 15:45

А у меня пока не получилось пока.
Как понял из текста статьи там написано, что это вывод и лог ошибок 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
пожалуйста, напишите, что у вас было?
Почему не устанавливалось?

Думаю нужно отладчиком просмотреть где ошибка, если это ошибка.
Пока не успеваю заниматься этим, но уже, раз оно так уперлось, то придёться соответствующе и копать.

Аватар пользователя WadimKo51 WadimKo51 3 февраля 2013 в 8:25

Вроде нашёл где получиться ошибка
/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 (
!== strpos($class$prefix)) {
                    continue;
                }

                foreach (

$dirs as $dir) {
                    
$file $dir.DIRECTORY_SEPARATOR.$normalizedClass;
                    if (
is_file($file)) {
                        return 
$file;
                    }
                }
            }
?>

Пока не докопался почему и не анализировал это программой.
У кого-нибудь есть идеи, от чего это?
Может это из за APC ?
Только в голову пришло, выключу, напишу.

Аватар пользователя WadimKo51 WadimKo51 3 февраля 2013 в 9:24

Установил 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 строки, и не думаю что это будет полезно.

Спасибо.

Аватар пользователя andypost@drupal.org andypost@drupal.org 5 февраля 2013 в 15:41

Может стоит обновить dev версию... там очень активно фиксятся баги, но это походу что-то с окружением связано.

Аватар пользователя slivorezka slivorezka 18 февраля 2013 в 15:02

Поставил себе Druapl 8
Packaged version: 8.x-dev
February 17, 2013 - 00:55

Установился без проблем. Покнопал, тоже норм.
Посмотрел что тама у него внутри... много интерсного.
Скажем так, приятно впечатлен Smile

Парни, кто-то уже пробовал писать модули под D8?

Аватар пользователя iNFerNo iNFerNo 18 февраля 2013 в 15:07

Тоже обновил 8 друпал модулек один еще добавил...

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