Для миграции Вам нужно иметь установленную Joomla! 1.0.12. В случае, если Ваш сайт работает на Joomla 1.0.13, необходимо установить патч Rob Schley-а. Также рекомендуем перед обновлением создать полную резервную копию Вашего сайта на случай, если что-то пойдет не так. Мы рекомендуем не уничтожать Ваш сайт на Joomla 1.0.x до тех пор, пока вы не убедитесь, что миграция на Joomla 1.5 прошла успешно и все работает так как нужно.

В идеале сначала необходимо выполнить миграцию на локальном компьютере и только потом на «живом сайте». Причем нужно установить Joomla 1.5 в отдельную директорию и отдельную БД, сохранив при этом файлы и базу Joomla 1.0.x
Шаг 1: Загрузка компонента Migrator и установка его на сайт с Joomla 1.0.x

Актуальная версия компонента-мигратора доступна на сайте Pasamio Project’s FRS site. На сегодняшний день это Migrator RC5. Загрузите компонент Migrator и установите его на ваш сайт с Joomla 1.0.x. Компонент устанавливается как обычный компонент и доступен после установки в меню Components — Migrator.
Шаг 2: Установка дополнительных плагинов для Migrator-а

Компонент Migrator осуществляет миграцию данных только для встроенных компонентов и модулей. В случае, если у Вас установлены сторонние расширения, Вам необходимо установить соответствующие плагины для компонента-мигратора Обратитесь за этими плагинами к авторам расширений. Существует два типа плагинов: «SQL» плагин, работающий с обычным текстовым SQL файлом и «ETL» плагин, содержащий небольшой кусок PHP кода в котором указывается каким образом мигратор должен обрабатывать данные, хранящиеся в таблицах и конфигурационных файлах. Вызов плагинов осуществляется из меню «Add Third Party Migrators», путем указания пути к файлу плагина. После выбора плагина он будет автоматически выполнен. Список доступных плагинов можно посмотреть кликнув на «List Plugins» на основной странице компонента
Шаг 3: Создание SQL файла для миграции

После того, как вы установили все необходимые дополнительные плагины нажмите «Create Migration SQL file» для начала процесса. Компонент миграции разработан таким образом, чтобы даже для большого количества данных не произошло прерывания процесса создания по тайм-ауту. Во время создания файла страница может несколько раз автоматически перегружаться сообщая о состоянии процесса. После того, как процесс создания миграционного файла будет завершен, на экране появится ссылка для загрузки созданного файла. Во время создания файла миграции в нем будет автоматически произведены все необходимые изменения полей в таблицах для корректной работы в Joomla! 1.5, включая изменение тегов mosimage.
Шаг 4: Установка Joomla! 1.5

Последним этапом миграции является инсталляция на Ваш сайт новой версии Joomla! 1.5. Следуя указаниям мастера инсталляции выполните все шаги. На последнем шаге инсталляции Вам будет предложено ввести название сайта и запустить процесс миграции данных. Для выполнения миграции данных Вам нужно загрузить на Ваш новый сайт миграционного SQL файла, который Вы создали на предыдущем этапе (Шаг 3). Миграционный файл можно загрузить двумя способами:
загрузить по HTTP
загрузить по FTP/SCP

Первый метод — загрузка по HTTP пригоден для файлов миграции небольшого размера во избежании прерывания выполнения скрипта из за превышения времени выполнения указанного в настройках PHP. Альтернативный метод — загрузка файла по протоколу FTP или SCP или же любым другим способом, предложенным Вашим хостинг провайдером. Этот метод подойдет для сайтов с большим количеством контента и, соответственно большим объемом миграционного SQL файла. При использовании метода загрузки по HTTP,— просто выберите файл миграции и нажмите кнопку «Загрузить». При использовании альтернативного метода — предварительно загрузить файл миграции в директорию installation/sql/migration и переименуйте его в «migrate.sql». Если по каким либо причинам процесс миграции не удался, Вам необходимо заново загрузить файлы миграции и повторить процедуру.

После того, как процесс миграции завершился,— введите название сайта (по техническим причинам название файла не может быть мигрировано автоматически) и завершите установку Joomla 1.5.

В директорию /files поместим файл index.php следующего содержания:
<?php
header(«Location:files»);
?>

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

