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/

 

 

 

 

 

 

 

帰ってきた英語の時間。外人からの問い合わせ

何度か外人の問い合わせ対応をしていると、不思議と英語がデキる気がして怖いです。。 :mrgreen:

 

最近、プラグインをアップデートすると、なぜか30分もしないうちに寄付してくれた方がいました。

いやー、ありがたいです。ありがとうございます!

ってか早くないですか?ほんとにちゃんとプラグイン使いました??あなたの国はいま何時ですか???

ただのすれ違いのような気もしますが。でも、ありがとう! 🙂

 

今回もプラグインをアップデートした後、さっそく何件か問い合わせがありました。

wordpress.orgのサポートフォーラム、WP Admin UI Customizeのマルチアドオン購入者、直接私宛にメールをくれた方。

私宛に直接メールを送る方は初めてなので、完全にスパムと勘違いしてましたよ。マシューさん。

 

今回の問い合わせは今までと違っていました。

今までは

 

How can I add custom post types to the menu?

カスタム投稿タイプをメニューにどうやって追加できますか?

 

みたいなシンプルな質問だったので、どちらかと言えば答えやすかったです。

でもやはり、長文のメールや初めて聞くような熟語?はなかなか解読&解釈するのが難しいです。

md5で暗号化された文字列を複合化している気分です。 😐

 

今回の問い合わせ。サポートフォーラム経由で、

Like a fool….

 

と文章がはじまり、その後に4行ぐらいのメッセージが。

Like と付いているから、多分プラグインを好いくれているのかな?それは良かったと思いGoogle翻訳で翻訳してみると、、、

 

愚か者のように…..

 

😳

 

えっ?Like a fool ってそういう意味なの?Google翻訳の間違いじゃないの??

確認の為、Google検索で「Like a fool」で検索。すると、、

いやー。いやーーー。やっぱりおろかものーーー 😆

 

ここでおろかものは、プラグインをアップデートしたことで、何か重大なトラブルでもあったのかな…。と考えてみました。

 

でも何も思い浮かびません。とりあえずおろかものは、翻訳を続けてみました。

I removed the custom admin panel links from the administrators menu.

私は管理メニューからカスタム管理パネルリンク?を削除しました。

 

カスタム管理パネルリンク?っていったい何??プラグインの設定リンクの事…かな。

 

Now it tells me i do not have permission to view any of the links of this module.

教えて、私は権限を持っていなくて、このモジュールのいくつかのリンクが表示されません。

 

うーん、この訳は合っているかな。。多分あっていると思うけど。。モジュール?

でも、tells me って使う時もあるんだ。ひとつじゃなくていくつかを教えて欲しいってことかな。

 

I need to find the value that it stores in wp_options and then delete it and reinstall the module.

私はwp_optiionsから値を見つけて削除し、再インストールする必要があります。

 

この、storesって何でしょう。。翻訳をかけても、店。 that it stores 。その店?ここはちょっと分かりません。

というより、再インストールする必要があります。という訳も変だとは思っていますが、他の訳が分かりません。。

 

Could you detail what i need to be removing?

私は削除する為に何が必要か詳しく教えて?

 

あ、なるほど。多分メニューを誤って削除した、自分自身に言っているのかな?Like a foolって。

値を削除する必要があるかどうかって事なのか。

 

とりあえず、削除する必要うんぬんじゃなくて、メニューが表示されればいいのかな?と思い、私はこう返事をしてみました。

I was maybe understand the problem.

The first way
To reset the user roles.
http://sample.com/wp-admin/plugins.php
Settings link from here.

The Second way
Delete the value of the side menu from wp_options.
option_name is wauc_sidemenu_setting.

I'm sorry if you are not resolved.
In addition, please contact me.

私は多分問題を理解しました。

最初の方法
ユーザー権限をリセット。
設定方法はここです。

次の方法
wp_optionsからサイドメニューの値を削除してください。
option_name はwauc_sitemenu_settingです。
もし解決しなかったごめんなさい。
また、お問い合わせ下さい。

 

たぶん、これで大丈夫だろう。。maybe…。

 

そういえば、日本のwordpressのサポートフォーラムでも、的確な回答をするのって結構大変です。

たまにサポートフォーラムで回答したりしていますが、

PHPが全く分からない方もいれば、データベースの存在を知らない人も、目の前の問題だけを質問していてその背景で何をしようとして、そうなったのかが書かれていなかったり。

日本語のサポートでも結構大変だなぁと感じています。

 

それが英語になると、解読だけでも大変です。。

普通に外人に返答が出来る方達は本当に凄いですね。

羨ましいです。首の後ろにUSB挿すことが出来て、コピー出来たらいいのに。といつも思います。

 

ちなみに最近、少し学習?しました。わざとカタコト?みたいな感じで返事を出すようにしました。

自分で書いた文章を、3つか4つに分けた一文形式みたいな。

たとえば先ほどの、「次の方法」の説明部分。

日本語だと、「****テーブルの****が****の値を削除してください。」と一行で書けるんですが、これを機械翻訳すると、英語素人の私でも、「う~ん、これは変。」となんとなく思います。

かといって、長文をかける分けでもないので、

 

「 ポニョ、ソータ、スキ! 」

 

みたいな感じで分けて返事をしています。

きれいな英語というよりは、とにかく伝わる事を第一。にしています。

 

Thanks for the response,

all fixed!

 

