а файл .htaccess вы перенесли?
по умолчанию в *nix системах файлы, имя которых начинается с символа "." являются скрытыми.
Если вы переносили исходный код проекта как архив, а потом распаковывали его при помощи файл-мененджера в панели управления хостинга, то архиватор мог его не распаковать.

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

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

Задача решается до неприличия просто.
После создания форумов в разделе "Содержание" -> "UIE Forum" открываем для каждого из созданных форумов блок "Контроль доступа" и выставляем для него соответствующие права.

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

Это не баг, это фича.

Скорее всего, боятся что станете использовать wget в каких-нибудь неблагородных целях.

Как вариант решения (только ногами не пинайте), использование iframe в котором прописан cron.php.

Объясняю, что я имею в виду:
1) Создаем блок, который содержит следующий HTML-код:

<div id="cronframe">
<iframe width="1" height="1" src="/cron.php" ></iframe>
</div>

При вызове скрипта крона через php -f скрипт работать не будет, т.к. расчитан на запуск под управлением веб-сервера (т.е. доступ по URL).

Попробуйте вместо
*/5 * * * * /usr/local/bin/wget -O - -q /pub/home/ЛОГИН/cron.php

написать
*/5 * * * * /usr/local/bin/wget -O - -q http://ваш.домен.зона/cron.php,

т.к. основной параметр для команды wget - это URL, а не путь к файлу, другими словами вместо /pub/home/логин/cron.php нужно писать адрес страницы вида http://......./cron.php

1. Проверьте переменную $base_url в файле конфигурации, если нужно, то выставьте ее в нужное для вашего случая значение (URL вашего домена 3-го уровня без слеша в конце строки)

А что по этому поводу скажет Кальтенбрюннер ? т.е. что написано в логе ошибок сервера ?

Может быть не совсем для дизайнера, но на этапе кодинга очень здорово выручает расширение Web Developer для Firefox. Помимо изменения размера окна браузера, позволяет включать/отключать javascript, изображения, есть экранная лупа, линейка, отображение направляющих и еще много полезных функций.

Для Internet Explorer есть похожее решение под названием Internet Explorer Developer Toolbar.

Да, ты прав, я забыл про сортировку документов.

Тот код, который предложил я, отсортирует по алфавиту термины, тот код, который прислал goodboy - документы.
Объединив усилия, получишь требуемый результат.

Задача решается просто:

После строки :

$terms = taxonomy_get_tree($vid);

(5-я строка в вашем исходном файле)

Добавляем строку:

usort($terms,create_function('$a,$b','return strcasecmp ($a->name,$b->name);'));

И наслаждаемся списком, который отсортирован по алфавиту

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

Нас, как я понимаю, в первую очередь интересует защита от вызова скриптов (в том числе и административных) на НАШЕМ сервере.
Соответственно, все пользовательские изображения должны быть в каталоге files, все изображения модулей и тем должны находиться в каталоге sites. Все обращения за изображением в другие каталоги должны быть пресечены как провокаторские.
Внешние ресурсы нас мало интересуют, хотя вполне возможна и такая атака - если у посетителя открыта сессия на другом сайте, код которого вызывается при помощи IMG.

А если сделать обработчик вывода, который анализирует атрибут src для изображений и фильтрует все изображения, которые ссылаются на файлы вне каталогов тем и files ?

Конечно, нужное и важное дело. Но пока одна небольшая корпорация откуда-то с северо-запада США не научит свое дол....детище поддерживать в полном объеме и в полном соответствии с спецификацией хотя бы HTML4 и CSS2, все результаты дальнейшей работы по развитию этих спецификаций могут так и остаться не более чем словами на бумаге.

Какая версия Drupal ?

gsitemap уже не поддерживается автором и переименован в xml sitemap, над которым и ведуться работы

Детальная информация по поводу safe_mode доступна на официальном сайте PHP .

Это связано не с Drupal, а с режимом работы safe mode PHP. В этом режиме для PHP-приложений запрещен доступ к файлам, расположенным вне DocumentRoot.

Можно сделать поддомен soko1 алиасом основного домена, а для ведения блога именно в этом сабдомене использовать (или хотя бы попытаться использовать) модуль Domain Access

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

Т.к. хостинг по вашим словам дешевый, скорее всего дисковая квота у Вас небольшая.