Bloginforama

Archive for Ноябрь, 2009

В первой и последующих частях статьи мы установили WordPress на Localhost и изучили работу некоторых плагинов. В восьмой части научились заливать файлы по FTP с помощью Total Commander и скопировали нашу сборку WordPress на хостинг, перенесли туда же предварительно адаптированную базу данных, узнали что такое CHMOD, обновили плагины и движок прямо на домашнем компьютере т.е. на локальном сервере. В этой части продолжим работу с плагинам автонаполнения контентом, Autoblogged, WP Robot, WP Autoblog.
44. Autoblogged 2.4.22

Autoblogged 2.4.22 сайт автора Autoblogged.com – вот он мой плагин, подумал я, прочитав анонс, плагин правда платный и 130 баков стоит, нет проблем, купим. Плагин, как и FeedWordPress тянет контент с Rss лент. Установил, первым долгом он прописал свою таблицу в базе данных.

А также в вертикальной панели инструментов появилось дополнительное меню AutoBlogged с пятью кнопками.
AutoBlogged – Support.

На странице Technical Support видим ссылку AutoBlogged Diagnostic Tests:

И Show PhpInfo, нажав на которую получаем окошечко с подробнейшей информацией о конфигурации нашего сервера:

Не удержался и наверное переборщил со скриншотами, ведь интересненько, заодно можно контента добыть и настройки сервера нашего хостинга проверить(скрины приведены не все, их раза в три больше).
Можно отметить чеки на “Включить ведение журнала” и “Показать подробную информацию”, послать письмо саппорту заполнив специальную форму.
AutoBlogged – Settings. На странице Settings поле Serial Number, куда вводим ключ покупки.

В General Options проставлен чек на AutoBlogged Включено: Снимем его, если хотим, приостановить AutoBlogged. Далее указываем минимальное и максимальное время между обновлениями.
Excerpts выдержка: Когда создается выдержка, здесь проставляем случайный порядок между – (проставляем значения, или по умолчанию), и проставляем чек по выбору слова, сентенция или параграф
Интеграция в WordPress.
Отмечаем чек на ссылки WordPress и WordPress автор. Использовать сохраненные ссылки, если они есть и автора, если он зарегистрирован. Функции поиска RSS – устанавливаем таймаут кэширования и запоминаемся.
AutoBlogged – Filtering – Filtering Options.

Duplicate Posts, здесь два чека на повторяющиеся фильтрации на основе заголовка и ссылок.
Title Filtering – Название фильтра. Устанавливаем максимальную длину заголовка в символах, ставим чеки когда слишком длинный заголовок на Усечение до ближайшего слова или Пропустить пост. Также два чека по названию фильтра Пропустить названия со всеми заглавными буквами или Пропустить название с несколькими последовательными знаками препинания. Мы знаем, что поисковики отрицательно относятся к длинным заголовкам.
Blacklists он и в африке блэклист. Составляем список постов любого из доменов или URL перечисленных в списке, по одному в каждой строке или в одну строку, разделенные запятыми.
AutoBlogged – Tag Options – Tag Options

General Settings. Проставляем данные в полях Минимальная длина тега, Максимальная длина тега и Максимальная длина тега для этого поста.
Tag Sources – источники тегов. Варианты – оригинальные теги Feed, использовать внутренние метки и добавить из контента, посетить URL источника и извлечь дополнительные теги, получить теги с помощью Yahoo, предварительно надо ввести свой Application ID.
Tags – вводим тэг, который будет случайным образом добавляться в каждый пост.
Tag Filtering – Вводим в окошко по одному в каждой строке или в одну строку, разделенные запятыми теги, которые мы не хотим использовать в постах. Это не приведет к удалению этих тегов в существующих в постах, если они есть.
AutoBlogged – Feeds – Source Feeds

Жмем кнопку click here или Add New Feed и попадаем на страницу Feed Settings

General Settings. Здесь в выпадающем списке типы фидов. Выберем пока Rss Feed, в поле Search Keyword вобъем кейворд или URL Feedа, и, далее, необязательное заглавие, которое в принципе может назначиться автоматически, в выпадающем списке выберем статус ноовообразованных постов и ниже чек если хотим использовать оригинальную дату поста.
Feed Processing – обработка фида делится на Process this feed – Обработку текущего фида, чеки на:
1. Каждого запланированного обновления.
2. После каждого(1-го,2-го…) запланированного обновления а также
3. Вручную или в случае получения уведомления через XML-RPC Ping.
Далее Post processing – Пост-обработка, чеки Включить все посты, Включить только первые(20, 30..) постов, Включить случайные (..%) постов.
Tags –Теги – вводим тэг, который будет случайным образом добавляться в каждый пост.
Categories – отмечаем чеком категории для публикации и создаем новые, ниже правила для выбранной категории, чек добавить все текущие посты или в случайном порядке один или более постов.
If unselected blog categories appear in the post content(Если неотмеченная категория появится в контенте поста), ставим чек на А также добавить в пост или Добавить их в качестве метки поста.
Далее – With original feed categories(с оригинальными категориями Feed): чеки на
1. Включить категории оригинального сообщения (если они существуют),
2. Добавить эти категории в своем блоге, если они не существуют.
Authors: В выпадающем окне выбираем какого автора установить для нового поста в различных вариантах.
Ниже указываем размеры встроенного плэйера или вводим URL альтернативного проигрывателя для воспроизведения. FLV и Mp3-файлов.
Filtering – фильтрация на предмет включения постов.
Ниже, по желанию, используем расширенные настройки, настраиваемые поля для конкретных фидов и глобальных шаблонов постов, Post Templates – Шаблоны сообщений, Поиск и замена регулярных выражений фидах, прежде чем добавлять их в посты. Справа жмем Safe Setting и попадаем на страницу:

В зависимости от настроек рост попадаем в Draft или Publish. При всех настройках в статье остается ссылка на URL первоисточника. Не нравится, хотите поменять, зайдите Post Templates – Шаблоны сообщений, и поменяйте в шаблоне внизу “link”, на ссылку по желанию.

Попробуем парсить по кею, в поле Search Keyword вобьем ключевик, далее Process Now и…получаем ошибку. Меняем кейворд на URL фида – Process Now, процесс пошел, вот результат:

Изменим настройки, парсить будем Yahoo Search по кейворду plugin, посты отправляем в Draft.

Вот что получилось:

Зарядим MSN Spases Search, результатов ноль, Google Blog Search, кидаем в Draft, результат положительный – 20 результатов.

Yahoo Video Search результат положительный.

YouTube Tag Search результат тоже положительный.

Flickr Tag Search сработало, а BlogDigger Search нет. Вывод плагин рабочий, им можно работать наравне или взамен вышеописанных.
45. WP Robot
WP Robot – еще один плагин тяжеловес. Денег он стоит для плагина немалых, баков 180, а с 8 – ю модулями оптом, так сказать, 140$. По описанию представляет собой мощный и простой в использовании Robotoblog плагин для Wordpress, позволяющий вести Ваш блог на полном автопилоте и дозированно наполнять его свежим контентом по расписанию. Кроме того созданные сообщения, будут ориентированы на любое ключевое слово и тему, которую Вы укажете! Содержимое постов комплектуется из разных источников, включая Amazon, Clickbank, YouTube и eBay, для этого существуют соответствующие модули. WP Robot добавляет из Amazon продукты, eBay – аукционы, Yahoo Answers – Вопросы и ответы, YouTube видео, целевые статьи, Flickr изображения и Clickbank объявления на Ваш блог автоматически и, конечно, вы полностью контролируете в какой пост они будут помещены. Кроме того WP Robot может также переделывать или автоматически переводить любой пост с помощью Google Translate или Babelfish Yahoo. Причем перевод контента осуществляется в несколько этапов(например, английский на немецкий и снова английский), таким образом обеспечивая ему уникальность. Перечисленные возможности позволяют использовать плагин как инструмент для создания сетей сателлитов, сплогов, добавить целенаправленные и полезные материалы для системы уже созданых блогов, чтобы заработать больше денег. Модули для WP робота позволяет зарабатывать комиссионные за продажу опубликованных сообщений блога из eBay, Amazon и программы Clickbank. Все это прекрасно, а вот как это будет выглядеть на практике мы и постараемся проверить.
Установка стандартная, копируем папку WPRobot с файлами плагина в директорию \wp-content\plugins\. Внутри этой папки, если у Вас хватило денег на дополнительные модули, будет папка modules, с этими самыми модулями. Активируем плагин, обнаруживаем в базе данных новую таблицу wp_wprobot и в админ панели вновь созданную панельку дополнительных опций меню WP Robot с четырьмя кнопками.
WP Robot – Options.
Содержание страницы зависит от того, какие модули у Вас установлены, вначале General Options, а далее, чем модулей больше, тем больше настроек вы увидите. Особое внимание надо обратить на идентификаторы в партнерках Amazon, eBay и Clickbank, без них Вы с них денег не поимеете.
В General Options первое выпадающее меню New Post Status: Устанавливаем статус, немедленная публикация или отправить в черновики(Draft).
Reset Post Count: Если выбрано численное значение этой опции, после того, как будет создано это количество постов, счетчик постов будет сброшен из всех модулей до нуля, и цикл начинается с начала. Это связано с поведением некоторых сайтов по отношению к ключевым словам после определенного числа результатов.
Randomize time of first post: Это опция контроля создания первого поста, после добавления новых ключевых слов. Значения по умолчанию означают немедленное начало создание первого поста, т.е. между 0 и 0 часа после зарядки ключевика. Если поменять значения, первая цифра должна быть больше второй, и оба значения не отрицательные.
Automatically create Tags: Создавать или не создавать автоматически метки.
Exclude from Tags: Слова, перечисленные в поле, нами туда же добавленные трех и менее буквенные не добавляются в метки.