В директорию files/files поместим файл .htaccess с настройками:
RemoveType application/x-httpd-php php php3
Options Indexes FollowSymLinks MultiViews
IndexOptions FancyIndexing ScanHTMLTitles
ReadmeName .footer.html
HeaderName .header.html

Команда RemoveType application/x-httpd-php php php3 запрещает запускать файлы *.php на выполнение в пределах вашего репозитория. Это полезно сделать, если вы будете давать доступ на размещение файлов в вашем репозитории третим лицам. В этом режиме php файлы не запускаются, а скачиваются как обычные файлы.

Команда Options Indexes FollowSymLinks MultiViews говорит серверу APACHE, что в данной директории разрешено сканирование содержимого. Это является ключевой настройкой, которая позволяет организовать репозиторий данного типа в принципе.

Команда IndexOptions FancyIndexing ScanHTMLTitles позволяет выводить заголовки html-файлов рядом с их именами. Эта опция является полезна, если в вашем репозитории будут хранится HTML-файлы.

Команды ReadmeName .footer.html, HeaderName .header.html назначают файлы, содержимое которых будет автоматически подставляться в начало и конец страницы репозитории и служат для достижения разнообразных оформительских эффектов.

Теперь создайте файлы .header.html, .footer.html и поместите их в каждую папку в пределах вашего репозитория. Если вы хотите, чтобы ваш репозиторий унаследовал стили вашего шаблона, то в файле .header.html нужно сделать подключение CSS-стилей, например так:
<link rel=»stylesheet» type=»text/css» href=»http://www.gorodbereza.ru/templates/akogreenportal/css/template_css.css» />
(В моем случае идет импорт стилей с шаблона «akogreenportal»)

Здесь существует один важный момент. В случае когда файлы заголовков не определены, APACHE автоматически создает заголовки с путём до текущей директории, например Index of /files/files . Это очень полезная информация, так как показывает координаты директории, которую вы в данный момент просматриваете. Если вы создаете свой заголовок (файл .header.html), то в нём будет полезно отразить эту информацию, прописав в каждом файле .header.html, каждой директории, путь до данной директории.

Использование файлов .header.html и .footer.html позволяет сделать из репозитория полноценную HTML-страницу, которую можно гармонично вписать в дизайн вашего сайта. Вот пример репозитория-галереи (в качестве файлов выступают рисунки): [ссылка]

Осталось самое важное – интегрировать наш репозиторий в JOOMLA. Для этого в админке JOOMLA войдите в окно создания нового элемента меню и выберите тип меню Wrapper. В открывшемся окне настроек впишите:
Name: – Файлы (название пункта меню)
Wrapper Link: – /files/files (путь до вашей директории с файлами)
Auto Height; – yes (активации данной опции является полезной, так как автоматически регулирует высоту окна и избавляет от неэстетической вертикальной полосы прокрутки)

В остальных опциях можно оставить значения по умолчанию.

Все, репозитарий готов. Он будет выглядеть примерно как у меня: [ссылка]
Создание закрытой директории

Очень часто вам может понадобиться закрыть некоторые директории от общего доступа. Это также можно сделать средствами Apache: В директорию, которую вы хотите закрыть (в моём случае, это директория private) поместите файл .htacces в котором необходимо прописать «секьюрные» настройки, например:
AuthName «Password Protected»
AuthType Basic
AuthUserFile /www/myproject/passwd.file
require valid-user>

Здесь самой важной является опция AuthUserFile, в которой прописывется путь до файла passwd.file. В файле passwd.file – хранятся данные авторизации: имя пользователя и хэш-образ пароля.

Файл passwd.file создается утилитой htpasswd, которая входит в состав сервера APACHE. Более подробно об этом можно узнать [здесь].

P.S. Если в вашем ропозитории будут отсутствовать иконки файлов, то распакуйте и поместите папку icons в корень вашего сайта [ссылка]

Одним из атрибутов и инструментов хорошего блога считается возможность назначать и управлять ключевыми словами (keywords) к материалам сайта, что предоставляет возможность пользователям при желании быстро находить необходимую информацию по интересующей их тематике. В своем блоге, созданном на CMS Joomla!, я решил использовать компонент JTags 1.3, он достаточно функционале и удобен в использовании. Думаю, что теперь поиск материалов заданной тематики по ключевым словам в блоге не вызовет у Вас затруднений.

