Tag Archives: PHP

WordPressと無関係なPHPファイル上で、WordPressの関数を実行する方法

WordPressには、便利な関数やフックが用意されているが、当然、これらはWordPressに無関係なphpファイルでは利用できない。 WordPress経由で読み込まれたphpファイルのみが対象となる。 私の作成したプラグインの中には、Javaスクリプトから読み込まれたphpファイル上で、WordPressの関数を実行しているものがある。 しかし、プラグインに含まれるphpファイルと言えども、Javaスクリプト経由である以上、WordPressとは全く無関係なファイルであり、本来は、WordPressの関数は利用不可能である。 実は、強制的にWordPressに関連付ける方法がある。 ただし、本来WordPressの関連のないファイルでWordPressの関数を実行するということは異例なことであり、これを行う際は、セキュリティ上の注意も必要だ。 方法は簡単で「require_once()」で「wp-load.php」を読み込んでやれば良い。「wp-config.php」と「admin.php」を読み込む方法もあるが、「wp-load.php」の方が良いだろう。 以下で解説する方法は、直接「wp-load.php」を読み込むのではなく、まず「wp-load.php」を読み込む処理を書いたファイルを準備し、「require_once()」を使って、それを読み込む方法である。 この方法は「Syntax Highlighter Compress」を参考にした。 複数のファイルで「wp-load.php」を読み込む必要がある場合でも重複した処理を記述する必要がなく、便利である。 まず、次のような記述のファイルを準備する。 <?php $path = ”; // It should be end with a trailing slash if (!defined(‘WP_LOAD_PATH’)) { $classic_root = dirname(dirname(dirname(dirname(__FILE__)))).’/'; if (file_exists($classic_root.’wp-load.php’) ) { define(‘WP_LOAD_PATH’, $classic_root); } else { if (file_exists($path.’wp-load.php’)) { define(‘WP_LOAD_PATH’, $path); } else { exit(__(“Could not find wp-load.php”)); } } } //Load wp-load.php require_once(WP_LOAD_PATH.’wp-load.php’); ?> 続いて、WordPressとは無関係なphpファイルの先頭に以下のように記述して、先ほど作成したファイルを読み込めばよい。 require_once( dirname( dirname(__FILE__) ) .’/my-bootstrap.php’); 場合によっては、セキュリティのために権限やその他条件チェックも行ったほうが良い。 例えば、上記の構文に続いて以下のような構文を追加する。 if ( !is_user_logged_in() || !current_user_can(‘edit_posts’) ) wp_die(__(“You are not allowed to access this file.”)); 上記の例では、このファイルをリクエストしたユーザーが、ログインユーザーでない場合、記事の投稿権限を持たない場合は、処理を中断している。

Posted in PHP, WordPress, ネット・PC | Tagged , | Leave a comment

WordPressの投稿やコメントで使えるタグを追加する

