プラグイン入れ替え
ワードプレスのプラグインを入れ替える時に無効化する必要はあるのか？
結論
必ずしも無効化する必要はありませんが、状況によっては無効化・再有効化が必要または推奨される場合があります。特に、データベース構造の変更（例: 新しいテーブルの追加、カラムの変更）やプラグインのアクティベーション処理に依存する変更を加える場合は、無効化・再有効化が安全です。以下に、ケースごとの説明とガイドラインを示します。
1. データベース構造を変更する場合（例: 新しいテーブルやカラムの追加）
無効化・再有効化が必要な理由:
WordPressプラグインでは、データベーステーブルの作成や変更処理は通常、register_activation_hook で登録された関数（この場合は rt_create_tables）内で実行されます。
このフックは、プラグインが有効化された時点でしか呼び出されません。既に有効化済みのプラグインのソースコードを上書きしても、register_activation_hook は再実行されず、データベースの変更（例: wp_referrer_exclusions テーブルの作成）が適用されないことがあります。
今回のケースでは、元のコードに wp_referrer_exclusions テーブルがなく、新しいコードで追加されたため、テーブルが存在しないエラーが発生しました。無効化・再有効化により、rt_create_tables が実行され、テーブルが作成されたため問題が解決しました。
対応方法:
無効化・再有効化: 最も簡単で確実な方法。プラグインを無効化し、ソースコードを入れ替えた後、再度有効化します。これにより、register_activation_hook が確実に実行されます。
アップグレード処理の実装: プラグインにバージョン管理を追加し、データベースの変更を検出・適用するアップグレード関数を作成します（後述）。
注意点:
無効化・再有効化はデータベースのデータ（例: wp_referrer_tracker のリファラーデータ）を削除しません（このプラグインでは TRUNCATE や DROP TABLE を実行しないため）。
ただし、他のプラグインや環境によっては、無効化時にデータをクリーンアップする処理が含まれる場合があるので、事前に確認してください。
2. データベース構造を変更しない場合（例: ロジックやUIの変更）
無効化・再有効化は不要:
プラグインのロジック（例: リファラーの処理方法）、管理画面のUI、ショートコードの出力などを変更する場合、データベース構造に影響がないため、ソースコードを上書きするだけで変更が反映されます。
例: rt_display_referrer_stats の出力を変更、フォームのHTMLを調整、エラーメッセージを修正する場合。
対応方法:
ソースコードを直接上書き（例: FTPやファイルマネージャーで referrer-tracker.php を更新）。
WordPressのキャッシュ（例: オブジェクトキャッシュ、ページキャッシュ）やブラウザキャッシュをクリアして、変更が即座に反映されることを確認。
注意点:
プラグインがキャッシュを使用している場合（例: transient API）、キャッシュをクリアする必要がある。
管理画面のJavaScriptやCSSを変更した場合は、プラグインのバージョン番号（例: wp_enqueue_script の第4引数）を更新してキャッシュを回避。
3. おすすめ: プラグインのアップグレード処理を実装
ソースコードの入れ替え時に毎回無効化・再有効化を行うのは手間がかかり、運用環境ではリスク（例: 一時的な機能停止）を伴います。より良い方法は、プラグインにバージョン管理とアップグレード処理を組み込むことです。これにより、データベース構造の変更を自動で適用できます。
実装例:
プラグインのバージョンをデータベースに保存（例: wp_options テーブル）。
プラグインのロード時に現在のバージョンと保存されたバージョンを比較し、必要に応じてデータベースを更新。
以下は、アップグレード処理を追加したコードの例（rt_create_tables の後に追加）：
php
// プラグインのアップグレード処理
function rt_upgrade_plugin() {
global $wpdb;
$current_version = get_option(‘rt_plugin_version’, ‘0.0.0’);
$plugin_version = ‘1.4.1’; // プラグインの現在のバージョン
if (version_compare($current_version, $plugin_version, ‘<')) { $charset_collate = $wpdb->get_charset_collate();
// 除外URLテーブルが存在しない場合に作成
$exclusions_table = $wpdb->prefix . ‘referrer_exclusions’;
$sql_exclusions = “CREATE TABLE $exclusions_table (
id bigint(20) NOT NULL AUTO_INCREMENT,
exclude_url varchar(255) NOT NULL,
PRIMARY KEY (id),
UNIQUE KEY exclude_url (exclude_url)
) $charset_collate;”;
require_once(ABSPATH . ‘wp-admin/includes/upgrade.php’);
$result_exclusions = dbDelta($sql_exclusions);
if ($result_exclusions) {
error_log(‘Referrer Tracker: Created/Updated table ‘ . $exclusions_table . ‘ during upgrade.’);
} else {
error_log(‘Referrer Tracker: Failed to create/update table ‘ . $exclusions_table . ‘ during upgrade.’);
}
// バージョンを更新
update_option(‘rt_plugin_version’, $plugin_version);
error_log(‘Referrer Tracker: Upgraded from version ‘ . $current_version . ‘ to ‘ . $plugin_version);
}
}
add_action(‘plugins_loaded’, ‘rt_upgrade_plugin’);
仕組み:
rt_plugin_version オプションに現在のプラグインバージョンを保存。
プラグインがロードされるたびに（plugins_loaded フック）、保存されたバージョンとコード内のバージョンを比較。
バージョンが古い場合、必要なデータベース変更（例: wp_referrer_exclusions テーブルの作成）を実行し、バージョンを更新。
利点:
ソースコードを上書きするだけでデータベース変更が自動適用される。
無効化・再有効化の手間が不要。
ユーザーがプラグインを更新した際も、データベースが正しく更新される。