В Amazon Options следующие настройки:
Amazon Affiliate ID:
Ваш аффилиатский ID в Amazon, вида “name-20″
API Key (Access Key ID): Для использования модуля Amazon, мы должны иметь “Amazon Product Advertising API Key”, который легко можно получить бесплатно по адресу _https://affiliate-program.amazon.com/gp/advertising/api/detail/main.html, в разделе “Access Identifiers”.
Secret Access Key: В дополнение к “Amazon Product Advertising API Key” Amazon требует секретный ключ “Secret Access Key”, который можно получить тоже в разделе “Доступ идентификаторы”(”Access Identifiers”).
Search Method: Это Методика поиска, которая распространяется только на многословные ключевые слова. “Exact Match” – Точное соответствие, “Broad Match” – Широкое соответствие. Если установлено “Точное соответствие” модуль будет искать продукты, содержащие все слова нашей ключевые фразы в том же порядке, если установлено “Широкое соответствие”, содержащие все слова, но в любом порядке.
Skip Products If: Правила пропуска публикации определенных продуктов при отсутствием информации о них: Не пропускать, пропускать если описание не найдено, если миниатюр не найдено, нет описания или нет миниатюр.
Post Reviews as Comments? Да или нет. Следует ли добавить отзывы на странице продукта Amazon в пост как комментарии. Выдержки из отзывов, как правило, отображается на правой стороне раздела обзора Amazon.
Amazon Description Length: Длина описания продукта на странице Amazon, которое будет включено в пост. Длина по выбору в символах или “Full Description” – “Полное описание”, которое не включает в себя любые картинки, таблицы и другие данные из оригинального описания.
Amazon Website: Выбираем, какие Amazon сайты Вы хотите использовать по таргетированному признаку(Amazon.com, Amazon.co.uk, Amazon.de).
Strip brackets from titles: Да, Нет. Упрощать и сокращать названия книг, удаляет все скобки.
Post Template: Шаблон поста, доступные теги(макросы): {thumbnail} – Миниатюра, {image} – URL большего изображения товара, {features} – Список функций переданый Amazon, {description} – Описание продукта, {price} – цены на Amazon, {avgrating} – Усредненный рейтинг продукта, {noreviews} – Общее количество отзывов, {link} – Партнерская ссылка на продукт.
Review Template: Шаблон Обзоров. Этот шаблон определяет, как отформатированы отзывы из Amazon, которые будут добавлены в комментарии.
Доступные теги(макросы): {review} – Полный текст обзора, {rating} – От 0 до 5 рейтингов – рейтинг оппонента, {link} – партнерская ссылка на продукт, {keyword} – Ключевое слово, которое было задействовано в WP Robot, {url}- URL партнерки продукта.

Article Options – будем парсить статьи.
Article Source: Выбираем источник статьи, это будут “articlesbase.com” либо “sooperarticles.com”.
Article Formatting Method: Метод форматирования статьи, выбираем “Leave Formatting Intact” – используем оригинальные правила оформления статей, при переводе все ссылки в статье сохраняются, или “Replace Formatting” заменяет все исходное форматирование кода и статей, считается безопаснее, если вы переводите Ваши статьи.
Article Language: Выбираем язык статьи, только помните эта опция будет работать если “articlesbase.com не помечен как “Источник статьи “.
Post Template: Шаблон сообщения: Доступные теги(макросы): {article}- Тело статьи, {authorbox}- Окно с информацией о авторе и ссылки.

Clickbank Options.
Clickbank Affiliate ID: Clickbank Партнерский ID – будет также Вашим именем пользователя на clickbank.com.
Filter Ads? Проставим чек и слова “Commission” и “Affiliate” будут пропущены.
Post Template: Шаблон сообщения: Доступные теги(макросы): {description}- Описание Clickbank Ad, {link}- Аффилиатская ссылка Clickbank Ad.

eBay Options.
eBay Affiliate ID (CampID): Наш ID в партнерке для eBay.
Country: Выбор какой сайт eBay будет использоваться.
Language: Выбор языка на аукционе.
Sort results by: Сортировать результаты по: Различные варианты заказа результатов eBay.
Number of Auctions per Post: Количество аукционов на одно сообщение.
Auto Renew Auctions: Да, вставлять Feed RSS, значит выбран канал RSS и он будет размещать его в сообщении, то есть мы получим результаты последних аукционов с сайта eBay. Если нет, аукционы будут жестко привязаны.
Title Template: Шаблон тайтла, определяющий название, которое используется для eBay поста.
Post Template: Шаблон сообщения: Доступные теги(макросы): {auctions}торги от eBay

Yahoo Answers Options
Add “Powered by Yahoo! Answers” text to footer? Добавить “Работает на Yahoo! Ответы” текст в footer: Yahoo требует, чтобы веб-сайты, которые используют их содержание добавляли текст “Работает на Yahoo! Ответы”, на странице. Эта опция дает вам возможность сделать это автоматически.
Language: Устанавливаем язык публикации.
Post Template: Шаблон сообщения: Доступные теги(макросы): {question} вопрос из Yahoo Answers.

Youtube Options.
Language: Устанавливаем язык поста.
Video Size: Размер видео.
Post Template: Шаблон сообщения: Доступные теги(макросы): (Video) видео Youtube, {description} описание данного ролика.
Post Comments? Комментарии к данному посту.

Flickr Options.
Flickr API Key: Ваш API ключ в сервисе Flickr.
License: Перечислите все имеющиеся варианты лицензии(1..6).
Image Size: Размер изображения, которые будут добавлены в посты.
Image Width: Ширина изображения.

Content Type: Тип содержимого: Эта опция может ограничить поиск только фотографий и скриншотов.
Sort by: Сортировать по: Какие результаты Flickr будут отсортированы.
Post Template: Шаблон сообщения: Доступные теги(макросы): {image} Заменить реальное изображение, {date}Отобразить оригинальную дату изображения, {owner}правообладатель, {keyword}кеу поста.

{keyword} (the keyword the post was created for) () ключевых слов (ключевые слова пост был создан для)
Translation Options:
Translate posts from English: Здесь вы можете установить нужный язык постов, которые будут переведены на…. Вы можете перевести этот же текст несколько раз, чтобы переписать его, например, путем перевода с английского на немецкий на английский язык.
Translation Service to use: Какой сервис перевода применить: WP Robot может использовать Переводчик Google или Yahoo Babelfish, или оба (на выборочной основе) для перевода текстов.
Translate… ? Что будем переводить? Вы можете выбрать, какие тексты и модули переводить, а какие нет. (ставим чеки). Yahoo Babelfish является менее надежным, чем Google Translate. Поэтому Google Translate выбран по умолчанию. Также по умолчанию некоторые из чеков (например, для тайтлов и Youtube комментариев) отключены, и рекомендуется не активировать все, потому что слишком много запросов переводчику Google приводит к временному бану Вашего IP адреса! Вот выбор:
Articles
Article Author Boxes
Clickbank Ads Yes
Amazon Descriptions
Amazon Reviews
Yahoo Answers Questions
Yahoo Answers Answers
Youtube Descriptions
Youtube Comments
Post Titles
Запоминаем установки: Safe Options

