カスタム投稿タイプを管理する Custom Post Type Maker を試してみた

管理画面からカスタム投稿タイプやら、カスタム分類やらを設定するために有名なプラグインといえば、Custom Post Type UI だと思いますが、デバッグモードにすると notice エラーが出たり(あまり人のこと言えない。。)、アップデートもしばらくされておらず、3.5 で追加になったパラメーターの指定ができなかったり、UIが今ひとつ使いにくいなど、今後にちょっと心配があり、代替となるプラグインで良いものないかなと探していたところ、Custom Post Type Maker の存在を知り、試してみました。

結論から言うと、現バージョンでは、使用すべきではないというのが私の判断です。

カスタム投稿タイプなどを新しく追加した場合、表示されるURLが新たに加わりますが、パーマリンク使用時にこのURLを表示するためには、リライトルールというマッピングデータを更新してあげる必要があります。

Custom Post Type Maker は、Webページ表示時にこのリライトルールを毎回再生成しているのですね。こうすることによって、新しくカスタム投稿タイプやカスタム分類を追加したときにも、自動的に表示されるようになるのですが、このリライトルールの再生成は、それなりに重い処理で表示の際に毎回やるようなことではありません。これは、Codex の flush_rewrite_rules の説明にもしっかりと注意書きとして載っています。

Important: Flushing the rewrite rules is an expensive operation, there are tutorials and examples that suggest executing it on the ‘init’ hook. This is bad practice. Instead you should flush rewrite rules on the activation hook of a plugin, or when you know that the rewrite rules need to be changed ( e.g. the addition of a new taxonomy or post type in your code ).

WordPress は、3.3 で、リライトルールの改善を行い、この処理も大幅に軽減はされていますが、毎回行うようなことではありません。

私の判断ではありますが、この点が改善されるまで、利用すべきでないプラグインととらえています。

プラグインでバージョン情報を使いたいときは、get_file_data を用いるととってもエコなのよ

こんにちは、こんにちは!ぼく、はm

WordPress のプラグインでプラグイン自体のバージョン情報を利用したいときに便利な方法という、なんともニッチな技法の紹介です。

たまに、プラグイン内でプラグインのバージョンを定義していたりしますが、これだと、うっかりバージョン番号を変更し忘れることが多々発生します。(ぼけっち!)

このようなアルツh・・もとい、うっかりなすびな方は、プラグインファイルに書いているであろうコメントのバージョンを利用しちゃうと便利です。

WordPress では get_file_data という関数を使うと一発で、これらファイル内の記述から該当する記述をパースして配列で取得できる超絶便利なシロモノがあります。

get_file_data はパラメーターを2つ指定する必要があり、最初がファイルのパス、2つ目が取得したデータのキーと指定名を配列で指定します。プラグインのデータを取得する get_plugin_data では、パラメーターとして、下記の配列が使われていますので、計9パラメーターが WordPress 側で認識可能ということになります。(_sitewide は、Networkパラメーターと同義で非推奨)

$default_headers = array(
	'Name' => 'Plugin Name',
	'PluginURI' => 'Plugin URI',
	'Version' => 'Version',
	'Description' => 'Description',
	'Author' => 'Author',
	'AuthorURI' => 'Author URI',
	'TextDomain' => 'Text Domain',
	'DomainPath' => 'Domain Path',
	'Network' => 'Network',
	// Site Wide Only is deprecated in favor of Network.
	'_sitewide' => 'Site Wide Only',
);

これをちょっとひねって、プラグイン内で自プラグインのバージョンを用いる場合は、下記のように記述できるかと思います。

$data = get_file_data( __FILE__, array( 'version' => 'Version' ) );
$version = $data['version'];

なお、取得できるデータはファイルの冒頭よりファイルサイズで 8kバイト の範囲内になりますので、データ部分はファイルの最初に書いておきましょうね。

Meta Manager 1.0.5アップデート

Meta Manager を 1.0.5にアップデートしました。非公開のカスタム投稿タイプでもメタ情報のボックスが表示されてしまっていたため、非公開のカスタム投稿タイプの場合、表示しないように条件の変更を行いました。

併せて、メタ情報のボックスを非表示にできるようにフィルターフックを追加しています。CODE 1 では、book というカスタム投稿タイプであれば、表示しないようになります。投稿タイプ以外にも記事の情報を参照出来る $post もパラメーターとしてとれますので、記事の属性などによっての切り替えも可能です。

CODE 1

function meta_manager_meta_box_control_filter( $display, $post_type, $post ) {
	if ( $post_type == 'book' ) {
		$display = false;
	}
	return $display;
}
add_filter( 'meta_manager_meta_box_display', 'meta_manager_meta_box_control_filter', 10, 3 );

Custom Post Types Relationships (CPTR)を使って、手動で関連記事の設定と表示を実装する

Custom Post Types Relationships (CPTR) というプラグインをご存じでしょうか。このプラグインは、投稿と投稿や投稿と固定ページ、固定ページとカスタム投稿タイプなど、記事と記事の関連付けが行えるプラグインです。今回は、この Custom Post Types Relationships (CPTR) を使って、手動での関連記事設定と表示する方法をご紹介したいと思います。

“Custom Post Types Relationships (CPTR)を使って、手動で関連記事の設定と表示を実装する” の続きを読む

qtranslateと干渉して、Trust Formのエラーメッセージが英語になってしまう原因を調べてみた

WordPress で qtranslateTrust Form を利用しているサイトで、Trust Form のエラーメッセージが英語になってしまうんですけどという相談を受けたので、どうにかならないものかと調べてみました。

“qtranslateと干渉して、Trust Formのエラーメッセージが英語になってしまう原因を調べてみた” の続きを読む