アクションとフィルター — WP STAGING をカスタマイズする

By , Founder · Updated

開発者は、利用可能なアクションとフィルターを使って WP STAGING を調整できます。この記事では、現在のフックを文書化し、Backup・クローン・Push プロセスをニーズに合わせてカスタマイズする使用例を紹介します。

フックとフィルターを使用するには、別の Plugin である WP STAGING Hooks をインストールするか、このページのフックとフィルターを mu-plugin 内で使用することをお勧めします。
そうしないと、すべてのアクションが期待どおりに動作しない可能性があります。

このページのほとんどのフィルターは、WP STAGING Pro プランのいずれかを必要とします。

WP STAGING Hooks Plugin

この記事で言及されている多くのフィルターを含む WP STAGING hooks Plugin をダウンロードして、サイトで簡単に使用できます。

注: この記事で言及されているすべてのフィルターが GitHub リポジトリに含まれているわけではありません。

このページに記載されているフィルターが WP STAGING hooks Plugin に含まれていない場合、このページの該当コードを新しい mu-plugin か、wp-content/plugins/wp-staging-optimizer.php にある WP STAGING の mu-plugin などの既存のものにコピーできます。

サイトで mu-plugin を作成する方法は「mu-plugin の作成方法」をご覧ください。

完全なコードを mu-plugin の先頭にコピーし、ニーズに合わせて調整してください。サポートが必要な場合はお知らせください。

Contents

無制限のメモリ使用を許可する

WP STAGING は最大メモリ消費を 256M に制限しており、これは通常クローンや Backup プロセスに十分です。このプロセスの間、他のすべての Plugin は無効化されますが、これはサイトの他のページには影響しません。

WP STAGING を正常に実行するには通常 256M のメモリ上限で十分です。WP_MEMORY_LIMIT や PHP の最大メモリ上限を 512M を超えて設定することはお勧めしません。これを超える設定は、いずれかの Plugin の問題か、有効化されている Plugin が多すぎることを示す可能性があるためです。メモリ上限は PHP プロセスごとに関連付けられるため、これらの上限を超えることは推奨されません。すべての WordPress リクエストに対して大きな許容メモリ消費を設定すると、マシンの使用可能メモリがすぐに埋まり、サイトが利用不能になる可能性があります。

ただし、256M の制限を超える必要がある場合は、WP STAGING のメモリ上限を無効化できます。正当な理由があり、サーバーに十分なメモリが利用可能でない限り、これは推奨されないことに注意してください。

メモリ上限を無効化するには、用意されているフィルターを使って WP STAGING に無制限のメモリ消費を許可します。この場合の唯一の制限は PHP の最大メモリ上限です。

PHP
add_filter('wpstg.resources.ignoreMemoryLimit', function() {
  return true;
});

ログインフォームの WP STAGING ロゴを変更する (Pro 版)

下のコードを使って、Staging サイトのログインフォームのロゴを変更できます:

PHP
add_filter('wpstg_login_form_logo', function(){
  return 'https://example.com/path/to/custom/image.png';
});

WP STAGING のリクエスト時間と PHP の最大実行時間を増やす

通常、WP STAGING の Backup と Restore は小規模な Web ホストでも動作します。巨大なデータベースや数百万行を持つサイトの場合、デフォルトの PHP 実行時間制限である 30 秒では低すぎる可能性があります。Backup の作成・Restore を動作させるには、php.ini で PHP 値 max_execution_time= 120 を設定してください。

また、Apache の値 Timeout 120 を増やすか、Nginx ディレクティブ fastcgi_read_timeout 120; を設定してください。

これを行った後、下のフィルターを mu-plugin/wp-staging-optimizer.php のような mu-plugin に追加してください。

PHP
​add_filter('wpstg.resources.executionTimeLimit', function(){
    return 100;
});

入力値が実際の PHP 最大許容実行時間よりも小さいことを確認してください。これは、WP STAGING のリクエスト時間が PHP の実行時間を絶対に超えないようにするために必要です。

Staging サイトのタイトルを変更する

PHP
function wpstg_get_title(){
   return 'DEV';
}
add_filter('wpstg_staging_site_title', 'wpstg_get_title');

キャッシュフォルダへのパスを変更する

一時的な Backup ファイルの保存に使用するフォルダをグローバル PHP の temp フォルダや別の場所に変更するには、下のコードを使えます:

PHP
​add_filter('wpstg.directory.cacheDirectory', function(){
        return trailingslashit(sys_get_temp_dir()) . 'wpstagingcache';​
​});

テーブルを検索置換操作から除外する

検索置換処理が利用可能メモリの多くを消費し、クローンや Push がメモリ枯渇エラーで失敗する場合に使用してください。クローンや Push の速度を改善するためにも使えます。

リンクの検索置換を必要としないテーブルを除外してください。これらは訪問者の統計、IP アドレス、または類似のものを含むテーブルです。それらのテーブルを除外した後、WP STAGING 設定の DB 検索置換の上限をより高い値に増やしてパフォーマンスを向上できます。

PHP
function wpstg_searchreplace_excl_tables($default){
    $tables = array('_posts', '_postmeta'); 
    return array_merge($default, $tables);
}
add_filter('wpstg_searchreplace_excl_tables','wpstg_searchreplace_excl_tables');

エンコードされたデータベース値のカスタム検索置換