WP Robot – WP Robot, попадаем на страницу WP Robot – Active Keywords:
Вверху слева заполним форму “Добавить новое ключевое слово” по тематике будущего поста, выбираем категорию, и периодику создания сообщений в днях или часах. Посередине ставим или снимаем чеки, определяя таким образом количество работающих модулей, справа добавляем некоторые специфические параметры включенных модулей.

После того как Вы нажмете Add Keyword, введеные настройки будут показаны в верхней части страницы:

Здесь приведены данные о ключевых словах и созданных сообщениях, то есть мы получаем параметры для удаления или редактирования ключевых слов. После нажатия кнопки Post Now, Вы также можете создавать дополнительные посты для любого отмеченного ключевого слова вне обычного графика.
Вскоре после добавления нового ключевого слова, автоматически будет создан первый пост. Количество постов не соответствует указанному, так как, например, включает дублированные посты, то есть их количество будет больше.
WP Robot – Propabilities:
Здесь мы можем установить в процентном соотношении, вероятность выбора определенного модуля для создания поста. По умолчанию Clickbank ads, eBay auctions и Youtube videos применяются немного реже, чем другие модули. Учтите, что общая сумма всех вероятностей должна быть 100%. Если вы решили не использовать определенные модули, устанавливаем их в нуль для данного ключевого слова..

WP Robot – Bulk Add Keywords:
Проставив чек в первом варианте, мы можем случайным образом выбрать интервал между созданием постов, или, отметив второй, указать интервал в списке ключевых слов. При заполнении списка Вы должны указать ключевые слова и категории, разделенные “;” и можно установить произвольные промежутки времени между созданием постов, или задать собственные(Keyword;Category;Post Every;hours/days – например: Games;News;7;hours). Если чек проставлен по первому варианту, число;часы / дни можно не указывать, так как они уже указаны. После процедуры добавления на странице WP Robot – WP Robot в секции Active Keywords появится новая строчка или не одна, смотря сколько ключевиков Вы ввели. Там же, нажав Edit можно подкорректировать установки.

MIX Feature: Эта функция EBay и Flickr модулей, которая позволяет использовать их содержание в любом другом модуле WP Robot. Пост будет выглядеть более естественным, и, наверное, в плане уникализации у него появляются больше шансов у поисковиков.
MIX Template Tags: Доступные MIX теги(макросы): {auction}) – используем этот тег в шаблоне любого модуля, чтобы вставить содержание из аукциона eBay.
{image} – используем этот тег в шаблоне варианта любого модуля, чтобы вставить изображения из Flickr внутрь каждого сообщения этого модуля.
Ну что Вам сказать, взял я последнюю на то время версию WP Robot 1.21, зарядил, испытал. Пришлось зарегиться на нескольких ресурсах: affiliate-program.amazon.com, www.flickr.com, ebay.com, www.clickbank.com. Правда amazon, ebay и clickbank в аффилиаты не пустили, но кое какие кеи выдали. Не успел я обрадоваться, что плагин работает, как получил горькую пилюлю, он, видимо наябедничал производителю, тот принял меры, и вместо того, чтобы увидеть на первой странице плагина в результатах нечто типа “Category: News Next Post: 14th of November 2009 16:35:57″, я увидел примерно такое “Category: News Next Post: 14th of November 1970″. Шара закончилась, версия оказалась “неправильная”, надо было что то делать. Не покупать же ради эксперимента плагин, даже со скидкой за 140$. Порылся в интернете, нашел правильную версию wprobot_1.15. Она оказалась недоделанной. Видимо перестарались и убрали все связи с сервером автора, не работал счетчик “Posts created: 6…”, да и вообще плагин через раз запускался. Пришлось ради дела напрячь остатки соображаловки, посетить некоторые вражеские форумы, залезть в base64, и на время испытаний обнулить v.1.21, да простят меня жадные авторы плагина, которые хотят денег(шутка). Плагин заработал как часики, не уверен в уникальности контента, но тянет исправно. Так что можно ставить и работать.
46. WP Autoblog
Следующий плагин автоматически парсящий различные RSS-каналы, WP Autoblog, до кучи проверим, что это за зверь(автор Elliott Back – сайт _www.elliottback.com). По описанию wp-autoblog – очень наглый плагин, кроме того, что он забирает контент с RSS лент, он еще и пингует, ставит на себя ссылку с этого ресурса. В связи с его хамским поведением было много жалоб, автор плагина перепугался, везде плачется про гнусных спамеров, которые занимаются злоупотреблениями, убрал его из публичного доступа, но если поискать, то можно найти. Автор пишет, что в любом случае, даже при спаме, Вы хотите знать, что ваша интеллектуальная собственность нарушается, и если кто кто-то скопировал содержание, пинг является системой оповещения, т.е. в этом случае Pingback безвреден.
Загружаем папку с файлами плагина в соответствующую директорию, активируем и получаем дополнительную кнопку WP Autoblog в левой инструментальной панели.
WP Autoblog – WP Autoblog Settings: Жмем и получаем окошко с двумя полями и минимумом настроек.

В левом поле – Базовые настройки составляем список RSS или ATOM-каналов, по одному в каждой строке.Это и будут источники контента. В правом – расширенные растройки, здесь можно менять автоматом кое какое содержание в синдицируемых постах. Для этого надо ввести старые и новые значения в паре, не забывая о регистре на всякий случай. Под окошками настройки, касающиеся отношению к интеллектуальной собственности. Тут мы выбираем полностью показывать новость или выдержку и присваивать ли оригинальное авторство. Плагин выделяется из себе подобных, тем, что использует, так называемый, “Snoopy.class”. Для чего это нужно? Дело в том, что не все ресурсы охотно отдают контент, они определяют, кто обращается к ленте – браузер серфера, читалка фида или парсер. Определив последний вариант они контент не отдают. Наш плагин с помощью этой фичи маскирует серверный парсер под браузер и, соответственно, получает контент с тех rss лент, которые закрыты для остальных.
Далее вроде все ясно, вводим адреса фидов по одному в строчку, Safe Setting – Run Skript Now и Run Script Now. Исправно залился контент, плагинработает но есть нюансы. Зарядил я ленту одного блога на wordpress.com, откуда FeedWordPress не смог стянуть контент. Wp-autoblog сработал, но все метки постов трансформировались в новые одноименные категории. Зато самих меток в постах нет, ясно, что это никуда не годится. И хуже всего, что и контента не было в постах.

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

Продолжение следует.
Автор Stepan Demin. Использование и копирование статьи РАЗРЕШАЕТСЯ с указанием автора и ссылки на первоисточник BlogInforama