WordPressの投稿やコメントでタグを使ったところ、タグが消されたり、属性が消されたりした経験はないだろうか? このような現象は、記事やコメントを保存した後や、ビジュアルエディターとHTMLエディターを切り替えた後に起こっているはずた。 これは、単に禁止されているタグや属性があるからなのだが、逆に言えばきちんと許可さえしてやれば削除されなくなる。 実は、WordPressでは、入力出来るタグや属性を制限する仕組みは2つある。 1つは、HTMLエディターでの制限で、ksesというフィルターによるもの。「/wp-includes/kses.php」での制限である。 この制限は、HTMLエディターを利用する投稿画面とコメント欄で有効であるが、管理者権限を持つものには適応されないので、管理者として記事を投稿し、コメントを書いているなら、そもそも制限はないので無視して良い。 もし何かの事情で許可したいなら「/wp-includes/kses.php」に記述されている配列にタグや属性を追加すれば良い。 投稿画面の場合は、 $allowedposttags = array( ‘address’ => array(), ‘a’ => array( ‘class’ => array (), ‘href’ => array (), ‘id’ => array (), ‘title’ => array (), ‘rel’ => array (), ‘rev’ => array (), ‘name’ => array (), ‘target’ => array()), ‘abbr’ => array( ‘class’ => array (), ‘title’ => array ()), にタグや属性を追加する。 コメント欄の場合は、 $allowedtags = array( ‘a’ => array( ‘href’ => array (), ‘title’ => array ()), ‘abbr’ => array( ‘title’ => array ()), ‘acronym’ => array( ‘title’ => array ()), ‘b’ => array(), に付け加えれば良い。 上記と同じような記述は、プラグインやfunctions.phpでも書くことが出来る。 私は、コメントで使えるタグを追加で許可する構文をプラグイン中で書いているので、それを参考にまとめておく。 function my_allowedtags_in_comments($data) { global $allowedtags; $allowedtags['pre'] = array( ‘name’=>array(), ‘class’=>array()); $allowedtags['script'] = array( ‘type’=>array(), ‘class’=>array()); … 続きを読む →

Posted in PHP, WordPress, ネット・PC | Tagged , , , , | Leave a comment

WordPress 3.2以降のフルスクリーンモードにボタンを追加する

私は、WordPressの標準のビジュアルエディター「TinyMCE」に独自の機能を持ったボタンを追加するプラグインを作っている。 SyntaxHighlighter TinyMCE Button しかし、WordPress 3.2以降では、フルスクリーンモードの仕様が変わり、今まで通りのやり方ではノーマルモードでしか追加したボタンが表示されなくなってしまった。 試行錯誤の結果、WordPress 3.2以降で、フルスクリーンモードにボタンを追加する方法が分かったのでまとめておく。 既に「TinyMCE」にボタンを追加する「TinyMCE」用のプラグインを作成し、有効化済みであることを前提とするので、「TinyMCE」へのボタンの追加自体の説明は省略する。 ボタンを追加する手順自体は、過去のバージョンと同じである。フルスクリーンモードへの追加には、これとは別に次のような処理が必要となる。 まずは、「wp_fullscreen_buttons」フックを使ってフルスクリーンモードにボタンを追加する。 以下は、「my_button」の場合の例である。 function my_fullscreen_button($buttons) { $buttons[] = ‘separator’; // 必要ならボタンの前に区切りを追加 $buttons['my_button'] = array( ‘title’ => __(‘My button’), // マウスオーバーで表示されるテキストラベル ‘onclick’ => “tinyMCE.execCommand(‘my_button_cmd’);”, // 実行するコマンド ‘both’ => false); // trueならHTMLエディターでも表示 return $buttons; } add_filter(‘wp_fullscreen_buttons’, ‘my_fullscreen_button’); 「onclick」で実行しているコマンドは、 ed.addCommand(‘my_button_cmd’, function() { のような形で、既に「TinyMCE」用プラグイン内のJavaスクリプトとして記述しているはずなので、それを実行させる。 ここまでの作業で、既にフルスクリーンモードにボタンが追加され、ボタンも機能しているはずだ。 しかし、ボタンラベルのアイコンが表示されていない。 続いて、ボタン上にアイコンを表示させるための処理を追加する。 アイコンは、CSSを使ってボタンの背景として表示させる。 まず、次のように背景の画像を定義したCSSファイルを準備する。 .wp_themeSkin span.mce_my_button { background: url(“my_icon.png”) no-repeat 20px 20px; background-position:0 0 } ボタンを表示させる箇所のclass属性は「mce_ボタンの登録名」となるので、この場合は「mce_my_button」となる。 今度は、このCSSを、エディター画面で読み込ませる処理を書く。 function my_editor_style() { wp_enqueue_style(‘my-editor-style’, ‘http://www.near-mint.com/blog/my_editor_style.css’, false, ’1.0′); } add_action(‘admin_print_styles-post.php’, ‘my_editor_style’); add_action(‘admin_print_styles-post-new.php’, ‘my_editor_style’); add_action(‘admin_print_styles-page.php’, ‘my_editor_style’); add_action(‘admin_print_styles-page-new.php’, ‘my_editor_style’); 以上で、ボタンのアイコンも表示され、無事、フルスクリーンモードへのボタンの追加が完了する。

Posted in PHP, WordPress, ネット・PC | Tagged , , | Leave a comment

WordPressのプラグインの後始末

プラグインをアンインストールした後、データベースの「options」テーブルの掃除することが習慣になって来ている。 掃除と言っても、プラグインによってデータベースに書き込まれたデータを削除しているだけだが。 最近、偶然に、 http://WordPressのURL/wp-admin/options.php にアクセスすると、「すべての設定」というページが表示され、「options」テーブルに格納されたデータの一覧を見ることが出来る事を知った。 シリアル化されていないものについては、データの更新も出来るようだが、残念ながら削除は出来ない。 WordPress上から「options」テーブルの掃除が出来れば掃除も楽になるが、phpMyAdminを使うしかなさそうだ。 そこで、WordPressの管理画面からMySQLを管理できるプラグインは無いかと探してみたところ、「Adminer」と言うプラグインが見つかった。 「Adminer」は、phpMyAdminのようなMySQLの管理ツールで、それをプラグイン化したものらしい。 高機能なツールなのだが、「options」テーブルを掃除したいだけなので、もっとシンプルな機能のもので十分なのだが・・・。 さて、今回の話題は、以前からプラグインの利用者としても開発者としても気になっていたが、最近、Twitterでも話題になったようだ。 私の作成したプラグインもそうであるが、WordPress用のプラグインの多くが、データベース上に設定値などを格納している。 例えば、アクセス解析プラグインのログなど、頻繁に書き込みや更新が発生するようなデータは、データベース上に独自のテーブルを作成し、そこにデータを格納しているのが通例だが、対して、設定値など頻繁に書き込みや更新が行われないデータであれば「add_option()」を使って、データベース上の「options」テーブルに保存している事が多い。 プラグインを使っている間は、これらデータベースに格納された値は、なんら問題にならない。むしろ、動作に必要である。 ところが、プラグインが不用になり、一旦アンインストールしてしまうと、データベース上のゴミと化す場合も少なくない。 アンインストール時にデータベースの「options」デーブルに追加した値を削除してくれれば良いのだが、そうではない行儀の悪いプラグインも多い。 開発者なら知っていることだが、add_option()で追加されたデータは、delete_option()で簡単に削除できる。 要はタイミングの問題で、プラグインのアンインストール時にdelete_option()を実行出来れば、ゴミを残すこともなくなる。 勿論、その方法は用意されており、プラグインのアンインストール時にdelete_option()を実行したいのなら、下記の様に記述した「uninstall.php」ファイルを作成し、プラグインファイルに含めるだけで良い。 <?php if (!defined(‘ABSPATH’) && !defined(‘WP_UNINSTALL_PLUGIN’)) {exit();} delete_option(‘my_plugin_option1′); delete_option(‘my_plugin_option2′); delete_option(‘my_plugin_option3′); . . . ?> 「uninstall.php」が実行される前に「WP_UNINSTALL_PLUGIN」が定義されているかは、確認したほうが良いようなので上記のような記述になっている。 また、現在は使われていなが、過去のバージョンで使用して値がある場合は、それも記述した方が良い。 同様の処理を「register_uninstall_hook()」を使って実行させる方法もあるが、私のプラグインの場合は、「uninstall.php」を使っている。 アンインストール時の処理とは関係ないが、プラグインが有効化された時、無効化された時の処理を記述する場合は、「register_activation_hook()」、「register_deactivation_hook()」が利用出来るので覚えてくと役立つかもしれない。 しかし、「uninstall.php」や「register_uninstall_hook()」は、WordPress 2.7からの新機能のようなので、もっと古いバージョンでも動作するプラグインの場合は、別の方法をとる必要があるかもしれない。 と言え、開発者にアンインストール時の処理が浸透するまでは、データベースの「options」テーブルの掃除から解放されそうにはない。 様々なプラグインのデータを格納している「options」テーブル自体、雑居ビルのような状態であるため、不要なものを探すだけでも一苦労である。

Posted in PHP, WordPress, ネット・PC | Tagged , , , | Leave a comment

WordPress用のプラグインを簡単に作成する方法

今回は、簡単なプラグインの作成方法を説明する。 ただし、作成するプラグインは、あくまで個人的な利用を目的としているので、推奨されている作法に従っていない部分もある。 まず、「UTF-8 BOMなし」で保存できるテキストエディタで下記のように記述する。 <?php /* Plugin Name: My Plugin Plugin URI: http://www.near-mint.com/blog/ Description: For personal use. Version: 1.0 Author: Redcocker Author URI: http://www.near-mint.com/blog/ */ //ここに処理を記述する ?> 最初のコメントの部分は、プラグインに合わせて修正しておくこと。 Plugin Name・・・プラグインのタイトル Plugin URI・・・プラグインのサイトのURL Description・・・プラグインの説明。 Version・・・プラグインのバージョン Author・・・プラグインの作者 Author URI・・・作者のサイトのURL 今回作成するプラグインは、あくまでパーソナルな目的であるので、日本語で記述しても構わない。 問題は「//ここに処理を記述する」の部分に何を記述するかという点だが、書くべき処理を意外に簡単に見つける方法がある。 このブログでも書いた事があるが、「◯◯◯するために、☓☓☓をテーマのための関数(functions.php)に追加してください。」と言った内容の記事を見たことがあるのではないか思うが、その「☓☓☓」を記述すれば良い。 このブログでは「WordPressのヘッダを変更してフィードをカスタマイズ」で、ヘッダーからフィードリンクを削除するために、2行の処理を「テーマのための関数(functions.php)」に追加したが、それを記述してみよう。 <?php /* Plugin Name: My Plugin Plugin URI: http://www.near-mint.com/blog/ Description: For personal use. Version: 1.0 Author: Redcocker Author URI: http://www.near-mint.com/blog/ */ remove_action(‘wp_head’, ‘feed_links’, 2 ); remove_action(‘wp_head’, ‘feed_links_extra’, 3); ?> このファイルを 「UTF-8 BOMなし」形式で「.php」で終わるファイル名を付け保存し、「/wp-content/plugins」にアップロードする。フォルダに入れてアップロードしても構わない。 後は、管理画面のプラグインから有効化すればフィードリンクがヘッダーから消える。 とは言え、これだけではあまりにも寂しいので、その他の不要なヘッダー部分の要素も同時に削除する処理を追加した。 <?php /* Plugin Name: My Plugin Plugin URI: http://www.near-mint.com/blog/ Description: For personal use. Version: 1.0 Author: Redcocker Author URI: http://www.near-mint.com/blog/ */ remove_action(‘wp_head’, ‘feed_links’, 2); remove_action(‘wp_head’, ‘feed_links_extra’, 3); remove_action(‘wp_head’, ‘rsd_link’); remove_action(‘wp_head’, ‘wlwmanifest_link’); remove_action(‘wp_head’, ‘index_rel_link’); remove_action(‘wp_head’, ‘parent_post_rel_link’, 10, … 続きを読む →

Posted in PHP, WordPress, ネット・PC | Tagged , , | Leave a comment

ソースコードをハイライト表示するプラグインを作成

WordPress用にソースコードをハイライト表示するプラグインを作成した。 コードのハイライト表示について function wp_sh_setting_link( $links, $file ){ static $this_plugin; if ( ! $this_plugin ) $this_plugin = plugin_basename(__FILE__); if ( $file == $this_plugin ){ $settings_link = '<a href="options-general.php?page=wp-syntaxhighlighter-options">'.__('Settings', 'wp_sh').'</a>'; array_unshift( $links, $settings_link ); }  return $links; } 「WP SyntaxHighlighter」という名称で現在、公開中である。 最新の「WP SyntaxHighlighter」をダウンロード 作成したと言っても「SyntaxHighlighter」というJavaスクリプトで記述されたライブラリを利用しているだけで、コアの処理は「SyntaxHighlighter」ライブラリ任せである。 同様の「SyntaxHighlighter」ライブラリを利用するプラグインは、数多く公開されているが、新しいバージョンのライブラリを搭載し、比較的、有名なプラグインとなると、 SyntaxHighlighter Evolved Syntax Highlighter for WordPress あたりに限られるだろう。 「SyntaxHighlighter」ライブラリ、本来の仕様では「<pre>」や「<script>」タグを使って、ハイライト表示させるコードを指定するようになっているが、上の2つのプラグインは、ショートコードで指定する方式を採用している。 WordPressのビジュアルエディターでは、「<pre>」タグはともかく、「<script>」タグは簡単に入力する手段がなく、むしろタグではないショートコードの方が扱いやすい。 そのような理由もあり、WordPressでは、この手のプラグインの多くが、ショートコード採用している。 しかし、私が作成したプラグインでは、「<pre>」タグで指定する方式を採用した。 この方法ならば、ショートコードに関する処理を記述する必要もなく、処理の大部分を「SyntaxHighlighter」ライブラリに依存でき、プラグインの記述も大幅に楽になる。 「<pre>」タグに拘る理由としては、このような消極的な理由の他に、タグで指定した方が、後々都合が良いという積極的な理由もある。 例えば、ソースコードのハイライト表示を使わなくなり、プラグインを無効化した場合でも、過去の投稿の中のコードも、一応は表示されるし、スタイルシートでレイアウトすることも可能だ。 「<pre>」タグを使う場合の問題は、ビジュアルエディターからどのように「<pre>」タグを入力するかと言う点だが、標準での唯一の方法が「整形済み」を使う方法である。 「整形済み」に指定したコードは、自動的にエスケープされ、その点は都合も良いのだが、何分「<pre>」で囲まれるだで、calss属性の指定が要求される「SyntaxHighlighter」ライブラリには不都合である。 かと言って、一々、HTMLエディターに移動してclass属性を入力するのも馬鹿、馬鹿しい。 そこで、この問題を解決するために「SyntaxHighlighter TinyMCE Button」というプラグインを作成した。 最新の「SyntaxHighlighter TinyMCE Button」をダウンロード 「SyntaxHighlighter TinyMCE Button」は、ビジュアルエディターに「<pre>」を入力するためのボタンを追加する。 と言っても「CodeColorer TinyMCE Button」を少し弄っただけだが、独自の機能も実装している。 ビジュアルエディタの欠点の1つが、タブによるインデントが無効化されることだが、このプラグインの機能を使えば、一旦「<pre>」タグで囲んでしまえば、「<pre>」タグで囲まれたソースコードの部分は、タブによるインデントが可能となる。 本当は、ビジュアルエディターにソースコードをペーストした瞬間にタブが無効化される問題を解決したかったのだが、これは実現出来なかった。 少なくとも、このプラグインでは、後でタブによる整形が可能となっている。 「<pre>」タグを入力すると言っても、けして汎用のものではなく、「SyntaxHighlighter」ライブラリに、完全に特化している。 そのため、ボタンをクリックした際に、言語の指定などが必要になる。 最初は、殆どのパラメーター設定が可能な、もっと複雑なものを作成したのだが、最終的にシンプルなものに落ち着いた。 行番号の表示/非表示の選択も要らないかもしれないと思っている。 「SyntaxHighlighter TinyMCE Button」は、「WP SyntaxHighlighter」から独立したプラグインとなっているが、汎用的に「SyntaxHighlighter」ライブラリを採用するプラグインで使えるかと言えば、微妙かもしれない。 将来的に「WP SyntaxHighlighter」に実装してしまう可能性も高い。 「SyntaxHighlighter」ライブラリでは、各言語に対応した「ブラシ(言語定義ファイル)」を読み込む必要があるが、この制御をプラグイン側で動的に行なっている場合も少なくない。 ちなみに私のプラグインでは、動的な「ブラシ(言語定義ファイル)」の読み込みを「SyntaxHighlighter」ライブラリに依存している。 そのようなプラグインでは、ショートコードのみを認識してる場合が多いので、「<pre>」ダグで書いても対応する「ブラシ(言語定義ファイル)」読み込まれないかもしれない。 全ての「ブラシ(言語定義ファイル)」を予め読み込むか、「SyntaxHighlighter」ライブラリの動的読み込み機能に依存してる、または機能として残しているプラグインなら「SyntaxHighlighter TinyMCE Button」は役立つだろう。 ちなみに「SyntaxHighlighter Evolved」との組み合わせなら、「SyntaxHighlighter Evolved」側の設定によっては機能するが、「Syntax Highlighter for WordPress」との組み合わせでは、「SyntaxHighlighter TinyMCE Button」は役に立たない。

Posted in WordPress, ネット・PC, 自作アプリ | Tagged , , | Leave a comment

「zenback」をWordPressに導入するためのプラグインを作成

ブログパーツなどを追加するためにテーマのテンプレートを変更しているケースが少なくないのだが、テーマをアップデートすると加えた変更は、全て無に帰すため、テーマのアップデートのタイミングで必ず作業が発生する。 頻度は高くないが、これは結構、面倒である。 また、気軽にテーマを変更することも出来ない。 その原因の1つが「zenback」なのだが、「zenback」を導入をプラグインに任せることが出来れば、テンプレートを編集する必要がなくなる。 しかし、そのようなプラグインは、WordPressでは存在していないようなので、自作する事にし、作業を進めてきた。 根本的にPHPが分かっていない事もあるが、このプラグインの作成にはかなり苦労した。 しかも、結論から言えば、自身の要求は全て満たすことが出来なかった。 「zenback」の解析精度を高める「zenback」タグの追加は、WordPressにも比較的に簡単に実装できたが、問題は、「zenback」スクリプトコード本体の追加である。 「zenback」の表示位置としては、コメントの直ぐ上、または直ぐ下が適当だろうと考えたが、そこに追加する手段が見つからなかった。 コメントにどうにかして加えるしかないと考え、その方向で、試行錯誤していたところ「/wp-includes/comment-template.php」の中で「comment_form_after」、「comment_form_before」という、如何にも使えそうなフックを見つけ、調べたところ、ビンゴだった。 これらを使えば、コメント欄の前、または後ろに簡単に「zenback」を挿入できる。 この2つの関数のお陰で、大きく前進した。 そして誕生したWordPress用プラグインが「EZ zenback」である。 ダウンロード出来るように「EZ zenback」を公開したので、WordPressをお使いであれば、ぜひ、試して欲しい。 バージョン1.0は、商標表示の不足のため公開を中止。最新版をダウンロードのこと。 最新の「EZ zenback」をダウンロード しかし、まだ、大きな問題が残っていた。 「EZ zenback」の弱点は、標準のコメントシステムに依存している点である。 しかも、このブログでは、標準のコメントシステムではなく「DISQUS」を利用している。 従って、折角完成させた「EZ zenback」は、このブログでは使えない。 そこで「DISQUS」導入用のプラグイン「Disqus Comment System」を改造して「EZ zenback」に適合させることにした。 テーマの編集を避けるためのプラグイン化であったのに、今度は別のプラグインを弄ることになり、本末転倒である。 テーマの更新が早いか「Disqus Comment System」の更新が早いかで、今後の手間が決まる。 改造を加え「EZ zenback」に対応させた「Disqus Comment System」は、「Disqus Comment System for EZ zenback」の名称で公開した。 最新の「Disqus Comment System for EZ zenback」をダウンロード

Posted in WordPress, ネット・PC, 自作アプリ | Tagged , , , , , , | 4 Comments