Tag Archives: WordPress

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

SyntaxHighlighterとWordPress用プラグイン

私も「SyntaxHighlighter」ライブラリを使って、ソースコードの強調表示を行うのプラグインを作成しているが、今回は「SyntaxHighlighter」ライブラリについての技術情報の簡単なまとめとライバル?との機能比較を兼ねた「SyntaxHighlighter」ベースのWordPress用プラグインの比較をしてみる。 参考:ソースコードを綺麗に表示するプラグイン 「SyntaxHighlighter」という言葉は、単にソースコードの強調表示を行う機能やアプリを指す場合も多いが、この記事で言うところの「SyntaxHighlighter」とは、Alex Gorbatchev氏がJavaスクリプトで記述して公開している強調表示用のライブラリを指す。 Alex Gorbatchev氏のSyntaxHighlighter 「SyntaxHighlighter」ライブラリの利点は、Javaスクリプトで記述されている点にある。 そのため多少のカスタマイズが可能なサイトであれば、比較的、簡単に導入できる。 しかし、Javaスクリプトであるが故にブラウザの種類、バージョン、設定によっては、上手く強調表示されない可能性がある。 また、サーバーから送信されるソース自体が強調表示されているわけではなく、ソースを受け取ったブラウザがJavaスクリプトで処理し、強調表示に変える仕組みであるため、ブラウザ上で強調表示になるまでにタイムラグが生まれる場合もある。 WordPress用のプラグインでは、「GeSHi」ライブラリをベースとしたプラグインも人気が高いが、こちらはPHPで記述されているため、(CSSの解釈は別として)ブラウザによる違いやタイムラグは起こり得ない。 「GeSHi」の場合は、PHPで記述されたサイトでなければ導入できないが、そのような制限がない「SyntaxHighlighter」の利点は大きい。 しかしながら、PHPで記述されたWordPressの場合、むしろ「GeSHi」の利点の恩恵の方が大きいと言えるかもしれない。 ちなみに私は、ソースコードの強調表示用プラグインを色々と試した結果、既存のプラグインで気に入ったものが見つからなかったため自作する道を選んだが、「GeSHi」ではなく「SyntaxHighlighter」をベースにした理由は、CSSにある。 「SyntaxHighlighter」に同梱されているCSSは、十分に使い物になると思われたが、「GeSHi」の場合は、CSSを自分で作り込む必要があり、その手間を敬遠したためである。 1.SyntaxHighlighterの導入 「SyntaxHighlighter」の導入は比較的簡単である。 「3.0.x」の場合は、ダウンロードファイル内の「scripts」と「styles」フォルダをサーバーにアップロードし、<head>・・・</head>の間に、以下のような記述を追加すれば良い。 <link href="styles/shCore.css" rel="stylesheet" type="text/css" /> <link href="styles/shCoreDefault.css" rel="stylesheet" type="text/css" /> <link href="styles/shThemeDefault.css" rel="stylesheet" type="text/css" /> <script type="text/javascript" src="scripts/shCore.js"></script> <script type="text/javascript" src="scripts/shBrushXml.js"></script> <script type="text/javascript" src="scripts/shAutoloader.js"></script> <script type="text/javascript">//<![CDATA[ SyntaxHighlighter.autoloader( "applescript scripts/shBrushAppleScript.js" ,"as3 actionscript3 scripts/shBrushAS3.js" ,"bash shell scripts/shBrushBash.js" ,"cf coldfusion scripts/shBrushColdFusion.js" ,"cpp c scripts/shBrushCpp.js" ,"c# c-sharp csharp scripts/shBrushCSharp.js" ,"css scripts/shBrushCss.js" ,"delphi pas pascal scripts/shBrushDelphi.js" ,"diff patch scripts/shBrushDiff.js" ,"erl erlang scripts/shBrushErlang.js" ,"groovy scripts/shBrushGroovy.js" ,"java scripts/shBrushJava.js" ,"jfx javafx scripts/shBrushJavaFX.js" ,"js jscript javascript scripts/shBrushJScript.js" ,"perl pl scripts/shBrushPerl.js" ,"php scripts/shBrushPhp.js" ,"plain text scripts/shBrushPlain.js" ,"ps powershell scripts/shBrushPowerShell.js" ,"py python scripts/shBrushPython.js" ,"rails ror ruby rb scripts/shBrushRuby.js" ,"sass scss scripts/shBrushSass.js" ,"scala scripts/shBrushScala.js" … 続きを読む →

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