Если Вы внимательно прочитали статью с первой по седьмую части то, наверное, заметили, что автор явно увлекся описанием плагинов и начинающий блогомастер просто может потеряться во всем их многообразии. Конечно не помешает знать как работают плагины, которые помогают нам обеспечить стабильную работу движка и заработать в интернете. Это плагины навигации, антиспам плагины, SEO плагины по добыче контента – FeedWordPress, Caffeinated Content, Autoblogged. Но изначально мысль то была такая: настроить движок WordPress на Localhost, т.е. на сервере домашнего компьютера, и эту сборку клонировать. А мы установили в процессе изучения материала столько плагинов, что ни один хост из дешевых(как правило для сателлитов покупается дешевые хосты) не выдержит, да и зачем их столько. Если просто деактивировать лишние плагины, в таблице wp-options базы данных останется немало мусора. А если при испытании плагинов, блог наполнялся контентом, то и в таблицах wp-post и wp-comment, тоже останутся лишние записи. Это могут быть Rss ленты, статьи, которые мы напарсили из Yahoo или Google например. А мы ведь готовим на локалхосте, практически, шаблон для быстрого развертывания множества блогов-сплогов, и нам нужна чистая сборка, чтобы мы могли загрузить готовый блог к хостеру в котором активирован необходимый минимум плагинов. Выхода два: очистить базу данных от информации о настройках плагинов, содержимого Rss лент, и прочей наработанной в процессе наладки информации т.е. обнулить соответствующие таблицы в существующей базе данных. Этот путь хорош тем, что нам не придется по новой устанавливать движок, и настраивать его. Но для начинающих это решение не совсем прозрачно, можно запутаться и не совсем понять что и зачем мы делаем. Поэтому в данном случае более приемлем второй вариант. Вариант более трудоемкий но более понятен. Мы просто установим WordPress вчистую.
1. Заходим http://localhost/Tools/phpmyadmin/index.php, выбираем нашу базу данных, отмечаем, слева снизу все таблицы(Отметить все), и в выпадающем списке внизу справа жмем уничтожить. Таким образом, мы вернулись к началу. Что мы имеем?
Файлы движка в папке на локальном сервере.
Пустую базу данных(без таблиц).
Настроенный файл wp-config.php, с прописанными данными. Если помните, в первой части мы прописали название базы данных, пароль, фразу для Secret Key.
Файл Robots.txt, где прописаны команды поисковым роботам. Если в нижней части файла прописаны прямые пути к Host: и карте Sitemap:, не забудьте их подкорректировать в зависимости от названия будущего хоста.
Файлы карты сайта sitemap.xml и sitemap.xml.gz. Обратите внимание что если Вы ранее активировали плагин Google (XML) Sitemaps Generator и вручную, с его помощью создавали эти карты, то они содержат записи, которые нам не нужны в будущей установке. Откройте в нашем редакторе файл sitemap.xml, очистите его от записей, затем в “Total Commander” в одном окошке откройте архив с файлом sitemap.xml.gz, в другом подчищенный sitemap.xml и скопируйте последний с заменой в открытый архив. Таким образом в архиве тоже будет чистый файлик sitemap.xml. Это я обьясняю тем, кто не знает как по простому заменить содержимое в архиве. Как работать в Тотал командере описано ниже в этой части статьи.
Файл .htaccess, в которм Вы тоже должны проверить правильность прописанных путей к папке с сайтом.
Вот эти пять файлов плюс, на всякий случай, install.php у Вас должны храниться отдельно и применяться по назначению.
Повторяться по поводу установки не буду, перейдите к первой части и воспользуйтесь одним из способов установки. Не забудьте, если Вы удалили по моему совету в целях безопасности файл install.php из папки wp-admin загрузите его. После установки движка на локалхосте, поочередно активируем и настраиваем все основные плагины, затем создаем эталонный дамп базы данных.
2. Установите базовую подборку плагинов, примерно по такому списку:404-notifier, akismet, google-sitemap-generator, revision-control, statpress-reloaded, wordpress-23-related-posts-plugin, wp-noexternallinks, wp-page-numbers, wpseo, FeedBurner_FeedSmith_Plugin, rus-to-lat, the-excerpt-reloaded, total_disable_updates. Это минимум плагинов, которые нам понадобятся. Здесь нет плагинов, необходимых для наполнения блога контентом.
Итак, мы подготовили эту сборку WordPress для использования ее в качестве клона. Уберем из служебных папок лишние плагины, шаблоны тем, установим дефолтную тему, проверим присутствие файлов Robots.txt, .htaccess, sitemap.xml и sitemap.xml.gz.
В процессе установки WordPress, база данных заполнилась служебной информацией, это настройки плагинов и настройки собственно движка. Теперь нам нужно их сохранить, чтобы в будущем использовать. Как получить дамп базы эталонного образца, то есть ее слепок, в виде файла sql, для того, чтобы дальше с ним работать описано чуть ниже.
Не забудьте, когда научитесь работать с базой данных, в данном случае я имею в виду получение дампа базы и обратное действие – восстановление базы из одного из них, сразу же сделать первый дамп базы только что настроенного нами движка. Он пригодится нам в дальнейшем, и не раз.
Sypex Dumper Lite. Как сделать дамп базы данных?
Чтобы сделать дамп базы данных для переноса ее на сервер в интернете или для других действий, применим замечательный скрипт Sypex Dumper Lite. Дело в том, что путей, для получения резервной копии базы данных множество, в том числе и рассмотренный нами в третьей части плагин db-backup. Я же привык к Sypex Dumper Lite – надежный, удобный, безотказный. Версию возьмем 1.03, уже вышла 2-я версия скрипта, шикарная, судя по описанию, я ее испытал, но она у меня почему то не пошла. Создаем папку с файлом dumper.php, называем ее, например, dumper_wp_2.7.1, помещаем в корень локального сервера, туда же где находится наш WordPress. Можно просто загрузить файлик dumper.php в корень сервера или в папку блога и вызвать его в браузере. При инициализации скрипта автоматически создается папка backup с файлами. Эту установку Sypex Dumper Lite мы можем применять для бэкапа всех баз данных на локалхосте, только при входе надо будет менять название и пароль для каждой базы. Вызываем командой в браузере http://localhost/dumper_wp_2.7.1/dumper.php, получим окошко, куда вводим название и пароль базы данных. Если Вы загрузили наш файлик в корень сервера, без папки, набираем в браузере адрес http://localhost/dumper.php, так, наверное, будет даже удобнее.

Вводим логин и пароль для входа в базу данных. Значения берем из файла wp-config.php нашего блога, это название базы данных и пароль входа в базу. Далее работаем в верхней части окошка, жмем Применить – Backup – Создание резервной копии БД, в выпадающем окошке выбираем нашу базу, без сжатия или выбираем метод и степень сжатия по желанию – далее Применить.

После окончания работы скрипта станут активны кнопки Скачать файл и Вернуться.

Итак, при первой загрузке в папке dumper_wp_2.7.1, или в корне сайта, то есть там куда будет залит файлик dumper.php, автоматически создалась папка backup, в которую сгенерились несколько файлов и среди них файл с дампом нашей базы – wp_2.7.1_data.sql. Название файла сформировалось из названия базы данных, а также даты и времени создания дампа. С помощью этих дампов мы будем клонировать наши базы на будущие установки сплогов, или работать с ними на Localhost. Повторсь, первый backup базы сделаем сразу же после настройки необходимого пакета плагинов. Этот дамп базы нам пригодится, в том случае, если сплог будет наполняться контентом не на локалхосте, а в интернете, да и не только в этом случае. Допустим для разных экспериментов с движком на денвере пригодится, ведь если надо откатиться к этой опорной точке, делов то на пару минут.
Восстановление базы данных из дампа.
Для этого в окошке скрипта жмем Вернуться.