В процессе обсуждения первой статьи из данного цикла было указано, что при использовании данного компонента с кириллицей ключевые слова или словосочетания, содержащие более 10-15 знаков, отображаются нормально, но в случае поиска почему-то обрезаются и, соответственно, перестают давать результат. Предложенный разработчиком Kayumov вариант небольших модификаций полностью решает данную проблему. В том же материале предложен к реализации хак для модуля компонента JTags, позволяющий после каждого тэга, в скобках, указывается встречаемость его на сайте.

Ещё одним часто используемым элементом блога является календарь, позволяющий просматривать материалы опубликованные за определенную дату. Для CMS Joomla! отличным решением является компонент Blog Calendar. Компонент работает с использованием технологии Ajax и имеет весь необходимый функционал: переключение между месяцами, группировка по датам и годам, вывод количества материалов в тот или иной день при наведении на число – необходимый минимум, который приличествует нормальному календарю, здесь есть. Модуль может быть выведен не только в виде собственно календаря, но и в виде архивного дерева, разбитого по годам и месяцам. При установке и работе данного компонента на некоторых хостингах могут возникать проблемы, которые однако легко решаются путями собранными воедино в материале Устанавливаем Blog Calendar – AJAX календарь для Joomla.

Надеюсь данные рекомендации помогут Вам в развитии личного блога на CMS Joomla!

Работу всего описанного можно посмотреть на примере личного блога автора статьи или на MitrichLab.RU.

Напомню, что нами рассматриваются вопросы создания личного блога на CMS Joomla 1.5.x.

Эти понятия конечно взаимосвязаны, но имеют кардинальные отличия, как в плане функционального назначения, так и в плане их создания и разработки. Давайте разберемся, что такое компонент Joomla, что представляет собой модуль Joomla и в чем их принципиальные отличия.

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

Итак, представим себе обычный автомобиль, и из каких функциональных узлов он состоит. Аналогия конечно не полная, но для понимания отличия между компонентами и модулями Joomla вполне подойдет.
Компоненты и модули CMS Joomla как узлы автомобиля.

1. Основные узлы, которые предназначены непосредственно для того, чтобы автомобиль двигался.

Это двигатель, коробка, ходовая часть и т.п. Сюда же можно включить и узлы, которые непосредственного участи в движении автомобиля не принимают, но без которых либо не возможна, либо затруднительна работа основных узлов (бензобак, система зажигания и т.п. ).

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

Все это и есть компоненты Joomla. Можно установить на сайте магазин товаров вместо каталога, но вывести структурированный список товаров из базы данных без того и другого невозможно.

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

Это может быть получение информации о работе и состоянии основных узлов, создания более комфортных условий для управления автомобилем, получении какой-либо дополнительной информации и узлы управления автомобилем.

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

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

Применительно к CSM Joomla, все это – модули сайта: меню сайта, модули авторизации, опросов, вывода популярных статей, баннеров, случайных картинок и т.п.

3. Кузов, на который устанавливаются и крепятся все узлы.

Применительно к сайту на Joomla, это шаблон сайта. Непосредственного отношения к компонентам и модулям он не имеет, но именно шаблон определяет, в каком месте будет выводиться основное содержание, и где будут располагаться те или иные модули. Плюс ко всему шаблон определяет общий дизайн сайта, но это тема для отдельной статьи.
Отличие № 1.

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

Имеется ввиду, что без определенных компонентов, выполнение необходимых вам функций будет невозможно. То есть если вы определили, что на сайте должна быть гостевая книга, то для этого будет необходим компонент. Почему не модуль?

Во первых, содержимое гостевой книги должно выводиться в основной части страницы, во вторых, нужно чтобы сообщения отправляемые посетителями обрабатывались (проверка валидности email и url, проверка на нецензурные выражения, проверка на SQL-инъекции и т.д.), и в третьих, сообщения посетителей должны записывались в базу данных сайта.

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

Таким образом, модуль, в подавляющем большинстве случаев, нужен лишь как вспомогательный элемент к имеющемуся компоненту.
Отличие № 2.

Выводить что-либо на страницу сайта в один и тот же момент времени может только один компонент и только в одно поле. Это поле является главным полем страницы (чаще всего – центральная часть страницы), и выводить в него данные может лишь компонент. Модулям это поле недоступно.

