новый модуль для загрузки только нужных модулей

Комментарии

Аватар пользователя B.X B.X 19 мая 2008 в 20:17

ого, интересно... надо попробовать...
кто уже пробовал, отпишитесь, как результаты?

Аватар пользователя crank@drupal.org crank@drupal.org 19 мая 2008 в 20:40

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

Аватар пользователя Valeratal Valeratal 19 мая 2008 в 21:44

вот интересно, загружаемый модуль загружает свои CSS
если этот модуль блокирует ненужную загрузку модуля, то и CSS этого модуля не должны грузится
Значит, сжатие CSS не имеет смысла?

Аватар пользователя crank@drupal.org crank@drupal.org 19 мая 2008 в 22:51


Значит, сжатие CSS не имеет смысла?


почему же имеет смысл, все равно полезно.
к тому же JS может быть жирным довольно.

я осталсе доволен, когда убрал с морды загрузку lightbox2 с 30 кб JS
на морде он нафиг не нужен, надо чтоб морда быстрая была.

поставил путь node/\d+, admin/content*, *lightbox*
в итоге грузится только в админке где надо и при просмотре документов

Аватар пользователя crank@drupal.org crank@drupal.org 20 мая 2008 в 0:24

да нужно. это ведь вещи разные - отключить модуль+ксс и сжать все ксс.
кстати модуль для друпала 5.
друпал 6 сцуко другой, только ковырять начал.

Аватар пользователя VladSavitsky VladSavitsky 20 мая 2008 в 1:20

Модуль только появился!
Вы видели коммент к релизу (точнее к версии - релиза ещё не было):
Early prototype for testing and feedback purposes only.

Аватар пользователя Valeratal Valeratal 20 мая 2008 в 9:52

да уж, иногда хорошие люди делаю то, что вообще то должно быть по дефолту в CMF
тем более для Друпала

Аватар пользователя Valeratal Valeratal 20 мая 2008 в 9:57

по поводу сжатие CSS
тут дело в чем, сжатие CSS объединяет все CSS (и модулей и дефолтные) в один большой CSS
НО, если мы не грузим модуль - то не грузится и CSS, тогда целесообразность одного большого CSS (в котором находятся и ненужные стили для какой либо страницы) под вопросом. То есть зависит от количества этих нужных/ненужных

А сжатие ява-скриптов у меня не заработал модуль - файлы (сжатых яваскриптов) создаются с chmod 600......

Аватар пользователя likeleto likeleto 20 мая 2008 в 20:56

Сжатие цсс можно делать самому вручную это не сложно!
Отпарсить и сжать!
http://webo.in/articles/habrahabr/07-gzip-all/
http://webo.in/articles/habrahabr/14-minifing-css/
главное что бы цсс не был совсем маленьким 1-2 кб практически не оптимизируются
тоже самое насчет js

Аватар пользователя crank@drupal.org crank@drupal.org 20 мая 2008 в 16:08

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

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

и вопрос как хранить.
вариант как php array, есть функция var_export,
но вывод не особо красивый.

появилась хорошая идея в виде скрипта типа:

*admin/content* node*
role anonymous user
load content

*lightbox* node* admin/content*
load lightbox2

role translator
load translation
grant moderator

path not user*
skip captcha

private*
role anonymous user
access deny

но насколько это целесообразно, все равно парсить
придется и кешировать в пхп массиве.

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

Аватар пользователя B.X B.X 22 мая 2008 в 19:15

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

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

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

Аватар пользователя player player 22 мая 2008 в 20:25

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

Аватар пользователя crank@drupal.org crank@drupal.org 22 мая 2008 в 22:29

ну я только под 5.7 тестил.
у меня ровно работает.

а так буду ща писать.
короче все будет на хуках как и весь друпал.
т.е. любое условие и действие можно как модуль подключать.

хуки аля друпал:

hook_bootstrap_condition_info();
hook_bootstrap_condition_match($type,$command);
hook_bootstrap_condition_form($type,$command);

hook_bootstrap_action_info();
hook_bootstrap_action_match($type,$command);
hook_bootstrap_action_form($type,$command);

a хранить в файле аля

*admin/content* node*
role anonymous user
load content

*lightbox* node* admin/content*
load lightbox2

role translator
load translation
grant moderator

path not user*
skip captcha

private*
role anonymous user
access deny

Аватар пользователя crank@drupal.org crank@drupal.org 22 мая 2008 в 22:34

вы версию загрузите последнюю.
и поосторожней конечно с правилами
короче смысл такой.

например указываем путь (КАК В БЛОКАХ)

*lightbox*
node*
admin/content*

и в табличке модулей напротив lightbox2 ставим галку 'load'.
это означает что модуль будет грузиться ТОЛЬКО на указанных страницах.

если поставить 'skip', то модуль на заданных страницах грузиться не будет.

с ролями также как с путями.

версию загрузите последнюю.