В нижней части – Restore в выпадающем списке выбираем нужный дамп базы данных – Применить. База, куда мы заливаем дамп, должна быть пустой, поэтому не забудьте перед заливкой уничтожить полностью или очистить таблицы базы данных. Помните, выше было сказано: Заходим http://localhost/Tools/phpmyadmin/index.php, выбираем нашу базу данных, отмечаем все таблицы – с отмеченными – очистить/уничтожить.
Бывает, правда, даже проверенный скрипт первой версии на некоторых серверах не работает, это, например, в том случае, если сервер не разрешает просматривать список баз данных и при вызове скрипта мы получаем ошибку сервера. Решается так: открываем файл dumper.php, и в 37-й строке перечисляем названия баз через запятую. Я с этим сталкивался не раз, так что запомните это и возьмите на вооружение. Если скрипт и после этого отказывается работать, а это часто бывает на бесплатных хостингах, тогда придется изощряться по другому. У нас на Localhost скрипт точно будет работать.Не забудьте сделать первый бэкап базы данных движка, что мы только что настроили.
3. Подготовка файла базы данных для работы на хосте.
Адаптирование базы данных перед заливкой на хост.
Перед тем как залить базу данных к хостеру, надо кое что изменить в ней, адаптировать под хост, где будет установлен блог – сплог – сателлит. Открываем файл дампа базы данных в правильном редакторе, где можно сделать замену слов, у меня это Notepad++. Мой дамп базы назывался wp_2.7.1_data.sql, у Вас часть названия до расширения будет другим. Любители Dreamwiewer могут все последующие действия прозводить в своем любимом редакторе. Первое, и основное что мы сделаем, это поработаем с абсолютными и относительными путями к файлам сайта которые прописанны в нашей базе. В статическом сайте эти пути прописаны прямо на страницах, которые существует физически, в нашем же случае WordPress является динамическим сайтом, где формирование страниц происходит “на лету”, и данные берутся их базы данных.
Поговорим немного о файлах, и путях к ним.
Наш сайт существует в как бы в реальном и виртуальном измерениях. Для серфера, который набирает адрес сайта http://moi.site.ru/index.html – это виртуальный веб-сервер, где нет файлов физически. Мы же работаем над сайтом на локалхосте, на реальном компьютере, с жестким диском, каталогами и файлами. Скрипты тоже работают с реальными файлами, на физическом диске, скрипты должны исполняться, и пути к ним самим и другим файлам должны прописываться. Пути к файлам бывают абсолютные и относительные, и между ними, естественно есть различия. При создании относительных путей, в начале пути корень не указывается, он прописывается от текущего положения, то есть конкретного нахождения файла. Дойти по такому пути можно только из исходной папки, в которой лежит файл. Из другой папки мы попадем уже в совсем другое место, т.е. если файл находится на одном и том же сервере, но в другом каталоге, необходимо прописать путь к файлу от каталога, где находится документ, из которого к нему обращаются. Любой нормальный поисковик должен хорошо обрабатывать относительные пути. Простой пример относительного пути – это просто имя файла(file.php), если файл находится в том же каталоге, с которым работает программа, в нашем случае это корень сайта. А вот браузер уже достраивает его до абсолютного. Если файл, например лежит в папке “papka”, которая находится в корне, мы пишем papka/file.php
Абсолютный путь(absolute path) – путь к файлу, который указывается от корневого каталога сайта, и который всегда остается неизменным, независимо от того где, на какой странице и на каком месте мы его пропишем. Эту ссылку можно переместить на любой уровень сайта, не изменяя формата пути. Абсолютный путь напоминает почтовый адрес – откуда не идешь, в одно и то же, указанное в адресе место попадешь. Для перехода по ссылке, содержащей абсолютный путь, необходимо находиться в режиме онлайн, он не работает в автономном режиме – это вроде бы недостаток абсолютного пути, но в нашем случае это то, что надо.
Корень веб-сервера, как его видит браузер, и корень файловой системы на диске у хостера, или у нас на компьютере, это разные вещи, но по сути это директория где расположены файлы сайта. Абсолютный путь на диске к файлу какого то скрипта допустим /home/hosts/public_html/papka/index.html, виртуальный адрес в браузере серфера http://moi.site.ru/papka/index.html, где http://moi.site.ru/ или /home/hosts/public_html и есть начало сайта – корень сайта. Для того, чтобы ссылка в браузере гарантированно работала, независимо от того, из какого места сайта она вызывается, она должна быть абсолютной, состоящей из первой части, т.е. пути до корня сайта плюс путь до файла на диске(papka/index.html), для браузера это самый полный путь. Для скрипта же, исполняющегося на сервере это будет путь к корневой папке(например: /home/hosts/public_html), плюс вторая часть papka/index.html
В Юниксе и на веб сайтах корень сайта обозначается косой чертой – (/). Например в http://moi.site.ru/ последняя косая черта обозначает конкретный адрес – начало сайта. В Unix в качестве разделителя каталогов используется левая косая черта (/). Если вы используете обратную косую черту, то она должна быть “отменена” (\\). В Windows можно применять как левую, так и обратную косую черту, файловая система разбивается по дискам, и в абсолютном пути к файлам надо указывать имя диска. Получается абсолютного корня всей файловой системы в Windows нет, у каждого диска – свой корень – C:\ E:\ и.т.д.
На используемом нами сервере на базе UNIX(у хостера) путь будет примерно такого вида – /home/hosts/public_html, а так как мы работаем на Denver, который представляет из себя Windows сервер, путь к файлам, скриптам, плагинам и.т.п. будет иметь примерно такой вид: Z:\\home\\localhost\\www\\vashapapka.
Из вышесказанного становится понятным, что после того, как мы построим сайт, и загрузим его на хост, абсолютный путь будет отличаться от прописанного на локалхосте, и мы должны в нашей базе данных его подкорректировать.
Замена путей.
В верхней инструментальной панели жмем Поиск/Поиск и вводим в поле поиска Z:\\home\\localhost\\www\\vashapapka, это стандартный путь к корню сайта на локалхосте. Если Вы выбрали при установке денвера другую букву диска, вместо Z:, путь будет drugaiabukva:\\home\\localhost\\www\\vashapapka. Мы увидим в поле документа закрашенную или закрашенные строчки. Если вдруг нет, ищем что то подобное. Далее переключаемся на Поиск/Замена, у нас в верхнем окошке данные поиска, которые нам надо поменять, в нижнее вводим на замену домашний путь(Host path), который получим у хостера после регистрации.
Жмем Заменить все:

и получаем результат с исправленными адресами, количество их зависит от заполненности базы контентом, вот в моем конкретном случае 599 замен. Может быть больше или меньше.

Далее, вполне логично предположить что раз на локалхосте, для того, чтобы зайти в WordPress мы в браузере набирали адрес типа http://localhost/vashapapka, и он очевидно прописан в нашей базе как siteurl, надо бы заменить слово localhost/vashapapka на адрес будущего блога без http://, для этого жмем поиск/замена, вводим в верхнее окошко localhost/vashapapka, нижнее moi.site.com – заменить все.
Не называйте папку словом, которое может присутствовать в базе, например WordPress, Upload, wp-admin и.т.д. После этого файл базы можно уже заливать на хост.
Если же Вы выбрали наименование папки по url будущего сайта, и на локалхосте применили плагины автонаполнения контентом и награбили контента с картинками, замены будут другими, если нет, этот абзац пропустите.
Так как название папки менять не надо, просто поменяем слово “localhost/” на пробел и siteurl из _http://localhost/moi.site.com преобразуется в _http://moi.site.com.
В дампе базы полученной на локалхосте пути к картинкам будут примерно такого вида:
<a href=\”/moi.site.comhttp://bloginf.com/wp-content/uploads/cc/image.jpg\”><img src=\”/moi.site.comhttp://bloginf.com/wp-content/uploads/cc/image.jpg\” title=\’image\’ alt=\’image\’ />
Отличие может быть только в moi.site.com. Если мы не изменим их, при построении адреса на сайте, в браузере пропишется еще раз moi.site.com/ и путь к картинке будет вида http://moi.site.com/moi.site.comhttp://bloginf.com/wp-content/uploads/image.jpg и, естественно, ни одной картинки мы не увидим.
Вводим в блокноте в верхнем поле Поиск/замена что то типа \”/moi.site.com/wp-content/, или находим в базе такого вида строчку и выделяем ее, и затем меняем на вот это – \”/wp-content/, то есть убираем из базы moi.site.com/
Почему мы убираем именно в этих путях moi.site.com/, дело в том, что нельзя просто убрать moi.site.com/, так как он прописан в разных других местах – siteurl, home, настройках плагинов и пр.
Далее не забудьте сохраниться: Файл – Сохранить. Кроме того нам будет интересно покопаться в базе, посмотреть ее содержимое, что то убрать, чего то заменить. Если Вы активировали плагин ошибок 404, возможно есть логи. Посмотрите INSERT INTO `wp_ak_404_log` VALUES, и если есть информация – сотрите. Это не обязательно, но лишняя практика не помешает. Очень много ссылок на wordpress.org. В базе данных WordPress, установленного мной в процессе написания статьи их более 300. А левых ссылок, неизвестных мне ресурсов и того боле. Короче, хотите почистить базу, и тем самым дать движку дышать свободнее, метОда есть, действуйте. Моральный аспект и возможные траблы на вашей совести и на вашу ответственность.
Очень возможно, особенно на фришниках, после загрузки на хост в созданном блоге будет видна только главная страница но не будет работать навигация. Никакие ухищрения, изменение прав на перезапись, изменение файла .htaccess, mod_rewrite и пр., в данном случае у меня не помогли. Решение такое: на странице Permalink(Постоянные ссылки) перейдем с ЧПУ на дефолтную систему построения веб-адресов. Вывод такой, если мы знаем что будем пользоваться бесплатными хостингами, наверное стоит пренебречь рекомендациями в первой части статьи и оставить общие настройки на странице “Постоянные ссылки” по дефолту.
Маленькое отступление.
Ну все, база подчищена и готова к работе на новом блоге. Диспозиция такова. В настоящее время наш блог физически находится на жестком диске нашего компьютера, виртуально на локальном виндовском сервере – сборка Denver. Блог на движке WordPress – по сути своей динамический сайт. Вкратце, он отличается от статического тем, что страница, которая загружается в браузер серфера не присутствует в готовом виде на жестком диске серверного компьютера, а формируется на лету по запросу того же клиентского браузера. Текстовые данные для загружаемой страницы(контент, служебные записи, настройки) хранятся в базе данных MySql, графика в папке на сервере, или на стороннем сервисе, но пути к графике прописаны там же в Б.Д. Если контент еще не загружен, в базе данных будет минимум служебной информации(плюс стандартный довесок, реклама и пр. – дань бесплатности движка), файлы графики только в служебных папках движка и тем. Так как движок постоянно делает запросы к базе данных, он обращается, естественно по определенным адресам. Значит если мы загрузим файлы WordPress вместе с графикой на жесткий диск выделенного или виртуального сервера, загрузим базу MySqL, поменяем в ней УРЛы на нужные, чтобы все запросы выполнялись правильно, цель будет достигнута. Блог будет работать. Мы не вникаем в то, как и за счет чего это работает на хосте, там тот же Apache, Zend Optimizer, дополнительные расширения – mbstring, curl, как у нас на Denver. Главное мы должны соблюсти целостность структуры файлов и связей нашего движка.
Регистрация у хостера.
Для того чтобы понять как установить WordPress на хост, а в нашем случае это сводится к заливке файлов и базы данных к хостеру, нам надо иметь этот хост. Большинство блогомастеров начинают с бесплатного хостинга. Давайте изучим процедуру регистрации у хостера на примере freehostia.com.
Заходим на главную страницу выбираем и кликаем на левое крайнее окошко.