В это же время на этой же странице могут располагаться десятки модулей и выводить в своем теле (в границах своего модуля) абсолютно любую информацию, даже никоим образом не связанную с текущим компонентом. Более того в одном и том же поле могут располагаться и выводить свою информацию, абсолютно все модули сайта. Это конечно бессмысленно, так как разработчики Joomla определили для вывода модулей целых 50 полей, но, тем не менее, никаких ограничений в данном случае нет.
Отличие № 3.

Следующее отличие компонента от модуля заключается в том, что при выполнении своих функций, модуль ничего не записывает в базу данных сайта. Такого ограничения в возможностях, конечно, никто не накладывал, но если подходить к вопросу грамотно, то самостоятельно модуль в базу данных ничего писать не должен, а если есть такая необходимость, то нужно обращаться к существующему компоненту Joomla и передавать ему данные для записи в базу данных.
Отличие № 4.

В принцип работы CMS Joomla не заложен механизм непосредственного обращения к отдельному модулю из строки браузера и передача ему каких-либо параметров. Все параметры и основные данные модуль получает из базы данных сайта. Этот факт конечно можно обойти и передать методом GET или POST, какую либо переменную, которую распознает только модуль, но, по-моему, это не имеет никакого смысла и больше походит на извращение.

Существует, конечно, и другие отличия, например, компоненты и модули имеют разную файловую и внутреннюю структуру, отличные способы управления и администрирования, совершенно по-разному устанавливаются и размещаются в разных папках сайта. Но все эти различия не дают ответа на вопрос: «Почему именно компонент, а не модуль?».
Резюме.

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

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

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

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

Я уже рассказывал об основных отличиях компонентов и модулей, а определение понятия «модуль» Вы можете посмотреть в глоссарии Joomla на этом сайте. Теперь давайте рассмотрим, из чего состоит и как строится классический модуль CMS Joomla. Хочу подчеркнуть – именно классический! Модуль Joomla, это обычная программа которая может содержать все доступные скриптовому языку PHP средства и методы, вплоть до манипулирования системными переменными сервера и обращения к другим интернет-ресурсам. Однако все это выходит далеко за рамки функционального предназначения модулей CMS Joomla, а значит, рассматривать мы это не будем.
Из чего состоит модуль CMS Joomla.

В минимальном составе, это два файла – mod_названиемодуля.xml и mod_названиемодуля.php, которые по умолчанию располагаются в папке «modules» на сервере.

Файл mod_названиемодуля.xml, это многофункциональный файл, который содержит:
общие сведения о модуле – название, описание, авторство, версию и т.п.;
сведения для инсталляции/деинсталляции модуля – список файлов и пути их размещения;
список параметров для конфигурирования модуля.

Файл mod_названиемодуля.php содержит программный код модуля.
Что такое программный код и как пишутся программы (на PHP в том числе), я рассказывать не буду, сами понимаете почему.
Хочу заметить, что создатели CMS Joomla разработали целые библиотеки классов, которые облегчают изготовление, как модулей, так и любых других расширений для Joomla. Эти библиотеки называются Joomla API. К сожалению, я не встречал полную документацию по API Joomla. Существуют лишь разрозненные или плохо сгруппированные описания. Могу посоветовать посмотреть здесь http://www.php.joomlademo.de или здесь http://help.joomla.org/api/, либо воспользоваться поиском google.
Если Вы обладаете иной информацией, прошу высказаться в комментариях к статье.

При выполнении кода модуля, все, что выводится с помощью оператора echo или аналогичных ему, будет выведено на страницу сайта в теле модуля.

Чтобы модуль стал доступен, он должен быть инсталлирован в CMS Joomla.
Инсталляционный файл модуля представляет собой обычный архив в который помещены все файлы модуля. Наиболее распространен архиватор zip, да и сама Joomla очень хорошо работает с такими архивами, поэтому на нем и остановимся.

Итак, чтобы изготовить и установить свой модуль на CMS Joomla, необходимо:
Изготовить как минимум один программный файл модуля.
Создать xml файл и прописать в нем все необходимые данные.
Поместить оба файла в архив zip.
Инсталлировать полученный модуль в Joomla.

Все!

