При переносе с локалки на хостинг вдруг перестали открываться друпаловские страницы. Даже сообщений об ошибках не появляются. Просто страницы недоступны, и все. Сам домен не пингуется. Но при этом недрупалловские страницы на этом же самом сайте вполне открываются. Что бы это могло быть?
Комментарии
это может быть, например база данных (MySqL) версии 3.х.х
PHP Version 4.3.9
mysql 4.1.20
---
---
All content management systems suck, Drupal just happens to suck less. -- Boris Mann at DrupalCON Amsterdam, August 2005.
Выдает сообщение annot find server
---
---
All content management systems suck, Drupal just happens to suck less. -- Boris Mann at DrupalCON Amsterdam, August 2005.
а что значит "[b]недрупалловские страницы на этом же самом сайте[/b]"? на этом же домене? или как? это статичные страницы или под другими движками? "[b]Просто страницы недоступны[/b]" - это как? не открываются при нажатии?
[b]Добавлено:[/b]
а site/settings
путь к сайту изменён?
Любые другие страницы: хоть статичные html, хоть форум phpbb.
"Просто страницы недоступны” - это как? не открываются при нажатии?
"
Вообще ничего не загружается по адресу сайта.
---
---
All content management systems suck, Drupal just happens to suck less. -- Boris Mann at DrupalCON Amsterdam, August 2005.
странно... а как сайт настроен? с ЧПУ или без? может на хостинге отключен mod_rewrite?
Смотрите сами:
домен
http://www.transgarret.com
старый форум phpbb (для примера)
transgarret.com/forum
phpinfo
www.transgarret.com/phpinfo.php
mod_rewrite включен
---
---
All content management systems suck, Drupal just happens to suck less. -- Boris Mann at DrupalCON Amsterdam, August 2005.
хм... а файлы-то по отдельности видит...
ex: http://www.transgarret.com/install.txt
может надо как-то сначала базу и настройки переправить на локалке потом перенести?
Я изменила settings.php и залила базу данных. А что еще надо? На всякий случай почитала кэш и заменила тему на стандартную, но все равно не помогает. Поиск на drupal.org подсказывает, что это может быть segfault, но у меня нет достуа к логам Апача. Буду выяснять у хостера.
---
---
All content management systems suck, Drupal just happens to suck less. -- Boris Mann at DrupalCON Amsterdam, August 2005.
ну он в базу у тебя вообще не лезет никак....
http://www.transgarret.com/admin/block
просто тоже ничего не выдаёт как на главной, а должен ругаться...
а чистый сайт с Друпал пробовали установить? да, странно, что ошибок нет... что за хостер, интересно?
у меня http://www.transgarret.com/install.txt тоже не открывается...
кстати проверить бы еще какие стоят права на все каталоги друпала.
может стоят запреты на исполнение?
тогда бы было forbidden
Апач-то там работает нормально...
Я не знаю, это какой-то знакомый дает хоститься у него.
Попробую вечером все стереть и установить чистый инстолл.
---
---
All content management systems suck, Drupal just happens to suck less. -- Boris Mann at DrupalCON Amsterdam, August 2005.
2 B.X
"тогда бы было"
да не факт... если сама система запускается с index.php а потом пытается что-то взять, а не может... вовсе необязательно ошибку будет выводить, не в индекс.пхп же она
2 Natalie
во-во! надо его поставить попробовать (как положено его ставить), потом можно поверх залить
Может файл .htaccess не положен (или покладен) в корень?!
Все на месте. Я это первым делом проверила
---
---
All content management systems suck, Drupal just happens to suck less. -- Boris Mann at DrupalCON Amsterdam, August 2005.
тогда больше ничего в голову не приходит, должно работать...
настройки у Друпала не такие уж необычные, чтобы он не работал...
Да, это явно хостинг глючит. Будем разбираться.
---
---
All content management systems suck, Drupal just happens to suck less. -- Boris Mann at DrupalCON Amsterdam, August 2005.
Похоже, проблемы были с каким-то из сторонних модулей, потому что после их удаления все появилось.
---
---
All content management systems suck, Drupal just happens to suck less. -- Boris Mann at DrupalCON Amsterdam, August 2005.
По ходу дела, некоторые родные модули throttle и statistics тоже вызывают пустую страницу вместо admin/modules. В общем, я в непонятках.
---
---
All content management systems suck, Drupal just happens to suck less. -- Boris Mann at DrupalCON Amsterdam, August 2005.
хех, сторонние модули надо отключать в первую очередь... у меня уже такое бывало, включаешь модуль на локалке - всё нормально, а на хостинге ему памяти для исполнения не хватает и появляется чистая белая страница...
У меня тоже некоторые страницы были пустые.
Оказалось, что Smarty не мог создать свой кэш в каталоге templates_c, просто не были настроены права для каталога. Это я узнал через логи сервера.
И как вы с этим боролись? Установили заново?
---
---
All content management systems suck, Drupal just happens to suck less. -- Boris Mann at DrupalCON Amsterdam, August 2005.
А вот другая вещь: при переносе на субдомен главная страница показывается нормально, но любая ссылка вызывает ошибку 404. Значит ли это, что субдомен неправильно сконфигурирован?
---
---
All content management systems suck, Drupal just happens to suck less. -- Boris Mann at DrupalCON Amsterdam, August 2005.
http://drupal.ru/node/288
Спасибо, добавление в .htaccess сработало
---
---
All content management systems suck, Drupal just happens to suck less. -- Boris Mann at DrupalCON Amsterdam, August 2005.
Если используется движок для тем Smarty и появляются пустые страницы и в логах сервера фигурируют ошибки от этого Smarty, то скорее всего не заданы права на запись для скрипта.
Решение: зайти через ssh на сервер, зайти в каталог /что-то/themes/engines/smarty и выполнить комманду chmod -R 775 templates_c.
(согласно документации по Smarty)
Практически таже ситуация...
Стоял друпал 5 ветки на фрибсд+апаче+пхп 4.3.2+мускус 3.28 - все работало супер нареканий нет... Но через некоторое время (6-8 мес.) друпал стал "съедать" всю память 256М, затем свапы и машина ложилась...
Обновил апач, пхп, все модули к ним, подкинул памяти до 512... Поднялись сайтики (vBulletin в частности), друпал отобразил пару страниц и кирдык... БЕЛЫЙ ЭКРАН...
Как нибился... все в пустую... Что подскажете господа кодеры...?
Что пишут логи?
Машина своя или шаред?
В логах при обращении к друпалу - апач, а точнее процесс валится, пример:
Apr 23 14:37:56 kernel: pid 11826 (httpd), uid 80: exited on signal 11
Apr 23 14:38:02 kernel: pid 11828 (httpd), uid 80: exited on signal 11
Apr 23 14:38:02 kernel: pid 11829 (httpd), uid 80: exited on signal 11
Apr 23 14:38:09 kernel: pid 11833 (httpd), uid 80: exited on signal 11
Apr 23 14:38:09 kernel: pid 11830 (httpd), uid 80: exited on signal 11
Apr 23 14:38:13 kernel: pid 11831 (httpd), uid 80: exited on signal 11
Apr 23 14:38:14 kernel: pid 11832 (httpd), uid 80: exited on signal 11
конфиг пхп: phpinfo();
а вот и собственно и сам друпал: смотрим тут
Тазик свой, по железу нареканий нет...
Что братья кодеры, не вкурсе...?
Проблема остается на повестке дня, у кого подобное случалось?
Если с железкой все впорядке и уверенность в ней на все 100, то возможно модуль php валит апач... Я недавно пересобрал апач и php и добавил несколько модулей в него поставил пхп 5.2.6, апач 2.2.8. Начал сыпать в кору, но не всегда на каких-то скриптах... потому что валится не сразу как обращаешься к сайту (кстати не на движке друпал)... Весь сайт самописный... Но вот думаю что-то не то... Потому что я добавил зенд оптимайзер, с которым вообще все перестает работать(сейчас он отключен) ... Буду проверять модули апача, какой из них новый так нехорошо глючит... Ошибка та же - апач падает в корку... кстати апач собран как worker, а для него падание в корку это однозначно потеря около 200 коннектов (((( Так что бум бороться...
Может есть еще у кого мысли?
такое бывало у меня при синхронизации live и локальной версии сайта в случае, когда синхронизируется не только файловая система, но и структура БД (сайты, к примеру, live-site.com и local-site.com). собака здесь зарыта в БД, в полученном дампе базы нужно заменить все вхождения строки live-site.com на local-site.com, и только тогда выполнять sql-запрос.