このフィルターを使って、データベース内で base64 エンコードされているデータ (ページビルダーや複雑な Plugin 設定でよく使われる) に対して検索置換操作を実行します。これにより、クローン・Push・Restore 処理中にエンコード形式で保存された URL や他の文字列が正しく更新されることを保証します。

// Replace URLs inside base64-encoded database values during cloning/pushing/restore.
add_filter('wpstg.database.searchreplace.replace_extended_data', function ($data, $search, $replace) {
    $plain = base64_decode($data, true);
    if ($plain === false) {
        return $data;
    }

    $replaced = str_replace($search, $replace, $plain);
    if ($replaced === $plain) {
        return $data;
    }

    return base64_encode($replaced);
}, 10, 3);

このフィルターを使えば、WP STAGING が自動で処理できないあらゆる種類のカスタムデータをデータベース内で置換できます。

別の例: 一部の Plugin は URL や他の値を平文ではなくエンコードされた JSON 文字列の中に保存します。一般的な例は base64 エンコードされたプロパティ値を含む JSON です。

これらの場合、WP STAGING の通常の検索置換では元の URL を検出できません。エンコードされた値の中に隠れているためです。

このようなケースに対応するため、WP STAGING は次のフィルターを提供しています:

wpstg.database.searchreplace.replace_extended_data

このフィルターを使うと、開発者は通常の検索置換が実行された後にデータベースの列値を変更できます。

次の処理中に使用できます:

  • クローン
  • Staging から本番への Push
  • Backup の Restore

このフィルターはいつ使用すべきか

Plugin や Theme が次のような形式でデータを保存している場合にこのフィルターを使用してください:

  • base64 エンコードされた値を持つ JSON
  • エンコードされた文字列を含むネストされた JSON 構造
  • URL が平文として保存されないカスタムデータ形式

このフィルターがないと、エンコードされた値の中の URL は変更されないままになります。

フィルターパラメータ

このフィルターは 3 つのパラメータを受け取ります:

パラメータ型説明
$datastring通常の検索置換後のデータベース列の値
$searcharray検索文字列
$replacearray置換文字列

基本的な考え方

コールバックでは次のことができます:

  1. データベースの値を調査する
  2. エンコードされたデータが含まれているかどうかを検出する
  3. 値をデコードする
  4. 検索配列と置換配列で str_replace() を実行する
  5. 値を再エンコードする
  6. 変更後の結果を返す

期待される形式と一致しない場合は、そのまま返してください。

例: base64 エンコードされた JSON 値内での検索置換

次の mu-plugin の例は、プロパティが base64 エンコードされている JSON 値内の URL を置換する方法を示しています。

次のファイルを作成します:

wp-content/mu-plugins/wpstg-base64-search-replace.php

このコードを追加します:

<?php

/**
 * Decode base64-encoded values inside JSON database columns during
 * WP Staging search/replace so that URLs within them are replaced.
 */
add_filter('wpstg.database.searchreplace.replace_extended_data', function ($data, $search, $replace) {
    // Only process JSON-looking data
    if (empty($data) || ($data[0] !== '[' && $data[0] !== '{')) {
        return $data;
    }

    $decoded = json_decode($data, false);
    if (json_last_error() !== JSON_ERROR_NONE) {
        return $data;
    }

    $changed = false;

    // Recursively walk JSON to find base64-encoded string values at any depth
    $walk = function ($node) use (&$walk, &$changed, $search, $replace) {
        if (is_array($node)) {
            foreach ($node as $item) {
                $walk($item);
            }

            return;
        }

        if (!is_object($node)) {
            return;
        }

        foreach ($node as $key => $value) {
            if (is_array($value) || is_object($value)) {
                $walk($value);
                continue;
            }

            if (!is_string($value) || $value === '') {
                continue;
            }

            $plain = base64_decode($value, true);
            if ($plain === false) {
                continue;
            }

            $replaced = str_replace($search, $replace, $plain);
            if ($replaced !== $plain) {
                $node->$key = base64_encode($replaced);
                $changed = true;
            }
        }
    };

    $walk($decoded);

    return $changed ? wp_json_encode($decoded) : $data;
}, 10, 3);

この例の仕組み

この例は次のことを行います:

  1. データベースの値が JSON らしいかどうかを確認します。
  2. JSON をデコードします。
  3. ネストされたすべての配列とオブジェクトを再帰的に走査します。
  4. 各文字列の値を base64 デコードしてみます。
  5. デコードされた内容に対して WP STAGING の検索置換値を実行します。
  6. 変更があった場合、変更後の値を再び base64 エンコードします。
  7. 更新された JSON 文字列を返します。

サンプルデータ

Plugin がデータベースに次を保存していると想像してください:

{
  "title": "Example",
  "url": "aHR0cHM6Ly9vbGQtc2l0ZS5jb20vcGFnZQ=="
}

url の値は base64 エンコードされています。デコードすると次が含まれています:

https://old-site.com/page

WP STAGING のクローン・Push・Restore 中、通常の検索置換ではエンコードされているためその URL を直接見ることはできません。

上のフィルターを使うと、WP STAGING は次の動作を行います:

  • 値をデコードします
  • https://old-site.com を https://new-site.com に置換します
  • 再びエンコードします
  • 更新された値をデータベースに保存し直します

結果

フィルター実行後、保存されている値は次の base64 エンコードバージョンになります:

https://new-site.com/page

このコードはどこに配置すべきか

最も安全な選択肢は、リクエストごとに自動的に読み込まれるように mu-plugin に配置することです。

