Но как водится выход есть даже из самой жопской ситуации. То есть если вам необходимо завести пяток сайтов в одной базе, то это возможно сделать. Но надо учитывать несколько моментов:

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

Если вы все же решили что оно того стоит, то создаем базу данных средствами хостинга, после чего закачиваем нужное количество копий wordpress на хостинг, подключаем домены и запускаем установку CMS Wordpress, где для каждой установки указываем различные table_prefix: wp_ ; wp1_; wp2_ и т.п, которые после копируем в файл wp-config.php (в самом файле для копии wordpress эта строка будет выглядеть $table_prefix = ‘wp_’; )

Точно такое же действие подойдет и для других CMS:
в Drupal прописываем в файл sites/default/settings.php аргумент $db_prefix = ‘drupal1_’;
в Joomla в файле configuration.php указываем var $dbprefix = ‘joomla1_’;
После того как запустим установку CMS все необходимые таблицы, с указанными префиксами создадутся установочными скриптами.

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

Собственно погуглив какое то время обнаружил, что это баг дебиановской платформы, так как сама платформа и её дистрибутивы содержат не оригинальный GD, а кастрированную модификацию, в которой ради безопасности отключены по умолчанию  некоторые функции,, которые могут скомпрометировать систему. В том числе вырублен и упомянутый функционал imageantialias.  Так что с этой стороны лечится данный косяк не хитрыми манипуляциями пересборки пакета php с включенным функционалом:
устанавливаем необхоимые для пересборки пакеты:
# apt-get install build-essential debhelper fakeroot

Вытягиваем исходник php и подтягиваем депендансы
# cd /usr/src
# apt-get source php5
# apt-get build-dep php5
# cd php5-5.2.17

После этого в файле  debian/rules меняем содержащеюся там строку
–with-gd=shared,/usr –enable-gd-native-ttf \
на более правильную
–with-gd=shared –enable-gd-native-ttf \
И затем пересобираем пакет
dpkg-buildpackage -rfakeroot
dpkg -i php5-gd_5.2.0-8+etch13_i386.deb
Собственно тут же мне упал ответ от хостинга, гласивший что данная проблема является особенностью php5.2 так как в этой версии интерпретатора не включен функционал ‘bundled’. И если я хочу чтобы мне было щасте. то они могут меня перести на php5.3, но с оговоркой что могут быть косяки в работе. Прошерстив все подробности о проблемах wordpress с php 5.3, я решил остаться на версии 5.2, предложив парням свое решение проблемы, на что они мне поведали, что пробовали эту тему, но зверек получается крайне нестабильный, так что на шареде они это не будут делать точно.

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

Итак на “Завалинку” прикрутил Поиск, который у меня по каким то причинам не работал. Собственно по-началу не мог понять чем это вызвано, поскольку поиск не искал ничего, и любой запрос получал 0 результатов. Проковырявшись какое то время в сторону того что поиск не ищет по utf-8 я допетрил, что в Joomla все крайне взаимосвязано, и включив модуль в разделе модулей, также необходимо активировать соответствующие ему плагины.  Так что собственно после включения плагина Search – Content все начало нормально искаться.

Туда же я прикрутил отличный модуль RokAjaxSearch, позволяющий осуществлять поиск как по содержимому сайта, так и по Google. Причем найденные страницы он выводит сразу же по мере набивания текста, в ниспадающем меню, что крайне удобно и позволяет не прибегать к каким нибудь сторонним поисковым формам.  Модуль абсолютно бесплатный и крайне удобный в настройке и использовании. Единственное что, надо его заставить говорить по русски, а то слово Search среди русских букв слишком бросается в глаза.  Для этого берем файл language/en-GB/en-GB.mod_rokajaxsearch.ini (для другого модуля файло будет называться соответственно), в котором меняем правую часть выражений на русские варианты. Далее файл сохраняем в кодировке UTF-8, иначе все будет козякозябрами. Для этого в блокноте, при сохранении, в нижнем выпадающем меню кодировка выбираем UTF-8. Сохраняем- заливаем обратно на сайт- и все работает.

