Most Plugin Version up for on SSL

いやー、最近かなりバグの報告をいただいていて、なかなかブログの更新ができませんでした。

とにかく相手の症状を理解し、原因探し、解決策考え…。

なんとか最近落ち着きました。いやー、疲れました。
外国の方はあまりWordPress.orgのサポートフォーラムは使わないのでしょうか。。直接のメールの問い合わせが多かったです。

(2~5件/1日、でも英語での問い合わせはかなり大変)

今回もほぼすべてのプラグインをアップデートしました。

 

一部のプラグインは機能追加を加えたりしています。

あと、全てWordPress 3.6 にて動作確認済みです。

 

更新するまでの経緯

ユーザーから寄せられるバグの症状をひとつひとつ見ていっても、なかなか”これだ”という原因が見つからず、よくある「他のプラグインの影響じゃないだろうか」という事を想定して原因を探っていました。

ただここで、症状を報告した方が色々試した結果「あなたのプラグインを使用している場合だけこういう症状が出ます」と調べていただたいた場合はありがたいです。

●●●のプラグインを一緒に使うとバグがありました~とか(バグではないですが)、使っていてこういうバグが出ますよーと教えてくれる場合は、なんとか改善の方法を検討をする事ができますが、「ヘイ、どうなってんだよ。動かないじゃないか」みたいな報告の場合、かなり厳しいです。

どうなっているのか調べたいけど、「動かない」とだけ言われても分からない。
分かるなら、直してますよ~。。 🙁

(そんなことはおいといて)

 

ただ今回、ひつとだけ、いつもと違うバグ報告をいただきました。

そのバグの原因を探る為に、プラグインの影響やテーマ、WordPressのバージョンやPHPの設定等をもとに原因を探っていたのですが、全く見当外れな所でした。。 😳

 

ちなみに、私は英語が得意ではありませんので、バグ報告をいただいた際に、「ごめんなさい、キャプチャを送っていただけませんか?」とお願いすることが時々あります。(というより、最近は画面を見せたほうがスムーズに解決すると感じています)

その際、「自分の画面はなるべく見せたくない」という方が多いと思います。
(特に管理画面に関しては)

なので、プラグインの設定画面”だけ”送ってもらう場合が多いので、その部分だけで原因がどこにあるのかを考えていました。。

これが、原因を探すことができない原因でした。。 😳
どんなに調べても、原因不明。

次に、バグ報告をいただいた方の中に、どでかい画面キャプチャを送っていただけた方がいました。
(操作している画面を動画で送ってくれた方もいました。これは非常に助かりました。  🙂  )

そして、キャプチャと同じように設定したりしてみましたが、相変わらず。。
プラグインの設定画面に原因があると思いひたすら探っていましたが、やはり見つからず。

う~ん。分からない。(こういう時はノートPCを( ̄  ̄ )ノ⌒)

一息ついて、ふと、キャプチャを再度よく見てみると、アドレスバーにhttps
SSLでの管理画面への接続でした。

あ、確かにSSL環境での動作確認はしていなかったな~。でも、SSLでも使えるとは思うけどな。

とりあえず確かめてみないと分からないものは分からない。という事でxampp内のOpenSSLを利用して試してみました。

そして、やっと原因が分かりました。

 

 

SSLの場合だけ上手く動作しなかった

不正確ですが、一言で言うならこんな感じのバグです。

少しだけ正確に言うと、プラグインでJavascriptを読み込むように設定しています。

そのJavascriptでjQueryのSortableやDropable等を設定しているので、データが変化します。最終的にユーザーが保存するデータは、ソート後のデータです。

そしてそのソートを行う為には、その処理を記述しているJavascriptファイルが読み込み出来なければ、もちろんソートすらも出来ません。

そしてSSLの場合だけそのJavascriptファイルが読み込まれない、というバグでした。

ただ、よく分からないのが何故SSLの環境だけ?と思いました。

以前からSSLの環境でプラグインを使っている方はおそらくいると思うのですが、なぜ今になってそんなバグ…?ユーザーが増えてきたから?

と色々考えても仕方ないので、実際に試してみたら…動きました…。SSLでも。  😕

う~ん、やっぱりSSLでも動くよね。。

その後も色々試行錯誤&バグ報告くれた方と色々とやりとりをしていて、やっと分かりました。

正確に言うと、「管理画面へのアクセスはSSL、フロントへは通常のhttp」。

「アクセス」。なるほど。気づきませんでした。 🙄

 

今回の方はおそらくですが、「サイトのURL(home)及びWordPressのURL(siteurl)httpでも管理画面にアクセスするときだけはhttps」という環境で使っているのではないかと考えました。

 

SSLで試すという事で、私のほうでは動作確認の為に、WordPressのインストールからサイト及び管理画面の閲覧まで全てhttpsの環境で全て試していました。

おそらくこのバグ報告をくれた方は、インストール時はhttpでインストールしたのか、または途中でhttpに変更したのか。等をおこなったのではないかと思います。

何をしたのかはおいといて、そのような環境を想定して試してみることに。

そりゃ、いくらget_option(‘siteurl’)とかを使って、CSSファイルやJavascriptファイルを読み込もうとしても、アクセスしているプロトコルはhttpsだったら読み込めないよね。 😎

 