Как видите, ничего сложного процесс изготовление модуля под CMS Joomla не представляет! Однако остается вопрос, что же должны содержать в себе файлы модуля? Давайте разберемся с этим более подробно.
Структура и содержимое файлов модуля Joomla.
В данной статье для примера взят модуль mod_awmnews. Вы можте его найти на нашем сайте в разделе «Модули Joomla». Скачайте его и инсталлируйте на свой локальный тестовый сайт. Затем зайдите на диск локального сервера и перейдите в папку сайта modules. Там Вы найдете два файла – mod_awmnews.xml и mod_awmnews.php. Откройте их с помощью любого текстового редактора, лучше с подсветкой PHP синтаксиса. Я посоветую Zend Development Environment, или что-нибудь попроще, например, EditPlus.

Итак, начнем с XML файла.

XML файл модуля AWM_news – mod_awmnews.xml.

<? xml version=»1.0″ encoding=»windows-1251″ ?> – заголовок документа xml версии 1.0, с набором символов «windows-1251″ – русская таблица windows.

<mosinstall type=»module» version=»1.0.0″> – говорит о том, что данный xml файл является документом для инсталляции модуля CMS Joomla, а версия механизма инсталляции – 1.0.0.
Тег mosinstall является открывающим. Между тегами <mosinstall …> </mosinstall> помещается вся информация о модуле.
Далее, до тега <files> идут информационные поля, которые будут отображены в таблице «Установленные модули» на странице «Установка/удаление модулей».

<name>AWM_news</name> – наименование модуля. Используется еще как заголовок модуля в перечне модулей сайта.

<author>Soloviev Ivan</author> – поле автора модуля.

<creationDate>06.11.2007</creationDate> – дата создания модуля.

<copyright>ArtWebMaster Soloviev Ivan. All rights reserved.</copyright> – сведения о копирайтинге.

<license>http://www.gnu.org/licenses/gpl-2.0.html GNU/GPL</license> – сведения о том, с какой лицензией выпущен модуль.

<authorEmail>artwebmaster @ hotbox.ru</authorEmail> – Email автора модуля.

<authorUrl>http://artwebmaster.ru</authorUrl> – сайт автора.

<version>1.0.0 RE</version> – версия модуля.

<description>Это модуль вывода какого либо текста. Может быть использован для отображения новости, предложения, акции, картинки и т.п.</description> – краткое описание модуля. Выводится в ходе инсталляции и на странице изменения параметров модуля в поле «Описание:».

<files> – открывает список файлов относящихся к этому модулю.

<filename module=» mod_ awmnews»> mod_awmnews.php</filename> – эта конструкция говорит о том, что файл mod_awmnews.php входит в состав модуля mod_awmnews и Joomla должна его разместить (инсталлировать) в папке «modules». Эта информация используется также и для деинсталляции файлов модуля.
Если с модулем будут идти дополнительные файлы – JavaScript, CSS таблицы и т.п., их лучше размещать в отдельной папке с именем вашего модуля. Для этого при создании инсталляционного архива создайте папку, к примеру, mymodule, поместите туда дополнительный файл, пусть это будет myjcsript.js и запакуйте эту папку вместе с основными файлами mod_mymodule.xml и mod_mymodule.php.
В xml файле эти файлы прописываются так:

<filename module=»mod_mymodule»>mod_mymodule.php</filename>
<filename module=»mod_mymodule»>mymodule/myjcsript.js</filename>

После инсталляции, полный путь к файлу myjcsript.js будет таким:

http://вашсайт.ru/modules/mymodule/myjcsript.js

Обратите внимание! Сам файл mod_mymodule.xml здесь прописывать не надо! Joomla самостоятельно поместит его в папку «modules» на Вашем сайте и сама удалит, при деинсталляции.

</files> – закрывает список файлов.

<params> – отрывает перечень настраиваемых параметров модуля. О том, какие значения они могут принимать и как их правильно прописать читайте в отдельной статье «Параметры XML файла модуля Joomla».

<param name=»moduleclass_sfx» type=»text» default=»" label=»CSS-cуффикс класса модуля» description=»Суффикс, который будет использован в описании класса (table.moduletable) таблицы стилей (CSS) модуля. Это позволяет использовать индивидуальный стиль модуля.» /> – здесь указывается, что нужно вывести для редактирования системный параметр определяющий суффикс CSS класса модуля.

<param name=»sometext» type=»textarea» cols=»80″ rows=»5″ default=»" label=»Текст» description=»Обычный текст или текст в формате HTML, который будет выводиться в блоке модуля.» /> – данный параметр служит для вывода в административной части модуля многострочного текстового поля. Запомните имя этого параметра – «sometext». Это имя будет использоваться в дальнейшем.