Переходим на страницу, где указаны технические характеристики будущего хоста.

Жмем Take in now в самом низу страницы.

И получаем форму для заполнения. Жмем Use a subdomain, 12 months period, заполняем остальные поля, почту лучше Gmail. Если все правильно заполнили, получаем окошко и ждем подтверждение по почте, на адрес что мы указали.

Через некоторое время на указанное мыло придет тикет, в котором прописаны все данные по хосту – ваш id, логин, пароль, DNS, информацию по FTP и базе данных и.т.д. Все это нам пригодится ниже.

Администрирование.
На компьтере у нас был установлен сервер на базе Windows в сборке Denver. С его помощью мы управляли файлами и базами данных. На хосте же сервер на Юниксе, и для тех, кто не работает в нем, да у нас и доступа по шеллу нет как правило, хостеры устанавливают т.н. “Панели управления”. Набираем https://cp.freehostia.com/members/login.php, вводим полученный логин и пароль и попадаем в контрольную панель.

Здесь в первую очередь нас интересует Файл-менеджер. Жмем кнопку Файл-менеджер и попадаем на страницу с таким же названием:

А вот и папка, куда будут загружены файлы будущего блога.

Файлы WordPress в эту папку можно загрузить через отдельный FTP-Менеджер, или в этой же панели на странице Файл-менеджер. После загрузки файлов, можно кликнуть на название папки, и посмотреть ее содержимое.

Кроме того здесь можно поменять права доступа к файлам, если это необходимо. Очень полезная возможность загрузки файлов движка запакованных в ZIP, и самое главное, распаковка их тут же в панели. Здесь нам кажется не повезло, такой возможности не предусматривается. Для этого ниже рассмотрим регистрацию у другого хостера, и работу с файлами запакованными в ZIP.
В контрольной панели еще много разных кнопок, обратим внимание на кнопку Управление базами данных SQL. Кликаем по ней и попадаем на страницу:

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

Для менеджирования уже существующей базы набираем https://cp.freehostia.com/pma/ или жмем на название базы на странице Управление базами данных SQL.
Для входа в систему вводим логин и пароль.

Внешний вид phpMyAdmin такой же как на локалхосте и принцип работы тот же, но единственно, на бесплатном хосте при работе с базой данных неизбежны тормоза.
Регистрация у другого хостера.
Регистрация у различных хостеров по сути своей ничем не отличается. Но для того, чтобы Вы могли сравнить и уловить, нет не различия, а именно что то общее, понять основные принципы, давайте не поленимся и рассмотрим еще один пример регистрации у какого то обезличенного хостера. Конечно удобно пользоваться тупой инструкцией “нажми зту и эту кнопку, не понимая их смысла и все получится”, но надо стараться, может быть не с первого раза, понять суть и дальше действовать осмысленно. Кроме того нам нужен хост, где в панели управления можно работать с зазипованными файлами.
Набираем нужный адрес и попадаем на страницу регистрации

Вбиваем в окошко нужное слово, выбираем субдомен жмем Proceed и переходим на страницу регистрации. Заполняем поля формы.

Жмем Continie, переходим на следующую страницу, здесь можно посмотреть данные аккаунта. На майл придет страница с подтверждением аккаунта.

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

Панель управления по интерфейсу отличается от ранее рассмотренной, но суть та же. Здесь мы так же сможем управлять файлами и базами данных. Отсюда мы можем войти в файл менеджер, удалить созданную для нас базу данных, войти, нажав кнопку Manage DB в PHP Admin, для менеджирования баз данных, изменить конфигурацию PHP и.пр.
Чтобы зайти в Файл-менеджер, жмем соответствующую кнопку и в полученном окошке вводим данные FTP(берем там же на последней странице регистрации).

Здесь мы видим папки и файлы, которые изначально находятся в Root директории. Ниже рассмотрим, как залить сюда файлы движка запакованные в ZIP, и распаковать их тут же.

В панели управления нас, так же как у первого хостера, интересует возможность работы с базами данных.
Переходим в Панель управления, жмем на Manage DB и попадаем на страницу, где видим кнопку и ссылку для входа в PHP Admin. Тут же нам подсказывают наш логин, и напоминают, что пароль такой же как у аккаунта. Жмем батон:

и через логин, пароль

попадаем в PHP Admin, где мы будем управлять базами данных.
Итак мы посмотрели как входить на страницы, где можно работать с файлами и базой данных, а как с ними работать чуть ниже.
Еще пример создания баз данных MySQL и немного о привилегиях.
Рассмотрим пример создания базы данных на примере третьего хостинга и заострим внимание на привилегиях. Почему пример у третьего хостера. Первое, у предыдущих хостеров привилегии прописались автоматически, а бывают варианты, когда это надо сделать вручную. Если Вы это не сделаете, в базу данных при установке какого либо скрипта не попасть никак. Кроме того, необходимо, чтобы Вы уловили общие моменты и не терялись в случае, если у одного хостера будет установлена Си панель, а у другого Директ Админ и различие лишь в интерфейсе админок, явится неким препятствием в работе.
Для создания базы данных, заходим в панель управления нашим хостом(помните где данные для входа). Жмем “Базы данных MySQL”

Попадаем вот на такую страницу:

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

После подтверждения создания базы, надо добавить пользователя и пароль

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

Кодировка таблиц в базах данных MySQL.
И еще один, не менее важный момент, это кодировка таблиц. Если в таблицах базы данных неверно указана кодировка MySQL, мы рискуем получить при просмотре вопросики или крокозябры. В последних версиях MySQL при установке по умолчанию указывает кодировку для БД latin1, нам же нужна utf8_general_ci. Неправильная кодировка в MySQL – это большая проблема. Необходимо, пока база данных еще пустая, правильно прописать кодировку и Вы забудете о ней думать.
Сразу после оформления аккаунта, зайдите в PhpMyAdmin, и если там увидите что то подобное:

или вот это:

то нам обязательно надо изменить кодировку на UTF-8. Для этого вверху жмем Операции и попадаем в окошко, где в нижней части примерно такое:

Делаем сравнение, в выпадающем окошке находим utf8_general_ci и жмем OK.

Все, ваша база в правильной кодировке:

Бывает, в базе данных, которую мы создали для WordPress, видно что некоторые таблицы установленных плагинов в кодировке cp1251_general_ci, это нормально.
Заливка файлов на хост.
Перед нами следующая задача. Как мы уже поняли для правильной работы блога, крайне необходимо наличие файлов движка на хосте и таблиц в базе данных. Начнем с файлов:
Файлы можно залить по FTP или через панель управления сервером. Для заливки файлов по FTP обычно используются FTP менеджеры. Так как в повседневной работе я пользую Total Commander, мне удобно использовать его встроенный менеджер FTP. Время показало, что в нашем случае его возможностей вполне хватает. Я думаю, нет смысла тратить время на изучение отдельной программы для работы с FTP, а Total Commander пригодится во многих случаях. Открываем программу, видим две большие файловые панели. В правой панели(какой из них не имеет значения) находим каталог с файлами будущего блога.
Прежде чем заливать файлы, мы должны настроить наше FTP соединение. Здесь, как и в любой программе есть верхняя инструментальная панель. Жмем Сеть/Подключение по FTP. Появится окошко “Соединиться с FTP сервером”.

Далее, справа жмем Добавить. Появится новое окно “Настройка FTP соединения”