で、私の場合プラグインディレクトリ内のCSSやJavascriptファイルを読み込む際に、

WP_PLUGIN_URL . '/' . dirname( plugin_basename( __FILE__ ) ) . '/'

という風にプラグインディレクトリのURLパスを取得していました。

この  WP_PLUGIN_URL が https:// で管理画面にアクセスした場合、https://にならずにhttp://のままでした。

get_option('siteurl') . '/wp-content' . '/plugins'

このように取得・設定している為です。

get_option(‘siteurl’)では、いくらhttpsでアクセスしても、一般設定にて設定されているhttpでのURLを取得するのでダメでした。

 

ただ私は詳しくは分かりませんが、分かることとしては、Google Chromeの場合、https:// で呼ばれる画面から http:// のファイルにアクセスさせない仕組みのような感じでした。(具体的には何の影響でそうなるのかは分かりません。セキュリティ的な意味合いな気はしますが)

なので、全プラグイン、WP_PLUGIN_URL は使わず、

plugin_dir_url(__FILE__)

これにしました。

これだと、set_url_scheme が間に入って、WP_PLUGIN_URLで取得したアドレスに対してhttpやhttpsも書き換えてくれるような感じでした。というか、こっちで動くならこっちのほうがいいですね。シンプル。 😮

(なんか、WordPressのデバッグ機能を有効にしたら「この関数よりこっちの関数のほうがいいですよ」みたいな表示を出してくれたら嬉しいな。。便利な関数があったとしても、存在が分かりません。。) 

 

で、これで試してもらうと無事動作したようでした。

今回のケースはたまたまどでかいキャプチャと、動画ファイルをいただけたのでなんとか解決までに至りました。

めでたしめでたし  🙂

Most Plugin Nonces Version UP

今回、ほぼすべてのプラグインのバージョンアップをおこないました。

 

更新するまでの経緯

とあるアメリカ?の方からWordPress.orgのサポートフォーラム経由で「あなたにプラグインのバージョンアップ版をあげます。」と、今までにない、不思議な問い合わせ?プレゼント?がありました。

怪しいな。 😈

とりあえず、そんな気持ちはおいといて。バージョンアップ版を確認してみることにしました。

確認してみると、確かに今のプラグインに導入したほうが機能性は良くなりそうでした。

なんていい方なんでしょう! 🙂

すぐに導入させてもらいました。

 

すると、「あなたのプラグインにNoncesを導入したほうがイイヨ!」とご返事がありました。

Nonces? 全く聞いたことの無い言葉でした。何かの注意表示のこと?

プラグインの使い方について、注意を表示したほうがいいという事かな??

 

う~ん。。分かりません。 😕

こういう時は素直に「分かりません」と言う事にしています。 返事いただけたら嬉しいですが。 🙁

で、その後返事が来ました。 😮

そのNoncesはというと、

http://codex.wordpress.org/Glossary#Nonce

http://markjaquith.wordpress.com/2006/06/02/wordpress-203-nonces/

WordPress Nonces

セキュリティに関する事のようでした。(正直、長文の英語のほうはあまり理解できていません。英語力不足…。 😆 )

今回、問い合わせのあった方の意見として「あなたのプラグインにXSS攻撃から保護する仕組みを導入したほうが良い」という意見だと解釈しました。

WordPressってそんな仕組みがあったんですね。

というか、私のプラグイン、XSSから保護されていなかったんですね。。これはすぐに対応しなきゃ。。 😳

 

 

やったこと

今回はセキュリティに関する事でしたので、ほぼすべてのプラグインを更新しました。

プラグイン設定フォーム内に

wp_nonce_field()

を追記。

フォームデータの更新直前に、

check_admin_referer()

にて、wp_nonce_field()にて設定されたワンタイムトークンのチェック。

 

あとはAjax経由でデータを取得しているプラグインには、Ajaxでデータを取得する際にワンタイムトークンのチェック確認を入れました。

既に利用されている方は出来るだけ最新バージョンを使用してください。

 

WordPress Plugin Media Insert from Themes Dir

久しぶりに新しいプラグインを作りました。

このプラグインは、テーマディレクトリ内の画像を、投稿編集画面の「メディアを追加」から挿入できるようにするプラグインです。

 

と、そのままプラグインの説明に入ろうと思いましたが、今見ているこのページ、勝手ながら”二部”に分けることにしました。

  • 第一部 : プラグイン開発中のうっぷん。
  • 第二部 : プラグインについてのご説明

プラグインの説明を期待されている方が9割以上もしくは10割だと思います。

このプラグインを作ることに、予想以上に時間が掛かり、ちょっとだけうっぷんが溜まっていたので、その鬱憤晴らしを書きました。。鬱憤については読まなくても、プラグインの使用方法に全く影響しません。

プラグインを使いたいだけの方はそのままプラグインの説明までスクロールしてください。 😉

 

↓ここからうっぷん開始。

だいぶ、だいぶ、疲れました。。 😳

このプラグインを必要とする方はあまりいないと思います。あと、このプラグイン自体使ってみればわかりますが、もの凄い機能を持ったプラグイン。という訳ではありません。