「WP Multibyte Patch」で見るWordPressのバージョン

「WordPress 日本語版」と共にその歴史を歩んできた「WordPress 日本語版」のためのプラグインがある。 「WP Multibyte Patch」である。 「WordPress 2.5 日本語版」にパッケージされて以来、現時点の最新バージョンである「WordPress 3.2 日本語版」まで、欠かさず「WordPress 日本語版」にパッケージされ続けている。 ただし、「WordPress 3.2 日本語版」以降は、ダッシュボードからWordPress本体をアップデートしただけでは更新されず、「WP Multibyte Patch」の単独更新が必要になるので注意して欲しい。 参考記事:WordPress 3.2以降へアップデートする際の問題点 WordPressは、日本版だけでなく、中国語版をはじめとして、マルチバイト文字を使う国の言葉にも翻訳されているが、マルチバイト文字を使うが故の問題を解決するプラグインをパッケージしているものは珍しいと思われる。 これは、日本語版作成チームの1つの成果だろう。 私は、既に登録されているものと勘違いしていたが、「WP Multibyte Patch」が最近になってようやく、「wordpress.org」の「Plugin Directory」に登録された。 おそらく、バージョン3.2以降の問題への対処と思われるが、ダッシュボードで更新通知が受け取れるようになった事は有難い。 WordPress本体をバージョン3.2以降にアップデートしたなら、「WP Multibyte Patch」の更新は、「WordPress 3.2 日本語版」のアップデートに頼らず、ダッシュボードで更新通知があれば、独立してアップデートすることになる。 逆に言えば、バージョン3.2未満では、意識している、していないは別として「WordPress 3.2 日本語版」のアップデートと同時に、「WP Multibyte Patch」を更新していたユーザーが殆どではないだろうか。 つまり、過去においては、インストールされている「WP Multibyte Patch」のバージョンが分かれば、WordPress本体の大まかなバージョンも特定できる可能性が高い。 次に「WP Multibyte Patch」の各バージョンと、それがパッケージされている「WordPress 日本語版」のバージョンをまとめた。 WP Multibyte Patch 1.0・・・WordPress 2.5、2.5.1 WP Multibyte Patch 1.1・・・WordPress 2.6 – 2.6.5 WP Multibyte Patch 1.1.1・・・WordPress 2.7 WP Multibyte Patch 1.1.2・・・WordPress 2.7.1 WP Multibyte Patch 1.1.3・・・WordPress 2.8、2.8.1 WP Multibyte Patch 1.1.4・・・WordPress 2.8.2 – 2.8.4 WP Multibyte Patch 1.1.5・・・WordPress 2.8.5、2.8.6 WP Multibyte Patch 1.1.6・・・WordPress 2.9 – 2.9.2 WP Multibyte Patch 1.2・・・WordPress 3.0、3.0.1 WP Multibyte Patch 1.3・・・WordPress 3.0.2 – 3.1.4 WP Multibyte Patch 1.4.2・・・WordPress 3.2 WP Multibyte Patch 1.5・・・WordPress … 続きを読む →

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

WP SyntaxHighlighter バージョン1.4 リリース

