WordPressフックを使用してコードをクリーンアップし、アクティブ化してアンインストールする
公開: 2015-01-23プラグインの作成者は、製品の主な機能に多くの時間とエネルギーを費やしているため、重要性の低いものを途中で落とすことができます。
たとえば、アクティブ化と非アクティブ化を考えてみましょう。 アクティベーションフックは広く普及していますが、多くのプラグインはいくつかのオプションを追加したり、書き換えルールをフラッシュしたり、データベーステーブルを作成したり、インストール時にバージョンの違いを確認したりする必要があります。
ここでのポイントは？ 多くのプラグイン作成者は、自分たちの後でクリーンアップするのに時間をかけません。 WordPressのインストールには、プラグインを削除した後に作成したカスタムテーブルが本当に必要ですか？ プラグインをゴミ箱に移動する前に、プラグイン専用のいくつかのオプションをクリアしてみませんか？
この記事では、アクティブ化、非アクティブ化、およびアンインストールフックを使用してプラグインを初期化し、ユーザーが製品を使い終わった後、より簡単にクリーンアップする方法を紹介します。
- アクティベーションフック
- インストールシーケンス
- 書き換えルールのフラッシュ
- データベーステーブルの作成
- 依存関係チェック
- 非アクティブ化フック
- アンインストールフック
- 追加のセキュリティ
- クリーンアップする時が来ました
注：この記事をざっと読む予定がある場合は、最後にある「追加のセキュリティ」セクションを確認することを強くお勧めします。このセクションでは、コードをいくつかの貴重なセキュリティチェックで補完しています。 また、WordPressプラグインフックのヘルプが必要な場合は、WordPressフックの使用方法とWordPressで機能をアクティブ化する方法について簡単に復習します。
アクティベーションフック
アクティベーションフックは非常に簡単ですが、インストールは少し特殊なケースであるため、イベントのシーケンスに注意を払う必要があります。 これらすべてに入る前に、簡単な例を次に示します。
そのすべての鍵は、 register_activation_hook()関数です。 最初のパラメーターは、メインのプラグインファイルへのパスです。 2番目のパラメーターは、実行する関数を定義します。 内部的には、 register_activation_hook()関数は「activate_ [plugin_name]」アクションのラッパーですが、少し使いやすいため、プラグインにフックが表示されるのは珍しいことです。
インストールシーケンス
インストールシーケンスを理解することは、慣れている方法を使用できなくなるため重要です。 register_activation_hook()は、ユーザーがアクティベーションリンクをクリックして、アクティベーション通知が表示されるまでの間に呼び出されます。 中間ページで実行され、フックが実行される直前にリダイレクトされます。
例を見て、これが非常に厄介な理由を見てみましょう。
書き換えルールのフラッシュ
多くのプラグインがカスタム投稿タイプを作成します。 新しいカスタム投稿タイプから投稿にアクセスしたときにユーザーが404エラーを受け取らないようにするために、アクティベーションの書き換えルールをフラッシュするのは賢明な方法です。
以下のコードは論理的に見えますが、失敗します。
それは完全にうまくいくようです。 カスタム投稿タイプが作成され、アクティブ化されると、書き換えルールがフラッシュされます。 問題は、書き換えルールをフラッシュするときに、カスタム投稿タイプがまだ作成されていないことです。
プロセスフローは次のようになります。
- ユーザーがプラグインをインストールします。
- ユーザーがアクティベーションリンクをクリックします。
- 中間ページはアクティベーションフックのみを実行し、それ以外は実行しません。 これにより、書き換えルールがフラッシュされます。
- プラグインはアクティブで、コードは通常どおり実行されます。 カスタム投稿タイプが登録されます。
WordPress Codexによって公式に承認されているStackOverflowに投稿されたソリューションは、私たちの小さな問題を解決します。 このソリューションには、プラグインがインストールされたことを示すオプションを追加することが含まれます。
このオプションが存在する場合は、アクティベーションを行ってから削除します。
このようなもの：
個人的には、このソリューションはあまり好きではありません。 問題は、8行目のチェックが1ページの読み込みごとに実行されることです。 サーバーに大きな負荷をかけず、ユーザーのWebサイトの速度を低下させないため、心配する必要はありません。 これは非常に迅速なチェックであり、パフォーマンスへの影響はごくわずかです。 ただし、99.9％の確率で不要です。
flush_rewrite_rules()関数のドキュメントのコーデックスに記載されているより良い解決策があります。 このソリューションでは、関数のモジュール性を使用して、アクティブ化時にカスタム投稿タイプを個別に登録します。
常に実行する必要のあるチェックに依存する代わりに、アクティベーション関数を使用して投稿タイプを登録します。 プラグインがアクティブ化されると、投稿タイプは常にinitフックから登録されることに注意してください。
これは、コーデックスがいたるところにある悲しい例です。 一般的に、WordPressには優れたドキュメントがありますが、何かが無駄または非論理的であると思われる場合は、自分で調査することを恐れないでください。
データベーステーブルの作成
一部のプラグインが実行するもう1つのタスクは、データベーステーブルを作成することです。 多くの場合、これは不要ですが、いくつかの正当なユースケースがあります。
テーブルの作成に関するCodexの記事のこの例は、複数のアクティベーション呼び出しを使用する方法を示しています。
最初の関数jal_install()は、新しいデータベーステーブルを作成します。 2番目の関数jal_install_dataは、初期データをテーブルに追加します。 register_activation_hook()を使用してこのコードをすべて含む1つの関数を追加する代わりに、 register_activation_hookを複数回使用できます。
これは、モジュール性の優れた方法です。 一方では、初期テストデータを追加する必要はありません。アクティベーションフックを削除するのと同じくらい簡単なので、関数をそのまま維持できます。 一方、これらの機能は分離されているため、どこでも自由に再利用できます。
依存関係チェック
活性化関数のもう1つの一般的なタスクは、依存関係をチェックすることです。 プラグインは、特定のバージョンのWordPress、別のプラグイン、または特定のバージョンのPHPに依存している場合があります。
以下のコードは、WPとPHPの最小バージョンをチェックし、必要に応じて（プラグインをアクティブ化せずに）ユーザーをリダイレクトします。
非アクティブ化フック
非アクティブ化フックは、ユーザーがプラグインを非アクティブ化したとき、ただしプラグインがアンインストール（削除）される前に実行されます。 非アクティブ化フックは、アクティブ化フックと同じ方法で使用されます。
非アクティブ化とは、ユーザーがプラグインを非アクティブ化しただけなので、アンインストール中ほど多くのことをしたくないことを意味します。 おそらく書き換えルールをフラッシュしたいと思うかもしれませんが、この段階では、すべてのオプションとデータベーステーブル（ある場合）を削除したくないでしょう。
これはかなり簡単ですが、リライトルールのフラッシュには特に注意を払います。これも、問題があるためです。
コーデックスは以下に示すようにそれらを行うことを推奨していますが、これは機能しません：
これが機能しない理由は以前と同じです。 非アクティブ化を実行すると、 initフックが実行されます。つまり、プラグインを非アクティブ化するときに、カスタム投稿タイプも登録します。 書き換えルールはフラッシュされますが、カスタム投稿タイプが考慮されます。
これに取り組むためにTracチケットが用意されていますが、それまでは、これを行うための非常に良い方法を提供することはできません。 私が見つけた唯一の方法は、書き換えルールを完全に削除することです。
これは過去に私のために働いたが、私はそれをお勧めしません。 これは、いくつかの追加の書き換えルールがあるという問題よりも大きな不確実性をもたらします。 むしろ、非アクティブ化後にパーマリンク設定にアクセスするようにユーザーに求めるメモを表示します。これにより、書き換えルールがフラッシュされます。 より良いソリューションが実装されるまで、私たちはこれで立ち往生しています…ごめんなさい！
アンインストールフック
プラグインをアンインストールするときにコードを実行する方法は2つあります。 register_uninstall_hook()を介してアンインストールフックを使用するか、プラグイン内で専用のuninstall.phpファイルを使用できます。 両方を紹介しますが、推奨される方法はアンインストールファイルを使用することです。
アンインストールフックの主な問題は、「アンインストール中にメインプラグインファイルが実行されないようにすることです。これは、プラグインがグローバルスペースでコードを実行する場合に問題になる可能性があります。 アンインストールコードが一元化されているという点でも優れています。」 –スコットライリー
以下のコードは、基本的なフックを使用したアンインストールプロセスを示しています。
説明したように、これは最善の解決策ではありません。 アンインストールを処理するはるかに優れた方法は、 uninstall.phpファイルを使用することです。 あなたがする必要があるのはそれを作成することだけであり、それが利用可能であればそれが使用されます。
ご覧のとおり、これは実際にはより単純なソリューションです。 何よりも、それは自己完結型です。
追加のセキュリティ
これまでに示した例をセキュリティ関連の問題で過度に複雑にしたくはありませんでしたが、実際には、許可された人だけがこれらのアクションを実行できるようにするためのいくつかの手順を実行する必要があります。
アクティブ化と非アクティブ化については、次のスニペットを使用してください。
このコードブロックは、ユーザーがこのアクションを実行するためのアクセス許可を持っていること、およびアクションが適切なページで発生したことを確認します。 これは、ほとんどの悪意のある試みから保護する必要があります。
アンインストールプロセスは特別なので、少し異なるコードを使用する必要があります。
クリーンアップする時が来ました
プラグインがWordPressに何かを追加する場合、ユーザーがプラグインを削除することを決定したときにプラグインを削除するのは開発者としてのあなたの義務です。
上記のアクティブ化、非アクティブ化、およびアンインストールの方法を使用すると、これを安全かつ確実に実行するシステムを構築できます。 また、OOP環境でのこれらのプロセスの概要を説明しているこのStackexchangeスレッドを読むことを強くお勧めします。
まだWPMUDEVメンバーでない場合は、完全にリスクのない無料トライアルに今すぐサインアップしてください。 メンバーになると、すべての優れたプラグインと超高速ホスティングサービスにアクセスできるほか、WordPress関連のすべての質問と問題に対する専門家による24時間年中無休のサポートが受けられます。
タグ：