なので、気持ち、ぱぱっとやって、動作チェック。としたかったのですが、知識やスキルが少なかった分、想像以上に時間が掛かりました。

 

ちなみに、なんでこのプラグインを作ったかと言うと、別の記事「WordPressのマルチサイト作成、運営で思ったこと」に書いていることへの対策方法として、作りました。

私の場合、マルチサイト内の投稿の本文にテーマディレクトリ内の画像を挿入することがよくあります。

テーマフォルダ内の画像を投稿に挿入する方法として、

  1. 「メディアを追加」を押して、「URLから挿入」を選択
  2. ブログのURLをコピペ
  3. /wp-content/ からはじまり、テーマフォルダ内の画像が入っているフォルダまでのパスを記入
  4. テーマフォルダ内の挿入したい画像ファイル名をコピペ
  5. 最後に、整列やらリンクやら選んでキャプションやらを書いて挿入

という感じだと思います。

テーマフォルダ内の画像を投稿に挿入するまでのこの手順。初めは何とも思っていませんでしたが、投稿が多くなるにつれ、かなり手間でした。 🙁

 

挿入したはずの画像が表示されない。

「あれ?画像のパス合っているはずだけど…。」入力したパスが微妙に違っていたり。 🙁

FTPでサーバに接続してファイル名を確かめにいったり。。 🙁

これをもっと手軽に、今の「メディアライブラリ」のように、画像の一覧から選択して、はい、そーにゅー。

手間を最大限省きたかったので、このプラグインを作りました。

 

また、作りあがるまでの途中についてですが、

このプラグインの作成に取り組み始めるまでは、簡単にこうこう、こうして、こうすれば、あぁん違う。もっとこうぅ。とか、「media_upload_tabsにフックして、あれこれすればいけそうかな」と考えていました。

色々と試してみました。

が、結果、できませんでした。メニューやページは作れても、挿入が出来ない。 😕
(他にやり方があるのかな…。結構試しましたが出来ませんでした。)

とにかく、まだ情報が足りないようなので、色々とググってみましたが、あまり参考になるような情報が出てきませんでした。

うーん、まいった。 😥

 

誰か他の方が、同じ機能のプラグイン作ってくれていたら嬉しかった。。(それとも既にあったりするのかな。。だとするなら、そのプラグインを探しきれなかった。。)

情報が無い以上しょうがないので、フックさせる所を探す為に、WordPressのコアファイルとひたすらにらめっこ。 😯

そして、にらめっこをし続けて、なんとなく出た結果。
Javascriptで動作させているような感じでした。

「media-view.js」あたりがメディアを挿入する際の画面レイアウトを作成しているような。

 

jQueryはよく触る機会があるので、なんとかなるだろう。
と思い、media-view.jsのコードとひたすらにらめっこしました。

ひたすらにらめっこした結果、今回のプラグインを作成する為に必要な知識やスキルは全く別物でした。 :mrgreen:

Backbone.jsってなんですか?Underscore.jsってなんですか? 😯
<script type=”text/html” id=”tmpl-attachment”>ってなんですか?

そんな状態です。。見なけりゃ良かった。。でも見ないと進まない。。

そもそも、Backbone.jsというフレームワークの存在を私は知らなかったので、フレームワークを使用している存在に気づくまでに時間が掛かりました。

MVCについては何となーく…なら分かりますが、Selectionってなんですか? 🙁
なんだこのinitializeやら、eventの設定の仕方は…。
どういう仕組みでやっているのか理解するまでに、かなり時間が掛かりました。。

Backbone.jsについての情報をぐぐりました。
基本中の基本、みたいな所は何となく分かりましたが、これをWordPressの場合にどういう風にしたらいいのかが分からない。。

ひたすらググって、なんとかアテになりそうな情報を見つけました。 😮

Add a menu item to WordPress 3.5 Media Manager

こちらのページの情報が、今回のプラグインを作るための情報として一番の候補になり、この情報をもとにあーだこーだをひたすら、ひたすらやって、なんとかできました。。。。あー。

↑グチ、ここまでです。人間って言葉に出すだけで気が晴れる生き物ですね。私だけかな。。。

 

ここから、プラグインの使い方について記載しています。

 

使い方

いまのところ、WordPress 3.5 ~ 3.5.2 までの対応となっていますのでご注意ください。
(試してはいませんが、3.5未満はおそらく動かないと思います。3.5から画像挿入の機能が変わったはずなので。)

私のプラグインは基本、WordPress 3.4.2 からの対応をしているのですが、今回は対応させませんでした。

サポートフォーラムなんかで3.4.2への対応希望者がいれば、対応するかもしません。 😉

 

インストール方法は、プラグインインストールの画面から「Media Insert from Themes Dir」と検索すると、そのまんまのプラグイン名が出てくると思うので、それをインストールして有効化してください。

インストールした後、有効化しても画面上、何も変化もなく設定画面も存在しません。

ちょっとわかりづらいですが、これで使用可能な状態です。

 

投稿編集画面などで「メディアを追加」をクリックすると、「URLから挿入」の下に「テーマディレクトリから挿入」のメニューが追加されます。

メニュー追加部分
メニュー追加部分

 

