19 июня 2009 в 19:46
УРАА. Я нашел решение как избавиться от белой страницы модулей в друпал 6 (=медленная загрузка модулей).
В подобных темах советуют править php.ini . увеличивать объем памяти и тп.
Но этот лучше:
а именно: открываем файл \www\modules\system\system.admin.inc
строка 621, находим там
drupal_rebuild_theme_registry();
node_types_rebuild();
menu_rebuild();
cache_clear_all('schema', 'cache');
node_types_rebuild();
menu_rebuild();
cache_clear_all('schema', 'cache');
и заменяем на
if ($form_state['post']) {
drupal_rebuild_theme_registry();
node_types_rebuild();
menu_rebuild();
cache_clear_all('schema', 'cache');
}
drupal_rebuild_theme_registry();
node_types_rebuild();
menu_rebuild();
cache_clear_all('schema', 'cache');
}
ВСЕ ПАШЕТ!!! пишут что на 90% ускорение. те на 90% меньше запросов!
Комментарии
сайт грузится быстрее, работает..)
кагбе править ядро, караемо богом
У меня при попытке использовать на локалхосте с Wamp и заходе на страницу модули выдает кучу ошибок, которых до этого не было
warning: uasort() [function.uasort]: The argument should be an array in C:\wamp\www\modules\system\system.admin.inc on line 629.
warning: Invalid argument supplied for foreach() in C:\wamp\www\modules\system\system.admin.inc on line 645.
warning: Invalid argument supplied for foreach() in C:\wamp\www\modules\system\system.admin.inc on line 660.
warning: Invalid argument supplied for foreach() in C:\wamp\www\includes\form.inc on line 1200.
warning: Invalid argument supplied for foreach() in C:\wamp\www\modules\system\system.admin.inc on line 2029.
warning: ksort() expects parameter 1 to be array, null given in C:\wamp\www\modules\system\system.admin.inc on line 2035.
warning: Invalid argument supplied for foreach() in C:\wamp\www\modules\system\system.admin.inc on line 2039.
да,это классно,но бедные котята...
А за счет чего улучшение???
И почему его нет в ядре - если это так просто? Какие подводные камни (ну помимо котят и хака ядра, что само по себе немало...)
да вообще много вопросов
tracker2 , модуль работающий лучше чем стандартный, стоящий на друпалорг почему то не является ядерным
Обычно, при каждом открытии странички с модулями чистится некоторое кол-во кеша ([ru-api=drupal_rebuild_theme_registry]drupal_rebuild_theme_registry()[/ru-api] и [ru-api=cache_clear_all]cache_clear_all[/ru-api]('schema', 'cache')) + перезагружается вся система меню ([ru-api=menu_rebuild]menu_rebuild()[/ru-api]). Думается перезагрузка меню и занимает как раз наибольшую часть времени открытия этой странички.
После введения этого изменения перечисленные выше действия осуществляются только после того, как пользователь нажал на кнопку "Save configuration" на страничке с модулями.
Допустим пользователь наколдовал с модулями (включил/отключил), нажал на "сохранить", началось сохранение, перезагрузка меню и т.п. И вот если в этот момент происходит ошибка (превышение таймаута или еще чего-нить) и перезагрузка меню прерывается, то уже ни одна страничка сайта не откроется.
Если бы такое произошло до хака, то достаточно былоб просто перезагрузить страничку с модулями, и все бы восстановилось. После хака же для восстановления необходимо произвести отправку post данных вручную.
Ну, и плюс, если идет разработка модуля, и, к примеру, в [ru-api=hook_theme]hook_theme()[/ru-api] вписывается новый темплейт, то до хака можно было просто перезагрузить страничку с модулями, а сейчас надо жать на "save configuration")
Ну для такой ситуации можно предусмотреть страничку, на которой осуществляется просто голимые вызовы, которые фиксят ситуацию, типа /admin/repair
Мэтры, если всё так хорошо как пишут, то почему бы не озаботится проталкиванием в ядро?
А надо ли? Вы часто ходите в модули?
Зачем придумывать костыли к костылям? Вы что, на страницу модулей смотрите каждые 15 минут? Эта страница мало посещаемая и она уже является "/admin/repair"
Разве на локальном тестовом сайте можно на неё часто захаживать, ну её можно и поправить как описал топик стартер, а рабочие сайты - пусть будет как есть.
Насколько я понимаю дело не только в модулях, но и во всей админке, нет?
Опять же, если данный фикс позволяет избежать возможных проблем, то почему бы нет даже для модулей?
Нет.
Пока проблема одна - неподходящий хостинг. А "возможные проблемы" возникнут после патча.
Хм. Тогда встречное предложение - нельзя ли как-то заставить Drupal анализировать ситуацию, когда ему может не хватить памяти и соответственно вместо белого экрана выдавать осмысленное сообщение?
Это не друпалу, а PHP не хватает памяти. Может быть можно это сделать с помощью исключений, только, опять же, это дополнительные расходы. И какой смысл? Если была хоть раз белая страница - увеличивай память.
Недавно натыкался на нечто и в составе этого нечто было средство для диагностики WSoD'ов. Щас поищу.
Ну как всегда: http://www.drupal.ru/node/26963
Прошу не забывать также, что не все WSOD`ы одинаковы. Например, к белому экрану может привести неверная кодировка одного из файлов шаблона или наличие BOM-сигнатуры в нем.
Эта штука, к сожалению, сама проблемы вызывает.
Не только. К белому экрану могут привести неправильные права доступа в CGI и fastCGI режимах, а также исполнение заZend'его PHP в окружении, где не установлен Zend.
Это же не для продакшен! Она подменяет системные вызовы друпал.
реально помогло))! Спасибо! На Freezoka хостинге только 24мб памяти для пхп, хоть так до модулей добрался)
Нуачо? Могу повторить второй раз:
кагбе править ядро, караемо богом
Здравствуйте,
аналогичная проблема, срочно нужна помощь.
Вначале появлялось только белое окно на странице модулей,
Но у меня теперь не грузится не только панель модулей, но и ВСЁ в администраторском разделе, даже страница Управление.
Сайт находится на хостинге, править настройки php не могу.
P.S. вчера включил кеширование для одного из views, могло ли это повлиять?
Вроде решил.
Ошибка появилась после включения модуля update (он до этого был выключен)
После удаления(да, тупого удаления) update все снова забегало.
Никому, конечно, не рекомендую, но вдруг.
Тряси хостера. Скорее всего, он тебе закрыл исходящие запросы на 80-й порт отсюда и проблема. А модуль слишком полезный, чтобы им жертвовать.
И зря! Этот модуль - полезная штука, а то что он подвесил Ваш хостинг - это проблемы хостинга, а не модуля.
Тряси хостера. Скорее всего, он тебе закрыл исходящие запросы на 80-й порт отсюда и проблема. А модуль слишком полезный, чтобы им жертвовать.
Увы. Спасибо за совет, но, видимо, причина - собственные руки и голова.
Белый экран стал снова появляться, даже на обычных страницах. Установил WSoD - он говорит, что все дело в нехватке памяти.
Вот у меня и вопрос к опытным товарищам - зачем друпалу 20 мб памяти, если на сайт никто не заходит (1-2 посещения в день), а конфигурировать его я перестал дня 4 назад?
Откуда берется такая утечка памяти?
утечка здесь совсем непричем. это нормальное пиковое потребление памяти под законные нужды PHP интерпретатора. и количество зависит не от количества посетителей, а от объема перерабатываемого кода, то есть включенных модулей.
Почитайте как работает web-сервер. Для каждого пользователя создаётся новый поток (по сути - новый web-сервер), который после генерации и отдачи станицы клиенту уничтожается.
20мб - это мало. Ищите другой хостинг или конфигурируйте локально, а на рабочем сервере - кэширование (хотя если работаете с изображениями всё равно не хватит).