なんて返事が返ってきた時はやっと少し落ち着けます。返事が返って来ない時が、不安です。

英語の解釈を間違ったのではないだろうか。。なんて。

 

解釈を間違っていたら、バグを取ったり修正したりすることすらも出来ません。 🙁

グローバル化の波を、地味に感じています。

 

 

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/

今話題のブルートフォースアタックの対策 (LITE?

最近ブルートフォースアタックという言葉をよく聞きますね。

 

多分あっていると思いますが、まずは認識。

ブルートフォースアタック = 総当たり攻撃。数打てば、いつかは一発あたるでしょ。的な。

 

怖いですね。でも私のブログなんてそんな対象にならないだろう、と思っています。

そんななか、WordPressのフォーラムで、たまたまあがっていたのが、

IDやパスワードを空白でアタック

されるというような内容でした。

へーそんなアタックも存在するんだ。もしやるとすれば、ログイン画面のURLを特定する為にかな?なんて思ったり。

ちょっと気になったので、「ブルーフォースアタック 空白」で検索してみました。

すると・・・なんと!Googleの検索窓の直下にこんな表示が。

次の検索結果を表示しています: ブルーフォースアタック 空白

あ、ブルーじゃないんですね。ブルートなんですね。

真剣にこの記事を読まれていた方へ。大変失礼しました。ここから下は、ちゃんとしています。

 

で、検索結果2件目ぐらいのYahoo!知恵袋の質問に目がいきました。質問は、

「こんな事ここで聞くのはお門違いかもしれませんが、 8文字のブルートフォースアタックってどれくらいの時間を要しますか?」

という内容。ちょっと気になりました。

回答者の計算は、私には全く理解できませんでした。そんなことはおいといて、その回答は、

5.8×94×94×94/60/60/24≒約55日

という結果だそうです。後ろの60/60/24は1日の事か。でもこの94って何なんだ?w

いや、その前に。突破される時間ってそんなに早いの??

 

もちろんこれは、8文字のブルートフォースアタックの場合。ログインのパスワードなんかがこれにあたると思います。ユーザーのIDも分からなければ、もっと時間を要するはずです。

でも、最近WordPressへのブルートフォースアタックは、ユーザーIDを「admin」としての攻撃が多いようです。

そう、何をかくそう…かくしていない…このブログも…。 😳

 

ということで対策しよう( Liteだよ

ちなみに私の場合ですが、サーバはロリポップを使用しています。

幸い、ロリポップはその対策として、「WAF(ウェブアプリケーションファイヤーウォール)」という機能を実装してくれました。

なるほど!これで万時解決!

 

よし、コンパネからWAFを設定しよう!

という事で設定しました。すると…

記事の更新やコメントがたまに返せない等になる(エラーとなる)」

事が発生しました。う~ん、本当にWAFの設定の影響かな?

WAFの機能を切ってみました。すると・・・

記事やコメントがほぼ100%更新

う~んw。

まぁ、いいや。他に何かWordPressか、PHPか、.htaccess系の設定を変更すると、使えるようになるのかな。

 

で、次。

よくあるパターンとして、ユーザー名を変更しよう!という事が多いと思います。

よくある攻撃対象のユーザーIDが「admin」が多いから、というのが理由として多いようです。

 

ユーザー名変更するとなると、記事の作成者も変更しないといけないのか~。ちゃんと変更できたかどうかを確認するのも大変そうだな~。途中で何かエラーが出たら嫌だな~とか、ネガティブな事をとりあえず考えてみました。

で、少しポジティブに、ユーザー名を変更しようと色々と調べていると、WordPressのフォーラムでこんな記事が。

ユーザー名をadmin以外にしてもセキュリティ上の意味は無いのでしょうか

読めばなるほど。よく考えれば確かにそうですね。

admin決めうちでアタックしてくるものは防げる

そして、決め手となる記述が。

補足ですが、twitterでも同様のことがいえますね。
URLを調べればログインIDが分かります。

twitterはあまり使っていないので詳しい仕組みは分かりませんが、そうなるんですね。

ユーザーIDを変更する事自体も、何割かアタックは防げそうですね。

かといって、対策を大きくするのも…。どうかな~。ブログのアクセスが多い訳でも無いし。大事な事だとは分かっているけれど、セキュリティはいたちごっこだし、超機密情報を持っているわけでもないし。

よし、手っ取り早い方法として…。

 

結論

「パスワードを30文字」ぐらいにしよう。

という結論に達しました。これなら、パスワードを決めるだけ。そして出来る限りランダムな英数字+記号を混ぜまぜと。

30文字ぐらいなら、どれくらいの時間が掛かるんでしょうか。

 

追記

よくあるコメントを投稿する時の画像キャプチャの文字列を入力しないとコメントができない仕組みを、ログインにも出来ないんでしょうか。。そんなプラグイン無いかな。

 

 

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/

wordpress plugin Post Lists View Custom version up 1.4.1

様々な一覧画面のカスタマイズができる

Post Lists View Custom

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

最新バージョンは1.4.1。

 

 

やったこと

一覧画面にアイキャッチ画像やカスタムフィールドに指定している画像を表示することができますが、
このサムネイル画像のサイズを自由に変更できるようになりました。

サムネイル画像サイズ設定画面
サムネイル画像サイズ設定画面

 

ダウンロードはこちらです。

http://wordpress.org/extend/plugins/post-lists-view-custom/