</params> – закрывает перечень параметров модуля.

</mosinstall> – закрывает инфомационные данные модуля.

Итак, с XML файлом разобрались, теперь перейдем к программному файлу модуля.

Запускаем Денвер, запускаем браузер и вводим в строке адреса

http://localhost/Tools/phpmyadmin/index.php

Мы попали в веб-интерфейс администрирования баз данных на локальном компьютере – phpMyAdmin. Выбираем из выпадающего списка в левой колонке имя базы данных переносимого сайта и после окончания отображения сводных данных о таблицах базы нажимаем на закладку «Экспорт».

В зависимости от того, какая версия phpMyAdmin у Вас установлена, выведенная страница может немного отличаться, тем не менее, действия, которые Вы должны выполнить будут одинаковыми.

Внимательно прочитайте все надписи на странице и убедитесь, что:
список таблиц базы данных в поле «Экспорт» выделен полностью. Если нет, нажмите на «Отметить все»;
радио-кнопка в поле «Экспорт» установлена на «SQL»;
на всякий случай установите галочку в поле «Добавить удаление таблицы», другой вариант названия этого поля «Добавить DROP TABLE / VIEW / PROCEDURE / FUNCTION»;
галочка в поле «Добавить IF NOT EXISTS» установлена. Если нет, установите.

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

Далее устанавливаем галочку в поле «послать» или «Сохранить как файл» и в поле «Шаблон имени файла» дописываем к имеющемуся там «__DB__», например, слово LOCAL и сегодняшнюю дату в формате ГОД_МЕСЯЦ_ЧИСЛО. Пробелы в названии лучше не ставить. Получаем что-то вроде этого: «__DB__LOCAL_2008_09_28». Такое формирование имени поможет Вам в дальнейшем лучше ориентироваться в большом количестве файлов баз данных.
Когда будете делать копию базы данных с сервера хостера вместо LOCAL вписывайте SITE. Это тоже поможет лучше ориентироваться в сохраненных файлах.

Установив радио-кнопку в поле «Сжатие» (или «Упаковать») в позицию отличную от «Нет», Вы можете уменьшить объем файла базы данных и соответственно уменьшить скорость загрузки этого файла на удаленный сервер, однако тем самым Вы увеличите нагрузку на процессор этого сервера, что может быть не всегда приемлемо. Если выход в интернет у Вас скоростной, лучше установить «Нет».

Итак, с кнопками и галочками разобрались, теперь нажимаем кнопку «Пошел» или «ОК» и в открывшемся окне выбираем папку на Вашем компьютере для сохранения копии базы данных MySQL локального сайта Joomla.
2. Закачиваем на удаленный сервер копию базы данных.

Полученную базу данных нашего локального сайта Joomla теперь необходимо записать в базу данных удаленного сервера. Для начала, с помощью веб-интерфейса управления хостинг-площадкой (обычно это cPanel), создаем новую базу данных. Способ создания базы данных у разных хостеров свой, поэтому с этим Вам придется разбираться самостоятельно.

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

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

В открывшемся окне нажимаем закладку «Импорт», если таковой нет, тогда «SQL». После этого, в поле «Импортируемый файл» или «Месторасположение текстового файла», нажимаем «Обзор» и в открывшемся окошке находим файл нашей базы данных. Устанавливаем в расположенном рядом выпадающем списке «Кодировка файла» кодировку «cp1251» и нажимаем кнопку «ОК» или «Пошел». Начнется процесс закачивания файла базы данных на удаленный сервер, создание таблиц и заполнение их информацией. Это может занять какое-то время, так что придется немного подождать.

Если все в порядке и процесс прошел нормально, в левом поле высветятся названия таблиц нашей базы, а phpMyAdmin сообщит, что все хорошо и выдаст количество выполненных запросов. После этого страницу можно закрывать – здесь нам больше делать нечего.

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

Чаще всего ошибки возникают из-за разности версий phpMyAdmin, когда более старой версии подсовывают файл базы данных, созданный более новой, либо при расхождении в кодировках баз данных и т.п. Проще всего, если у Вас возникла ошибка при импорте базы данных, обратиться в службу поддержки хостера.
3. Изменяем системные переменные в файле configuration.php

