Bloginforama

Archive for the ‘SeoTraining’ Category

Как удалить все записи из таблиц в базе данных MySQL, или удалить сами таблицы, если у нас нет доступа к PHPAdmin. Такой вот вопрос иногда встает перед нами. Это бывает, например, когда хост нам предоставляет спонсор, данные доступа к базе MySQL пожалуйста, а вот к PHPAdmin никак. О доступе ssh в этом случае вообще нереально говорить. Да мало ли вариантов, когда нас урезают в правах. Так вот иногда при неудачной установке какого либо скрипта надо очистить, а иногда и удалить все таблицы в вашей базе. Вроде элементарно, но для того, чтобы ее решить я потратил немного времени, и дабы Вы его не тратили, почитайте эту статью.
Погуглив немного, понял, что в лоб тут не получится, всякие там SQL запросы на очистку таблиц, установки своей версии PHPAdmin в корень сайта не годятся.
Остается одно, найти программу или скрипт, с помощью которого можно решить задачу. Все промежуточные варианты рассматривать не будем возьмем за основу крайний.
Им явился скрипт Matt`s MySQL Control Panel выпуска 2002 года.
Заливаем файлы скрипта в корневую директорию, и все скрипт установлен.
Вызываем скрипт с помощью URL, http://ваш-сайт.com/mpanel/, и получаем вот такое окошко:

Заполняем поля, жмем login, и получаем окошко в котором мы будем работать:

Я из команд использовал удаление всех таблиц в базе, все прошло гладко, думаю и с остальными проблем не должно быть.
Как видите, все просто и элементарно, если кому то поможет, буду рад.
Автор Stepan Demin. Использование и копирование статьи РАЗРЕШАЕТСЯ с указанием автора и ссылки на первоисточник Bloginforama

Социальные сети плодятся как кошки, и не только такие типа “Социальная сеть г. Урюпинска” а довольно таки крупные. Одной из таких крупных сетей является сервис микроблогов Twitter. Да да, Twitter это социальная сеть, это произошло после того как Twitter запустил новую функцию «You both follow». Здесь человек ведущий микроблог с помощью этой функции узнает какая тематика интересует другого пользователя микроблога и пр. Так что из сайта, состоящего из микроблогов, где по замыслу создателей была только возможность задать вопрос типа: «Что ты сейчас делаешь?», – и так же коротко(140 символов) ответить на него, выросла огромнющая сеть. Причем она настолько популярна. что скоро президенты станут «твиттерянами».
Ну ясно, что взоры seo-мастеров периодически обращаются в сторону Twitter’а, и, естественно, им в помощь пишутся плагины с разной функциональностью. Кто ставит мощные, многофункциональные плагины, а кто довольствуется попроще, с ограниченными функциями. Вначале я выбрал из множества предлагаемых плагинов Twitter Tools, плагин мощный хороший, функций ну очень много.
Сильным Twitter’оманом себя я не считаю и потому, решив остановиться на чем то более легком, обратил взор на TweetSuite.
Неплохой плагин, по “мощности” не уступающий предыдущему, имеется кнопка ReTweet, умеет показывать tweetback, публиковать твиты о новых записях, работает с виджетами. Занозой было создание четырех таблиц в базе данных, ну не нравится мне, когда плагины в базу лезут, да еще такие, вроде не очень обязательные. Поработал он у меня на блоге, и решил я его все таки снести и поискать для других блогов что нибудь другое, полегче. Список твитплагинов с описанием функций перечислять нет смысла, их уже сотни наверное.
После недолгих поисков наконец нашел таки я “свой” плагин – Twitter Updater v1.1 автора Victoria Chan. Плагин этот для ранних версий – WordPress(v2.5). На базе этой версии созданы плагины для более поздних версий WordPress уже другими авторами(v2.0-2.08). Очень он мне понравился простотой, и ведь самое главное он делает – публикует твиты при создании, публикации, или изменении Вашего сообщения. Использует сервисы “коротких имен”. Правда очень не понравилось то, что он повторно публикует твиты при каждом редактировании поста.
Так что довольным я оставался недолго, да тут еще заглядываю в аккаунт Twitter и вижу:

Как видно из рисунка в новых записях, опубликованных после смены плагина TweetSuite, их можно определить по смене сервиса (zz.gd это новый), русские буквы отображаются кракозябрами. Пришлось искать альтернативу.
Чуть не повелся на плагин Twitme, думаю милый плагинчик, по описанию один из плагинов, который автоматически публикует в твиттер сообщения, когда вы что-то написали в блоге.
Ну еще имеет настройки по автопосту публикаций записей из определенных категорий, настраивается формат сообщения. Ладно, думаю надо не надо – пусть будет, вроде не такой монстр как Twitter Tools и TweetSuite. Хорошо что в папку плагина заглянул. Я был в шоке, представьте себе плагин из 15картинок, 53 файлов из них 31 с расширением .js. Для сравнения в мощном, многофункциональном Twitter Tools 4(четыре) файла .php, в TweetSuite два.
Следующим протестировал Twitpress, маленький плагин, в виде одного файлика. Версия 0.3.2 автор Thomas Purnell, производство 2007 года. Самое интересное что плагин тестировался на версии WordPress 2.3.3, а у меня на версию 2.8.4. Заполнил информацию об учетной записи в Twitter в меню конфигурации:

Опубликовал пост и тут же получил сообщение в твиттере:

Как Вы видите плагин не использует сторонних сервисов по короткому урл. Честно говоря я в последнее время стал склоняться к мысли, что ссылки даже в твиттере лучше оставлять прямыми. Мнение конечно спорное, учитывая ограничение в 140 знаков, но лишний сервис и пр…
Самое главное кракозябры исчезли. Приятно, что нет imho ненужной функции предыдущего плагина, это повтор публикации редактируемого поста. Правда таблицу в базе данных twitpress он все же создает. Называется она “twitpress”.
Так что если Вам нужен простой плагин с минимальными функциями, рекомендую. Плагин для ленивых или занятых – поставил и забыл. Вроде в Твиттере отмечаешься, но и без фанатизма.
Автор Stepan Demin. Использование и копирование статьи РАЗРЕШАЕТСЯ с указанием автора и ссылки на первоисточник BlogInforama

В восьмой части статьи Wordpress – атака клонов. я немного коснулся темы абсолютных (Absolute links) и относительных (Relative links) ссылок. Вообще понятие абсолютных и относительных ссылок касается не только интернета. Например в Microsoft Excel формулы, реализующие вычисления в таблицах, для адресации ячеек используют ссылки на ячейку, которые могут быть относительными или абсолютными.
Нас же эти ссылки интересуют применительно к работе с файлами на сайте.
Прописывая ссылки мы должны помнить, что везде есть т.н. корень, в нашем компьютере в файловой системе это корень файловой системы на диске а на сайте нет никакого диска это корень веб-сервера.
В Windows нет единого корня всей файловой системы, их столько, сколько разделов или отдельных жестких дисков столько и корней, т.е. все исчисления путей будут идти от каждого конкретного диска(C:\ D:\ E:\).
Мы уже поняли что там и там ссылки могут быть абсолютными и относительными. Везде как и в жизни надо плясать от “печки”, и у нас это пресловутый корень.
На сайте для скриптов, физически находящихся на диске и работающих с реальными файлами исчисление путей может быть примерно таким /godu/www/mysite, где “mysite” это корневая папка веб сервера.
То что касается сайтов как виртуальных субстанций у них и адреса виртуальные, при просмотре в браузере, который не находится непосредственно на сайте, нужно прописывать только абсолютные ссылки, которые и являются виртуальными адресами(URL).
К примеру корнем для браузера будет http://moisite.com/ являющийся виртуальным адресом. Почему при наборе этого адреса мы на странице видим реальный контент? А потому что в настройках сервера при наборе этого адреса подразумевается вызов реальной страницы index.php или index.html.
В данном случае нас этот вопрос интересует с практической точки зрения, как на сайте правильно прописать пути к файлам.
Когда веб мастер прописывает ссылки у себя на сайте у него два варианта:
1 Прописать перед папкой с нужным нам файлом(неважно это .php, .jpg и.т.д) полный путь включая http://, допустим вызываемый объект image.jpg находится в папке “images”, тогда путь примерно такой: http://moisite.com/images/image.jpg. Тут мы обозначили корень так же как его видит браузер, для которого это единственный вариант – абсолютный путь который прописан от корня сайта.
Если же этот абсолютный путь прописывается внутри структуры сайта, получается некая двусмысленность, мы задействуем протокол HTTP.
Соответственно исполняемому скрипту(программе то бишь) необходимо задействовать web-сервер для подгрузки, создается повышенная нагрузка на сервисы nginx и apache, которым требуется обработать запрос к картинке.
Мы то путь к этому рисунку прописали не для того чтобы серфер набрал адрес у себя в браузере и скачал себе на комп. Этот рисунок(файл) должен обработаться каким нибудь скриптом(например галереи) находящемся тут же на сайте и лечь в определенное место на странице ему прописанное, он может ресайзиться, меняться на другой и.пр.
По идее мы тут имеем локальный адрес и его можно прописать без указания протокола и домена, то есть можно подойти к этому файлу впрямую. .
2 Это как раз тот случай где на локальный адрес можно в начале пути корень не прописывать, тогда этот путь к файлу будет относительным, и он достраивается от текущего положения скриптом. Вид у ссылки в нашем примере /images/image.jpg, путь к корню /godu/www/mysite или http://moisite.com мы не прописываем.
Вот тут мы и подошли к тому, ради чего и написан этот пост.
Интуитивно я всегда склонялся к относительным ссылкам, как не крути а путь короче. Проявлялись правда иногда кое какие несоответствия в путях, иногда перед папкой или файлом надо было проставлять “/” иногда нет, это случай когда адрес внутри темы прописывался. Но я везде, например вставляя в пост миниатюру, которая ведет к большой картинке все таки прописывал относительные пути. Да и некоторые скрипты, где надо было много картинок вызывать, я применял на разных хостах и удобно было применять относительные ссылки, чтобы лишний раз их не переписывать шаблон.
Тут в форуме “WordPress – форум поддержки” на MyWordPress.ru тему прочитал, где хостер объясняет, что нормальным способом является тот, при котором картинка загружается напрямую, внутри сервера по относительной ссылке. Ну, думаю хорошо, прав я что относительным ссылкам верю. Правда авторитеты, например “Ю.Б” раскритиковали претензии хостера, но это вроде касалось чисто зависимости вида ссылок на нагрузку сервера.
И вдруг, в один прекрасный момент захожу я на на свой Фид и, о ужас, ни одной картинки. Хорошо еще Altы прописывал, хоть что то видно, но в любом случае хороший “подарочек” для подписчиков – статьи без картинок. Смотрю а у меня ссылки вида hppp://bloginf.com/wp-content/uploads/image.jpg заменены на hppp://feeds.feedburner.com/wp-content/uploads/image.jpg. А ведь тот же “Ю.Б” предупреждал, цитирую: “Только имейте в виду, что браузер, если не указан полный URL, подставляет текущий протокол, текущий домен и, если нужно (для относительных url) текущий путь.”
Поменял в постах все ссылки на картинки на абсолютные. Проблема ушла, но так как любовь к относительным ссылкам осталась, решил я поставить плагин relative-links, который на лету меняет все ссылки с абсолютных на относительные, если они ведут по внутренним путям блога. Плагин v 1.1 в версии WordPress 2.8.4 работает, картинки на feeds.feedburner не исчезли, все вроде нормально.
Автор Stepan Demin. Использование и копирование статьи РАЗРЕШАЕТСЯ с указанием автора и ссылки на первоисточник BlogInforama

Выбирая WordPress в качестве движка для блога мы как бы сразу соглашаемся на некоторые неудобства, связанные с его бесплатностью. Речь идет о огромном количестве рекламы в админке, когда я впервые увидел сколько “левого” кода прописано в базе данных свежеустановленного движка то был, мягко говоря, неприятно удивлен. Ну что ж делать, бесплатный сыр…. Далее, когда все чаще сталкиваешься с “тормозами” возникает и нарастает раздражение. Чаще правда мы сами виноваты, плагины ведь ставим без разбору, ленимся заглянуть лишний раз в базу данных, в исходный код страницы, посмотреть сколько мусора тот или иной плагин туда вносит. Поначалу мы соблюдаем порядочность, и упаси боже даже подумать о том, чтобы какую нибудь ссылку внешнюю на Вордпрессовский ресурс убрать(видели бы вы сколько их в базе данных). Потом бывшая советская ментальность побеждает и мы, забывая о ней(порядочности) начинаем потихонечку убирать то, что по нашему мнению нам мешает жить. А очень мешает обилие новостей “планеты WordPress”, различные ссылки, которые нам впихивают на странице админки называемой Dashboard. И что делать? Убирать. Как? Сейчас попробуем, только не бейте сильно, я успокаиваю себя тем, что чайник и после моей подсказки не разберется, а опытный все равно и без меня, если надо это сделает.
Первым делом убираем показ новостей с “планеты WordPress”. Вообще есть специальные плагины для этого, но при ближайшем рассмотрении они не оправдали надежд. В разных версиях WordPress, разные косяки.
Пойдем другим путем, для этого откроем файл index.php в каталоге wp-admin и начиная со строки 11 уберем скрипт вызова новостей:

Напоминаю речь идет только о версии 2.5.1 WordPress.
На этом можно успокоиться, грех на душу взяли уже, но нет, чешется еще что нибудь испортить. В принципе, этого вроде достаточно так что дальнейшию кастрацию файла index.php можно не делать.
Начиная со строки 30 убрал:

Со строки 38

Строка 72

Строка76

Строка77 убираем:

Со строки 86:

В результате кастрации файла страница админки приобрела из такого:

вот такой вид:

Пугаться не надо, остальные страницы выглядят как обычно:

Можно скачать файлик index.php, но перед заменой в папке wp-admin сохраните оригинальный, если что не так вернете обратно.
Далее, надо бы почистить от уже существующего мусора и оптимизировать базу данных. Дело в том, что отдельные таблицы, созданные однажды активироваными плагинами при необходимости можно удалить ручками, для этого заходим в phpMyAdmin, отмечаем таблицы этих плагинов и в выпадающем окне жмем удалить. А вот мусор оставляемый ими в штатной таблице wp_options не так легко удалить, для этого нужен определенный опыт или плагин. Мы для чистки базы применим плагин CleanOptions, который освободит ее от неиспользуемых данных. В нашей версии WordPress 2.5.1 он чудненько работает.
Установка плагина стандартная, настроек нет, в созданной кнопке Manage/CleanOptions отражается количество найденных мусорных опций, далее будем их называть “осиротелые опции”. Вернее здесь отражено количество всех найденных опций в таблице wp_options, среди которых есть принадлежащие движку WordPress, часть принадлежит активированным плагинам, поэтому после всех чисток это число не будет равняться нулю. Про то, что надо сделать бекап базы данных перед работой с плагином надеюсь Вы знаете. Работу начинаем с вызова страницы плагина, для этого жмем Manage/CleanOptions, и получаем первое окошко:

Здесь информация автора, просьба поделиться деньгами и пр., нас интересует кнопка “Find Orphaned Options”, ставим один или два чека, жмем на нее(кнопку) и видим другое окно:

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

Вижу знакомое название плагина Pretty Link. Я даже подзабыл, что когда то ставил этот плагин, затем деактивировал, а хвосты оказывается остались. Вот prli_link под сомнением, жму ссылку после кнопки “Google it”, все ясно – тоже концы от этого плагина. После просмотра, отмечаем выбранные значения или если решили все удалить, находим кнопочку Wiew Selected Options Information, жмем ее:

Получаем длиннющюю страницу с найденным (по мнению плагина) мусором:

Если согласны все это удалить, в самом низу кнопка, которую жмем, перед этим ставим чек на Yes, кнопка называется Submit:

И в следующем окошке видны результаты:

Жмем CleanOptions вверху и видим что количество найденных опций изменилась:

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

Действительно кое что осталось:

Отмечаем и удаляем:

Далее оптимизируем базу данных, для этого заходим в PHPADMIN – Выполнить SQL-запрос(ы) к базе данных. В поле вводим запрос “OPTIMIZE TABLE wp_options” без кавычек.

Из 4.7мб получилось 3.7мб
Можно сделать по другому, в выпадающем окошке выбрать “оптимизировать таблицу” в результате:

Проверяем блог, все нормально функционирует.
Результат всех действий такой: было в базе данных 526500 знаков стало 130100.
Я думаю в плане уменьшения нагрузки для сплогов на базе WP 2.5.1 на грошовых, а тем паче на бесплатных хостингах польза будет большая. А вот если мы имеем крутой блог на хорошем хосте, свежую версию WP, админу удобно просматривать в “доске обьявлений” последние комментарии, он пользуется быстрой публикацией, может быть все это и не надо.
Автор Stepan Demin. Использование и копирование статьи РАЗРЕШАЕТСЯ с указанием автора и ссылки на первоисточник BlogInforama

3VDZHMGH6NWE

Архивные записи в WordPress вещь конечно нужная, но и некая головная боль с другой стороны одновременно. Дублирование контента в архивах вещь не очень хорошая для SEO и приходится плагинами или прописывая в .htacces скрывать их от поисковиков. Кроме того при выводе категории, во многих темах на странице отображаются полные посты в количестве указанном в настройках блога. Как правило их не меньше десяти, и если статьи еще и большие по обьему получается очень большая лента. Как это изменить?
В интернете есть предложения выводить заголовки постов в архиве в виде нумерованного или маркированного списка используя php и html код. Для примера возьмем дефолтовый шаблон и поменяем код вывода в arhives.php

на

Вот что получилось в результате:

Можно оставить вывод даты поста, название рубрики,сведения о комментариях.
Для этого найдем в файлике Arhives.php кусок кода отвечающего за вывод контента:

и поменяем его на:

Получим в итоге следующее:

Но еще лучше мне кажется, при подключенном плагине “the-excerpt-reloaded” сделать некое подобие главной страницы с выдержками постов.
Для этого поменяем код вывода контента

на:

И получим

Таким образом мы достигаем нескольких целей, страница получается компактней и в то же время информации на ней побольше, чем в вариантах выше, и дата есть и название рубрики и выдержка из каждого поста – можно предварительно ознакомиться с содержанием.
Учтите, в разных шаблонах коды отличаются, Вам надо интуитивно понять где что менять. Далее, для удобства, можно еще, опять таки при активированном плагине навигации, например “wp-page-numbers” вставить соответствующий код:
В дефолтной теме вместо:

Вставляем

И получаем внизу полоску навигации. Таким образом архивная страница все больше становится похожей на главную.
Чтобы поместить больше постов на архивной странице, надо изменить настройки плагина “the-excerpt-reloaded” уменьшив количество слов в выдержке, и с помощью плагина “Custom Query String” увеличить количество выводимых постов.
Автор Stepan Demin. Использование и копирование статьи РАЗРЕШАЕТСЯ с указанием автора и ссылки на первоисточник BlogInforama

В первой и последующих частях статьи мы установили 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

В предыдущих частях статьи начиная с первой мы узнали как создать базу данных и познакомились с интерфейсом админки, изучили как устанавливаются SEO плагины, плагины редиректа, сервисов и плагинов статистики. Сейчас Мы попробуем сделать первый шаг к успеху в деле создания сплогов и сателлитов, заполнить блог контентом. Следующие пункты скорей всего следует читать только тем, кто как раз собирается делать сплоги, сателлиты и прочие серые “шалости”. Все представленные здесь плагины, платные и бесплатные, предназначены именно для заполнения сплога контентом и попыткам его уникализировать. Почему столько внимания контенту, спросите Вы. А где описание разных приемов по продвижению, Seo оптимизации, семантичное ядро в конце концов где. А потому, скажу я, что контент, естественно уникальный, это бог нашего дела, и если Вы этого еще не знаете, то в будущем поймете. Вы можете сделать сайт с убогим дизайном затасканного шаблона, статический, без всяких примочек типа пингования, сайтматов с уведомлениями и прочих атрибутов движков динамических сайтов, можете не прописать Seo мета теги, но если у Вас на сайте уникальнейший контент, вездесущие роботы рано или поздно Вас найдут, выделят, на сайте постепенно закипит жизнь и польется такой трафик, который и не снился горе – оптимизаторам, неспособным добыть контент. Я как то случайно зашел на блог известного эрудита Анатолия Вассермана размещеный в livejornal(awas1952.livejornal.com). Дизайн наипростейший, навигация никакая и прочие вроде бы “отступления от канонов SEO продвижения”. Конечно, я предполагаю что, ему некогда заниматься Seo продвижением, но пиар блога в Google знаете какой…. PR5. Очевидно ему просто есть что сказать и о чем поговорить, народ к нему тянется, вот Вам и трафик. Анатолий вышел на Дерибасовскую, встретил знакомого, обсудил с ним какую то проблему, вот и очередной пост в блоге. Так как подавляющее большинство из нас далеко не “Вассерманы”, приходится как то изощряться, применять различные приемы по добыче контента и технически вооружаться. Оружие средней тяжести – плагины в WordPress. Конечно использовать эти плагины приходится на свой страх и риск, можно поймать бан, попасть в фильтры и прочие санкции со стороны поисковиков.

42. FeedWordPress.

Одним из факторов, определяющим выбор Wordpress в качестве движка – это возможность автонаполнения контентом. Для этого можно использовать несколько плагинов. Один из них FeedWordPress.
Высказываются мнения, на мой взгляд спорные, что FeedWordPress – самый главный плагин в сплоггерском деле. Он позволяет из одной или нескольких RSS лент делать посты, и делает это атоматически, т.е. практически без нашего участия. Причем он работает по расписанию используя свой “cron”. Чтобы установить плагин, скопируем папку feedwordpress с файлами в папку wp-content/plugins/, а файлы из папки MagpieRSS-upgrade – rss-functions.php и rss.php в директорию wp-includes/ нашей инсталяции блога. Эти папки вы обнаружите в архиве , который можете скачать на сайте разработчика(сайт автора _http://radgeek.com). После этого плагин активируем и настраиваем. Для настроек используется вкладка “Syndication” в админке. Произведя настройки, можно добавлять новые ленты и сразу же увидеть результат в виде записей после того, как лента была создана, можно необходимые ленты отметить галочками, и нажать кнопку “Updated”, или настроить запуск автообновление по графику, например, каждые 30 минут. Серверный “cron”, что у нас на хосте тут может помочь, но абсолютно не обязателен! Полученную запись можно опубликовать сразу, или сохранить в черновик, с последующей публикацией. Работа ведется с лентами формата RSS/Atom. Подойдут и ленты популярного FeedBurner’а. Мы можем установить как общие настройки для всех лент, так и настроить каждую по отдельности, например, задать рубрику, куда будут помещены записи, полученные с определенной ленты. Рубрики могут создаваться автоматически. Мы также можем выбрать будет ли отображен только анонс на статью с дальнейшей ссылкой на сайт автора, или же статья будет переноситься к вам в блог полностью. Второй вариант, как известно, приветствуется далеко не всеми, правда и найти блоги, где отдают полные статьи тоже требует усилий. Записи можно присвоить определенное имя автора, или же плагин автоматически создаст аккаунты для всех авторов, чьи статьи вы импортируете.
И наконец, вы можете разрешать или запрещать комментарии или пинги к импортированным записям. В интернете есть несколько доработанных версий плагина. Одна из них, со своими уникальными настройками от splogmaster_а, вторая от blog.romb, но имхо применение их все таки носит временной характер – появляются новые версии WordPress, которые требуют и новые версии плагинов, да и сам плагин совершенствуется, поэтому лучше все таки ставить самую свежую версию. Я как то, на локалхосте подключил одну из модифицированных версий плагина, но она вдруг не заработала с тем фидом, что мне был нужен. Подключил такую же версию в оригинальном варианте. Результат тот же. И только когда я поставил последнюю на тот момент версию(2009.0707), она мне выдала в письменном виде причину ошибки. Возможные проблемы. Если на хосте, при добавлении новой ленты возникает ошибка “Fatal error: Call to undefined function xml_parser_create() in /wp-includes/rss.php”, или лента просто не добавляется, это значит, что на хостинге нужно подключить расширения php, связанные с xml. Это можно сделать самостоятельно через админку хостинг-провайдера, а если такой возможности нет, попросить техподдержку.
Активируем FeedWordPress. На момент написания статьи это FeedWordPress 2009.0707. При активировании плагина, этой версии, почему то постоянно вылезала ошибка о несоответствии версии 0707 и MagpieRSS 0618, что, впрочем, не мешало нормальной его работе.

После апгрейда окошко исчезло. Активируем и рассмотрим настройки плагина:
Syndicated – Settings – Syndication Settings.

Вначале окошко Syndicated Feeds. Здесь сверху вниз:
1. Рубрика для ссылок на источники:
2. Проверять новые записи: Автоматически или только по моему запросу.
3. Ограничить обновление по времени: Без ограничений.
Тратить на обновление не более…

4. Информация о ленте. Три чекбокса: Обновить заголовок источника при изменении заголовка ленты. Обновить описание источника при изменении тэглайна ленты. Обновить ссылку на источник при изменении ссылки в ленте.
Ниже три рубрички, где ссылки, которые ведут на другие страницы настроек. 1. Синдицированные записи, комментарии и пинги. 2. Синдицированные авторы. 3. Рубрики и метки.
В самом низу “Конец”, Уведомления об обновлениях: записывать ли заметки об обновлениях в логи PHP, Режим отладки: Когда режим отладки включен, FeedWordPress отображает много диагностических сообщений об ошибках, которые обычно подавляются, и отключается кэширование всех лент. GUID индекс: можно создать Guid индекс, который иногда может существенно повысить производительность. По этой странице все.
Syndicated – Settings – Syndicated Post Settings(Настройки синдицированной записи)

Окошко Publication(Публикация), в нем на выбор разные значения Status for new posts(Статус новых записей):
1. Publish syndicated posts immediately: Опубликовать синдицированные записи сразу же.
2. Hold syndicated posts for review; mark as Pending: Оставить записи для обзора, пометить как незавершенный обзор.
3. Save syndicated posts as drafts: Сохранить синдицированные записи как черновики.
4. Save syndicated posts as private posts: Сохранить синдицированные записи как частные записи.
Окошко Formatting(Форматирование) и Formatting filters(Фильтры форматирования) с двумя значениями в выпадающем окошке:
1. Защитить синдицируемые записи от фильтров форматирования.
2. Передать синдицируемые записи на обработку фильтрам форматирования. Здесь же ссылка ” Если у вас есть проблемы с работой плагинов, которые используются для вставки каких-либо элементов после записей (что-то вроде релевантных ссылок или кнопок социальных сетей типа «Share This»), то попробуйте поменять этот параметр, возможно, это поможет решить вашу проблему”.
Окошко Links, в нем Permalinks(Постоянные ссылки), с выпадающими значениями:
1. Указывать на копию с оригинального сайта.
2. Указывать на локальную копию на этом сайте.
Там же Posts from aggregator feeds(Записи из лент агрегатора): отмечаем один из чеков.
1. Установить в качестве источника записей сам агрегатор.
2. Установить в качестве источника оригинальный источник, не агрегатор. Пояснение: Некоторые ленты (например, ленты созданные FeedWordPress) агрегируют содержимое из нескольких раличных источников и включают информацию об оригинальных источниках записи. Эта настройка контролирует какую именно ссылку FeedWordPress подставит в ленту агрегатора в качестве источника записи.
Окошко Comments & Pings (Комментарии и пинги), здесь чеки Комментарии:
1. Разрешить комментарии к синдицированным записям.
2. Не разрешать комментариев к синдицированным записям.
Пинги – чеки на:
1. Принимать пинги к синдицированным записям.
2. Не принимать пинги к синдицированным записям.
Внизу кнопка Safe Setting, не забывайте про нее.
Syndicated – Settings – Syndicated Author Settings(Настройки синдицированного автора). Эти настройки повлияют на синдицированные записи любой ленты, за исключением записей из лент, для которых существуют специальные настройки.

В первом поле Новые авторы. Для авторов, которые не были синдицированы ранее:
На выбор 1. Отфильтровывать. 2. Создавать новую авторскую запись. 3. Устанавливать в качестве автора пользователя Админ. 4. Устанавливать в качестве автора нового пользователя с именем: Заполняем поле.
В поле ”Подходящие авторы” ставим чек ”Считать синдицируемых авторов с одинаковыми e-mail адресами одним автором”.
Если e-mail адрес не совпадает с одним из следующих анонимных e-mail адресов: Вводим адреса почты.

Syndicated – Settings – Categories & Tags Settings(Настройки рубрик и меток).

Эти настройки повлияют на синдицированные записи любой ленты, за исключением записей из лент, для которых существуют специальные настройки. Первое поле Рубрики и метки ленты – Незнакомые рубрики:
Когда одна из рубрик синдицируемой записи встречается FeedWordPress впервые. Тут мы ставим чек на:
1. создать новую рубрику.
2. создать новую метку.
3. не создавать новых рубрик или меток.
4. не создавать новых рубрик или меток и не синдицировать записи, если они не в одной из известных рубрик.
Следующее поле Categories + Add New Category(Рубрики + Добавить новую рубрику). Здесь ставим чек на существующие рубрики, а также можем добавить новую.

Следующее поле Tags(Метки). Пометить все синдицированные записи как…Здесь вводим новые метки и добавляем их.
Syndicated – Settings – Syndicated Sites(Синдицированные сайты)

Вводим адрес фида в окошке вверху справа и жмем Syndicate.

Смотрим результат. Если там полный текст – синдицируем. Жмем Use this feed, заносим в список синдицированных лент

Ставим галочку на нужной ленте – update checked.

Таким образом мы утянули с сайта http://bloginf.com/ 25 постов. Правда это только анонсы статей, так как в Настройки чтения проставлен чек на Анонс.

Отсюда вывод, перед тем как синдицировать ленту, смотрите, чтобы там был полный текст.
Если хотим отписаться от ленты ставим чек и жмем Unsubscribe.

43. Caffeinated Content

Caffeinated Content v.3.3.7 от Kansieo, еще один плагин, для WordPress, который позволяет нам заполнять блог статьями и видео с Youtube и многих других мест. Плагин так же парсит контент с каталогов статей. Поддерживается несколько языков, английский французский, итальянский и другие, работает с цепями маркова. Принцип работы плагина такой — плагин берет вопрос из Yahoo Answers содержащий введенное ключевое слово и делает из него пост, затем берет ответы и делает из них комменты. Можно менять ссылки на странице редактируя их в текстовом файле Linlk.txt и Link2.txt(это обязательно, если не хотите плодить чужие ссылки, определять количество внедренных тэгов и выбирать способ публикации, в черновик или публикация по расписанию, варьируя датой добавления постов и комментариев, то есть плагин может постить с растяжкой по времени. Установка стандартная. Плагин платный, при установке надо ввести адрес электронной почты и ключ. Плагин требователен к серверу, к распределению памяти. Работать надо аккуратно, легко можно получить бан от Google или Babelfish. Как только активировали плагин, слева на панели появляются кнопки Settings – Caffeinated Content и Posts – Caffeinated Content Management и дополнительная таблица в базе данных.

Жмем на Settings – Caffeinated Content и попадаем на страницу:

Вверху страницы неприметная ссылочка с анкором management tab:

или нажимаем Posts – Caffeinated Content Management и попадаем на страницу Caffeinated Content Management:

Если на предыдущей странице отметим чек на Add top level link(Добавить ссылку верхнего уровня), обе страницы объединятся и все кнопки будут вызывать одну. Где то читал, что в v.3.3.7 не надо включать Top Level Menu, иначе постоянно будут слетать выбранные настройки. По моему даже автор об этом говорил. Чек не отметил от греха подальше.
Далее на странице Caffeinated Content настройки – Yahoo Developer Application ID: Здесь можно добавить Yahoo Developer API key, если нет оставляем YahooDemo.
Debug Mode: можно включить режим отладки – нужная вещь, внизу страницы увидим все настройки плагина в данный момент.

Translation Delay: и Post Delay: можно добавить задержку при запросах и публикациях в секундах.
На странице Caffeinated Content Management – Keywords: список ключевых слов через запятую или одно.
Post source: (Что хотим получить) Yahoo Answers на разных языках, YouTube для видео, Articlesbase статьи, или загрузить текстовый файл.
Post category: Контент в созданную или выбранную из существующих категорий.
Max tags to be automatically generated: Генерация меток, если 0 нет генерации.
Max questions to add: Количество запросов, чем больше, тем больше нагрузка и опасность бана Google, Babelfish и пр.
Include answers? Включить комментарии.
Auto approve added posts? Автоматически или вручную добавлять посты.
Clean bad words? Фильтр плохих слов. Можно редактировать файл badwords.txt в папке Caffeinated.
Auto approve added comments? Автоматическое добавление комментариев.
Schedule comments? Расписание добавления комментариев. На некоторых, и даже на многих блогах не работает.
Add links to comment author names? Добавить ссылку на имя автора каждого комментария. Если отметили чек, надо ниже выбрать файл с сылками, и обязательно отредактировать его.
Change comment author names to link anchor text? Имя автора в сомментах меняем на ссылку с анкором в выбранном линк листе в выпадающем списке. У нас эти файлы находятся в Z: \ Home \ Localhost \ WWW \ wp_2.7.1 \ WP-Content \ Plugins \links
Start Date (mm/dd/yyyy) и End Date (mm/dd/yyyy): Дата поста будет выбрана случайным образом между этими датами. Обратите внимание, формат американский, не перепутайте.
Post template, Comment template: Выбираем шаблоны и стили сообщений и комментариев в папке у нас это Z: \ Home \ Localhost \ WWW \ wp_2.7.1 \ WP-Content \ Plugins \ CaffeinatedContent\templates, там куча текстовых файлов с шаблонами – разные языки, цепи Маркова. Вообще, рекомендуется в качестве основного варианта выбирать для английского языка по умолчанию(Default) оба. Некоторые шаблоны можно редактировать, конечно при наличии некоторого опыта. Если работаете с русским, поимеете проблему, надо выбирать кажется польский, чтобы работало.
Произведем необходимые настройки, пропишем кеу, в выпадающем списке выберем источник контента, определимся с количеством тегов и запросов для парсинга. Количество запросов определяйте экспериментально(оптимально 50 – 200), большое количество, с большой вероятностью, может не с первой зарядки приведет к возможности бана со стороны поисковика. Вообще критическое число определяют 1000, но практически 900 – 950 не всегда успешно.
Auto approve added posts? – если уберете чек, посты попадают в Draft, и Вы их будете публиковать вручную. Кстати здесь, при публикации, проявляется преимущества более поздних версий движка WordPress. В старых версиях из Draft перевести в Publish то есть опубликовать можно только по одному посту. А вот, например, 2.7.1 позволяет опубликовать пачку постов. Для этого на странице Edit Posts отмечаем те посты, которые надо опубликовать, далее выбираем по фильтру нужное действие.

Жмем Apply, получаем окошко, в котором выбираем категорию куда публиковать, в выпадающих окошках нужные варианты, и Update Post. Все отмеченные посты будут опубликованы. Неплохо, правда.

При проставленном чеке Auto approve added posts? парсинг происходит с вариантом отложенной публикацией постов по расписанию т.н. Scheduled.

во временном промежутке указанном в настройках ниже.

Система западная, будьте внимательны месяц/день/год, не перепутайте.
Post template и Comment template, как сказано выше, в обычном варианте Default, но есть варианты. Что такое цепи Маркова, думаю, Вы знаете? Нет, почитайте в гугле, или пропустите следующий абзац. Так вот, чтобы применить эту фичу в нашем случае надо в этих окошках выбрать шаблон markoved default. В папке templates плагина они называются markoved default.c.txt и markoved default.p.txt.

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

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

Можно попытаться решить задачу можно с помощью Cron. В корне нашего блога WordPress лежит файлик wp-cron.php, называемый псевдо – кроном, необходимый для выполнения регулярно повторяющихся действий. В нашем случае это отложенная публикация. Однако если у хостера на сервере не прописано разрешение для функции fsockopen, позволяющее использовать локальные адреса, псевдо – cron не будет работать. Но, попытка не пытка. Открываем в нашем блокноте файл wp-cron.php, находим строку вида:
Можно отключить эти строчки, т.е. закомментировать их, добавив в начало символ #, и затем каждый раз набирая в браузере _http://moisait.ru/wp-cron.php, мы будем запускать скрипт и все просроченные публикации должны будут опубликоваться. Ручками мы это делать не будем, а зайдем в Панель управления нашего сайта, найдем, панельку с кроном, и пропишем вызов wp-cron.php один раз в час, два, три…, по желанию. Код выполнения примерно такой:
Можно не комментировать строчки, а вызывать скрипт wp-cron.php c параметром check.
Добавим временно перед вышеназванной строкой примерно вот это(Вам цифры надо поменять):
Набираем адрес _http://moisait.ru/wp-cron.php и видим значение хеша (ab2e68c22c68f2b872a1fa2df35b748a). В настройках cron пропишем адрес _http://moisait.ru/wp-cron.php?check=ab2e68c22c68f2b872a1fa2df35b748a. Это все для версий WordPress до 2.7.1, в 2.8.4. файл сron другой. Там в файле wp-cron.php уже нет такой проверки, поэтому его надо вызывать без параметров, добавив в системный cron: Можно использовать для этих целей онлайновые сервисы типа _WebCron.org(он уже платный) или бесплатный _http://www.onlinecronjobs.com, там по правилам на сервере надо держать пустой текстовой файл с определенным именем. Сервисов cron в интернете множество, поищите в Google.
Итак вводим кей, парсить пробуем _www.articlesbase.com, посты кидать в Draft, и жмем Go! Процесс пошел. Тут же вышло предупреждение, чтобы мы не паниковали, плагин работает в фоновом режиме, и если из за большого количества запросов не получим результат, надо нажать в браузере кнопку “Обновить” и процесс начнется там, где был прерван. Я специально взял ключевое слово, где явно должен быть результат. После первой попытке новых постов и комментов не наблюдалось. Нажал “Обновить”, плагин еще поработал 25минут, показал кучу логов и в конце концов загрузил 151 пост и 149 фото на заданную тему. Метки тоже создались.

Зарядил двусловный кей, не менее популярный plugin wordpress, количество запросов 950. Работа теперь прошла в три попытки. Результата нет. Попробовал зарядить просто plugin, изменил количество запросов до 50 против 950, для эксперимента много, долго ждать. Первая попытка неудачная хотя в логах все в норме:

Вторая попытка – 35минут, не дождался результата. Дальше у нас два варианта или поменять версию, так как много нареканий именно на последнюю 3.3.7 версию, как я понял, это касается в основном настройки Post source: со значением Article, а именно _www.articlesbase.com вроде блокирует попытки скачать содержание сайта. Кто то рекомендует каким то образом включить прокси для curl_setopt, кто то попытался таки с помощью CURL тянуть содержание с прокси-сервером, и результат пришел пустой. Чуствую или забанили или надо версию сменить.
Поменял версию на 3.3.5, загрузил, активировал, ввел email и пароль:

Плагин просит обновления:

В этой версии в настройках отсутствует пункт Change comment author names to link anchor text?
Зарядил тот же кеу ”plugin”, настройки в мозгах движка сохранились с прошлой установки те же, правда и результат тот же. Единственно в созданную плагином папку wp-content\uploads\cc\ загрузилось 50 напарсенных фотографий небольшого размера. Вторая попытка успешная, зарядилось 50 постов + еще 50 картинок. У многих постов не было заголовков, в конце каждого поста ссылка из файликов в папке links. Поставил чек на Auto approve added posts? и выбрал файл с линками. Зарядил ключевиком слово SEO, постов ноль, фотографий + 50. Нажал еще раз, не забыв опять прописать тот же кеу, все получилось – okey – много постов, внизу анкор с ссылкой из файла links.txt + еще фотографии. Все равно наблюдаются глюки. Поменял на другой вариант той же версии, вроде полностью рабочий. Настройки Post source: на Yahoo Answers, Max questions to add: 10, зарядил очень популярный двусловный кеу real estate. Результат сразу положительный, да еще и с комментами.

Поэкспериментировал с различными настройками и версиями плагина Caffeinated Content, выводы такие: основное условие, не перебарщивать с количеством кеев, чтобы не заработать временный бан. С публикацией в черновики вроде все понятно, залил на хост и жми себе периодически на кнопки, но это не совсем то, мы же добиваемся полной автоматизации, зарядил блог под завязку, к хостеру залил и забыл надолго. Более интересен вариант с временной публикацией по указанному нами расписанию(Scheduled). Теоретически тут тоже все ясно, залил на хост и посты себе публикуются по расписанию. На практике как я уже упоминал выше оказалось не так все гладко. Залил WordPress версии 2.7.1, а он отказывается публиковать по расписанию, и никакие танцы с бубном не помогли.

Что делать? Зарядил версию WordPress 2.7.1 на другой хост, результат тот же. Плохо…, берем версию 2.5.1, заливаем на второй хост, о чудо – заработало.

Делаю полную зарядку на основе 2.5.1, заливаю на первый хост, где не работала версия 2.7.1, почему то не могу зайти в админку – ошибка. Опять танцы с бубном вокруг .htacces, базы данных, заливка других файлов движка, ничего не помогает. Тут обнаружил в панели управления, при распаковке архива с файлами WordPress, что error_log, в течение каких то минут увеличился до 80mb. Вот часть лога
за 22 минуты 223 строки логов весом 37mb.
Катастрофа, хорошо, что вовремя увидел, иначе разборок с хостером бы не избежать. Вообще, это один из неприятных недостатков данного движка, разработчики никак не могут довести до ума работу псевдо крона, и отложенная публикация часто превращается в отложенную навсегда. Хорошо, если одна статья на sheduled, а если тысяча или две.
Ладно списал ошибку на то, что некорректно изменил базу данных перед заливкой на хост, ищу дальше пути выхода из ситуации. Совершенно случайно обнаруживал, что формат времени прописанный в базе для публикации отличается от дефолтного в движке(кто его трогает обычно).
Time Format g:i a или G:i a. Изменил, заработало расписание и для 2.5.1 и для 2.7.1. Радости, естественно полные штаны, но недолго.. Все равно WordPress делал, что хотел, такое впечатление что издевался, нельзя сказать, что не публиковал но и не всегда публиковал. И нельзя сказать, что не везде, потому что прямой зависимости от версии движка или конфига сервера не было. Надеюсь развязкой этой истории явилось то, что после долгих и мучительных поисков нашел плагин одного буржуина, который видно так проникся этой проблемой, что сотворил искомое чудо. Проверяю, вроде работает, но боюсь радоваться, чтобы не сглазить.
Решил проверить текст на уникальность. Для этого существуют онлайн сервисы и десктопные программы. Одна из них DCFinder – инструмент, который позволяет проверить содержимое сайта, текста на уникальность. Программа не новая, но ее возможностей достаточно. Для работы можно ввести проверяемый текст тремя способами – загрузить файл с текстом, указать интернет адрес проверяемой статьи, или добавить текст из буфера обмена. Естественно, чем больше текст, тем дольше поиск, много лучше не загружайте, лучше частями с разных участков статьи. Если ваш текст уникален, получаете текстовое сообщение, в обратном случае еще и список адресов, по которым расположены копии вашей статьи, в количестве до 50 штук. Проверил, текст не всегда уникален, иногда выдает совпадение в среднем по пяти – шести ссылкам. Выводы такие: плагин хороший, функции свои выполняет, а что касается уникальности текста, что ж, извините, чудес не бывает. Для уникализации контента добрые люди разработали плагины, некоторые из которых мы рассмотрим в последующих частях статьи, WordPress Uniquefier, который работает в связке с плагинами, дающими не уникальный контент, плагин синонимайзер под WordPress Simple Syn. Еще несколько платных плагинов – WP Robot, Autoblogged, WP Traffic, Auto paging mb, WP Limit Posts Automatically далее.

Продолжение следует.

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

В пятой части статьи мы продолжили изучение движка Wordpress, плагины редиректа, научились контролировать величину нагрузки, теперь же пришла очередь сервисов и плагинов статистики. Woopra, Google Analytics, CNStats, Wp-SlimStat, CyStats, StatPress Reloaded, неполный их перечень.
Пару слов о статистике. Любой вебмастер хочет знать статистику посещений своего сайта. Вещь необходимая, решений много, придется выбирать. Можно использовать сервисы специально предназначенные для отслеживания и обработки статистики, и на первый взгляд это самое правильное решение. Не используется своя база данных, нет лишней нагрузки на движок.

35. Woopra, Woopra Analytics Plugin.

Появилась недавно новая система статистики Woopra(http://www.woopra.com), уже ставшая популярной в западных подкастах. Заходим на страницу http://www.woopra.com/members/signup.jsp.

Заполняем все поля, переходим на другую страницу.

Здесь нам предлагают ввести код, который послали на наш емайл. В сообщении нам предлагают перейти по ссылке для подтверждения регистрации или вести определенный код на странице http://www.woopra.com/members/confirm.jsp. – это наша вторая страница. Я выбрал второй способ и меня кинули на следующую страницу.

После регистрации мы получим доступ для работы в системе в течении месяца.
Русского языка в интерфейсе пока нет, но установка очень простая, мы получаем код, который необходимо вставить на блог. Далее качаем программу, которую устанавливаем на компьютер и смотрим статистику в режиме реального времени. Очень много возможностей, есть поиск по данным статистики, есть раздел Live, где можно посмотреть кто сейчас на вашем блоге. Существует возможность чата с посетителями сайта, у пользователя появляется окошко и вы можете общаться. Есть настройка уведомлений. Создается уведомление, определяются условия, время срабатывания, и программка проинформирует нас об этом. Условий много – IP адрес, страна, город, страница, реферер, скачивание файла. Все это в режиме реального времени. Есть плагин для WordPress – Woopra Analytics Plugin, который установит код Woopra в наш блог.

36. Service Google Analytics, Plugin Google Analytics, Ultimate GA

Google не остался в стороне и создал Google Analytics – инструмент веб-аналитики. Эта служба позволяет оценить трафик на веб-сайт, т.е. позволит узнать сколько пользователей посетили ваш блог, сколько раз и откуда пришли на блог. Регистрируемся в системе Google Analytics. Заходим на страницу www.google.com/intl/ru_ALL/analytics.

Нажимаем кнопку регистрации. Попадаем на страницу www.google.com/intl/ru_ALL/analytics/sign_up.html. Если у Вас есть аккаунт Google и Вы сейчас в нем, появится такое окошко:

Если вы вышли из аккаунта, или у Вас его нет такое:

Соответственно, в любом случае нам нужен аккаунт Google т.е. регистрация в почте gmail.com. Вводим данные аккаунта и попадаем на страницу google.com/analytics/provision/, где в левом нижнем углу нас приглашают к процессу регистрации.

Проходим три этапа, заполняем адрес вашего сайта, временной пояс, регион, фамилию имя, телефон, соглашаемся с TERMS OF SERVICE. Последняя страница содержит код, который мы поместим на блог.

Базовая установка такая: Скопируйте и вставьте этот фрагмент кода в конец содержания, непосредственно перед тегом на каждой странице, которую нужно отслеживать. Если вы пользуетесь общим включением или шаблоном, код можно вставить туда. На нашем движке вставляем код отслеживания на страницу index.php или default.php, index.cfm. Вместо UA-xxxxxx-x, естественно наш код. После добавления кода Google Analytics начнет собирать данные о трафике. Данные появятся в отчетах в течение 24 часов. Чтобы не устанавливать счетчик вручную используем плагин google-analytics-for-wordpress или Ultimate Google Analytics. Эти плагины позволяет легко добавить код вашего счетчика Google Analytics. Активируем плагин и на странице настроек плагина вводим полученный код. После установки одного из этих плагинов, в меню Setting появится соответственно пункт Google Analytics или Ultimate GA, кликнув по которому мы попадем на страницу настроек плагина. Счетчик установлен. Теперь вы можете просматривать посещаемость нашего блога на странице www.google.com/analytics/settings.
Все рассмотренные сервисы очень удобные, но во первых, опять как с Akismet получается что все наши данные на постороннем сервере, что не очень хорошо, а потом вдруг сервис упадет, или вообще прекратит работу. А движок Wordpress, кстати очень хорошо приспособлен для ведения собственной статистики трафика. Существует много плагинов предназначенных для отслеживания траффика Wordpress-блога.

37. CNStats

Мой первый опыт, отдельный скипт – CNStats. Монстр конечно, таблиц в базе данных больше чем у Wordpress, более 50 базовых отчетов доступных через веб-интерфейс. На выделенном сервере CNStats обрабатывает 150 тысяч показов в сутки, не создавая существенной нагрузки. Установка скрипта с помощью инсталлятора. Для установки в общую базу данных CNStats имеет свой префикс для названий таблиц. Программа платная, при установке надо ввести полученный при покупке регистрационный ключ в соответствующее поле на странице регистрации. Кроме того надо вручную разместить на странице блога код сбора статистики и код счетчика. Для входа в систему выбираем язык интерфейса и вводим логин и пароль, указанные при установке системы, CNStats использует cookies для авторизации. В последних версиях Wordpress работает стабильно.

38. Wp-SlimStat

Следующий мой вариант – плагин Wp-SlimStat. Рассмотрим его установку. Загрузим файлы и активируем его. При установке плагина прописывается wp_slim_countries и wp_slim_stats в базе данных. Набираем http://localhost/Tools/phpmyadmin/index.php, выбираем нашу базу данных и проверяем наличие таблиц. Из файла wp-slimstat.csv из папки плагина данные IP-to-Country вписываются в таблицу. Мне известны две версии 0.9.2 и 0.9.4. Отличаются они не только одной буквой – slimstat 0.9.4 уже вроде и не плагин а отдельный скрипт – загружается в корень блога, а не в папку с плагинами и админка вызывается отдельным урлом. Версия 0.9.2 активируется обычным образом и появляется кнопка в Dashboard – панели объявлений. Там мы можем нажать на соответствующую кнопку и посмотреть данные статистики.

Как видите данных статистики пока нет. При желании можно вывести картинку с ссылкой на разработчика. Плагин генерирует две свои таблицы в базу данных.

39. mySTAT

Очень красивый плагин плагин, представитель отечественного плагиностроения mySTAT.

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

Для уменьшения веса базы данных в этом и других плагинах надо в настройках сократить количество дней сохранения статистики. Работает вплоть до версии Wordpress 2.8.4. У меня на локалхосте на версии Wordpress 6.5.2 и 2.7.1 был небольшой баг – не показывало картинку с графикой, но поменяв версию плагина 2.3 на 2.2 все стало в норму. На хосте в версии Wordpress 2.8.4 картинка не появилась, а плагин версии 2.2 вызвал фатальную ошибку. Обратился к автору, он сказал: “С картинкой баг мне уже известен, в версии 2.4 будет исправлен”. Я у него же спросил насчет вывода счетчика посещений на страницу блога. Оказывается, для того, чтобы вывести счетчик, надо зайти в Appearance (Внешний вид) – Widgets (виджеты) и кнопкой Add добавить виджет myStat statistics в какой то из сайдбаров.

40. CyStats

Еще один красивый и очень подробный, профессионального уровня плагин – CyStats. Очень много таблиц и графиков. Можно отслеживать статистику посещений на блоге имеющем несколько авторов. Есть и недостатки. Для определения географической принадлежности не используютс сервисы WHOIS, что не очень удобно. Очень достойный плагин, достойный всяческого внимания. Присмотритесь к нему, может это Ваш выбор. Первая страница CyStats Index:

Вторая Blog:

Третья CyStats Clients:

Четвертая CyStats Referer:

Пятая страница CyStats Robots & Tools:

Шестая страница CyStats Pages:

Седьмая CyStats Time:

Восьмая и последняя CyStats Options:

Плагин при установке создает по умолчанию в базе данных 2 таблицы

причем, что очень удобно, при деактивировании плагина, в нижней части страницы настройки – CyStats Options внизу ставим чеки на:
Delete all database data: Delete all data stored in database including options
Delete live database table: Delete all visits data stored in database
Delete static database table: Delete all static long term data stored in database
Do you really want this?, и удаляем все таблицы из базы данных.

41. StatPress Reloaded

Я пока остановился на плагине StatPress Reloaded.
Очень много положительного, эргономика, достаточно много отчётов, работает надежно, что немаловажно. Единственный недостаток – не очень “правильный” WHOIS-сервис из за чего, говорят, иногда ошибается в определении географической принадлежности некоторых IP. При установке в базу данных добавляется только одна таблица “wp_statpress”, а в админке в разделе StatPress появляется восемь кнопок:
StatPress – StatPress(Обзор)

StatPress – Details (Подробно) Нажимаем StatPress – StatPress и попадаем на страницу Overview, где смотрим статистику.

StatPress – Spy (Шпион).

StatPress – Search (Поиск)

StatPress – Export (Экспорт)

StatPress – Options (Настройки)

StatPress – User Agents(Браузеры посетителей)

StatPress – StatPressUpdate(Обновление StatPress)

Для вывода счетчика посещений на страницу заходим Внешний вид – Виджеты,

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

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

Чтобы данные выстроились в колонку применим <br>.
Visits today: %visits%<br>
Total visits: %totalvisits%<br>
Top: %toppost%
Доступные коды: %totalvisits% %visits% %thistotalvisits% %os% %browser% %ip% %since% %visitorsonline% %usersonline% %toppost% %topbrowser% %topos%. Кроме того можно применить виджет StatPress TopPosts. Его тоже перетягиваем из левой в правую колонку, редактируем заголовок, количество результатов, позицию в сайдбаре. Вначале я активировал русскую версию StatPress Reloaded 1.5.5 ru, затем автоматом обновил ее на локалхосте до последней версии statpress-reloaded.1.5.21. В результате у нас получился statpress-reloaded.1.5.21 ru, правда появилось несколько ошибок в переводе.
В подвале страницы настроек плагина Overview показаны некоторые данные.
Очень удобно то, что контролируется объем своей таблицы базы данных.

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

В предыдущей, четвертой части статьи мы изучили как устанавливаются и работают SEO плагины, а в этой части продолжим тему меток в плагине WordPress Related Posts, изучим плагины редиректа, RC Link Redirector, Link Cloaking Plugin, Wp-affiliate, WordPress Affiliate Pro, Alinks, WP-NoExternalLinks, для контроля нагрузки движка Wordpress подключим плагин Wptuner. Для чего нам изучать так много плагинов, их ведь их тысячи – все не перепробуешь? А для того, чтобы хоть из этого мизерного количества которое мы рассмотрим, выбрать наиболее подходящий для своего блога. Ведь не все из них работают так, как хотелось бы. Поэтому мы и тренируемся на локальном компьютере, подключаем, тестируем, и только после этого переносим сборку с выбранными плагинами на хост.

24. WordPress Related Posts.

Если Вы отказались от плагина Simple Tags, но понимаете смысл и ценность функции “Метки Родственных Записей”, есть альтернатива – плагин WordPress Related Posts, плагин вывода схожих тем для выбранной записи. Потребляет он очень мало ресурсов и кода на страницу вставляет ну совсем чуть чуть. Функцией плагина является создание списка “Связанных Записей”, как и в Simle Tags, так что просмотрите возможности плагина Simle Tags, и если эта функция будет основной или единственной, то есть для вывода меток/тегов, прописываия метатегов и пр., Вы найдете альтернативный метод – смело ставьте WordPress Related Posts. Количество знаков внедренного этим плагином кода на страницу, по сравнению с Simle Tags с даже отключенной функцией “Active auto link tags into post content”, все равно на пару тысяч меньше. Настройки плагина следующие:

Заголовок “Похожие записи” – пишем заголовок. Если нет похожих записей, то отображать: В выпадающем списке: Текст ‘Нет похожих записей’, Случайные записи, Наиболее комментируемые записи. Ниже заполняем графы Текст ‘Нет похожих записей’, Количество похожих записей. Ставим чеки: Автоматически вставить список вконце поста, Показывать в RSS, Показывать количество комментариев, Показывать дату публикации.
У этого плагина есть кое какие недоработки. Дело в том, что для определения релевантности записей во внимание берутся только ключевые слова в заголовках статей. В результате понижается эффективность плагина, т.е. он показывает не всегда верные результаты. Конечно можно очень тщательно прописывать названия статей, для решения этой проблемы. А вот некий автор, взяв за основу оригинал, создал более усовершенствованный вариант плагина Related Posts. Здесь схожесть постов определяется уже по нескольким параметрам – заголовок статьи, содержание ее, название рубрики. Для работы этого плагина необходимо добавить дополнительную таблицу в базу данных MySQL. Сделать это можно двумя способами:
1. Кликаем внизу страницы на ссылку “this script”. Если получена ошибка “Sorry, you must be at least a level user.” надо закомментировать 20-ю и 21-ю строки плагина:
//if ($user_level)
//die (”Sorry, you must be at least a level user.”); // Make sure that user has sufficient priveleges
2. Набираем http://localhost/Tools/phpMyAdmin/, слева в выпадающем списке находим нашу базу, далее на странице с базой вверху нажимаем MySQL, в полученное поле вбиваем

и жмем Пошел.

Таким образом мы импортируем в базу данных нужную таблицу с помощью MySQL запроса.
Для вывода списка релевантных записей на страницу, прописываем в шаблоне следующий код: <?php related_posts(); ?>

Plugins – Related Posts Options:How many related posts would you like to show? – сколько постов отображать в списке. Before / After (Post Title) – html-код до и после заголовка поста. Show excerpt? – показывать ли анонс поста. Excerpt length (No. of words) – длина анонса (количество слов). Before / After (Excerpt) – html-код до и после анонса поста. Show password protected posts? – отображать ли защищенные паролем посты.
Можно кое что изменить в настройках плагина путем правки кода. Заходим Theme – Edit или, кому удобно, открываем в текстовом редакторе или еще лучше в программе PHP Edin/// файлик related-posts.php, находим строчки:

Настраиваем вес ключевых слов в указанных элементах. Параметр ‘name’ => 2, имеет смысл менять, если в ссылках постов имеются ключевые слова, на английском языке. Сочетание слов подбирайте экспериментально. Можно править список стоп слов:
Причем мы можем ввести сюда и русские слова.
Ну чтож, залил я плагин, активировал, кликнул по “this script”, получил сообщение:

Просмотрел базу данных, но почему то не нашел новой таблицы.

Сделал запрос MySQL, получил ответ.
Ответ MySQL:
#1061 – Duplicate key name ‘post_related’. Я так и не понял прописались данные или нет. Вписал код <?php related_posts(); ?> в шаблон, но получил “No related posts”. На этом эксперимент с ним закончил, а жаль. У кого получится откомментируйтесь пожалуйста.
Еще по теме SEO.

25. WP-Cumulus

Я тут хотел уделить внимание еще парочке плагинов – WP-Cumulus, это красивое облако тегов в флэш варианте и плагин социальных закладок Давида Асатряна bookmarkz, но вовремя заглянул в исходный код страницы своего блога, помните мои слова про просмотр исходного кода нашей страницы. Так вот, когда я заглянул в исходный код одной из страниц блога после установки вышеуказанных плагинов мне представилась такая картина: Общее количество знаков на странице при установленных плагинах – 73000. Из них WP-Cumulus 13600, bookmarkz 17600. После деактивации плагинов страница со статьей весила 40600. Впечатляет? Очень жалко было удалять WP-Cumulus. Красивый плагин, да и теги полезную роль играют. Роль Bookmarkz, как инструмента социальных закладок в плане результативности и полезности и так спорная, а тут еще эти 1700 кода. Понятно, что нам с этими плагинами не по пути, по крайней мере я их не буду ставить.
Часть кода

Ни для кого не является секретом, что ссылки в SEO играют очень большую роль. Часто их надо прятать ото всех. Рефкоды — от людей, которые считают что процент, получаемый за их учебу, снимают с них, внешние ссылки — от поисковиков, экономля PR с наших страниц, говнокомменты и.т.д, и.т.п. Кроме того иногда нужно добавить target=’_blank’, rel=’nofollow’ и <noindex>, отменять обработку ссылок, используя для этого “белый список”. Плагинов для этого несколько.

26. Link Cloaking Plugin

Первым я попробовал Link Cloaking Plugin. У него настройки в двух местах Settings Link->Cloaking->Link Cloaking и Tools->Cloaking Cloaked Links->Static Cloaked Links.

В базе данных появилась новая запись:

Перед установкой плагинов такого рода, т.е связанных с навигацией, обязательно сделайте копию .htaccess для контроля. Ссылки получаются вида http://localhost/wp_2.7.1/Link Prefix/Ankor/1/2. У меня на локалхосте правда, даже при добавлении в список ссылок из блогролла, они не закрывались кодом.

27. RC Link Redirector

Неплохой плагин RC Link Redirector Роланда Чанишвили. Здесь одна страница настроек RC Plugins->RC Link RedirectorRC->Link Redirector. Он сочетает массу возможностей – закрывает ссылки от индексирования, поддерживает белые списки для статических ссылок и CSS шаблоны для динамических. Ссылки вида http://localhost/wp_2.7.1/Базовая ссылка/W0BHSVtJG0SUEwHUEYHVUVTQ==/. Значение Базовой ссылки указываем в настройках. Интересная функция “Если текст ссылки сам является ссылкой то заменять его на текст”, выбираете подходящее слово и все Ваши http://blabla.bla будут с анкором.

Плагин работает четко.

28. (J)ExR

Еще один плагин по преобразованию внешних ссылок во внутренние – это (J)ExR. Он состоит из одного файла, есть страница настройки, где Вы очень легко разберетесь. Проставляем чеки, где необходимо, вводим идентификатор редиректа, добавляем кнопкой или вручную в файл robots.txt

и наслаждаемся ссылками вида http://localhost/wp_2.7.1/go/aHR0cDovL2dvb2dsZS5jb20=.
Плагин в базу данных дополнительных таблиц не добавляет.

29. Wp-affiliate

Wp-affiliate – еще один плагин, который скрывает ссылки, и делает их локальными. Задача та же – скрыть реферальную ссылку от посетителя. На странице настроек можно включить статистику переходов по вашим ссылкам и указать свой ID в системе CJ.com.

Если Вы не практикуете сиджи и у Вас ID нет, пропустите этот момент. Настройка плагина в админке, на странице Edit Posts в разделе нужной записи нажмите Edit и увидите на странице редакции поста окошко “WP-Affiliate Links”. Оно появилось после того как Вы активировали плагин.

Вводим название в поле “Название категории” и жмем кнопку “Добавить базовую категорию”. В разделе “Список ссылок по категориям” жмем “Добавить ссылку” где заполняем поля “Ссылка в блоге”, “Текст анкора” и “Добавить ссылку”. Вставим курсор то место в редакторе, куда надо поместить ссылку, и в окошке “WP-Affiliate Links” жмем “Отправить ссылку в редактор”. Код ссылки размещается в нужном месте и в браузере будет виден анкор.Таким образом мы создали базовую категорию для ссылок под любым названием, и добавили ссылку для сокрытия. Анкор – это видимый текст ссылки, как правило – ключевое слово. При наведении на анкор мы видим локальную ссылку вида http://localhost/wp_2.7.1/ankor, при клике переходим по внешней ссылке. Однажды созданная ссылка будет работать во всем блоге. Будьте внимательны, лучше не включайте статистику – потом если надумаете удалить какую либо ссылку, постоянно будете получать ошибки. Если наплодите ссылок и затем деактивируете плагин, клик по аффилиатской ссылке будет кидать Вас на ту страницу откуда кликнули.

30. WordPress Affiliate Pro

Подключил плагин WordPress Affiliate Pro.
Settings->WordPress Affiliate Pro->Configure WordPress Affiliate Pro. Здесь общие настройки плагина, можно оставить по умолчанию.

Tools->WordPress Affiliate Pro->Manage WordPress Affiliate Pro Links. Тут настройка ваших ключевых слов и партнерских ссылок.

Add New Keyword – Добавить новое ключевое слово. Keyword that will be replaced by the affiliate link – Ключевое слово, которое будет заменено на партнерскую ссылку. Affiliate Link (enter the complete affiliate link here, including the http:// part): Партнерская ссылка (введите полную партнерскую ссылку здесь, в том числе в части http://). Statusbar Text (leave empty to show the click tracker URL, your affiliate link is always hidden): Текст состояния (оставьте пустыми, ваша партнерская ссылка всегда скрыта). Maximum Replacement Count (how many occurences of this keyword will be replaced on a page, 0 means replace all. If not 0, this will be used instead of the global setting): Максимальная замена граф (0 означает замену всех. Если не 0, то это будет использоваться вместо глобальных настроек, не понимаете – не трогайте). Keyword Weight for the weighted random link selection. This should be between 0 and 9 (leave unchanged if you don’t know what this means): Вес ключевого слова для взвешенного выбора случайной ссылке. Это должно быть в диапазоне от 0 до 9 (значение по умолчанию оставьте без изменений, если вы не знаете, что это означает). Ключевое слово было успешно сохранено.

Как это не смешно, основную функцию мы уже получили. Если мы напечатаем в тексте поста слово BLOGINFORAMA или BLOGINFORAMA 1 в нашем частном случае, при публикации мы получим это слово анкором к ссылке вида http://localhost/wp_2.7.1/wp-content/plugins/wp-affiliate-pro.php?id=1. или http://localhost/wp_2.7.1/wp-content/plugins/wp-affiliate-pro.php?id=2., которая нас кинет на http://bloginf.com. и соответственно на http://bloginf.com/seo/wordpress1.html. Плагин платный, с триальным сроком три месяца, но у меня срок работы вроде бы не ограничен по “некоторым причинам”, сколько реально проработает не знаю, не проверял. Плагин добавляет две таблицы в базу данных.

31. Alinks

Поставил плагин Alinks, связывающий наши сообщения по фразам, ссылки на которые мы устанавливаем в настройках. Плагин сделает ссылку на конкретное сообщение, ссылка на тег или другой сайт. Кроме того в настройках может быть иконка около ссылки, открытие в новом окне, чувствительность к регистру и пр. Заходим в админку ставим фразу “bla” и урл www .moisite.com. Теперь на всех страницах блога фраза “bla” автоматически превращается в урл. Вот скринсшоты:

Версия alinks1.0rc2 добавляется в базу данных одну таблицу.

Версия alinks2.0.2 от mikolka добавляет две.

Честно говоря я не вник во все, как я подозреваю, мощные возможности этого чуда. Весит он больше двух мебагйт, подробный Help, куча настроек, а что он такого особенного делает не знаю. Кого заинтересует, думаю разберется. Мне по вышеописанной функции, фраза – урл, больше по душе WordPress Affiliate Pro, всего один файлик, а работу выполняет. Wp-affiliate у меня на локалхосте работал хорошо, WordPress Affiliate Pro и (J)ExR Link тоже, а вот Cloaking Plugin редиректил на страницу 404. Победил в нашем случае RC Link Redirector который я и подключил. Он работал без сбоев на локалхосте и на хостинге тоже неплохо работает, правда недостатком такого рода плагинов можно назвать то, что они именно шифруют ссылки, то есть по идее можно обманным способом заманить пользователя на сайт с вредоносным содержанием и неизвестно, как к этому отнесется поисковик. Конечно для разных задач разные плагины.

32. WP-NoExternalLinks

Альтернативным решением можно назвать применение плагина WP-NoExternalLinks. Он позволяет на лету заменять все внешние ссылки на внутренние – в постах, комментариях, профилях комментариев. Плагин не меняет ничего в базе – просто делает замену на выводе. Его можно настроить, чтобы он работал с постами, комменариями и профилями комментариев. Применяется способ маскировки через mod rewrite и получаются при этом ссылки вида localhost/goto?mywordpress.ru.

Настройки плагина: Путь к файлу с редиректом, или к редиректу методом mod rewrite. Маскировка ссылок в своих постах. Маскировка ссылок в комментариях. Маскировка ссылок в указанном при комментарии профиле. Добавление атрибута rel=nofollow(для Гугла). Добавление атрибута target=_blank (открытие внешних ссылок на новой странце). Добавление тега <noindex>. Окошко для урлов исключений. Плагин хороший, свои функции выполняет, единственно почему то у меня в блоглролле ссылки не закрыл.

33. Customize Meta Widget

Для того, чтобы убрать внешнюю ссылку на WordPress.org в виджете Meta – это стандартный виджет, где Site Admin, Log out, Valid XHTML, RSS, WordPress, говорят нужно владеть специальными знаниями так как убрать ее не так просто. Сам виджет не лишний, так как с его помощью удобней входить в блог с любой страницы а не набирать специально адрес страницы входа http://moi-blog.com/wp-admin.

Можно поставить плагин Customize Meta Widget. Жмем Appearance – Widgets и переносим виджет Meta на сайдбар. Настроек никаких нет, у меня почему то он убирал не только ссылку, но и остальные виджеты. Если Вас очень раздражают внешние ссылки, например в блогролле, я покажу очень простой способ сделать это. Правда ручками. Допустим вот блогролл в дефолтном шаблоне. Как видите ссылок достаточно.

Набираем http://localhost/Tools/phpmyadmin, и выбираем в левой панельке нашу базу данных. Находим таблицу wp-links.

Жмем кнопку обзор.

И получаем наши линки.

Тут мы можем отметить чеками ссылки, редактировать или удалить отмеченные.

А вот ссылки в виджете Meta хранятся не базе данных движка, а в шаблоне. Например в дефолтном шаблоне в файлике sidebar.php, в 69 – 71 строчке. Вообще удалять эти ссылки или нет дело вашей совести, я показал как, а дальше вы сами..

33.1. Total_disable_updates

Вы, наверное слышали о том, что Wordpress тяжелый движок, что он сильно грузит сервер. Один из способов снизить нагрузку – уменьшить количество запросов движка. Немало запросов при проверке обновлений ядра и плагинов. Посмотрите в админке, ведь даже неактивированные плагины проверяют наличие новых версий, тем самым уменьшая скорость работы. Есть плагины, которые на первый взгляд блокируют проверку, но оказывается они не уменьшают нагрузку, а только скрывают напоминание о новых версиях. Другое дело плагин известного блоггера lecactus, который при включении отрубает все запросы на обновления. Если надпись в админке – напоминание о обновлении так и останется, не обращайте внимание, посылка запросов прекратится и восстановится только в том случае, если Вы по какой то причине отключите плагин. Функциональность вроде бы пострадала, но зато нагрузка на сервер уменьшилась. Раньше автор рекомендовал вручную внести изменения в файл wp-includes/update.php. Там надо было закомменитровать (перед строкой пишем значек #, строка станет неактивной) следующие строки:

а теперь он предложил плагин – это его первый опыт, рекомендую ставить.
Если у Вас русскоязычный сайт и вы используете движок в переводе lecactus, существенный прирост в скорости работы сайта, можно обеспечить используя различные языковые файлы для админки блога и “морды“ блога, то есть уменьшив количество вызовов этих строк.(автор Максим – maxsite.org). Для этого заменим в файле wp-config.php в корне блога строки:
на
Скачаем файлик “ru_RU_lite.mo” для различных версий на странице автора: lecactus.ru/2008/11/15/3110/. Поместим файл в папку /wp-includes/languages/. В результате на моем блоге потребление памяти уменьшилось на 22%. Отличное снижение нагрузки, не правда ли? Alex рекомендует переименовать файлы ru_RU в ru_RU_full, а файлы ru_RU_lite в ru_RU, видоизменив строку включения русской локализации в файле
Вообще нелишне будет освоить методы визуального контроля нагрузки нашего движка на сервер, и следить за ее динамикой в причинной зависимости от подключенных плагинов, тем, русификации и пр. Для визуального контроля добавим в код файла footer.php: В подвале появится новая строчка примерно такого содержания: где первая цифра – количество запросов к базе MySQL, вторая время запроса, третья – потребляемая при этом память в мегабайтах. И каждый раз, подключая очередной плагин, мы можем проконтролировать по счетчикам какую он добавляет нагрузку, и стоит ли его ставить.

34. Wptuner.

Если Вы хотите полную статистику в деталях, подключите плагин Wptuner. Он Вас проинформирует насколько шустрая или наоборот глючная стоит тема, насколько прожорливы установленные плагины, как работает движок, сколько он потребляет ресурсов и какие запросы по скорости, какие файлы, как быстро обрабатываются и пр. И опять нас выручает lecactus, который перевел плагин и выложил по адресу: hppp://lecactus.ru/wp-content/uploads/0000/00/20081115_wptuner_ru_ru.zip Он же пояснил так: чтобы плагин активировался корректно, Вам нужно установить права 666 на файл wp-config.php и права 777 на корневую папку блога, чтобы там создался резервный файл “wp-config.WPTunerOrig.php”. После активации плагина в целях безопасности надо вернуть права назад. Когда я сделал это на сервере(у хостера, не на денвере), у wp-config.php права поменялись без проблем, а поменяв права доступа на 777 у public_html получил ошибку сервера. Поменял на 755 сработало без проблем, т.е. сгенерировался файл wp-config.WPTunerOrig.php, чего мы и добивались. На локалхосте все эти заморочки с правами доступа естественно не нужны. Для тех, кто не еще знает, здесь мы работаем с виндовским сервером, где не надо проставлять права – эти примочки, прерогатива Юникса(про права доступа в 7-й части статьи). Для админа в футере блога появится окошко информации. Пользователи его вообще не увидят, админ же в зависимости от настроек в расширенном или сокращенном виде. Предыдущий код из футера, который мы прописали ручками, надо убрать. В админке все настройки можно оставить по умолчанию, если есть желание поиграйтесь с кнопками.
Сверху вниз: Предустановки. Восстановить значения по умолчанию. Минимально. (Это в футере и в подвале админки вид информационного окошка, его видит только админ). Ошибки и предупреждения. Анализировать время. Поиск медленных элементов. (Закрашивается желтым). Основная для разработчиков. Показывать все.
Изменения надо сохранить. Хороший плагин, нужный плагин, но… Опять вспомнил золотое правило, посмотрел исходный код, скопировал его, загрузил в Notepad++. Страница состоит из 50000 знаков, из них 8888 приходится на код WPTuner, т.е. для сохранения нужной пропорции служебного кода и контента, чтобы угодить поисковому роботу нам надо ощутимо добавить контента. Вывод – не обращать внимания, или отладить блог с помощью WPTuner, затем отключить плагин и вставить код, который не добавляет мусора на страницу – это тот, который мы рассмотрели первым.
Продолжение следует.
Автор Stepan Demin. Использование и копирование статьи РАЗРЕШАЕТСЯ с указанием автора и ссылки на первоисточник BlogInforama