Еще один способ обойтись без cron’a

Зачастую при размещении сателлитов нет смысла использовать платный хостинг, так как в свете нынешних алгоритмов Яндекса сателлиты долго не живут. В Интернете много бесплатных хостингов с поддержкой php и многими другими полезными функциями. Но в большинстве случаев на них нет cron'a. Это обстоятельство мешает публиковать запланированные записи в CMS типа Wordpress. Чтобы обойти отсутствие cron'a используют либо сервисы веб-крона (например, WebCron.org), либо используют заходы посетителей на сайт для активации псевдокрона.

Есть еще один способ с использованием отсылки опубликованных записей на емэйл и публикации запланированных записей на бесплатных блогосервисах. Из блогосервисов выберем blogger.com (blogspot.com) как один из наиболее известных и вполне нам подходящий.

Итак, в чем суть.

1. На блогспоте создаем блог и наполняем его записями с будущими датами публикаций, напротив этих записей появится отметка «запланированный».
2. На нашем блоге Wordpress на другом бесплатном хостинге настраиваем публикацию записей по электронной почте.
3. Емэйл, полученный на шаге два для Wordpress'a вписываем на блогспоте в «Настройки» → «Электронная почта и мобильные устройства» → «Уведомления по электронной почте. Адрес BlogSend»

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

Создание своей сборки Wordpress. Предустановочная настройка. Install.php

Теперь перейдем к работе с файлом wp-admin\install.php. В нем можно задать все те же настройки по умолчанию, что и в файле wp-admin\includes\schema.php не трогая при этом файл schema.php.

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

Например, эквивалент команды add_option('permalink_structure', '/%category%/%postname%.htm'); в schema.php, реализованный через install.php будет состоять из 9 строк с использованием семи переменных и нескольких вордпрессовских функций.

Использование файла wp-admin\install.php обычно обусловлено незнанием синтаксиса некоторых параметров в файле schema.php, так как документации по этому синтаксису практически нет. Я, например, не нашел в интернете как активировать плагины через файл schema.php, а в немногих найденных сборках предустановочная активация плагинов осуществлялась только через wp-admin\install.php. Так что, возможно, что я первый кто обнаружил, как активировать плагины через schema.php.

Рассмотрим предустановочную активацию параметров через install.php на примере активации плагинов.

