Отдельная база данных по ежегодному архиву WordPress

У меня есть большая база данных блог-постов, я уже экспортировал ее по годам и хотел бы сделать архив по годам на субдомене, например 2012.mysite.com. Я застрял в поисках решения в интернете и интересуюсь, не делал ли кто-то это раньше? И может ли кто-то посоветовать мне хорошее решение? Все, что я хотел, это разделить на другую базу данных по годам для архивирования.

У меня есть знания в PHP и MYSQL.

Недавно мне это понадобилось для клиента (он хотел сделать то же самое, но иметь возможность самостоятельно создавать архив в бэкенде WordPress) и я не смог найти хорошее плагин для этого. На самом деле, это довольно легко закодировать самостоятельно. Вам просто нужно сделать установку сетевой, а затем разместить пользовательский install.php в папке wp-content, чтобы переопределить функцию wp_install_defaults(). В этой функции вам просто нужно написать несколько SQL-запросов, которые перенесут контент с одного сайта на другой.

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

<?php

function wp_install_defaults($user_id) {
    global $wpdb, $table_prefix;

    // Мы позже очистим таблицу опций, эти опции мы хотим сохранить, поэтому мы извлекаем их здесь.
    $options = array('siteurl', 'blogname', 'blog_description', 'home');
    $options = dlx_archive::getOptions($options, $table_prefix);

    $wpdb->query("TRUNCATE {$table_prefix}options");

    // Также изменим таблицу термина (установка плагина будет подключена позже, но мы не можем перенести сейчас, если схема таблицы не синхронизирована).
    $wpdb->query("ALTER TABLE {$table_prefix}terms ADD `avhec_term_order` INT( 4 ) NULL DEFAULT '0'");

    $tables = array(
                'terms',
                'term_taxonomy',
                'term_relationships',
                'posts',
                'postmeta',
                'avhec_category_groups',
                'options'
                );

    // Это синхронизирует данные между основным блогом и архивом.
    dlx_archive::copyData($tables, $wpdb->base_prefix , $table_prefix);

    // Записываем опции обратно в таблицу.
    dlx_archive::writeOptions($options, $table_prefix);

    // Удаляем все посты из основного блога (исключение категории epaper (терм 18).
    $wpdb->query("DELETE {$wpdb->base_prefix}posts FROM {$wpdb->base_prefix}posts
                LEFT JOIN {$wpdb->base_prefix}term_relationships wptr ON wptr.`object_id` = {$wpdb->base_prefix}posts.`ID` 
                WHERE {$wpdb->base_prefix}posts.post_type="post"
                AND wptr.term_taxonomy_id != 18");

    // Мы только что импортировали новые настройки постоянных ссылок в таблицу wp_options, теперь сбросим правила перенаписи.
    flush_rewrite_rules();

}

class dlx_archive {

    static function copyData(array $tables, $source_prefix, $target_prefix) {

        global $wpdb;

        foreach($tables as $table) {
                $sql = "INSERT " . $target_prefix . $table . " SELECT * FROM " . $source_prefix . $table;
                $wpdb->query($sql);
        }
    }

    static function getOptions($array, $table_prefix) {

        foreach($array as $option) {
            $options[$option] = self::getOptionValueFromDB($option, $table_prefix);
        }

        return $options;
    }

    static function getOptionValueFromDB($key, $table_prefix) {

        global $wpdb;

        $option = $wpdb->get_row("SELECT * FROM {$table_prefix}options WHERE option_name="{$key}"");

        return $option->option_value;
    }

    static function writeOptions($options, $table_prefix) {

        global $wpdb;

        foreach($options as $key => $val) {
                $sql = "UPDATE {$table_prefix}options SET option_value="{$val}" WHERE option_name="{$key}"";
                $wpdb->query($sql);
        }
    }
}

Если у вас установлено много плагинов, вам также нужно будет позаботиться о пользовательских таблицах по отдельности. У меня был установлен только один плагин (нужно было изменить avhec_term_order).

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

С точки зрения производительности MySQL не справляется с большими таблицами, нет никакой выгоды в использовании совершенно отдельной базы данных. По моему опыту, достаточно использовать отдельные таблицы. Но если по какой-то причине вы действительно хотите иметь отдельную базу данных (вышеупомянутое решение основано только на таблицах, так как именно так работает WPMU), вы можете взглянуть на HyperDB.