Проверить помоему можно так: выгрузить дамп БД. Посмотреть какая в дампе кодировка и соответственно найти тот текст, который отображается криво на сайте - проверить что он именно в этой же кодировке.

Я просто помню у нас такие косяки были с Битриксом. Уж не знаю как клиенту это удавалось, но часть данных в БД была в UTF-8, а часть в cp1251 поэтому чудеса были ещё те при показе

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

Сие очень страннно, потому как наличие UTF-8 гарантирует, что проблем не должно быть.
Единственное, что мне приходит на ум: у вас на базе кодировка, которая не соответствует СОДЕРЖИМОМУ базы. Например кодировка указана UTF, а на самом деле данные в cp1251.

Зачем так сложнно? Я просто включаю пользователя nginx в группу пользователя владельца каталога/файлов. Таким образом можно обойтись без ACL'ей.

Вы не правы +x на каталог не означает прав на его чтение, это даёт право входить в этот каталог, выполняя на него change directory. А вот права читать +x не даёт. Попробуйте сами. Да, тут я конечно, погорячился. Дело в том, что без +x для каталога +r не имеет смысла, потому как прочитать содержимое каталога при наличии только +r можно, а вот прочитать содержимое файла уже нет, обязательно нужен +x. Мдя, век живи - век учись, я почему-то думал другое

Сталкивался. Как раз отказано в доступе. Просто у пользователя от которого работал nginx не было прав на чтение домашних каталогов пользователя, где лежали файлы, которые он должен был отдавать. И ещё по какой-то непонятной мне причине, nginx хочет прав на выполнение +x для всех каталогов, с которыми ему надо работать.

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

Видите, сами же согласны. Потеряли кучу времени! Ладно вам хватило упорства не бросить всё на полдороги, а представьте человека, которому нужно просто освоить CMS, не важно какую. Останется ли он с Drupal при таком раскладе или пойдёт поискать что полегче? Думаю, что наиболее вероятен последний вариант. И его трудно будет в этом упрекнуть.

Не пользуйтесь ligHTTPd. Есть более оптимальная, гибкая, развивающаяся отечественная разработка: nginx - делает всё тоже, что и lighttpd + много чего другого. http://nginx.ru

glu2006, я бы согласился с вами, но есть одно НО.
Новичок он на то и новичок, что ещё почти ничего не знает. Именно поэтому он не в состоянии найти ошибки, а вот наступить на них - запросто. В итоге ничего не работает, что делать непонятно! Да, можно, изучать исходники других модулей, засесть за словарь и переводить английские доки, но это равносильно вырыванию гланд не через горло, а простите через задницу.

Я не знаю какой у вас хостинг - спросите у хостера!
Чтение логов ошибок веб-сервера - это САМОЕ ПЕРВОЕ, что надо было сделать.

В стомиллионный раз пишу - логи веб-сервера читали?

Я писал уже про то, что эта книга из одни опечаток сделана, меня обкакали в итоге:
http://drupal.ru/node/25671
а то что я писал - в мусор. Ну да и наплевать.

2Автор: смотри и тебя в мусор щас определят!

Автор, в чём заключался ваш анализ? В том, что вы по очереди говорили себе, что эта причина вам не подходит? Логи веб-сервера смотрели? Пробовали отключить все доп. модули, оставив только стандартные? Что вы вообще пробовали - вы же не пишите!

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

> Проблема в том, что пытаясь установить абсолютно любой модуль он (модуль) не появляется в admin/build/modules.
Нет такой проблемы. Вот нет и всё.
Если распаковали архив верно, то всё будет работать. Если не работает проблема только одна - руки. Не туда распаковали, не так распаковали, распаковали в другой сайт, а не тот который пытаетесь потом посмотреть в админке.

В блоке точно HTML? Там не код какой-нибудь который должен этот HTML генерить?
Чудес не бывает! Либо ошибка в блоке, либо ошибка в настройках. Попытайтесь проделать всё заново, например заменив текст блока какой-либо безобидной строкой.

Автор, слабо в поиске на этом сайте набрать "белый экран"

Кэш включен? Если да, то выключите и почистите его.
Страница /about относится к публичке и может быть закэширована ранее без блока.

Не node/about, а node/НОМЕР или /node/НОМЕР - попробуйте оба варианта
Также можете попробовать ещё просто about без / вначале

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

По-моему, если остальное сделано правильно, должно работать либо /about либо node/N, где N - номер нода, алиас для которого /about

Надо будет статейку накропать по этому поводу, вдалбливая одну простую мысль, которую уже на этом сайте озвучивали неоднократно: "Не работают чистые URL? Разбирайтесь с правилами mod_rewrite в .htaccess".

Кэширование включено? Сколько модулей стоит кроме стандартных?

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

На самом деле ошибка, конечно, не в menu.inc в 452-й строке, просто callback, при вызове которого генерируется эта ошибка, сам вызывается из menu.inc в 452-й строке.

Со строками вида:
> There are 19 images in this gallery
Надо ещё посмотреть. Возможно нужна plural форма, а в переводе тупо забит один вариант.

А вообще, перевод берётся только для строк, которые вызываются в виде, например print t('строка'). Однако, авторы модулей часто пишут просто print 'строка'. Такие строки разумеется будут выдаваться как есть, какие бы переводы уже не существовали.

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