推奨パス:

wp-content/mu-plugins/wpstg-base64-search-replace.php

mu-plugins ディレクトリがまだ存在しない場合は、手動で作成してください。

重要な注記

  • このフィルターは、デフォルトの検索置換では処理されないカスタムデータベース形式用です。
  • コールバックは、期待される形式と一致しない場合、常に元の $data をそのまま返す必要があります。
  • 無関係なデータを変更しないように、ロジックはできるだけ具体的に保ってください。
  • 本番データで使用する前に、まず Staging サイトでテストしてください。

まとめ

URL や他の値がエンコードされたデータベースコンテンツの中に隠れている場合は、wpstg.database.searchreplace.replace_extended_data を使用してください。

これは特に、次の形式で値を保存する Plugin に役立ちます:

  • base64 エンコードされた JSON
  • ネストされた JSON オブジェクト
  • 他のカスタムエンコード形式

これにより、これらの値をデコード・置換・再保存する方法を開発者が完全に制御できます。

クローン・Staging フィルター

クローン後に Staging サイトでアクションを実行する

下の例は、Staging サイトが初めて開かれたときに SQL クエリを実行します:

PHP
add_action('wpstg.clone_first_run', 'wpstg_execute_after_cloning', 10);

function wpstg_execute_after_cloning() {
   
global $wpdb;

$sql = "DELETE * FROM wpstg0_tablename WHERE ....";

$wpdb->query($sql);
}

このクエリは Staging サイトのみ、Staging サイトでのみ実行されますが、念のため、例のように特定の Staging プレフィックスを含むテーブル名をハードコードして、誤って本番サイトで実行されてしまった場合でも本番サイトで害を及ぼすことがないようにすることをお勧めします。

このアクションにあらゆる種類のコードを追加でき、新しい Staging サイトを最初に開いたときに 1 回だけ実行されます。

クローン後に Staging サイトで特定の Plugin を有効化・無効化する

クローン後に Staging サイトで一部の Plugin を有効化または無効化するには、次のようにフィルター wpstg.cloning.update_active_plugins を使用します:

PHP
php
function wpstg_cloning_update_active_plugins($currentActivePlugins) {
// snippet to deactivate
$pluginsToDeactivate = array('plugin1-basename', 'plugin2-basename');
foreach ($pluginsToDeactivate as $pluginToDeactivate) {
  $key = array_search($pluginToDeactivate, $currentActivePlugins, true);
  if (false !== $key) {
    unset($currentActivePlugins[$key]);
  }
}

// snippet to activate
$pluginsToEnable      = array('plugin3-basename');
$currentActivePlugins = array_merge($currentActivePlugins, $pluginsToEnable);

return $currentActivePlugins;

}
add_filter('wpstg.cloning.update_active_plugins','wpstg_cloning_update_active_plugins');

wp_options の検索置換から行を除外する

PHP
function wpstg_clone_searchreplace_excl_rows($default){
   $rows = array('siteurl', 'home'); 
    return array_merge($default, $rows);

add_filter('wpstg_clone_searchreplace_excl_rows','wpstg_clone_searchreplace_excl_rows');

クローンから行を除外する

この例では、option name に応じて wp_options テーブルの行を除外したり、post_title と post_status とそれらの post メタデータに基づいて wp_posts テーブルから投稿を除外したりします。

使用可能な演算子は次のとおりです:

['=', '>', '>=', '<', '<=', '<>', '!=', 'LIKE', 'NOT LIKE']

PHP
function queryCloningRows($filters) {
	$filters = [
// Clone only options where option_name is not 'wpstg_is_staging_site'
		'wp_options' => [
			'option_name' => [
				'operator' => '<>',
				'value' => 'wpstg_is_staging_site'
			]
		],
// Clone only posts where post_title LIKE 'Hello%' AND post_status = 'publish'
		'wp_posts' => [
			'post_title' => [
				'operator' => 'LIKE',
				'value' => 'Hello%'
			],
			'post_status' => 'publish'
		],
// will filter postmeta depending upon filtered data in wp_posts, see above wp_posts filter
    'wp_postmeta' => [
			'join' => [
				'table' => 'wp_posts',
				'primaryKey' => 'ID',
				'foreignKey' => 'post_id',
			]
		]
	];
	
	return $filters;
}

add_filter('wpstg.cloning.database.queryRows', 'queryCloningRows');

クローンからカスタム投稿タイプを除外する

この例では、カスタム投稿タイプ「coupon」の投稿とその postmeta データも除外します:

使用可能な演算子は次のとおりです:

['=', '>', '>=', '<', '<=', '<>', '!=', 'LIKE', 'NOT LIKE']

PHP
function queryCloningRows($filters) {
	$myFilters = [
// Clone only posts which do not belong to post_type coupon
		'wp_posts' => [
			'post_type' => [
				'operator' => '<>',
				'value' => 'coupon'
			]
		],
// will filter postmeta depending upon filtered data in wp_posts, see above wp_posts filter
    'wp_postmeta' => [
			'join' => [
				'table' => 'wp_posts',
				'primaryKey' => 'ID',
				'foreignKey' => 'post_id',
			]
		]
	];
	
// will filter postmeta depending upon filtered data in wp_posts, see above wp_posts filter
    'wp_postmeta' => [
			'join' => [
				'table' => 'wp_posts',
				'primaryKey' => 'ID',
				'foreignKey' => 'post_id',
			]
		]
	];

	return array_merge($filters, $myFilters);
}