Аватар пользователя B.X B.X 7 июня 2008 в 19:34

"если поставить 'skip', то модуль на заданных страницах грузиться не будет.
с ролями также как с путями.
версию загрузите последнюю."

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

Аватар пользователя Dimm Dimm 28 мая 2008 в 21:10

К сожалению после включения модуля перестал работать модуль Advertisement 5.x-1.4-1 (Графические баннеры вызываемые с помощью JS перестали показываться).
Пришлось пока отказаться от bootstrap до выяснения причин.
PS
а на локалке все нормально работает Sad

Аватар пользователя Dimm Dimm 29 мая 2008 в 14:02

Еще проблемы: не запускается /update.php - перекидывает на главную страницу.
Advertisement не работает потому что не запускается скрипт

<div class="advertisement" id="group-tids-219"><script type="text/javascript" src="http://site.ru/modules/ad/adserve.php?q=1&amp;t=219"></script></div>

А скрипт не запускается потому что /modules/ad/adserve.php?q=1&t=219 не работает и выдает ошибки:

* warning: filemtime() [function.filemtime]: stat failed for ad/misc/jquery.js in /home/krasmebel/site.ru/docs/modules/javascript_aggregator/javascript_aggregator.module on line 49.
* warning: filemtime() [function.filemtime]: stat failed for ad/misc/drupal.js in /home/krasmebel/site.ru/docs/modules/javascript_aggregator/javascript_aggregator.module on line 49.
* warning: filemtime() [function.filemtime]: stat failed for ad/modules/jstools/jstools.js in /home/krasmebel/site.ru/docs/modules/javascript_aggregator/javascript_aggregator.module on line 49.
* warning: filemtime() [function.filemtime]: stat failed for ad/modules/jstools/tabs/jquery.tabs.pack.js in /home/krasmebel/site.ru/docs/modules/javascript_aggregator/javascript_aggregator.module on line 49.
* warning: filemtime() [function.filemtime]: stat failed for ad/modules/jstools/jquery.history_remote.min.js in /home/krasmebel/site.ru/docs/modules/javascript_aggregator/javascript_aggregator.module on line 49.
* warning: filemtime() [function.filemtime]: stat failed for ad/modules/jstools/tabs/tabs.js in /home/krasmebel/site.ru/docs/modules/javascript_aggregator/javascript_aggregator.module on line 49.
* warning: filemtime() [function.filemtime]: stat failed for ad/sites/all/modules/jquery_update/compat-1.0.js in /home/krasmebel/site.ru/docs/modules/javascript_aggregator/javascript_aggregator.module on line 49.
* warning: filemtime() [function.filemtime]: stat failed for ad/modules/devel/devel.js in /home/krasmebel/site.ru/docs/modules/javascript_aggregator/javascript_aggregator.module on line 49.
* warning: filemtime() [function.filemtime]: stat failed for ad/sites/all/modules/jquery_update/collapse-fix.js in /home/krasmebel/site.ru/docs/modules/javascript_aggregator/javascript_aggregator.module on line 49.

В чем может быть причина? где искать?
на локалке работает нормально. везде стоит PHP5.

Аватар пользователя crank@drupal.org crank@drupal.org 7 июня 2008 в 23:08

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

загрузка контролируется "скриптом" bootstrap.script,
который хранится в папке файла конфигурации текущего сайта

доступ к редактированию файла в админке
admin/bootstrap

почему скрипт?
потому что СУПЕР ГИБКО и СУПЕР МОЩНО
плюс отпадает потребность писать сложные формы для ввода
тривиальной информации

+ВОЗМОЖНОСТЬ ПИСАТЬ МИНИ-ПЛУГИНЫ С КОМАНДАМИ ИЛИ УСЛОВИЯМИ

короче инфа на англ. здесь
http://drupal.org/project/bootstrap

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

Аватар пользователя Dimm Dimm 9 июня 2008 в 10:46

Нашел решение - надо в adserve.inc раскомментировать
define('DRUPAL_ROOT', '/home/site/docs');

Осталось починить update.php - скорее всего где-то в инклудах пути сбиваются.
У меня не мультисайтинг, PHP5.
Есть идеи по решению проблемы?

Аватар пользователя Dimm Dimm 10 июня 2008 в 10:59

Решение в adserve.inc не работает:
define('DRUPAL_ROOT', '/home/site/docs');
У меня на виртуальном хостинге 2 сайта:
/home/site1/docs - нет Bootstrap
/home/site2/docs - стоит Bootstrap
И я случайно на втором сайте в adserve.inc прописал путь к первому сайту:
define('DRUPAL_ROOT', '/home/site1/docs');
А т.к. там не стоит Bootstrap, то AD заработал Smile

Если же прописывать все правильно: на втором сайте в adserve.inc:
define('DRUPAL_ROOT', '/home/site2/docs');
То AD так и не работает Sad

Аватар пользователя crank@drupal.org crank@drupal.org 10 июня 2008 в 13:33

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