「テーマディレクトリから挿入」を選択すると、現在選択しているテーマディレクトリ内の画像やフォルダを読み込み始めます。読み込みが完了すると、画像とフォルダ一覧が表示されます。

画像・ファイル一覧
画像・ファイル一覧

 

もちろん、サブディレクトリ内の画像も読み込みます。 🙂

あとはいつも通り、投稿に挿入したい画像を選んで、リンクをつけるなり整列を変更するなりして、「投稿に挿入」をクリックすると本文に挿入できます。

画像選択時
画像選択時

 

簡単に、テーマフォルダ内の画像を投稿に挿入できます。

 

どうぞご利用ください。

Media Insert from Themes Dir

WordPressのいろいろなデバッグ方法

WordPressをカスタマイズしていると、何かとエラーが出たりします。

その際によくあるデバッグ方法として、config.phpへの記述に

define('WP_DEBUG', true);

と記述し、エラーを表示させる機能があります。

ちなみにこれ、エラー表示を抑制するかしないかの機能。

 

もっと詳しく言うと、wp-admin/plugins.phpの140行目あたり、

if ( ! WP_DEBUG ) {
 error_reporting( E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_ERROR | E_WARNING | E_PARSE | E_USER_ERROR | E_USER_WARNING | E_RECOVERABLE_ERROR );
 }

こんな記述があったりします。

 

でも、WP_DEBUGをtrueにしても、

プラグイン有効化時のエラー
プラグイン有効化時のエラー

プラグインを有効化する際のエラーは表示してくれません。

何かいい方法無いかとぐぐってみましたが。

WordPressって、デバッグ方法について色々と機能が準備されていたんですね。

ほんと、知らないだけでした。

Debugging_in_WordPress

 

※この記事の情報は、記事を書いている時の最新バージョン、WordPress 3.5.1 をもとにしています。

 

define(‘WP_DEBUG_LOG’, true);

これはどんな機能か調べてみると、エラーの内容をログとしてwp-content/に記録してくれる機能。

詳しく見てみたい方は、wp-includes/load.php の 274行目付近を参照ください。

試しにconfig.phpに追加してみると、

エラーログファイル
エラーログファイル

debug.logというファイルが作成されました。その中身はこうでした。

 PHP Warning:  var_dump() expects at least 1 parameter, 0 given in

なんにもパラメータ無いじゃん。このxxxxやろう!! というエラーだと思いますね。

プラグインを有効化する際(ヘッダーを出力する前)のエラーを確認したい時に、とても便利な機能だと思います。

また、エラーの表示は出したくないけど、エラーが出た場合は記録だけしておきたい時には便利です。

たまにしか出ないエラーなんていうものだって、ありますもんね。

クライアントにWordPressをCMSとして提供している場合は、この機能を有効にしておいて、メンテナンスとしてこのログを確認することにも使えそうですね。

 

 

次は、

define(‘WP_DEBUG_DISPLAY’, true);

なんとなく英語を解釈すると想像できますが、念の為調べてみました。

wp-includes/load.php の 269行目付近。

php の display_errors を true にしているだけのようですね。エラーを表示するor しないを選択する機能のようです。

 

お次は、

define(‘SCRIPT_DEBUG’, true);

スクリプトデバッグ?何のスクリプト?と疑問です。で、調べてみました。

で、SCRIPT_DEBUGで条件分岐しているところがいくつかありました。

まずは、includes/class-wp-editor.php の551行目。

$suffix = ( defined('SCRIPT_DEBUG') && SCRIPT_DEBUG ) ? '_src' : '';

うん。$suffix。なんでしょうこれ。見る限りは、SCRIPT_DEBUGがtruだったら、_srcをいれる。

それがどういう役目なのか分からなかったので、$suffixが何に使われているのか調べてみると、