add_filter('wpstg.cloning.database.queryRows', 'queryCloningRows');

文字列を検索置換から除外する

PHP
function wpstg_clone_searchreplace_excl(){
    return array('blog.localhost.com','blog1.localhost.com');
}
add_filter('wpstg_clone_searchreplace_excl','wpstg_clone_searchreplace_excl');

検索置換パラメータを変更する

PHP
function wpstg_cloning_custom_params($args){
      // Default values - Can be changed
      $args['search_for'] = array_merge(
         $args['search_for'],
         array('SEARCHSTRING', 'SEARCHSTRING')
         );
         
     $args['replace_with'] = array_merge(
         $args['replace_with'],
         array('REPLACESTRING','REPLACESTRING2')
       );
       
      $args['replace_guids'] = 'off'; 
      $args['dry_run'] = 'off'; 
      $args['case_insensitive'] = false;
      $args['replace_guids'] = 'off';
      $args['replace_mails'] = 'off';
      $args['skip_transients'] = 'on';
      
      return $args;
}
add_filter('wpstg_clone_searchreplace_params', 'wpstg_cloning_custom_params');

ファイルを除外する

PHP
/**
* Cloning: Exclude files from cloning
* Example: You can use a wildcard pattern like *.log to exclude all log files
*/
function wpstg_clone_excluded_file_names($default)
{
    $files = array('custom-file', '*LOG-*', '*.logs');
    return array_merge($default, $files);
}
add_filter('wpstg_clone_excluded_files', 'wpstg_clone_excluded_file_names');

フルパスでクローンからファイルを除外する

デフォルトでは、WP STAGING は Staging サイトの作成時に次のファイルをコピーから除外します:

  • .htaccess
  • Absolute/path/to/WordPress/directory/wp-content/db.php
  • Absolute/path/to/WordPress/directory/wp-content/object-cache.php
  • Absolute/path/to/WordPress/directory/wp-content/advanced-cache.php

下のフィルターを使って、この動作を変更し、除外ファイルのリストを変更できます:

PHP
/**
* Exclude files from cloning using full path 
*/
function wpstg_clone_excluded_files_full_path($default)
{
    $files = ['full/path/custom-file1', 'full/path/custom-file2']; 
    return array_merge($default, $files);
}
add_filter('wpstg.clone.excluded_files_full_path','wpstg_clone_excluded_files_full_path');

フォルダを除外する

PHP
/**
* Excluded folders relative to the wp-content folder 
*/
function wpstg_exclude_folders_custom($args){
     $folders = array('plugins/wordpress-seo', 'custom-folder');
     return array_merge($args, $folders);
}
add_filter('wpstg_clone_excl_folders', 'wpstg_exclude_folders_custom');

マルチサイト: マルチサイトのクローン時にフォルダ (Plugin) を除外する

マルチサイトネットワークを使用している場合は、フィルター `wpstg_clone_mu_excl_folders` を使って wp-content フォルダからの相対パスでフォルダを除外できます。これは Plugin を除外したい場合に役立ちます。

PHP
**
* Excluded folders relative to the wp-content folder
*/
function wpstg_exclude_folders_custom($args){
   $folders = array('plugins/wordpress-seo', 'themes/custom-folder');
   return array_merge($args, $folders);
}
add_filter('wpstg_clone_mu_excl_folders', 'wpstg_exclude_folders_custom');

wp_options テーブルのオプション内でテーブルプレフィックスの検索置換を防ぐ

デフォルトでは、WP STAGING はすべてのテーブルをクローンし、新しいデータベースのテーブルプレフィックスで始まる値を置換します。クローン中に変更されないように、この置換操作からオプションを除外できます:

PHP
function wpstg_excl_option_name_custom($args){
     $cols = array('wp_mail_smtp', 'wp_mail_smtp_version');
     return array_merge($args, $cols);
}
add_filter('wpstg_data_excl_rows', 'wpstg_excl_option_name_custom');

ネットワークマルチサイトをクローンして移行先のホスト名を変更する

WP STAGING はカスタムドメインベースのマルチサイトをサポートしています。ネットワークサイトは、指定したメインサイトのサブドメインに自動的に作成されます。

例:

メインサイト example.com と、ネットワークサブサイト example.org、そしてもう 1 つ example.net があるネットワークサイトがあるとします:

ネットワーク全体を staging.example.com にクローンすると、ネットワークサイトは次のようにクローンされます:

  • staging.example.org
  • staging.example.net

下のフィルターを使って各サイトを調整できます。これはサブドメインベース・サブディレクトリベース・ドメインベースのサブサイトのいずれでも使用できる汎用フィルターです。

PHP
// Convert staging site with ID 2 to dev.example.com
add_filter('wpstg.cloning.multisite.subsite_info', function ($subsiteInfo, $blogId, $stagingSiteURL, $addWWWPrefix) {

if ($blogId === 2) {
    $subsiteInfo['domain'] = 'dev.example.com';
    $subsiteInfo['path']   = '/';
    $subsiteInfo['url']    = 'https://dev.example.com';
}

return $subsiteInfo;
}, 10, 4);

データベース内の「upload_path」値を保持する

古い WordPress ネットワークサイトでは、upload_path が変更されないように保持する必要があるかもしれません。これを実現するにはこのフィルターを使用してください:

PHP
add_filter('wpstg.cloning.preserve_upload_path',  '__return_true');

Push フィルター