с полями, которые надо заполнить. Имя соединения произвольное, а данные сервера, учетной записи и пароль пришли Вам по электронной почте от хостера, или Вы подсмотрели их на последней странице при регистрации. Ниже ставим чеки на:
Пассивный режим обмена и:
Посылать команду для поддержания… Больше ничего можно не настраивать.
Как же залить файлы?
Наводим курсор(отмечаем) на левую панель менеджера, на верхней инструментальной панели жмем FTP – “Соединиться с FTP сервером” – получаем окошко “Соединение с FTP сервером”. Отмечаем название нужного соединения, справа жмем кнопку Соединиться.
Теперь в левой панели “Коммандера” мы увидим структуру папок удаленного сервера, на который мы зашли по протоколу FTP, в правой панели находятся файлы блога с которым мы работали, их мы будем заливать на хост.

Возникает вопрос, а куда заливать файлы. Теоретически нам нужна корневая папка, которая как правило называется Publik.html. Если не нашли эту папку, можете дважды кликнуть на WWW и попадете в корень сайта, то есть именно в эту папку, WWW играет роль ярлыка. Но это все в, так сказать, классическом варианте, вот как на рисунке выше. А в жизни у разных хостеров, особенно у бесплатных бывает по разному. В рассмотренных нами вариантах файлы в первом варианте надо грузить в директорию, рядом с уже существующими, а во втором в папку названую в честь Вашего аккаунта. И не в коем случае не рядом. Далее из открытой в правой панели папки wp_2.7.1, простым копированием заливаем файлы WordPress в корень сайта. Как Вы уже поняли это, по простому, жесткий диск удаленного компьютера который мордой смотрит в интернет.
Следующий абзац читать не обязательно:
“Если Вы используете несколько сборок “Тотал Коммандер”, для того чтобы каждый раз не настраивать соединения, зайдите в корневую папку менеджера, найдите файлик wcx_ftp.ini. Там все настройки. Настраивайте в одной сборке все новые соединения FTP, а потом заменой поместите во все Ваши сборки “Total Commander”. Это относится, конечно, больше к Portable сборкам Коммандера, их удобно применять, если мы работаем на разных компьютерах”.
Заливка заархивированных файлов сборки.
Вообще заливать файлы вышеописанным способом весьма нудное занятие. Один большой или десяток мелких еще куда ни шло, а WordPress с его сотнями файлов, и если еще картинок сотни – ждать будете часами. Есть альтернатива – заархивировать файлы сборки в Zip, через Total Commander или Файл-менеджер на хосте быстренько залить одним файлом, и там же, в Файл-менеджере секунда дело, разархивировать. Правда на некоторых фришных хостингах в панели управления невозможна работа с архивами. У первого нашего хостера так и получилось, ну а мы на примере второго хостера, у которого мы зарегистрировались научимся это делать.
Открываем в Тотал Коммандере папку с файлами WordPress, отмечаем их и жмем на верхней инструментальной панели Упаковать файлы. Упаковывать надо в ZIP. Во втором окошке появится архив с названием папки, в которой был WordPress. Ходить далеко не будем, и тут же Тотал Коммандером скопируем этот архив в корень будущего сайта.
Заходим, используя данные Ваш ник и пароль в Account Manager, далее Файл менеджер, видим окошко(это все мы проходили):

Тут, кроме изначально присутствующих файлов появился наш архив. Отмечаем архив с файлами WordPress и чуть выше жмем Unszip – видим окошко:

Жмем зеленую галочку, видим процесс:

Возвращаемся по синей стрелке, в Файл менеджер, приятно посмотреть – результат налицо, все файлы WordPress распакованы. Сам архив надо удалить. Вот они распакованные файлы в Root директории:

Итак мы залили файлы Wordpress из папки wp_2.7.1 в корневую папку нашего будущего сайта. Перед тем как работать, надо выставить права на все папки и файлы Wordpress.Пропишем атрибуты на папки и файлы .htaccess, robots.txt, uploads.
Что такое атрибуты файлов или CHMOD777?
Если сервер на базе Windows, как, например, Denver права прописывать не надо. В Unix существует существует система разграничения доступа пользователей к директориям (каталогам, папкам) и файлам. В двух словах файлы, папки могут иметь целый набор правил по их изменению. Пользователи по отношению к директории или файлу могут быть: владелец, группа, остальные. Сюда входит разрешение на чтение, запись, выполнение в зависимости от статуса производящего эти действия. Для директорий выполнение означает возможность открыть файл по указанному пути. Права обозначают либо буквами rwxrwxrwx, либо цифрами 666 777. Отсутствующее право обозначают минусом (прочерком) для буквенного обозначения. Первая тирада – права владельца, вторая – группы, третья – остальных.
Вот пример для файлов:
rw-r–r– или 644 – все могут читать файл, а владелец может еще и писать в файл.
rw-rw-rw- или 666 – все могут и читать, и писать.
Пример для директорий:
rwxr-xr-x или 755 – все могут читать директорию и находить в ней файлы, владелец может создавать новые и удалять существующие файлы в директории.
rwxrwxrwx или 777 – всем все разрешено.
На нормальном хостинге права обычно автоматически прописываются на сервере, единственно нужно поменять доступ только на папки для аплоада и кеша, куда будет писать WordPress. Проследите, чтобы права на запись были 755 на папки и 644 на файлы, на wp-content рекомендуют всегда ставить 777. Если вам требуется внутренним редактором изменить какие либо файлы. например в / wp-content/themes /, надо поменять права на 666. Делаем это так: отмечаем в окошке Тотал Коммандера нужную папку, файл или всю группу, затем слева на верхней инструментальной панели “Файл – Изменить атрибуты”, появляется окошко

Вводим нужную комбинацию цифр, далее OK. Все это можно сделать в Account Manager на хостинге, кому как удобно. Если запутались, поставьте плагин, который подскажет какие права выставлены и какие надо выставить и на какие папки и файлы WordPress. Плагин называется Wp security scan. Жмем Security/Scanner – видим очень наглядное окошко, в котором зеленые полосочки показывают норму, а красным закрашены те файлы и папки, на которые надо изменить права. Current Chmod, это текущие значения, Needed Chmod – те, на которые поменять надо. Вот пример:

Если плагин рекомендует проставить права доступа на папки 755, 775 либо 777, сделайте это, так как они могут быть разными в зависимости от настроек вашего сервера. Всегда внимательно относитесь к этим требованиям так как это очень важно. Рекомендую активировать его на хостинге, после сканирования выполнить рекомендации, а затем отключить. Кстати там же можно посмотреть информацию о вашем хостинге.
Заливка дампа БД с помощью Sypex Dumper Lite.
Отредактируем файл wp-config.php, в корне блога, пропишем в нем необходимые данные по базе MySQL, которую мы создали у хостера, они наверное будут отличаться от тех, что на локалхосте.
Теперь нам надо залить в созданную у хостера базу файл с дампом нашей адаптированной базы данных с локалхоста. Делаем инсталляцию Sypex Dumper Lite в корень будущего блога. Так же как на локалхосте можно создать папку с файлом dumper.php, прописать CHMOD 777 на папку со скриптом, а лучше просто залить файлик dumper.php в корень сайта. После первого запуска скрипта, заливаем исправленный файлик дампа базы в папку backup, которая тут же создалась. Набираем адрес http://moi-site/papka-skripta/dumper.php или http://moi-site/dumper.php, во втором варианте вроде и проще. Видим знакомое окошко, вводим логин и пароль базы данных которую мы создали только что – Применить, получаем окошко Дампера. Здесь нам нужна нижняя часть – Restore.

Выбираем дамп базы данных, что мы перед этим залили, в нижнем разделе, из раскрывающегося списка – Применить и пошла заливка. Дамп появился в списке, потому что мы его перед этим закачали на хост в папку backup.
Альтернативные варианты. Заливка дампа базы данных с помощью phpMyAdmin
Хуже, если dumper не будет работать на нашем хосте, даже со всеми танцами с бубном. Тогда дело труба. Этим способом можно залить дамп максимум в несколько мегабайт, но не более. Базу данных WordPress с минимумом контента, во всяком случае на хост перенести можно. Итак заходим с панели управления в phpMyAdmin к хостеру. Там находим нашу базу, жмем вверху на кнопочку SQL, получаем окошко:

Копируем из текстового редактора нашу исправленную базу начиная с “DROP TABLE IF EXISTS” и ниже и вставляем в окошко, жмем OK. Если получим надпись одобрямс, значит база залита.
Второй вариант, который проходит не на всех фришниках.
Если Вы заходите в phpMyAdmin и видите верхнюю панельку такого вида, дело труба.