「WP SyntaxHighlighter バージョン1.4」をリリースした。 最新の「WP SyntaxHighlighter」をダウンロード このブログでは、ある程度メジャーなバージョンアップのみ案内しているため、マイナーなバージョンアップで実装された機能は案内していない。 バージョン1.3のリリース以降、7回のバージョンアップを行っており、結果、バージョン1.3.x系だけでも8種類のマイナーバージョンが存在する。 その間にかなりの機能強化が行われているが、細かい説明は省く。 バージョン1.3.9では、「SyntaxHighlighter」が本来持っている機能の殆どを実装し、設定画面でカスタマイズ出来るようにしたつもりだ。 さて、バージョン1.4の新機能の説明に移ろう。 ベータテスト中と言う位置づけではあるが、バージョン1.4から、コメントに書かれたソースコードのハイライトが可能になった。 デフォルトでは、この機能はOFFになっているため、必要に応じて設定画面で有効にする必要がある。 残念ながら、「WP SyntaxHighlighter」の最大特徴である2つのボタンは、コメントにソースコードを挿入する際には利用できない。 そのため以下ように<pre>タグを使用して直接記述する必要がある。 <pre class="brush: xhtml"> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <title>Syntax Highlighting Example</title> </head> <body style="width:500px"> <h1>Syntax Highlighting Example</h1> <p><?php echo 'Hello World!' ?></p> <p>XHTML with PHP script.</p> <div class="tabs"> TAB TAB TAB TAB TAB TAB TAB TAB TAB TAB TAB TAB <p>For 'Smart tabs'.</p> </div> <p>http://wordpress.org/</p> </body> </html> </pre> 勿論、言語以外のオプションも「class属性」で指定可能だ。 ただし、コメントでのハイライト表示が可能になると言うことは、ブログの訪問者にソースコードを含むコメントの投稿を許す事になるので注意は必要である。 勿論、エスケープされていないソースコードがそのまま表示される事がないような機能は実装している。 ソースコードは、コメントが投稿され、データベースに保存される際には、エスケープされた状態になる。 しかし、一旦投稿されたコメントを、権限を持つものが、編集、保存した際には、上記のエスケープ機能は働かない。 そのため、誤ってエスケープされていないソースコードが保存された場合は、ページを表示する直前にエスケープする仕組みも実装している。 ハイライト表示のコメントへの拡張は予想外に実装に苦労した機能でもあり、それなりにテストはしたつもりだが、ソースコードのエスケープに関しては、我ながら不細工な処理を行っているため、ソースコードに含まれる文字列によっては、エスケープによって、ソースコードを壊す可能性がある。 そのため、ベータテスト中という位置づけにした。 不具合があれば、遠慮無く報告して欲しい。 もう1つの新機能は見えない部分ではあるが、Javaスクリプトの動的読み込み機能が強化されている。(言語定義ファイルの動的読み込みではない。) 以前のバージョンでも「投稿」や「固定ページ」では、この機能をサポートしていたが、バージョン1.4からは、「ホーム」、「カテゴリー」、「アーカイブ」、「検索結果」、「コメント」にハイライト表示の対象となるソースコードが含まれるかを自動的に判断し、含まれている場合にのみJavaスクリプトを読み込むようになった。 ただし、「記事」の「抜粋」のみが表示されるページでは、ハイライト表示の対象となるソースコードが含まれている記事の「抜粋」が表示されていれば、見かけ上ソースコードが無くともJavaスクリプトが読み込まれる。 ちなみに、このバージョン1.4は、全くの予定外のリリースであった。 既にバージョン1.5の構想があり、それが本来のバージョン1.4である。 実のところ、本来のバージョン1.4であるバージョン1.5は、ほぼ完成している。 バージョン1.5では、Javaスクリプトだけでなく、CSSを含めて動的な読み込みをサポートする予定である。 ただし、この機能は、ブラウザに依存する部分を増やす結果になるため、敢えてバージョン1.4には実装していない。 将来、バージョン1.5をリリースして不評ならば、先祖帰りし、このバージョン1.4系を本流とするつもりである。

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

謎の人気プラグイン「Maribol IMDB」

「wordpess.org」の「Plugin Directory」には数多くのプラグインが登録されているが、人気のプラグインの上位は、概ね固定的で、アップデートの際にダウンロード数が跳ね上がり、多少の順位変動が見られる程度である。 ところが「Maribol IMDB」と言う見慣れないプラグインが、2011/7/20の時点で2位に食い込んでいるのを発見した。 動画の情報表示するプラグインのようだ。 ちなみに、この時点での1位は、三好隆之氏の「Contact Form 7」。 常に5位以内に食い込んでいる世界的に人気が高いプラグインである。 見慣れないプラグインが、突如、上位に食い込む理由としては、「地道にユーザー数を稼いでいたプラグインが久しぶりのアップデートでダウンロード数を稼いだ。」などが考えられるかもしれないが、このプラグインは、公開から1週間で、それはない。 また、「wordpess.org」で公開される以前に、ブログなどで公開されていた形跡もなく、公開以前に、沢山のユーザーを抱えていたとも考えにくい。 とすれば、公開直後から、人気を獲得したことになる。 「Stat」を見ると更に不思議なデータに気が付いた。 7/17には、13,539回ダウンロードされたが、翌日の7/18には一気に115回に落ち込み、更に7/19には、12,077回に回復しているが、通常ならば、これ程の大幅な変動は考えにくい。 ダンロード回数が落ち込むとしても、通常は、徐々に落ち込むものである。 更に、「Last Week」が「All Time」を上回っている点も奇妙だ。 内容的にも需要がありそうなプラグインだが、どうやったら、こんな風に一気に人気が出るのか謎である。 ちなみに私が公開しているプラグインは、「Contact Form 7」や「Maribol IMDB」の遥か後方にランキングされてる。 しかも、私が作った中でも、最も一般受けしそうな「EZ zenback」は、寒い事になっている。

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