Аватар пользователя andypost@drupal.org andypost@drupal.org 9 июня 2008 в 16:40

очень интересное начинание, в 7ке для этого будет использоваться registry как в 6ке для тем!
Стоит ли игра свечь? - имхо для небольших сайтов можно прописать все модули для нужных путей а для больших?
Сколько загрузится модулей в память влияет только на то, сколько nodeapi хуков будет вызвано и что прикрепится к ноде. Это в простейшем варианте. А вот когда сайты используют views или panels - как прописывать скрипты? для каждого вида и панели?
В остальном opcode кеширование практически стирает зависимость от кол-ва модулей в памяти.
Очень интересно услышать аргументы...

Аватар пользователя andypost@drupal.org andypost@drupal.org 9 июня 2008 в 19:15

Ускоряется не php Smile а количество загружаемых модулей - идея правильная! Ибо почти каждый модуль генерирует запросы к базе и на некоторых страницах их можно запросто исключить. Но на самом деле самое узкое место это альясы путей и перевод, а они нужны постоянно.

Аватар пользователя crank@drupal.org crank@drupal.org 9 июня 2008 в 22:41

ну во первых контроль загрузки модулей не единственная цель.

контроль доступа, тем, включений css & js,
логина бд, ролей, сжатие, кеширование и т.п. и т.д.

и главное текущий путь - не единственное условие.

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

т.е. мета управление текущей загрузки и конфигурации сайта.

а во-вторых, реальная версия друпала сейчас - 5ая.
так что пока такой модуль не помешает.

Аватар пользователя crank@drupal.org crank@drupal.org 10 июня 2008 в 17:46

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

у меня facet_search с faced_taxonomy в сумме до 20 мс грузятся.
что такое 20мс вроде фигня. а если шаред хостинг + юзеров много?
каждая миллисекунда на учете.

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

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

Аватар пользователя andypost@drupal.org andypost@drupal.org 11 июня 2008 в 2:34

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

Интересно как решается задача с блоками, ибо hook_block лежит в модуле и если он не загружается, то и блока не будет!

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

Аватар пользователя crank@drupal.org crank@drupal.org 11 июня 2008 в 14:28

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

по путям не знаю.
напиши свой url_overwrite или как он там.

Аватар пользователя andypost@drupal.org andypost@drupal.org 11 июня 2008 в 15:07

Кеширование на файлах не панацея, и прирост весьма минимальный, меня пока вполне устраивает кеширование в eAccelerator+memcache
Строки кешируются до 75 символов
custom_overwrite - муторно прописывать...
Вообщем все варианты хороши в своих случаях, а статическое кеширование - это когда килотонна кешированых страниц очищаются после каждого комента...

Аватар пользователя B.X B.X 21 июня 2008 в 18:00

"а статическое кеширование - это когда килотонна кешированых страниц очищаются после каждого комента"

интересно, а нельзя сделать так, чтобы обновлялась только "страница на которую добавлен комментарий", ну и трекер. соответственно?

Аватар пользователя andypost@drupal.org andypost@drupal.org 21 июня 2008 в 19:29

Очищается не только кеш страниц, но и фильтры, блоки и иногда меню. Сложно предугадать, где еще используются данные из ноды...
Здесть http://drupal.org/node/224772#comment-870401 я делал обзор, где используется чистка по маске и вторая проблема - cache_temporary = -1

Аватар пользователя Ильич Рамирес Санчес Ильич Рамирес Санчес 24 июня 2008 в 21:57

насколько я знаю, ты не прав.
локаль он сериалайзит и кладет блоб в кеш в таблицу cache с идентификатором locale:ru ааадним баальшым ассоциативным массивом.
Что кстати тоже дебильный оверхед по памяти. Smile
Локаль бы такую как реализовано в зендовском геттексте с возможностью кешировния кусочков Wacko

И зачем ВСЕ строчки в БД держать - ума не приложу.

Аватар пользователя kiev1 kiev1 22 июня 2008 в 8:55

интересно - а зачем нам вручную указывать что системе грузить? она что сама не знает? ведь непример если страничка использует тип данных cck то очевидно что его надо загрузить!

Аватар пользователя B.X B.X 22 июня 2008 в 11:12

"интересно - а зачем нам вручную указывать что системе грузить? она что сама не знает? ведь непример если страничка использует тип данных cck то очевидно что его надо загрузить"

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

Аватар пользователя kiev1 kiev1 22 июня 2008 в 12:14

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

Аватар пользователя B.X B.X 24 июня 2008 в 16:16

"тем более не каждый администратор сайта обязан разбираться в системе до таких тонкостей"

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

Аватар пользователя B.X B.X 24 июня 2008 в 18:01

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

Аватар пользователя andypost@drupal.org andypost@drupal.org 12 октября 2008 в 23:33

А для 6го оно особенно не нужно - там и так грузится немного и реестр меню решает, что грузить, а что нет.