Находим в корневой папке нашего сайта на локальном компьютере файл configuration.php и копируем его под новым именем, например, configurationSITE.php. Зачем, спросите Вы. Все просто. Для продолжения нормальной работы с нашим сайтом на локальном компьютере, нам нужен файл configuration.php, а файл configurationSITE.php мы подредактируем и будем использовать на удаленном сервере.

Итак, открываем файл configurationSITE.php в Блокноте или любом другом простом текстовом редакторе, ищем указанные ниже переменные и прописываем в них новые параметры. Новые параметры прописывайте внутри кавычек. Например, так:
$mosConfig_host = ‘c12345_joomla’;

$mosConfig_host – сетевое имя MySQL сервера базы данных. Чаще всего используется имя localhost, но если доступа к базе с этим именем не будет, посмотрите в настройках или общих сведениях Вашей хостинг-площадки, в крайнем случае, обратитесь в службу поддержки. Это имя может выглядеть примерно так: msql12.вашхостер.ru

$mosConfig_db – полное имя базы данных созданной Вами в предыдущей главе.

$mosConfig_user – полное имя пользователя базы данных.

$mosConfig_password – пароль доступа к базе.

$mosConfig_absolute_path – здесь прописывается абсолютный внутренний (серверный) путь к папке, в которой будут расположены файлы сайта, без слеша «/» в конце. Посмотреть его можно в общих сведениях о хостинг-площадке или обратившись в службу поддержки. Обычно выглядит так:

/home/папкасайта/public_html
Если Вы затрудняетесь найти этот путь, не беда, оставьте этот и следующий параметр как есть. Далее я расскажу, как можно попробовать вычислить этот путь.

$mosConfig_cachepath – внутренний (серверный) путь к папке «cache» Вашего сайта, без слеша «/» в конце. Здесь просто допишите к пути, прописанному в предыдущем параметре «/cache». Должно получиться:

/home/папкасайта/public_html/cache

$mosConfig_live_site – полный URL Вашего сайта с http://, но без слеша «/» в конце. Примерно так: http://joomla4all.ru или с www – http://www.joomla4all.ru

Как лучше с www или без – дело вкуса, и так, и так правильно, однако не забывайте, что здесь должно быть прописано главное зеркало вашего сайта указанное в файле robots.txt

Прописав все параметры, сохраняем изменения и закрываем Блокнот.

Находим в корневой папке сайта на локальном компьютере файл robots.txt, открываем его в Блокноте и дописываем в конце строку, указывающую домен основного зеркала Вашего сайта:
Host: вашсайт.ru

Опять-таки с www или без – дело вкуса, главное, чтобы в переменной $mosConfig_live_site и в robots.txt имена доменов полностью совпадали. Сохраняем изменения, закрываем Блокнот и идем дальше.

Три́ггер (англ. trigger) — это хранимая процедура особого типа, которую пользователь не вызывает непосредственно, а исполнение которой обусловлено наступлением определенного события (действием) — по сути добавлением INSERT или удалением DELETE строки в заданной таблице, или модификации UPDATE данных в определенном столбце заданной таблицы реляционной базы данных. Триггеры применяются для обеспечения целостности данных и реализации сложной бизнес-логики. Триггер запускается сервером автоматически при попытке изменения данных в таблице, с которой он связан.

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

Триггер активируется, когда происходит определенное событие для конкретной таблицы. Таких события все три:
INSERT
UPDATE
DELETE

Поддержка для триггеров включена начиная с MySQL 5.0.2.
Примеры данной статьи выполнялись на MySQL 5.0.18.
Постановка задачи

Для вас наверно не будет новостью, что можно создавать пользователей MySQL с разными привилегиями. При этом привилегии могут быть настроены очень тонко — вплоть до конкретного столбца.

Например, у вас база данных магазина. Одному пользователю можно разрешить только просматривать наличие того или иного товара, другой может редактировать количество оставшихся копий, а третий может изменять стоимость. Более подробную информацию о пользователях вы можете получить на узле MySQL из статьи <MySQL User Account Management> или на русском.

Предположим, вы так и поступили и у нас имеется несколько пользователей. Само по себе разделение прав и обязанностей уже большой шаг в сторону повышения безопасности. Однако этого явно не достаточно — если товар стоящий 100 у.е. вдруг будет продан за 10, как найти виновного? Кто изменил стоимость в БД?