WordPress 3.2以降へアップデートする際の問題点

先日「WordPress 3.2 日本語版」にアップデートした事を書いたが、どうも「WordPress3.2」から、ダッシュボードで本体パッケージを自動更新した際の挙動が変わったようだ。 差分のみ取得し、効率化する機能があるそうだが、単にそれだけなら機能強化であり、特に注意する必要もないのだが、どうも仕様自体が大きく変わったようだ。 結論から言えば、本体パッケージをダッシュボードで自動更新した場合、本体パッケージに含まれるテーマやプラグインは、更新されないようである。 勿論、新規インストールや、FTPでファイルを入れ替える場合は関係ない話だが・・・。 気づいていなかったが、実際、この仕様に起因する問題が「WordPress 3.2 日本語版」へのアップデート時にも発生していた。 ダッシュボードから「WordPress 3.2」にアップデートした数日後に「WP Multibyte Patch」の更新通知があったので、「WP Multibyte Patch 1.4.2」のアップデートした。 「WP Multibyte Patch」は、「WordPress 日本語版」パッケージにバンドルされているプラグインで、通常は「WordPress 日本語版」の更新と共に、最新版が配布され、単独の更新通知自体珍しい事だが、「WordPress 3.2」リリース直後という事もあり、緊急の修正が必要になったのだと思っていた。 ところが後日調べてみると「WordPress 3.2 日本語版」に「WP Multibyte Patch 1.4.2」は含まれており、つまり本体パッケージを更新した際に、なぜか「WP Multibyte Patch」は最新版に置き換わらなかった事になる。 更に調べてみると、「[wp-ja-pkg:1655] Re: 3.2.1」という記事を見つけた。 「WordPress 3.2.1 日本語版」のリリースが遅れている原因もこのあたりにありそうだ。 いずれにせよ、「WordPress 3.2.1 日本語版」のリリース時には、更新時の作業について何かアナウンスがあると思われるので注意が必要だ。 自動更新については、WordPress 本体のアップデートだけでなく、テーマやプラグインの単独自動更新ついても変更があったか否かも気になるが、プラグインの作成者は注意した方が良いかもしれない。 実際、私も、自動更新時の動きはよく分かっておらず、これは事前にテスト出来ないため、実際にリリースするまで結果は分からない。 例えば、プラグインの自動更新の際には、 プラグインを停止。 既存のプラグインのファイルを削除。 新しいプラグインのファイルを取得。 プラグインを再び有効化。 が行われると思っていたが、「WordPress-Amazon-Associate 1.7.0」への自動更新時にトラブルに巻き込まれた事から、どうもこれは間違いであることが分かった。 単に私が知らないだけかもしれないが、自動更新の際の動きについても公式なドキュメントが欲しいところだ。 ソースを見て、動きを確認しろでは、あまりにも不親切である。

Posted in WordPress, ネット・PC | Tagged , | 2 Comments

WordPress 3.2へアップデート