Первый способ. Плагины активируются на локальном сервере (например, denwer'e). В таблице options на локальном сервере находим поле с option_name равном active_plugins и копируем оттуда значение сериализованного массива. Для активированных плагинов из примера, приведенного в посте о schema.php, такой сериализованный массив будет выглядеть так:

a:3:{i:0;s:14:"rus-to-lat.php";i:1;s:16:"russian-date.php";i:2;s:34:"wp-contact-form/wp-contactform.php";}

Экранируем в этом сериализованном массиве двойные кавычки косой чертой (вот так - \") и помещаем полученную строку в SQL запрос вида

$wpdb->query("UPDATE ".$table_prefix."options SET option_value = 'вот тут и помещаем сериализованный массив' WHERE option_name = 'active_plugins'");

получаем запрос вида

$wpdb->query("UPDATE ".$table_prefix."options SET option_value = ' a:3:{i:0;s:14:\"rus-to-lat.php\";i:1;s:16:\"russian-date.php\";i:2;s:34:\"wp-contact-form/wp-contactform.php\";}
' WHERE option_name = 'active_plugins'");

Этот запрос размещаем в файле wp-admin\install.php после следующих строк:

$wpdb->show_errors();
$result = wp_install($weblog_title, 'admin', $admin_email, $public);
extract($result, EXTR_SKIP);

Всё, теперь нужные плагины будут активированы непосредственно при установке.

Второй способ. Предварительная активация плагинов в базе данных не требуется и сериализованный массив нам тоже не нужен. Способ сложнее, так как требует знания внутренних функций Wordpress'а – одним запросом к базе данных не обойдешься. В файл wp-admin\install.php после строки

<p><?php printf(__('WordPress has been installed. Were you expecting more steps? Sorry to disappoint.'), ''); ?></p>

вставляется следующий код (плагины взяты из предыдущего примера):

<?php
$current = array("rus-to-lat.php", "russian-date.php", "wp-contact-form/wp-contactform.php");
foreach($current as $plugin) {
do_action('activate_' . $plugin);
}
update_option('active_plugins', $current);
?>

Массив $current в вышеприведенном коде можно инициализировать и в виде:

$current[] = "wp-contact-form/wp-contactform.php";
$current[] = "rus-to-lat.php";
$current[] = "russian-date.php";

на работоспособности кода это не отражается.

Как видим, активация параметров через файл wp-admin\install.php вместо wp-admin\includes\schema.php никаких преимуществ не дает, а только приводит к усложнению кода.

Создание своей сборки Wordpress. Предустановочная настройка. Schema.php

За активацию тех или иных настроек в файле schema.php отвечает функция populate_options(). Находите место инициализации этой функции (т. е. строку function populate_options() ) и в теле функции увидите перечень конкретный настроек. Для версий Wordpress'a 2.6.*, 2.7.* этот перечень будет выглядеть примерно так:

add_option('siteurl', $guessurl);
add_option('blogname', __('My Blog'));
add_option('blogdescription', __('Just another WordPress weblog'));
add_option('users_can_register', 0);
add_option('admin_email', 'you@example.com');

и так далее,

а для версий Wordpress'a, начиная с 2.8, будет выглядеть вот так:

$options = array(
'siteurl' => $guessurl,
'blogname' => __('My Blog'),
'blogdescription' => __('Just another WordPress weblog'),
'users_can_register' => 0,
'admin_email' => 'you@example.com',

и так далее. Если перевести название опций с английского языка, то всё становится более или менее понятным. Например 'blogdescription' переводится как «описание блога». Следовательно, если в schema.php в теле функции populate_options() вставить строку

add_option(' blogdescription ', 'My Splendid Blog'); или строку

' blogdescription ' => 'My Splendid Blog',

соответственно версии Wordpress'а

то у всех ваших блогов будет описание «My Splendid Blog».

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

Параметр вида add_option('blogname', 'Wonderful Blog'); вообще не будет работать, ни в варианте с латинскими буквами, ни в варианте с кириллицей, так как требует ввода названия блога с клавиатуры. Можно заставить работать и этот вариант, но он требует редактирования не только файла schema.php. Подробнее на этом останавливаться не будем.

Параметр, устанавливающий адрес постов в виде их названия, работает без нареканий и выглядит так:

add_option('permalink_structure', '/%postname%/');

или так:

'permalink_structure' => '/%postname%/', .

Все прочие параметры, требующие в качестве параметра одну-единственную константу, числовую или строковую, также нормально работают при задании этих параметров в файле schema.php

Иногда в параметре настройки надо задать несколько значений. Делается это по-разному для каждой конкретной настройки.

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

add_option('active_plugins', array("rus-to-lat.php", "russian-date.php", "wp-contact-form/wp-contactform.php"));

или так:

'active_plugins' => array("rus-to-lat.php", "russian-date.php", "wp-contact-form/wp-contactform.php"),

В массив можно вписать любое количество активируемых плагинов. Обратите внимание, что если плагин располагается в собственной папке, то кроме запускающего файла плагина надо прописать и папку, - "wp-contact-form/wp-contactform.php".

А вот для параметра ping_sites запись будет выглядеть точно так же как и в базе данных, т. е. отдельные пинг-сервисы будут отделяться друг от друга переводом строки (клавиша Enter). То есть будут выглядеть так:

add_option('ping_sites', 'http://rpc.pingomatic.com/
http://bg.ping.com/
http://c.gomatic.com/');

или так:

'ping_sites' => 'http://rpc.pingomatic.com/
http://bg.ping.com/
http://c.gomatic.com/',

Судя по рекомендациям в интернете, список пинг-сервисов можно также отделять пробелом или экранированным переводом строки (эскейп-последовательностью – \n). Эти варианты я не проверял, поскольку вариант с разделением Enter'ом вполне нормально работает.

Создание своей сборки Wordpress. Предустановочная настройка.

Предустановочная настройка Wordpress'а – это изменение некоторых файлов сборки с тем, чтобы после установки Wordpress'а определенные функции были бы уже включены и не требовалось бы лезть в админку, чтобы их включать. Обычно предустановочная настройка сводится к активации ряда плагинов, но может включать в себя активацию и других функций.

Все настройки Wordpress'а хранятся в базе данных, в таблице options. Поэтому для того, чтобы активировать эти настройки непосредственно при установке, необходимо выполнение ряда запросов к базе данных, а сами эти запросы прописать в специальных файлах. Таких файлов в Wordpress'е два: 1. wp-admin\install.php и 2. wp-admin\includes\schema.php.
Собственно говоря, для записи предустановочных настроек предназначен только файл wp-admin\includes\schema.php, который содержит в себе весь перечень настроек Wordpress'a, которым присвоено некоторое значение по умолчанию или не присвоено никакого значение. Поэтому достаточно вписать нужное значение и соответствующая функция будет работать сразу же по завершению установки сайта. Файл wp-admin\install.php изначально не предназначен для записи предустановочных настроек и поэтому списка настроек, подобного тому, что имеется в файле wp-admin\includes\schema.php в нем нет. Что же касается использования файла wp-admin\install.php, то по своим результатам оно ничем не отличается от использования файла wp-admin\includes\schema.php, за исключением того, что приходится использовать полный синтаксис запросов к базе данных, что требует определенной квалификации.

Надо заметить, что значение конкретной настройки в большинстве случаев должны быть записаны именно так, как это значение выглядит в таблице базы данных, особенно при использовании файла install.php.

Поэтому прежде чем начинать вписывать в файл значения конкретных настроек своей сборки надо сборку установить на локальный сервер (например, denwer) активировать все необходимые настройки и плагины, а затем уже из конкретных таблицах базы данных копировать эти значения в запрос к базе данных, размещаемый в файле install.php.

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

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