После этого я подключил страницу о 404 ошибке, которая не смотря на мои пылкие терзания файла .htaccess не возымела никакого действия. Довольно странно, ибо получается что отработка движка  joomla каким то образом превалирует над правилами файла управления .htaccess
Собственно пути для получения страницы ошибки два:

1. Через файл .htaccess в который мы добавляем строчки:

ErrorDocument 401    /error401.php
ErrorDocument 403   /error401.php
ErrorDocument 404   /error401.php
ErrorDocument 500   /error401.php

2. Через движок Joomla

Изменяем вид стандартного документа об ошибке, который выдает CMS Joomla. Файлец находится по маршруту templates/system/error.php
Открываем его и заменяем его содержимое на следующий код:
######################################

<?php ($error->code == ‘404′) ;
{header (‘Location: http://odminblog.ru/error404.html’);
exit;
} ?>

######################################
где адрес http://odminblog.ru/error404.html путь к сконфигурированной до этого странице ошибки.

Никогда пожалуй я не тянулся к знаниям с такой силой, как в предвкушении этой задачи

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

Год уже работаю с различными буржуинскими хостингами, и очень они мне нравятся во всем: удобство, поддержка, обслуживание, цены, скорости. Поддержка вообще прекрасна- поскольку у большинства из них имеется лайв-чат, что не так, помогут почти мгновенно, или хотя бы просто быстро. Но это если что то простое или стандартное. А вот если возникают какие то сложности, то тогда почти всегда выходило так, что мне быстрее было допетрить самому чем долго и занудно общаться с суппортом. Вот и сейчас- полтора часа ушли на объяснения что и почему и как не работает, консультации с админами на их стороне и прочее, и только когда понял, что со мной работают наотъебись™ , немножко включил мозг- в итоге сделалось все за 5 минут. :-/ Кто вернет полтора часа? Но ладно- это так

******
Вчера на одном из своих хостингов апгрейдил движки и удалял не нужные домены и сайты. В итоге сегодня обнаружил, что по глупости удалил нужный сайт, который хостился в папке, принадлежавшей ранее другому домену, и в этой связи удобнейшая утилита Fantastico показала что эту установку использует домен который я давно уже снес, за ненадобностью.

Вообщем используя Fantastico я снес сайт крутившийся на Joomla.

И сегодня обнаружив пропажу- решил было все исправить. Взял имевшийся у меня бэкап домашней директории, закачал его в нужную директорию, после чего попытался восстановить бэкап базы сайта. Но стандартной восстановлялкой из утилиты Backups в панели управлении хостингом cpanel это не получилось, по не понятным мне, и как оказалось в последствии- техподдержке также, причинам. Тогда в утилите MySQL Databases я создал такую же базу и пользователя, назначив ему права на базу.  После чего я загрузил утилиту phpMyAdmin, доступную в разделе Databases и в ней, выбрав соответствующую базу, с помощью команды Import подтянул базу данных.

Но сайт по прежнему говорил о том, что не может соединиться с MySQL, из чего я сделал вывод, что пароль у меня к базе указан не правильно. А вот как правильно – это мне и предстояло узнать. После того как я перелопатил всю базу Joomla и бэкап общей базы mysql, в которой пароли были хешерованы, я полез собственно в установочную директорию Joomla. И вот в ней, я обнаружил файлик, содержавший всю ту информацию, которую я надеялся найти в базе Joomla, а именно пароли и явки.

Итак, разрешите представить файл %homedir%/configuration.php
Открываем на редактирование и видим много чего интересного, но нас интересуют поля относящиеся к движку mysql.

####################

<?php
class JConfig {

…….

var $dbtype = ‘mysql‘;
var $host = ‘localhost’;
var $user = ‘odminblog_mysqluser’;
var $db = ‘odminblog_jo177′;
var $dbprefix = ‘jo_’;
var $smtphost = ‘localhost’;
var $session_handler = ‘database’;
var $password = ‘Password’;

…..

}
############

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

Выполнив все указанные процедуры я получил работоспособный сайт назад.

На эту тему я перелопатил весь инет, как русскоговорящую часть, так и англоязычную, но единственное что я смог найти по этому поводу, это упоминание того, что да действительно, такая проблема имеет место быть, и есть такие люди у которых joomla тоже не показывает изображения, но никто не знает как с этим бороться и главное все это списывали на, чуть ли не на документированный баг, самой Joomla. С тем я и жил, забив на саму Joomla и не смотря на тот факт, что, на мой взгляд, она является второй по удобству CMS после Wordpress.

И вот сегодня решил привести в порядок одну из имеющихся у меня хостинг площадок, для чего залез на неё и стал чикать не нужные мне сайты и порталы. Заодно решил обновить имеющиеся движки. Актуальным обновлением для системы оказалась версия 1.5.15 и хотя на офф.сайте Joomla уже имеется версия 1.6, я обновился до предлагаемой версии.

И что вы думаете? Мало того, что сайт стал побыстрее крутиться и гораздо приятнее отображаться, так САМОЕ ГЛАВНОЕ: исчезла проблема того, что Joomla не показывала картинки!!! Так что все теперь отображается корректно, и Joomla снова стала моей любовью.

Мораль: не забывайте эпизодически обновлять систему! С Wordpress я это правило никогда не забываю, а вот с остальными сайтиками как то не сложилось, но теперь хорошее напоминание о прописной истине.

ЗЫ: для недовольных деятелей хочу сделать одно замечание, которое возможно придаст данному посту большую осмысленность. Если вы полагаете что совет обновить Joomla полная херь, то открою страшную тайну- Joomla является лишь CMS и то что в ней не отображаются картинки- является только ошибкой корректности отображения html кода, который вводили вы и интерпретирует CMS.  В этой связи откройте исходный код нужной страницы в браузере и сравните с им же в самой Joomla- вероятнее всего Joomla или вы изменили местоположение страницы в иерархии сайта, так что относительный путь к изображению ведет куда то вдаль, поэтому юзайте абсолютные пути для вставки изображений, с использованием доменного имени: Сайт/имаджес/изображение.jpg; а также проверяйте правильность синтаксиса img src, ибо движок Joomla опять же добавляет свои классы изображений, которые препятствуют корректному отображению картинок.

Как вариант, существует решение проблемы, путем добавления строки в файл configuration.php
var $live_site = vashsite.ru

UPD: столкнулся буквально на днях с подобной же проблемой, которую умельцы решали путем правки строки в файле libraries/joomla/document/html/renderer/head.php

заменяя стоку
$strHtml .= $tab.’<base href=”‘.$document->getBase().’”></base>’.$lnEnd;
на
$strHtml .= $tab.’<base href=”‘.JURI::root().’” />’.$lnEnd;
хотя по некоторым данным после подобных телодвижений, перестает отрабатывать навигация через якоря.

<a href=”clickme_baby” onclick=”window.open(‘TARGET_URL’);return false;” target=”_blank” rel=”nofollow”>Аццкая ссылка</a>

Т.е при наведении на ссылку в статусе будет видна ссылка, http://myserver.ru/clickme_baby , а при клике на ссылку бродилка будет переходить на нужный нам адрес.

2. Создаем директорию в корне своего сервака, назовем её например links и в не создаем директории url1, url2 и т.д. В каждой директории создается файлик index.php со следующим содержимым, меняем только ссылки куда нам следует переходить.

#####   index.php   #####

<?php $url = $_GET['url']; header(“Location: TARGET_URL”); exit; ?>

######################

После чего наши ссылки будут иметь вид http://myserver.ru/links/url1 ; http://myserver.ru/links/url2 и т.д