А если вот такого – GOOD.

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

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

Количество запросов 3, далее OK, пару тройку минут получаем результат.

И вот она база:

Можете себе представить, Ваш блог уже создан.
Ну а что действительно, файлы залиты, база данных со всеми настройками, связями, паролями, URL, и пр. тоже. Теперь можно набрать http://moi-site.com, и если все у нас прошло нормально попадаем на сайт.
Следующий шаг после заливки базы – заходим в админку нового блога, пароль тот же что на локалке. Произведем дополнительные настройки, пропишем API – Key, адрес почты Gmail, и пр., для сплога запрещаем коментарии к записям, различные уведомления для владельца блога на Email и прочий спам. Наша задача выполнена!!!
Апдейт плагинов на Localhost.
У меня на всех блогах были проблемы с автоматическим апдейдом плагинов, изменение атрибутов и прочее не помогали. Постоянно что то не хотело копироваться и пр. На локалхосте же не было случая, чтобы какой то плагин не захотел апдейдится. Возможно у Вас такая же ситуация, и ничего не стоит, имея на локалхосте рабочую установку WordPress, в случае неудачного апдейта на хосте, обновить плагин тут и загрузить файлы последней версии плагина на хост. А в нашем случае, перед переносом на сайт, просто заранее сделайте апдейт нужных плагинов.
Некоторые действия по защите блога.
Если Вы по моему совету активировали плагин WP Security Scan, то наверное заметили на первой странице некоторые замечания и рекомендации.

Одно из них гласит, что у нас не существует Файла .Htaccess в WP-Admin. Вроде там его не было и не должно быть. Однако известный гуру Мэтт Катс рекомендует для защиты директории /wp-admin/ закрыть общий доступ к ней по IP, оставив открытым только для некоторых. Для этого создается файл .htaccess, который и размещается в этой директории.

Указанный или указанные адреса будут иметь доступ директории /wp-admin/.
Вот почему плагин и указал нам на отсутствие файла.
Далее для того, чтобы скрыть информацию о том, какие плагины мы используем, надо защитить директорию /wp-content/plugins/, поместив в нее пустой файл index.html
Кроме того он еще советует вовремя делать апгрейд, но об этом ниже.
Обновление движка на Localhost.
Попробовал прямо на локалхосте обновиться до последней версии, в настоящий момент это v.2.8.6. Вы знаете получилось элементарно и очень даже быстро. Вообще оно нам надо, спросите Вы?
Для блога, очевидно да – отвечу я, а для создания сетки сплогов применять самые последние версии WP, наверное все таки нерационально. Слишком много ресурсов они потребляют размер кода всё растёт и растёт, производительность в плане работы с базой данных местами ухудшилось. Но с другой стороны, железо то совершенствуется, и на единицу у.е. мы получаем у хостера все больше ресурсов – памяти и пр., так что может быть не надо экономить на этом. Кроме того, начиная с Wordpress 2.7, упрощается процедура обновления блога, установки плагинов и их обновления. Все это можно выполнять в самом движке Wordpress, необходимо лишь указать логин и пароль, для доступа на ФТП-сервер, все остальное Wordpress сделает самостоятельно.
Пару слов об обновлении Wordpress. Начиная с версии 2.5 можно просто распаковать архив и файлы из архива, загрузить в папку Вашего блога на сервере, с заменой существующих файлов, предварительно сделать бэкап базы данных и файлов блога, затем зайти в админку. Вам скорее всего будет предложено обновить базу данных блога. Никаких проблем возкнинуть не должно, единственно может быть надо будет обновить некоторые плагины. Еще не забудьте перед заливкой, удалить файл install.php папки wp-admin, и если Вы пользуетесь темой default или classic, удалите из новой сборки, чтобы оставить старые файлы если мы что то меняли в них(для плагина навигации и возможно других). По мне, так папку wp-content с содержимым вообще менять не надо.
Преимущества последних версий движка, исправление уязвимостей.
В последних версиях исправили несколько дыр, связанных с безопасностью, кроме того теперь многие скрипты грузятся из футера страницы, что ускоряет начало отрисовки страницы т.е.в некотором роде увеличили производительность. С другой стороны, говорят что исправление уязвимости CORE-2009-0515 поломало работу некоторых плагинов, и если автор, например, перестал поддерживать какой – нибудь замечательный плагин из их числа, то приходится надеятся только на энтузиастов, что, как Вы понимаете, иногда приводит к непредсказуемым результатам. Но опять таки, появляются плагины только под новую версию движка, и тут мы в проигрыше.
Больная тема, надо ли бояться уязвимостей? Вот свежий пример, в сентябре 2009 года многие блоги на WordPress были подвергнуты атаке(MySQL-инъекция). По некоторым данным в короткое время было сломано около 1700 блогов, в основном правда западных. Хакер воспользовался уязвимостью, которая ломает структуру ссылок ЧПУ и дает доступ к администрированию блога. Создается пользователь с правами администратора, но в списке пользователей его нет. Постоянные ссылки превращаются в нерабочие из за того, что к ним добавляется код примерно такого вида:
Подмена ЧПУ нужна для того, чтобы выполнился скрипт, дающий юзеру админские права и делающий этого юзера практически невидимым. Скрипт состоит из двух частей: одна, закодированная в base64, передается как referer, в ней указан логин и пароль “повышаемого в звании” юзера, а вторая, универсальная часть за первой тянется с китайского сервера.
Для защиты старых версий движка Ю.Б. из “Клуб WordPress” советует взять из дистрибутива 2.8.4 файл /wp-includes/vars.php и подложить в свой WordPress.
1. Если блог уже заражен, идем в Setting – Permalinks и по новой прописываем свой вариант адреса страниц, у меня /%category%/%postname%.html.
2. Надо просмотреть в базе данных таблицу wp_usermeta, не ли там админских прав и имен, содержащих что то подозрительное, а еще лучше уничтожить всю базу данных и восстановить ее из последнего бэкапа.
3. Удалить последнего зарегистрировавшегося пользователя. Говорят один из врагов вот этот: MikeWink E-mail: bugbeemershonyhe@gmail.com.
4. Проверить пользователей с админправами, если их больше ожидаемого, вычислить последнего зарегистрировавшегося, правым кликом скопировать ссылку Edit и вставить его в адресную строку, увеличить номер на 1. В поле Имя у скрытого админа код странного вида. Код надо удалить, тем самым понизив его статус до “Подписчика”. Подписчика можно удалить у Пользователей в Админке.
5. На сателлитах подальше от греха закрыть регистрации юзеров.
6. Обновить Wordpress до последней версии.
Кто то скажет, а так ли безопасны последнии версии движка? Вот, например, была обнаружена уязвимость, в версии 2.8, которая позволяла злоумышленнику с помощью специальной ссылки, обойти проверку пользователя т.е сбросить пароль любого пользователя, сделав запрос к скрипту wp-login.php и запросить восстановление пароля. Любого, включая администратора. В результате пароль сбрасывался и новый посылался на электронный ящик, указанный в профиле. Злоумышленник не получал доступа к блогу, но мог менять Ваш пароль постоянно. Но подумаем и сделаем выводы:
1. Уязвимость не такая уж и «критическая», т.к после сброса пароля, новый высылается почтой не злоумышленнику, а соответствующему пользователю.
2. Уязвим не только WordPress 2.8, но и все предыдущие версии.
Кстати, для устранения уязвимости не надо качать версию 2.8.4, можно применить патч для WordPress версий 2.8.3 и 2.7.1(_http://blog.sjinks.pro/wordpress/616-wordpress-2-8-4/#more-616)
Таким образом понятно, что если вы не обновились, вы более уязвимы, обновляться нужно вовремя! Конечно решение какой версией пользоваться принимаете Вы сами, но, пожалуйста, учтите вышесказанное. Одно дело, если у Вас небольшой блог, типа сайта визитки(бывает и такое), информация практически не обновляется и Вы вовремя бэкапитесь, Вам это и не надо. Может Вы используете плагины, которые не ставятся на новые версии движка. А если у Вас огромный блог, с каждодневным обновлением и тысячными посещениями, хороший хост под него, подстраховаться можно. Да и зуд познания чего то нового, никто еще не отменял. Но если Вас устраивает ваша версия WordPress и не нужны новые плагины, и обновляться не стоит.

Продолжение следует.
Автор Stepan Demin. Использование и копирование статьи РАЗРЕШАЕТСЯ с указанием автора и ссылки на первоисточник BlogInforama