Staging サイトの Push 後に本番サイトで特定の Plugin を有効化・無効化する

Staging サイトを Push した後に本番サイトで一部の Plugin を有効化または無効化するには、次のようにフィルター wpstg.pushing.update_active_plugins を使用します:

PHP
function wpstg_pushing_update_active_plugins($currentActivePlugins)
{
    // snippet to deactivate
    $pluginsToDeactivate = array('plugin1-basename', 'plugin2-basename');
    foreach ($pluginsToDeactivate as $pluginToDeactivate) {
        $key = array_search($pluginToDeactivate, $currentActivePlugins, true);
        if (false !== $key) {
            unset($currentActivePlugins[$key]);
        }
    }

    // snippet to activate
    $pluginsToEnable      = array('plugin3-basename');
    $currentActivePlugins = array_merge($currentActivePlugins, $pluginsToEnable);

    return $currentActivePlugins;
}
add_filter('wpstg.pushing.update_active_plugins','wpstg_pushing_update_active_plugins');

検索置換パラメータを変更する

PHP
function wpstg_push_custom_params($args){
      // Default values - Can be changed
         $args['search_for'] = array_merge(
         $args['search_for'],
         array('SEARCHSTRING', 'SEARCHSTRING2')
         );
         $args['replace_with'] = array_merge(
         $args['replace_with'],
         array('REPLACESTRING','REPLACESTRING2')
       );
      $args['replace_guids'] = 'off'; 
      $args['dry_run'] = 'off'; 
      $args['case_insensitive'] = false;
      $args['replace_guids'] = 'off';
      $args['replace_mails'] = 'off';
      $args['skip_transients'] = 'on';
      return $args;
}
add_filter('wpstg_push_searchreplace_params', 'wpstg_push_custom_params');

Push からテーブルを除外する

PHP
function wpstg_push_excluded_tables($tables){
    $customTables = ['options', 'posts']; 
    return array_merge($tables, $customTables);
}
add_filter('wpstg_push_excluded_tables','wpstg_push_excluded_tables');

注: コード内のテーブル名にはテーブルプレフィックスを含めないでください!

この例は、テーブル wp_posts と wp_options を本番サイトへの Push から除外します。

Push から行を除外する。特定の行のみをコピーする

この例では、option name に応じて wp_options テーブルから特定の行を除外したり、post_title と post_status に基づいて wp_posts テーブルから投稿を除外したりして、postmeta データも除外します。

使用可能な演算子は次のとおりです:

['=', '>', '>=', '<', '<=', '<>', '!=', 'LIKE', 'NOT LIKE']

注意: テーブルプレフィックスは、実際の Staging サイトのテーブルプレフィックスに応じて wpstg0_、wpstg1_、wpstg3 などである必要があるため、wpstg[int]_ を実際のプレフィックスに置き換える必要があります。

PHP
function queryPushingRows($filters) {
	$filters = [
		// will only push options where option_name is not 'wpstg_is_staging_site'
		'wpstg0_options' => [
			'option_name' => [
				'operator' => '<>',
				'value' => 'wpstg_is_staging_site'
			]
		],
		// will only push posts where post_title LIKE 'Hello%' AND post_status = 'publish'
		'wpstg0_posts' => [
			'post_title' => [
				'operator' => 'LIKE',
				'value' => 'Hello%'
			],
			'post_status' => 'publish'
		],
    // will filter postmeta depending upon filtered data in wp_posts, see above wp_posts filter
    'wpstg0_postmeta' => [
			'join' => [
				'table' => 'wpstg0_posts',
				'primaryKey' => 'ID',
				'foreignKey' => 'post_id',
			]
		]
	];
	
	return $filters;
}

add_filter('wpstg.pushing.database.queryRows', 'queryPushingRows');

注: これらの投稿タイプを除外すると、Staging サイトを本番にコピーした後、これらの投稿タイプは本番サイトで利用できなくなり、含まれなくなります。

Push から特定の投稿タイプを除外する

この例では、カスタム投稿タイプ「coupon」の投稿とその postmeta データも除外します:

使用可能な演算子は次のとおりです:

['=', '>', '>=', '<', '<=', '<>', '!=', 'LIKE', 'NOT LIKE']

注意: テーブルプレフィックスは、実際の Staging サイトのテーブルプレフィックスに応じて wpstg0_、wpstg1_、wpstg3 などである必要があるため、wpstg0_ を実際のプレフィックスに置き換える必要があります。

PHP
function queryPushingRows($filters) {
	$myFilters = [
		// Push only posts where post_type is not 'coupon'
		'wpstg0_posts' => [
			'post_type' => [
				'operator' => '<>',
				'value' => 'coupon'
			]
		],
    // will push postmeta depending upon filtered data in wp_posts, see above wp_posts filter
    'wpstg0_postmeta' => [
			'join' => [
				'table' => 'wpstg0_posts',
				'primaryKey' => 'ID',
				'foreignKey' => 'post_id',
			]
		]
	];

	return array_merge($filters, $myFilters);
}

add_filter('wpstg.pushing.database.queryRows', 'queryPushingRows');

Push からフォルダを除外する

デフォルトでは、WP STAGING PRO は次のフォルダを反復処理せず、本番サイトに Push もしません:

  • cache
  • wps-hide-login
  • node_modules
  • nbproject
  • wp-staging

下のフィルターを使って、このリストにカスタムフォルダを追加できます:

PHP
function wpstg_push_directories_excl($default){
    $dirs = array('custom-folder', 'custom-folder2'); 
    return array_merge($default, $dirs);
}
add_filter('wpstg.push_excluded_directories', 'wpstg_push_directories_excl');

Push からファイルを除外する

デフォルトでは、WP STAGING PRO は次のファイルを本番サイトに Push しません:

  • .htaccess
  • .DS_Store
  • .git
  • .svn
  • .tmp
  • desktop.ini
  • .gitignore
  • .log
  • wp-staging-optimizer.php

下のフィルターを使って、このリストにカスタムファイルを追加できます:

PHP
function wpstg_push_excluded_files($default){
    $files = array('custom-file', 'custom-file2'); 
    return array_merge($default, $files);
}
add_filter('wpstg_push_excluded_files','wpstg_push_excluded_files');

wp_options のデータを保持して Push から除外する

データを保持するとは、Staging サイトを本番サイトに Push しながら、Push 処理中に特定のデータが上書きされるのを防ぐことを意味します。

下の例は、本番サイトの wp_options テーブル内の WordPress オプション ‘siteurl’ と ‘home’ の値を保持します。

追加のオプションをいくつでも追加できます。

PHP
function wpstg_push_preserve_options($options){
       $preserveOptions = ['siteurl', 'home'];
       return array_merge($options, $preserveOptions );
}
add_filter('wpstg_preserved_options','wpstg_push_preserve_options');

例: Push 後に WPML ライセンスキーを保持する方法

このコードを mu-plugin ファイルとして使用できます:

PHP
<?php
/*
Plugin Name: mu-plugin to keep the WPML license of the live site
Description: After you push the staging site to the live site, the live site's WPML license won't change
Version: 1.0
Author: WPSTAGING
*/

function wpstg_push_preserve_options($options){
    $preserveOptions = ['wp_installer_settings'];
    return array_merge($options, $preserveOptions );
}
add_filter('wpstg_preserved_options','wpstg_push_preserve_options');

本番サイトへの Push 後にアクションを実行する

このフックを使うと、Staging サイトを本番に Push した後に本番サイトでメソッドを呼び出せます。

PHP
function pushingComplete()
{
// do something
}
add_action( 'wpstg_pushing_complete', 'pushingComplete' );

Backup フィルター

フルマルチサイトを別のマルチサイトに Restore (移行)

フルマルチサイトネットワークから Backup を作成し、別の既存マルチサイトに Backup を Restore したい場合 (例えばマルチサイトを別のサーバーにコピーする場合)、運用しているマルチサイトの種類に応じていくつか考慮すべき点があります。詳細とその操作で使用する特定のフィルターについてはこの記事をお読みください。

マルチサイトネットワークサイトを別のマルチサイトネットワークに Restore (移行)

Backup の Restore 時にクリーンアップから除外する (uploads ディレクトリ内の) パス (ファイルまたはディレクトリ) の配列を受け取ります。使用例:

PHP
add_filter('wpstg.backup.restore.exclude_media_during_cleanup', function ($pathsToExclude) {
    $pathsToExclude[] = '/full/path/to/a/directory';
    $pathsToExclude[] = '/full/path/to/a/file';
    return $pathsToExclude;
});

デフォルトでは、WP STAGING はネットワークサブサイトで Backup を Restore する際、元のコンテンツ (language フォルダ、mu-plugins、Plugin、Theme、メディア以外のファイル) を保持します。既存のコンテンツを保持する代わりに、これらのフィルターを使って置き換えることができます:

PHP
add_filter('wpstg.backup.restore.replace_existing_languages', '__return_true');
add_filter('wpstg.backup.restore.replace_existing_mu_plugins', '__return_true');
add_filter('wpstg.backup.restore.replace_existing_other_files', '__return_true');
add_filter('wpstg.backup.restore.replace_existing_plugins', '__return_true');
add_filter('wpstg.backup.restore.replace_existing_themes', '__return_true');

検索置換を拡張してデータベース内のすべてのサブサイトの URL を変更する

デフォルトでは、Backup の Restore 処理を高速化するために、現在のサイトに属する URL のみが置換されます。マルチサイトで、ネットワーク内の他のサイトの URL を含む場合、フィルターを使ってこれらの URL も置換できます。サイト数が多いほど、すべてのサイト URL の置換に時間がかかることに注意してください。

PHP
add_filter('wpstg.multisite.full_search_replace', '__return_true');

Backup からファイル拡張子を除外する

特定のファイル拡張子を Backup のエクスポートから除外できるようにします。

PHP
function wpstg_backup_files_ignore_extensions($default_excluded){
    return array_merge($default_excluded, ['zip', 'gz']);
}
add_filter( 'wpstg.export.files.ignore.file_extension', 'wpstg_backup_files_ignore_extensions');

特定のファイルサイズより大きいファイルを Backup から除外する

デフォルトでは、WP STAGING は 200MB より大きいファイルを Backup への追加からスキップします。下のフィルターを使ってその値を増やせます:

PHP
function wpstg_backup_files_ignore_files_bigger_than($default){
    return 200 * MB_IN_BYTES;
}

add_filter( 'wpstg.export.files.ignore.file_bigger_than', 'wpstg_backup_files_ignore_files_bigger_than');

特定の拡張子で特定のファイルサイズより大きいファイルを Backup から除外する

デフォルトでは、WP STAGING は 50MB より大きい zip ファイルを Backup への追加からスキップします。下のフィルターを使って、拡張子ごとに個別にこれを変更できます:

