• 赤色のリンクは、まだ日本語Codexに存在しないページ・画像です。英語版と併せてご覧ください。(詳細

このWikiはいつでも誰でも編集できます

プラグインとテーマの移行/2.7

提供: WordPress Codex 日本語版
移動先: 案内検索

はじめに

WordPress 2.1や2.2のような新しいバージョンのWordPressがリリースされると、これまで使っていたテーマやプラグインが動かなることがあります。WordPressの根本的な仕様変更によって壊れてしまったのかもしれませんが、ちょっとした設定や少しの編集だけでなおることがあります。

この記事はプラグインとテーマの移行の一部です。Version 2.6Version 2.7の変更点をカバーしており、バージョン2.7でテーマやプラグインを動かすために必要なことが書いてあります。

もし使用しているテーマやプラグインが他人によって開発されたものならば、情報を探せる場所がいくつかあります。

テーマやプラグインの作者である、またはテーマをカスタマイズして使っているのならば、この記事はテーマ・プラグインを2.6対応版からアップグレードさせるのに役立つでしょう。テーマ・プラグインを配布しているのなら、対応が完了したあと上に挙げた互換性リストに追加しておいてください。そうすれば、ユーザーはどのバージョンを使えばいいかがわかります。

テーマやプラグインを修正する

次の節では、テーマやプラグインに影響を与える可能性のあるWordPressの変更点について説明します。

テーマ

コメント表示の変更 - スレッド分け、ページング etc

コメントはWordPress2.7において、スレッド分け、入れ子構造、ページングなど、たくさんの新機能を持つようになりました。組み込みの機能ですが、テーマが対応していないと機能しません。この新しい機能を利用できるようにテーマをアップデートするには、進化したコメント表示/enの記事を参照してください。


Postクラス

WordPress2.7はpostクラスを幾つか持っており、テーマ作者がシンプルなスタイリングをすることを可能にします。その関数はわかりやすくpost_class()と名付けられています。

この関数をテーマ内で使うには、ループ内の適切な場所に書けばいいのです。多くのテーマはすべての投稿をdiv要素などでくくっています。このdivは通常class="post”などの属性がついているので、その代わりにpost_classを呼び出せばいいのです。以下がその例です:

<div id="post-<?php the_ID(); ?>" <?php post_class(); ?>>

post_class()はdivにclass="なになに”を出力します。これはいくつかの異なるクラス名を含んでいます:post、hentry(hAtom microformatページ用)、category-X(Xにはこの投稿の含まれるすべてのカテゴリーのスラッグが入ります)。テーマに様々なスタイルを適用するのが容易になります。

自分のクラスを追加したいケースもpost_classはサポートしています:

<?php post_class('special'); ?>

これはspecial をクラスリストに追加します。もし複雑なコードを使用しており、その方が有用だと言うならば、クラスをスペースでわけて列挙したり、クラス名の文字列からなる配列を渡すこともできます。

投稿をループの外や別のループ内に表示する場合は、post_class関数の二番目のパラメータに投稿のIDを入れてください。クラスはその投稿によって定義されます。

<?php post_class('',$post_id); ?>

サイトからのログアウト

テンプレートタグ,wp_logout_urlはログアウト用の一時的なURLを提供するためにバージョン2.7から追加されました。もしもユーザがログアウトするリンクを生成するためにテーマ内で/wp-login.php?action=logoutを使っているならば、そのコードはwp_logout_urlを使って更新べきです。のよい使用例はWordPressのDefaultテーマとClassicテーマのcomments.phpcomments-popup.phpテンプレートに見ることができます。

テーマがログアウトURLにを使用していない場合、ユーザはyourdomain.tldからログアウトしようとしています。本当にログアウトしますか?というメッセージを見ることになります。

カスタムクエリからStickyポストを除外する

Version 2.7から投稿をstickyにするための機能が追加されました。query_postsでループを作っていると、stickeyな投稿がクエリに戻ってきてしまいます。これらの投稿がクエリに含まれることを避けるには、caller_get_posts=1をクエリに加えてください。

階層構造が見直され、テーマのヘッダーとフッターテンプレートが特定できるようになりました。名前が特定されると、そのヘッダー(またはフッター)がインクルードされます。これまでと同じように、テーマ内にheader.php(またはfooter.php)がなければ、デフォルトテーマからインクルードされます。

  • get_header('myheader')はheader-myheader.phpをインクルードします
  • get_footer('myfooter') はfooter-myfooter.phpをインクルードします

プラグイン

プラグインのアンインストール用API

WordPress2.7から、プラグインが自身をアンインストールするための新機能が加わりました。ユーザがプラグインを削除した瞬間を選んで実装できる2つのアンインストール・メソッドがあります。

一番簡単な方法は、プラグインのメインディレクトリにuninstall.phpというファイルを作成し、アンインストール用のコードを書くことです。このファイルはユーザがWordPressのプラグイン画面でプラグインの削除を選んだときにインクルードされます。うまくいけば、設定などのプラグインが生成した情報をデータベースから削除するコードだけで済むでしょう。このファイルはWordPressという傘の元に実行されます。つまり、このファイルからWordPressのすべての関数にアクセスできるのです。

二つ目の方法はアクションフックを使って、アンインストーラーを作成するものです。このアクションフックはアンインストールルーチンを実行し、WordPressのフックにregister_uninstall()フックを登録します。この方法は複雑なため、プラグイン開発者の中でも腕に自信がある人専用です。

管理画面用フックの追加と削除

WordPressの管理画面は2.7からデザインしなおされました。それに伴い、いくつかのプラグインフック(アクションとフィルター)は追加または削除されました。これがそのリストです(まだ不完全です)

//TODO

設定ページへの追加

WordPress2.7は管理画面の設定や管理にセクションを追加するためのAPIを持つ予定です。つまり、新しいページとしてではなく、既存のページに直接追加するための方法になります。add_settings_section(), add_settings_field(), register_setting(), unregister_setting()といった関数がこの機能を実装します。これらの関数はwp-admin/includes/plugin.phpで見ることができます(または、次のセクションを参照してください)。

管理画面ヘッダー

もうアイテムを追加するために使われていた管理画面のヘッダーがなくなったため、 "sidemenu" アクションが削除されました。

新たに"favorites"メニューが追加され、'favorite_actions'フィルターが使われています(wp-admin/includes/template.php内のfavorite_actions()関数の最後の部分に使用法があります)。

プラグインリストページ

プラグインがプラグイン一覧ページにアイテムを追加するためのフィルターが二つあります:

  • plugin_action_links_{$plugin}フィルター -- プラグインがアクション・カラムに新しいアクションを追加できるようにします。例:
$plugin = plugin_basename(__FILE__); 
add_filter("plugin_action_links_$plugin", 'my_plugin_actlinks' ); 
function my_plugin_actlinks( $links ) { 
 // プラグインの設定ページへのリンクを追加
 $settings_link = '<a href="whatevertheurlis">設定</a>'; 
 array_unshift( $links, $settings_link ); 
 return $links; 
}
  • after_plugin_row_{$plugin_file}フィルター -- 既存のフィルターと同じく、プラグインの表示されている列の最後に要素を追加することができます。ただ、あなたの作ったプラグインに対してだけ実行されるので、プラグインを表示しているすべての行に対して実行されません。

設定を登録する必要のあるプラグイン

もしプラグインが設定を保存するための簡単な方法(設定ページの作成/enに詳細があります)を使っているのならば、近い将来のWordPressは(そして、現在のWordPress MUも)登録された設定が有効なものであると認識する必要があるでしょう。

WordPressにおいて、register_setting()関数とunregister_setting()関数がこれを行います。これらは現在MPMUに存在するadd_option_update_handler()とremove_option_update_handler()のシンプルなラッパーです(WPMUにも、新しい名前がすぐに適用されるでしょう)

しかしながら、これらの関数を使用することは2.7では必須ではありません。将来、options.phpを使っているすべてのプラグインに対し、設定更新時にこれらのハンドラを使うことが要求されるでしょう。したがって、これらの新機能を実装しておくことは、前方互換という意味でも重要です。

こられの関数には幾つかの目的があります:

  • ホワイトリスト設定
  • サニタイズ用コールバックの登録
  • WPMUにおいて、管理者(誰でもブログを作れるように設定したWPMUにいる、必ずしも信頼できない人)がプライバシー設定やカスタムリンク構造、プラグインの有効・無効などの設定をいじることを避ける

こちらはその使用法です(関数リファレンスを読みたければ、wp-admin/includes/plugin.phpを参照のこと):

  • 'some-options'というように、設定のグループ名を定義する
  • 更新したい設定のそれぞれの admin_init アクションに対し、次のようなことを行う:
register_setting('some-options', 'option-1', 'intval');
  • 設定フォームでこんなことをする:
settings_fields('some-options');

settings_fields()はhiddenフィールドを出力し、nonceフィールドと同じようにすべてをoptions.phpがチェックします。新しいAPIを使えば、もはやpage_optionsのhiddenフィールドを設定する必要はないのです。


このページは更新中です...すぐに新しいものが追加されます(...といいですね)



最新英語版: WordPress Codex » Migrating Plugins and Themes to 2.7最新版との差分