WordPress 3.2 日本語版がリリースされたので、早速、アップデートした。 管理パネルから自動更新したが、特に問題なくアップデートを完了し、今のところ不具合も出ていない。 バージョン3.2のシステム要件は PHP:バージョン5.2.4 以上 MySQL:バージョン5.0 以上 なっており、以前のバージョンと異なり、PHP4はサポートしていないのでアップデートする際は注意が必要だ。 レンタルサーバーによっては、この要件を満たしていないケースもあるかもしれない。 PHPとMySQLのバージョンが分からない場合は、「Health Check」プラグインなどで調べることも出来る。 また、フォーラムでは、不具合と思われる報告も見受けられるので、こちらも注意が必要だ。 バージョンアップ後に正常に動作しないプラグイン、テーマが出る可能性もあるので、不具合が出るようなら「WP Multibyte Patch」以外のプラグインを停止し、標準のテーマに切り替えてみると良いだろう。 バージョン3.2では、パフォーマンスの向上が謳われていたたが、実際、パフォーマンスは向上している様に感じられた。 地味な部分ではあるが、パフォーマンスは、重要な要素である。 管理パネルのデザインも若干変わっているが、基本的にバージョン3.1.Xの大差はなく、さほど目新しさはないかもしれない。 OFFにしている人が多いかもしれないが、管理バーの機能は更に拡張されている。 画面上のブログタイトルの表示が小さくなっているが、私は、ここをクリックしてブログを表示させていたので、少し違和感がある。 バージョン3.2で追加された機能のうち、個人的に最も気になったのがエディターの変化である。 過去のバージョンでも、ビジュアルエディターに「フルスクリーンモード」が搭載されていたが、この「フルスクリーンモード」がHTMLエディターにも拡張され、加えて「集中執筆モード」を搭載した。 ビジュアルエディターやHTMLエディターをフルスクリーンモードに切り替えると、下の画像のようになる。 これだけでも、上部にメニューを配しただけのシンプルな画面構成であるが、暫く時間が経つつ、「集中執筆モード」に移行し、メニューが消え、白紙に投稿だけが表示されような画面になる。 メニューは、マウスオーバーで復元するので、必要な時にだけ表示させる事が出来る。 集中して執筆出来るようにと言う配慮だろうが、どうせなら、使用中のテーマを使って、実際の記事のように表示してくれるモードもあっても良いように思った。 プレビューしながら書けるイメージだ。 「フルスクリーンモード」の仕様変更は、私が公開しているプラグイン、「WP SyntaxHighligher」と「SyntaxHighlighter TinyMCE Button」にも、少なからず影響を与えている。 「フルスクリーンモード」でTinyMCE用のボタンが表示されなくなってしまった。 ビジュアルエディターの「フルスクリーンモード」では、表示されるボタンが激減することからも分かるように、処理が少し特殊になったようで、普通にTinyMCEのプラグインとして追加しただけでは「フルスクリーンモード」では表示されない。 /wp-admin/includes/post.php には、 $buttons = array( // format: title, onclick, show in both editors ‘bold’ => array( ‘title’ => __(‘Bold (Ctrl + B)’), ‘onclick’ => ‘fullscreen.b();’, ‘both’ => false ), ‘italic’ => array( ‘title’ => __(‘Italic (Ctrl + I)’), ‘onclick’ => ‘fullscreen.i();’, ‘both’ => false ), ’0′ => ‘separator’, ‘bullist’ => array( ‘title’ => __(‘Unordered list (Alt + Shift + U)’), ‘onclick’ => ‘fullscreen.ul();’, ‘both’ => false ), ‘numlist’ => array( ‘title’ => __(‘Ordered list (Alt … 続きを読む →

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

SyntaxHighlighter TinyMCE Button バージョン0.7 リリース

「SyntaxHighlighter TinyMCE Button バージョン0.7」を公開した。 最新の「SyntaxHighlighter TinyMCE Button」をダウンロードする バージョン0.7では、ボタンをクリックした時に表示されるポップアップウィンドウの入力オプションのデフォルト値を設定できるようになった。 これは、あるユーザーさんからのリクエストに応えて実装した機能である。 例えば、言語を選択するドロップダウンリストから使わない言語を除外して、リストを自分好みにカスタマイズ出来る。 デフォルトのドロップダウンリストには、かなり沢山の言語が登録されているが、実際に必要な言語は限られるているはずなので、必要ないものを無効にすることでリストをスッキリと整理できる。 また、行番号が必要ないなら、予め行番号を表示しない設定にしておくことで、ボタンでの余計な操作を省くことが出来る。 なお、「使用中のプラグイン」で、特定のプラグインを選択している場合は、そのプラグインの設定に従いデフォルト値を決定しているため、この機能をフルに生かすためには「その他」を選択すると良い。 バージョン0.7では、設定項目が一気に増えたため、設定をリセットするボタンも追加した。 巷では「WordPress 3.2」がリリースされ、既にバージョンアップを済まされている方も少なくないと思うが、「WordPress 3.2」では、ビジュアルエディターのフルスクリーンモードが変更され、フルスクリーンモードでは「SyntaxHighlighter TinyMCE Button」のボタンが表示されなくなってしまった。 フルスクリーンモードへのボタンの追加方法が分かり次第、この点は改善したいと考えているが、まだ情報収集の段階である。 /wp-admin/includes/post.php を見たところ、 「wp_fullscreen_buttons」フックを使えば、何とかなりそうな気がするが・・・。

Posted in 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