PHP
function wpstg_backup_files_ignore_files_w_extension_bigger_than($default){
$ignoreFiles = [
    'gz' => 100 * MB_IN_BYTES, 
    'tar' => 200 * MB_IN_BYTES,
    'zip' => 200 * MB_IN_BYTES
];
return array_merge($default, $ignoreFiles);
}

add_filter( 'wpstg.export.files.ignore.file_extension_bigger_than', 'wpstg_backup_files_ignore_files_w_extension_bigger_than');

ディレクトリを Backup に含めないように除外する

PHP
function wpstg_backup_exclude_directories($excludedDirectories){
        $customExcludedDirectories = [
            'var/www/example.com/htdocs/wp-content/cache'
        ];
        return array_merge($excludedDirectories, $customExcludedDirectories);
    }

add_filter( 'wpstg.backup.exclude.directories', 'wpstg_backup_exclude_directories');

Restore からファイルを除外する

このフィルターは、Backup の Restore からファイルまたはフォルダ全体を除外します。WordPress インストールのルートからの相対パスの配列を渡すことができ、Backup の Restore プロセスを開始したとき、それらのファイルやフォルダは Backup から抽出されません。

PHP
/**
 * Backup: Exclude files or folders from being restored.
 * If path is a folder, the entire folder including all contained files and subfolders will be excluded from backup restoration.
 */
function wpstg_backup_restore_exclude_paths($excludedFiles)
{
    $customExcludedFiles = [
        ABSPATH . 'documents', // a path
        ABSPATH . 'wp-content/share', // a path inside parent folder
        ABSPATH . 'wp-content/plugins/wp-crontrol', // a plugin 
        ABSPATH . 'wp-content/plugins/foo.php', // a file inside plugins folder
        ABSPATH . 'wp-content/themes/twentytwentyfour' // a complete theme
    ];

    return array_merge($excludedFiles, $customExcludedFiles);
}
add_filter('wpstg.backup.restore.exclude_paths', 'wpstg_backup_restore_exclude_paths');

Backup を Restore して既存のメディアファイル・Plugin・Theme を保持する

下のフィルターを使って既存のファイルを保持できます:

PHP
// Keep all plugins
add_filter('wpstg.backup.restore.keepExistingPlugins', function(){return true;});

// Keep all mu-plugins
add_filter('wpstg.backup.restore.keepExistingMuPlugins', function(){return true;});

// Keep all themes
add_filter('wpstg.backup.restore.keepExistingThemes', function(){return true;});

// Keep all media files in wp-content/uploads folder.
add_filter('wpstg.backup.restore.keepExistingMedia', function(){return true;});

// Keep all other files in wp-content folder.
add_filter('wpstg.backup.restore.keepExistingOtherFiles', function(){return true;});

一時的な Backup Restore データベーステーブルプレフィックスを変更する

Backup Restore 処理中にカスタムの一時データベースプレフィックスを使用できます。

使い方:

PHP
add_filter('wpstg.restore.tmp_database_prefix', function ($defaultTmpPrefix) {
	return 'wpstgt_';
});

この例は {WPSTG_TMP_PREFIX} を、デフォルトの tmp プレフィックス wpstgtmp_ ではなく wpstgt_ に置き換えます。これにより、テーブル名 (一時プレフィックスを含む) が 64 文字を超える場合に Restore エラーが発生する可能性を減らせます。これはデータベース内の識別子に対する MySQL の文字制限だからです。

上の例で、Restore 処理中に現在のテーブルに wpstgt_ プレフィックスのテーブルがすでにある場合、デフォルトの tmp プレフィックス wpstgtmp_ を使うようにフォールバックします。

Multipart Backup を有効化する

WP STAGING は、各 Backup ファイルのサイズを制限するために使用できる multipart Backup の作成をサポートしています。この機能は Plugin、Theme、メディアファイル、データベース用に複数の Backup ファイルを作成できます。非常に大きなサイトを持っていて、複数ギガバイトのデータを持つ Backup ファイルを作成できない場合に便利です。

この機能を有効化して、最大 Backup ファイルサイズを指定するには下のフィルターを使ってください:

PHP
add_filter('wpstg.backup.isMultipartBackup', function() {
    return true;
});

// 256 MB 
add_filter('wpstg.backup.maxMultipartBackupSize', function() {
    return 256 * 1024 * 1024;
});

Backup Restore 処理中にパーツを除外する

Backup 全体を Restore したくない場合は、このフィルターを使って Plugin、Theme、データベースなどの特定のパーツのみを Restore して既存データを保持できます。

例

このコードは mu-plugins のみを Restore して他のすべてのパーツを除外します:

PHP
//Will only restore mu-plugins
add_filter('wpstg.backup.restore.exclude_backup_parts', function ($partsToSkip)
{
    return [
        //'muplugins',
        'plugins',
        'uploads',
        'themes',
	      'lang',
        'wpcontent', // Doesn't include core wp directories inside wp-content (mu-plugins, plugins, themes, uploads, languages)
        'wproot', // Doesn't include core wp directories (wp-admin, wp-content, wp-includes)
        'wpstgdb' // database
    ];
});

クラウドプロバイダー Backup アップロードチャンクを増やす

これは Google Drive (例) へのリクエストを減らすのに役立ちます。サーバーの IP が Google によってブロックされた場合に役立つ可能性があります。Google への Backup のアップロードを再試行する前に 6 時間待ってください。これは IP アドレスが Google によってブロックされる時間です。