tinyMCEPreInit = {
 base : "<?php echo self::$baseurl; ?>",
 suffix : "<?php echo $suffix; ?>",

ビジュアルエディタのTinyMCEの何かのsuffixの値として、_src という値を入れているようです。

これがまたどういう役目なのか分からないので、もっと追っていこうと思いましたが、そもそもこの単語、どういう意味なんだろうとGoogleで翻訳してみました。

suffix = サフィックス。接尾。接尾語。

つまり、何かの接尾に_srcをつけるものっぽい。何かがさっぱり分からりません。

ただ、TinyMCEに使われている事は確かだと思いましたので、wp-includes/js/tinymce/tiny_mce.jsをひたすら検索していると、

"themes/"+q.theme+"/editor_template"+k.suffix+".js"

suffixが使われていますね。

おそらく、themes/advanced/editor_template_src.js というファイル名になるはず。

念の為確認すると、

  • editor_template.js
  • editor_template_src.js

2つ、ファイルがありますね。違いが分からないので開いてみましたが納得。

srcが無いほうのファイルは、圧縮されていました。(改行やスペース)

srcがあるほうは、デベロッパー向きでコードが見やすいものですね。

納得した後に他のコードも追ってみると、あとはほとんどがjsファイルに min を付けるか付けないか等の判別(圧縮ファイルを読み込むかどうか)で使われていました。

 

ただ、一箇所違う部分がありました。

wp-includes/script-loader.php 850行目付近

if ( ! is_admin() || ( defined('SCRIPT_DEBUG') && SCRIPT_DEBUG ) )
 $concatenate_scripts = false;

$concatenate_scripts ? これは一体なんでしょう。よく分からないので、変数名を翻訳してみました。

concatenate = 連結

連結。なんでしょう。。分かりません。Javascriptファイルの連結?しかも管理画面内のとき。

 

ふと考えると、WordPressのファイル読み込み設定は、

http://サイトURL/wp-admin/load-styles.php?c=1&dir=ltr&load=admin-bar,buttons,media-views,wp-admin&ver=3.5.1

このようになっています。もしかして、この連結のことかな?

SCRIPT_DEBUG をtrue にしたりfalseにしたりして、管理画面内のソースをにらめっこしてみると、trueにした時はbuttons のcssやnav-menusのjsなど、cssやjavascriptファイルをひとつずつ読み込む設定になる仕組みとなっていました。

こうやってみると、WordPressって多くのJSファイルを読み込んでいるんだな~と実感。それでいてよくあまりエラーが起きません。すごいな。。 😉

この機能は、普段のプラグインの開発やテーマの作成では使わないようなデバッグ機能かもしれません。

 

お次は、

define(‘SAVEQUERIES’, true);

クエリをセーブ。ログとして保存するのかな?分からないので探ってみました。

wp-includes/wp-db.php の1195行目あたり、

if ( defined( 'SAVEQUERIES' ) && SAVEQUERIES )
 $this->timer_start();

~

if ( defined( 'SAVEQUERIES' ) && SAVEQUERIES )
 $this->queries[] = array( $query, $this->timer_stop(), $this->get_caller() );

1つめのやつはtime_start()なんで、おそらく何か時間を開始していると解釈しました。

念の為確認してみましたが、microtime()で取得した値を変数に入れているだけのようです。

 

2つめの部分ですが、

 $this->queries[]

これがよくわからない。$this->queriesへ配列として追加。

よく分からないので $wpdb->queries を出力してみました。

Array
(
 [0] => Array (
 [0] => SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'
 [1] => 0.0027470588684082
 [2] => require_once('...省略...'), wp_not_installed, is_blog_installed, wp_load_alloptions
 )
)

↑省略しています。require_onceの中身。長いので。

クエリが出力されました。

 

ただ、queriesに入るクエリは、どういったタイミングのクエリなんでしょう。

と思い、この関数名を見ると、

function query( $query )

$wpdb->queryで実行されたクエリ全てが対象のようです。

 

今回は何のフックもせずに、$wpdb->queryを実行したのでクエリがひとつしか出力されませんでした。

なので試しに、$wpdb->queriesをadmin_footerにフックさせて実行してみました。

結果、やっぱり$wpdb->queryを実行したクエリの情報を格納しているようでした。

クエリがちゃんと実行できているかどうか、予定通りのクエリを発行しているかどうか、確かめるには丁度いい機能ですね。

プラグイン開発者でデータベースをよく使用してテストする場合は、嬉しい機能です。

 

 

プラグインのデバッグにいいもの

Debug Bar

作成者にwordpress.orgが含まれているので安心して使えそうです。

ただ、私はこのプラグインの使い方がいまいちよく分からないので、使ってはいません。

Developer

作成者にAutomatticが含まれているので安心して使えそうです。

 

 

クライアントに納品するWordPressの管理画面カスタマイズ vol.6

管理画面のカスタマイズするところ、探せばたくさんありますね。

前回はクライアントに納品するwordpressの管理画面カスタマイズ vol.5 にて、クライアントへダッシュボードを使って、クライアントへのお知らせ表示をしました。

  1. クライアントに納品するwordpressの管理画面カスタマイズ vol.1
  2. クライアントに納品するwordpressの管理画面カスタマイズ vol.2
  3. クライアントに納品するwordpressの管理画面カスタマイズ vol.3
  4. クライアントに納品するwordpressの管理画面カスタマイズ vol.4
  5. クライアントに納品するwordpressの管理画面カスタマイズ vol.4.5
  6. クライアントに納品するwordpressの管理画面カスタマイズ vol.5
  7. クライアントに納品するwordpressの管理画面カスタマイズ vol.6

 

今回は投稿画面のカスタマイズとなります。

デフォルト投稿編集画面
デフォルト投稿編集画面

この画面を、クライアント向けにカスタマイズする方法です。

 

まず最初。いらないものはレッツ削除。

すぐに思いつくものは「ヘルプタブ」という名称となるのかは分かりませんが、それ。

ヘルプタブ
ヘルプタブ

まずはこのヘルプタブを削除したいと思います。

今回は簡単にヘルプタブと表示オプションタブを削除することができるプラグイン「Screen Options and Help Show Customize」をインストールして有効化して、そこから削除の設定をしました。

※使い方はWordPress プラグイン Screen Options and Help Show Customizeをご覧下さい。一応使い方を見なくても簡単に設定できるようには作っています。

 

できましたか?ついでに表示オプションも必要ないなら一緒に削除してもいいと思います。

ヘルプタブ削除後
ヘルプタブ削除後

あ、必要の無いメタボックス(タグとかスラッグとかリビジョンとか)は、表示オプションタブを削除する前に非表示にして、表示オプションタブを削除すると良いと思います。

 

投稿画面カスタマイズの本題、ビジュアルエディタ

ちなみに、デフォルトのテーマ(TwentyTwelve)でのビジュアルエディタはこうですね。

ビジュアルエディタ-デフォルト
ビジュアルエディタ-デフォルト

 

H2タグやH3タグやul liタグなど、このような表示です。

ちなみに、フロントのサイト(一般のユーザーが見るサイト)のデザインを変更(style.css)しても、このビジュアルエディタの部分は変更されません。

ビジュアルエディタのCSSは別で用意されている為です。

で、このビジュアルエディタのH2などの部分にも、デザインが適用されるようにカスタマイズしていきます。

 

先に

フロントサイトのコンテンツ部分のCSSを以下のように設定しました。

.entry-content {
 background: rgba(0, 0, 0, 0.06);
 padding: 20px;
}
.entry-content h2 {
 font-size: 30px;
 line-height: 38px;
 background: rgba(195, 87, 0, 0.4);
 padding: 8px 22px;
}
.entry-content h3 {
 font-size: 22px;
 line-height: 28px;
 background: rgba(25, 100, 128, 0.4);
 padding: 8px 22px;
}
.entry-content h4 {
 font-size: 18px;
 line-height: 26px;
 padding: 8px 22px;
 color: green;
}
.entry-content ul {
 margin: 0;
 paddign: 0;
}
.entry-content ul li {
 color: red;
}

 

で、このCSSと同じものを、ビジュアルエディタにもこれから適用していきます。

デフォルトのテーマのままだと、黒字しかないので上手く適用されているのか分からなかったので、上記はCSSが適用されているどうか分かりやすいようh2やh3の背景色を適当に変更しています。

デザイン変更後のフロント
デザイン変更後のフロント

 

フロントのコンテンツ部分はこれでCSSが適用されている事が分かりました。

次に、本題のビジュアルエディタのCSS設定です。

 

デフォルトテーマ(TwentyTwelve)のfunctions.phpをくまなく探せば分かりますが、適用するためにはまず、

add_editor_style();

という関数を、functions.phpに記載します。

※フックを用いて実行させてください。具体的には例えば↓

function mytheme_setup() {
  add_editor_style();
}
add_action( 'after_setup_theme', 'mytheme_setup' );

 

実行すると、テーマディレクトリ内のeditor-style.cssというCSSファイルをビジュアルエディタに読み込む設定をしてくれます。

あとは単純に、テーマディレクトリ内にeditor-style.cssというファイルが無ければご自身で作成して、上記のCSSを適用すればOKです。

※注意 : ビジュアルエディタ内に entry-content というクラスはありません。

なので、.entry-content となっている部分を、ビジュアルエディタ内の mceContentBody クラスなどに変更してください。

 

たまに記述したCSSが適用されない場合があります。
この場合は、ファイル名が微妙に間違っているか、キャッシュが原因だったりします。

ブラウザのF5や更新ボタンを押しても、なかなか更新されない場合もあります。

その場合は、キャッシュを削除するか、スタイルシートを直接ブラウザから一度開いてください。

chromeでのスタイルシート読み込み一覧
chromeでのスタイルシート読み込み一覧

キャッシュが残っていると、ファイルを開くと真っ白だったり古いCSSの記述だったりします。この場合はキャッシュが原因なので、ここで更新をし、CSSファイルの内容が変われば、ビジュアルエディタにも記述したCSSが適用されます。

ビジュアルエディタへのCSS適用後
ビジュアルエディタへのCSS適用後

これでビジュアルエディタにもフロントサイトと同じようにCSSの適用ができました。

これで完了!

と思います。

 

が、よーく考えて下さい。フロントサイトのCSSを触る時って、これからも発生しますよね。

だとすると、同じようにeditor-style.cssも触らないと同じデザインが適用されません。

同じスタイルを適用するだけなのに、もう一度同じような事をする…。ちょっと手間ですね。 😕

 

ビジュアルエディタとコンテンツ部分のCSS適用が1箇所で済めばいいのに。

と思った方は、以下の続きの記事は参考になると思います。

ということで次は、ビジュアルエディタのCSSとフロントサイトのCSSをひとつにまとめる(コンテンツ部分のスタイルを一つにまとめる)方法です。

 

ビジュアルエディタとフロントサイト共通のCSS

どちらにも読み込む為のCSSファイルを先に作成します。

今回は front-content.css というファイルを、コンテンツ部分共通のCSSとして使うことを想定して進めます。

先ほど、ビジュアルエディタにCSSを適用する方法として、 add_editor_style() を使用しましたが、もうひとつこの front-content.cssを読み込ませます。

function mytheme_setup() {
  add_editor_style();
  add_editor_style( "front-content.css" );
}
add_action( 'after_setup_theme', 'mytheme_setup' );

※@importでCSSファイルを読めばいいじゃないか。と思われる方もいるかと思いますが、importだとブラウザのパフォーマンスに影響が出るという事例もあったりするので、今回は追加で読み込ませる方法をとっています。
ご自身のお好みの方法で読み込ませて下さい。

これで、ビジュアルエディタに「editor-style.css」「front-content.css」の2つのCSSが読み込まれるようになりました。

もともとのeditor-style.cssはビジュアルエディタのCSSをリセットする目的等で使用されるといいと思います。

先ほどの、ビジュアルエディタに適用させていたCSSを、front-content.cssに記述します。

が、両方のコンテンツ部分に適用させるために、合体? 😎 させます。

front-content.css

.entry-content, .mceContentBody {
 background: rgba(0, 0, 0, 0.06);
 padding: 20px;
}
.entry-content h2, .mceContentBody h2 {
 font-size: 30px;
 line-height: 38px;
 background: rgba(195, 87, 0, 0.4);
 padding: 8px 22px;
}
.entry-content h3, .mceContentBody h3 {
 font-size: 22px;
 line-height: 28px;
 background: rgba(25, 100, 128, 0.4);
 padding: 8px 22px;
}
.entry-content h4, .mceContentBody h4 {
 font-size: 18px;
 line-height: 26px;
 padding: 8px 22px;
 color: green;
}
.entry-content ul, .mceContentBody ul {
 margin: 0;
 paddign: 0;
}
.entry-content ul li, .mceContentBody ul li {
 color: red;
}

ビジュアルエディタで問題なくCSSが読み込まれましたか?

問題が無ければ、あとはフロントサイトにも追加でfront-content.cssを読み込ませてください。

header.phpに書くなり、wp_headerにフックさせるなりで適用させれば、コンテンツ部分のCSSの管理が1箇所で管理できるようになります。

私はたまにやってしまいますが、

フロントサイトのCSSは設定したが、ビジュアルエディタには適用してなかった。。 😥

なんて事には、多少はなりづらくなると思うのでおすすめです。

 

wordpress plugin Post Lists View Custom Version UP 1.5.1

WordPressの一覧画面のカスタマイズをするプラグイン、

Post Lists View Custom

のバージョンアップをおこないました。

最新バージョンは1.5.1。

 

 

やったこと

思いっきりバグがありました。

記事一覧でカスタムフィールドの項目が、選ぶことはできますが空白のままだなんて。

カスタムフィールド空白
カスタムフィールド空白

誰もそのバグについて言ってくれない。それを自分で気づく。

ちょっと悲しいバグ発見でした。

機能を増やすと、確認する箇所が多くなって大変です。。

 

ダウンロードはこちら
http://wordpress.org/plugins/post-lists-view-custom/

 

 

 

 

 

 

 

wordpress plugin Post Lists View Custom Version UP 1.5

wordpressの管理画面にある様々な一覧画面をカスタマイズする

Post Lists View Custom

のバージョンアップを行いました。

最新バージョンは1.5。

 

こちらもWordPressの3.6のローンチを待っていましたが、まだまだ掛かりそうな気配がしたので待たずにコミットしました。

 

やったこと

WP Admin UI Customizeも疲れましたが、こちらもかなり疲れました。

まず、カラム(一覧表示の列)にカスタムフィールドを指定することができるのですが、そのカスタムフィールドの値が何も無い場合、「 – 」←こんな感じで何にもないよ的な表示をしていましたが、このプラグイン+フックカスタマイズをすると、これが邪魔。なので削除しました。

あとは大幅に中身を変更しました。なんか、無駄な所があったりしたので。

データベースへ更新するoption_name値も変更しました。少し管理がしやすいようにしています。

あとは別で、Widgets List View CustomizeというプラグインもWordPress.orgにて公開していたのですが、そもそもPost Lists View Customizeの中に機能をそのまま入れたほうが楽だな。と思いましたので、利用できるウィジェット一覧もカスタマイズできるようになっています。

そして最後。ここからが一番大変なやつ。

Post Lists View Customを適用する権限を選べるようになりました。

ユーザー権限選択画面
ユーザー権限選択画面

うん、ここまでは普通です。権限を選択して、その指定された権限だけに設定されたPost Lists View Customizeの設定を適用すればいいだけの話なので。

今回はこのPost Lists View Customizeとは別に、アドオンとして、「Post Lists View Customize Multiple setups add-on」をリリースしました。

Post Lists View Customize Multiple setups add-on

機能は、権限ごとにPost Lists View Customizeが設定できます。

なぜか、日本人の方からの要望はありましたが、外国の方からの要望は一切ありませんでした。

下のキャプチャを見ると、分かりやすいと思います。

 

Added the user roles tab
Added the user roles tab

 

なんで、Post Lists View Customizeと一緒にしないの?と思う方もいるかもしれません。

 

アドオンにした理由ですか?

販売しようと考えていました。以外の理由なんてないよ。てへぺろ(・ω<)

というか販売してもプラグインユーザーが少なすぎて売れないじゃないか。
じゃあアドオンにして自分のブログに少しでもアクセスしてね。えへへへぺろ(・ω<)

なんてことをしても別にいいじゃないか! 😳

(個人的にてへぺろを使ってみたいと思いましたので、ちょっとすっきり)

 

次は、まじめなほうの理由。販売のほうはまじめな理由でしたけどね。

権限ごとに設定可能ということは、権限の分だけ設定をしなければいけないという事にもなります。

なので、この権限の分だけ、という部分が必要な方不必要な方が出てくると考えました。

どちらにもメリット・デメリットはありますので、機能を分けることにしました。

アドオン無し

一覧設定がひとつだけ。その一つの設定を適用する権限を選ぶだけ。の簡単設定。権限ごとに分けることはできない。

アドオン有り

一覧設定の数は、権限の数の分だけ。 設定するのは大変だけど、細かく権限ごとに一覧画面のカスタマイズは可能。

 

という感じです。

あとは、普通にまだまだプラグインユーザーとしての信頼や実績が少ないなと思いましたので、無料で配布しています。

 

ダウンロードはこちら
http://wordpress.org/plugins/post-lists-view-custom/

wordpress plugin WP Admin UI Customize version up 1.3.2

WordPressの管理画面UIをカスタマイズする

WP Admin UI Customizeのバージョンアップを行いました。

最新バージョンは 1.3.2

 

やったこと

本当はWordPress3.6のローンチに合わせて、最終確認をしてからコミットしようかと思って5月20日まで待っていましたが、ローンチのスケジュールがまたずれそうな感がしたので、先にコミットしました。

なので、WordPressのバージョンは今のところ、3.6 beta 3 まで確認済みです。

 

さて、やったことですが、まずバグ修正から。

管理画面のサイドメニューのカスタマイズが出来るのですが、サブメニューがひとつも無い設定をすると、エラーの表示が出ていました。ので、このバグ修正です。

次に、いくつかプラグイン内で使用できる変数を増やしました。

今まで全く気づきませんでしたが、テーマを子で使用している場合、template_directory_uriでは使用中のテーマディレクトリが上手く取得出来ませんでした。

※具体的には、親テーマが Twenty Twelve、子のテーマがMy Themeという名前で、ディレクトリ名も同じような名前だと仮定します。
使用テーマがMy Themeです。 で、そのテーマ内のfunctions.phpや他のテンプレート内からtemplate_directory_uriでテーマフォルダのURLを取得しようとすると、

http://サイトurl/wp-content/themes/twentytwelve/

になるようです。でもあくまでも親テーマなんて触ることはほぼ無いので、子のテーマディレクトリを取得できるよう、stylesheet_directory_uri を追加しました。

また、マルチサイトの場合だと現在のブログ名ではなく、ネットワークサイト名も扱えるようにしました。

次に、ここが一番難関でした。

 

投稿編集画面、固定ページ編集画面、それぞれメタボックスがありますよね。

このメタボックスで、デフォルト以外のメタボックスがあります。これを非表示にする機能。

ググっていると、「あぁ、グローバル変数の$wp_meta_boxesから取得できるじゃない」

となるかもしれませんが、実はほとんど取得できません。

(プラグインによって、フックをかける場所・タイミングが違う為)

他に方法は無いだろうか。どこかにフックをかければ取得できるんじゃない?とだいぶ、試行錯誤してみましたが、さっぱり。。

結果、思いついた方法として、「投稿編集画面」を表示すると、現在設定されているメタボックス全てを一度データベースに保存。

その後にWP Admin UI Customizeのメタボックス削除メニューから、先ほど保存したメタボックス一覧を読み込んで、非表示にするか選択する形式です。

この、「一度投稿編集画面または、固定ページ編集画面にアクセスする必要がある」という点を、英語でまた説明するのも私には難しいところです。

 

 

なんだかんだで、こんな機能を更新しましたよ。良かった寄付してね使ってみてね。

ダウンロードはこちら
http://wordpress.org/plugins/wp-admin-ui-customize/

wordpress plugin Announce from the Dashboard version up 1.2

WordPressのダッシュボードにユーザーの権限別にお知らせを表示させることのできるプラグイン

Announce from the Dashboard

のバージョンアップをおこないました。

最新バージョンは1.2。

 

 

やったこと

今までは、

  • 通常(背景グレー)でのお知らせ表示
  • 赤色での注意的な表示
  • 黄色のアップグレード的な表示
  • メタボックスとして表示

の4タイプでしたが、これに無属性(スタイル無し)の表示ができるよう追加しました。

それと複数お知らせを作成済みの際に、削除をしようと思うとひとつずつしか削除が出来なかったので、一括削除の機能を追加しました。

 

ダウンロードはこちら
http://wordpress.org/extend/plugins/announce-from-the-dashboard/

wordpress plugin Screen Options and Help Show Customize Version up 1.2.3

wordpress管理画面の右上にある「表示オプション」と「ヘルプ」のボタン表示を変更するプラグイン、

Screen Options and Help Show Customize

のバージョンアップをおこないました。

最新バージョンは1.2.3です。

 

やったこと

寄付メッセージを削除できるよう設定を追加しました。

それと、今まで一列表示で設定できるようにしていたのですが、二列表示になるよう変更しました。

少しだけ使いやすさがあがったんじゃないかな。と思います。

Screen Options and Help Show Customize 設定画面
Screen Options and Help Show Customize 設定画面

 

ダウンロードはこちら
http://wordpress.org/extend/plugins/screen-options-and-help-show-customize/