Или вдруг обнаружится, что закуплено было 10 экземпляров, по факту продано 5, а в остатке числится только 3. Куда делись еще 2? Кто списал товар?

Вот тут нам понадобится журнал аудита — который будет хранить информацию о том кто и что делал с записями в БД.

MySQL предоставляет такую возможность — существует так называемый General Query Log. По всей видимости, там сохраняется даже слишком много информации. Мы напишем свой журнал аудита для одной конкретной таблицы. И, как вы уже наверно догадались, будем использовать триггеры.

Наш журнал аудита это новая таблица в БД. О существовании такой таблицы должно знать как можно меньше людей.

Назовем нашу таблицу mylog. Пусть в ней будет 4 столбца:
| id | user | query | timestamp |

Таблицу легко создать, используя phpMyAdmin** с помощью следующего запроса:
CREATE TABLE `mylog` (
`id` INT NOT NULL AUTO_INCREMENT ,
`user` VARCHAR( 20 ) NOT NULL ,
`query` VARCHAR( 15 ) NOT NULL ,
`timestamp` TIMESTAMP NOT NULL ,
PRIMARY KEY ( `id` )
);

Так же пусть у нас есть таблица table1, за изменениями в которой мы и будем следить.
Каждый раз, при добавлении, изменении или удалении записей таблицы table1 в таблице mylog будет добавляться строка, содержащая имя пользователя MySQL, сам запрос, а также время, в которое он был выполнен.
Создадим простой триггер

Каждое из трех поддерживаемых триггерами событий (INSERT, UPDATE и DELETE) как бы подразделяется еще на два:
начало события BEFORE
конец события AFTER

Иными словами у нас есть не 3 события:
INSERT
UPDATE и
DELETE

а целых 6:
BEFORE INSERT
AFTER INSERT
BEFORE UPDATE
AFTER UPDATE
BEFORE DELETE
AFTER DELETE

Например, событие BEFORE INSERT произойдет перед вставкой новой строки в таблицу, а событие AFTER INSERT после вставки.
Важно отметить, что событие AFTER INSERT может и не наступить, если во время выполнения запроса произошла ошибка.

На каждое из 6 событий для одной конкретной таблицы можно повесить только один триггер.

Таким образом, мы можем записать в наш журнал аудита (в таблицу mylog) все попытки выполнения (события BEFORE) запросов или только удачные (события AFTER)**.

Давайте записывать все попытки — будем использовать события BEFORE.

Следующим запросом к MySQL мы создадим триггер с именем my_trigger для таблицы table1:
CREATE TRIGGER `my_trigger` BEFORE INSERT ON `table1`
FOR EACH ROW
/*ниже следует действие, выполняемое триггером*/
INSERT INTO `mylog` SET `user`= ‘имя_пользователя’, `query`=’insert’;

Как видите все просто: триггер вставляет строку в таблицу mylog. Однако такой триггер нужно еще немного подкорректировать — он должен вставлять не текст ‘имя_пользователя’ в качестве значения для поля user, а реальное имя пользователя.

Что бы узнать реальное имя пользователя воспользуемся одной из встроенных функций MySQL — USER(); Эта функция возвращает строку с именем пользователя MySQL. (Более подробно о функциях MySQL можно узнать на официальном сайте).

Вот так будет выглядеть полностью рабочий триггер:
CREATE TRIGGER `my_trigger` BEFORE INSERT ON `table1`
FOR EACH ROW
INSERT INTO `mylog` SET `user`= USER(), `query`=’insert’;

По аналогии могут быть созданы триггеры для оставшихся событий UPDATE и DELETE.

Надо заметить, что в данном примере, в журнал событий попадает имя пользователя СУБД, однако, при желании туда можно записывать и более подробные данные — например имя пользователя CMS. Ведь в триггере есть информация об изменяемой строке таблицы, а из нее почти всегда можно получить ссылку на пользователя который ее создал/изменил.
Примечание

*При создании более сложных триггеров, если вы пользуетесь phpMyAdmin не старших версий, у вас, скорее всего, возникнут проблемы. Для корректной работы используйте версии старше 2.9.1.

**Вообще то, по-хорошему, журнал аудита должен содержать информацию, как о событии, так и о результате. Однако у нас простой триггер — а значит и простой журнал аудита