PHP
add_filter('wpstg.remoteStorages.chunkSize', function () {
    return 10 * 1024 * 1024; // 10 MB chunk size, try increasing the chunk size in multiple of 5 MB if this still fails.
});

クラウドプロバイダーのリクエスト間の遅延を増やす

Backup 処理中にサーバーから Google Drive へのリクエスト間の遅延を増やすには、このフィルターを使ってください。IP が Google によってブロックされた場合に役立つはずです。Google への Backup のアップロードを再試行する前に 6 時間待ってください。これは IP アドレスが Google によってブロックされる時間です。

PHP
add_filter('wpstg.remoteStorages.delayBetweenRequests', function() {
    return 500; // 500ms, if this still fails, try increasing delay by multiple of 250ms.
});

FTP リモートストレージへ FTP 拡張機能経由でアップロードを強制する

デフォルトでは、WP STAGING は curl 拡張機能で Backup ファイルを FTP にアップロードしますが、このフィルターを使って curl に切り替えられます:

PHP
add_filter('wpstg.ftpclient.forceUseFtpExtension', '__return_true');

HTTP サイトで作成された Backup を HTTPS サイトに、またはその逆に Restore する

HTTP サイトから HTTPS サイトに、またはその逆に Backup を Restore する必要がある場合、このフィルターが必要です。

PHP
add_filter('wpstg.backup.restore.use_current_scheme_on_same_site', '__return_true');

Backup Restore 中にファイルとディレクトリを削除から除外する

Backup を Restore して、特定のファイルやフォルダがクリーンアップで削除されないようにしたい場合、このフィルターを使ってこれらのファイルをロックできます:

PHP
add_filter( 'wpstg.backup.restore.exclude_enqueue_delete',
	function($excludedFiles) {
		return array_merge(
			$excludedFiles,
			[
				ABSPATH . 'wp-content/db.php',
				ABSPATH . 'wp-content/database',
				ABSPATH . 'wp-content/wp-staging',
				ABSPATH . 'wp-content/plugins/wp-staging',
				ABSPATH . 'wp-content/plugins/wp-staging-pro',
				ABSPATH . 'wp-content/plugins/wpstg-sqlite-integration',
				ABSPATH . 'wp-content/mu-plugins/0-staging-url.php',
				ABSPATH . 'wp-content/mu-plugins/0-allow-wp-org.php',
				ABSPATH . 'wp-content/mu-plugins/1-pretty-permalinks.php',
				ABSPATH . 'wp-content/mu-plugins/2-deactivate-sqlite-plugin.php',
				ABSPATH . 'wp-content/mu-plugins/sqlite-database-integration-main',
			]
		);
	}
);

Backup Restore 中にデータベース照合順序をカスタムフォールバック照合順序で置き換える

このフィルターを使うと、Backup Restore 処理中に欠落しているか、サポートされていないデータベース照合順序を置き換えられます。ターゲットサーバーで照合順序が利用できない場合、WP STAGING は一般的な代替バリアント (例えば utf8mb4_general_ci) で置き換えようとします。

このフィルターを使うと、独自の優先フォールバック照合順序を定義できます。

PHP
add_filter('wpstg.database.importer.replace_collation', function ($collationSearchReplace) {
    $collationSearchReplace['utf8mb4_uca1400_ai_ci'] = 'utf8mb4_0900_ai_ci';
    return $collationSearchReplace;
});

パラメータ:

  • $collationSearchReplace (array): 置換する照合順序の連想配列。キーは欠落している照合順序、値は置換先です。

例:

Backup に utf8mb4_uca1400_ai_ci が含まれているが、ターゲットの MySQL サーバーがサポートしていない場合、上の例を使って utf8mb4_0900_ai_ci に置換できます。

Backup Restore からテーブルを除外する

下のコードスニペットを使って、特定のデータベーステーブルを Restore から除外できます:

PHP
add_filter('wpstg.backup.restore.exclude.tables', function ($excluded_tables) {
    $excluded_tables[] = 'users';
    $excluded_tables[] = 'usermeta';
    return $excluded_tables;
});


Backup・Restore 中にセーフパフォーマンスモードを有効化

セーフモードを使って、弱いサーバーで 503 エラーを防ぎます。Backup のパフォーマンスに影響します。Backup が正しく作成されている場合は使用しないでください。

PHP
add_filter('wpstg.job.performance_mode', function ($mode) {
    return 'safe';
});

Remote Sync フィルター

Apache Basic 認証をバイパスする

移行先サイトがサーバー側の「Apache Basic 認証」の背後にある場合、Remote Sync 機能を正しく動作させるためにこのフィルターを使う必要があります。これはサーバー側のパスワード保護をバイパスします:

add_filter('http_request_args', function ($parsed_args, $url) {

    $host = 'https://example.com/';
    $username = 'admin';
    $password = 'password';

    if (strpos($url, $expectedUrl) !== false) {
        $parsed_args['headers']['Authorization'] = 'Basic ' . base64_encode($username . ':' . $password);
    }

    return $parsed_args;
}, 10, 2);

$host、$username、$password の値をサーバー設定に変更してください。

Updated on 5月 23, 2026

Rene Hermenau

著者： Rene Hermenau

About the author: René Hermenau is the founder of WP STAGING. He works on WordPress backups, staging, migrations, database handling, and safe deployment workflows.