終了したイベントを自動的に過去のイベントにする

Posted on 2012年5月14日 by Sho Doi

2012/05/16追記・修正

@jim0912さんよりご指摘を頂きましたのでhome.phpのソースを修正しております。ありがとうございます。

@uemera @show_web #wbkobe WordPressは、date使うと時差分ずれるのでdate_i18n使うとよいですね。

2012年5月15日 08:15 via webReply RetweetFavorite

@jim0912

Hitoshi Omagari

var_dump(date( 'Y/m/d H:i:s' )); //string '2012/05/15 15:06:01' (length=19)
var_dump(date_i18n( 'Y/m/d H:i:s' )); //string '2012/05/16 00:06:01' (length=19)

上記をvar_dumpしたところ確かにdate()だとズレてますね。（2012/05/16 0時頃確認）
というわけでdate_i18n()を使いましょう。
関数リファレンス/date i18n – WordPress Codex 日本語版

先日おじゃましたWordBench神戸分科会の「案件で詰まっていることを晒してみる」であった以下の質問に答えてみました。
詳細については案件で詰まっていることを晒してみる #wbkobe – by shigemk2を参照。

トップページにイベントの部分があるけど、終わったら「過去のイベント」に移行したいこれを自動化するにはどうしたらよいのだろうか。

覚えている限りの仕様としては

トップの「開催中のイベント」に”2012/05/14～2012/06/01 イベント名”形式で出力
終了したものに関しては「過去のイベント」部分に同様の形式で出力

という訳で思い浮かんだのがカスタムフィールドを用いて開催日・終了日を設定、終了日の値を元に振り分けるというもの。

Custom Field Templateプラグイン設定

カスタムフィールドの設定はCustom Field Templateプラグインに任せることに。
インストール後、”設定 > カスタムフィールドテンプレート > テンプレートコンテンツ”に以下を記述。

[start_date]
type = textfield
label = 開始日
date = true
dateFirstDayOfWeek = 0
dateFormat = yyyy/mm/dd
startDate = (new Date()).asString()

[end_date]
type = textfield
label = 終了日
date = true
dateFirstDayOfWeek = 0
dateFormat = yyyy/mm/dd
startDate = (new Date()).asString()

投稿ページのカスタムフィールドテンプレートに開催日・終了日のDatepickerが追加されたのでイベント日時はここで設定。

home.phpの設定

出力部分に関しては以下の通り。meta_queryでカスタムフィールドの値を元に検索しています。meta_queryの使い方に関しては query_posts（WP_Queryクラス）でカスタムフィールドを使う：WordPress私的マニュアルを参照。

<section>
	<h1>開催中のイベント</h1>
	<?php
	$current_date = date_i18n( 'Y/m/d' );
	$args = array(
		'meta_query' => array(
			array(
				'key' => 'end_date',
				'value' => $current_date,
				'compare' => '>=',
				'type' => 'DATE'
			)
		)
	);
	$output = '';
	query_posts( $args );
	if ( have_posts() ) :
		$output .= '<dl>';
		while ( have_posts() ) : the_post();
			$output .= '<dt>' . get_post_meta( $post->ID, 'start_date', true ) . '～' . get_post_meta( $post->ID, 'end_date', true ) . '</dt>';
			$output .= '<dd>' . get_the_title() . '</dd>';
	endwhile;
		$output .= '</dl>';
		echo $output;
		wp_reset_query();
	else :
		// イベントがない場合の処理
		echo '<p>イベントないよ～</p>';
	endif;
	?>
</section><!-- /section -->
<section>
	<h1>終了したイベント</h1>
	<?php
	$current_date = date_i18n( 'Y/m/d' );
	$args = array(
		'meta_query' => array(
			array(
				'key' => 'end_date',
				'value' => $current_date,
				'compare' => '<',
				'type' => 'DATE'
			)
		)
	);
	$output = '';
	query_posts( $args );
	if ( have_posts() ) :
		$output .= '<dl>';
		while ( have_posts() ) : the_post();
			$output .= '<dt>' . get_post_meta( $post->ID, 'start_date', true ) . '～' . get_post_meta( $post->ID, 'end_date', true ) . '</dt>';
			$output .= '<dd>' . get_the_title() . '</dd>';
	endwhile;
		$output .= '</dl>';
		echo $output;
		wp_reset_query();
	else :
		// イベントがない場合の処理
		echo '<p>イベントないよ～</p>';
	endif;
	?>
</section><!-- /section -->

ちゃちゃっと書いたのでいろいろ問題あるかもですねー。

Custom Field Templateプラグインでajaxzip3を使う

Posted on 2012年5月6日 by Sho Doi

進めている案件で使うかもしれないのでメモです。（既にありそうなネタだけど）
カスタムフィールド拡張プラグイン Custom Field Template と郵便番号検索API ajaxzip3 を使って、投稿のカスタムフィールドに郵便番号を入力したら住所が出るようにします。それぞれの詳しい使い方については本家を参照下さい。

カスタムフィールドコンテンツ登録

“設定 > カスタムフィールドテンプレート”のコンテンツ部分に以下を記述します。

[zipcode]
type = text
size = 10
label = 郵便番号

[pref]
type = text
size = 10
label = 都道府県

[addr]
type = text
size = 50
label = 市町村区

投稿に郵便番号・都道府県・市町村区の入力欄が表示されました。

郵便番号を入力したら自動的に都道府県・市町村区に住所が入力されるようにします。

ajaxzip3読み込み、JavaScript記述

ajaxzip3の設置方法を見ると

<script src="http://ajaxzip3.googlecode.com/svn/trunk/ajaxzip3/ajaxzip3.js" charset="UTF-8"></script>

でスクリプトを読み込み

<input type="text" name="zip01" size="10" maxlength="8" onKeyUp="AjaxZip3.zip2addr(this,'','pref01','addr01');">
<input type="text" name="pref01" size="20">
<input type="text" name="addr01" size="60">

のonKeyUpイベント実行時にname属性”pref01″,”addr01″のフィールドに値を入力しているようなのでJavaScriptを追加する事に。

JavaScriptの記述箇所は”設定 > カスタムフィールドテンプレート”のテンプレートインストラクションになります。

JavaScriptを記述する前にカスタムフィールドのname値が必要なので投稿ページのソースを見ておきます。

<dl id="dl_zipcode0_0" class="dl_text">
	<dt><span><label for="zipcode0_0">zipcode</label></span></dt>
	<dd><p class="label">郵便番号</p><input id="zipcode0_0" name="zipcode[0][]" value="" type="text" size="10" /></dd>
</dl>
<dl id="dl_pref1_0" class="dl_text">
	<dt><span><label for="pref1_0">pref</label></span></dt>
	<dd><p class="label">都道府県</p><input id="pref1_0" name="pref[1][]" value="" type="text" size="10" /></dd>
</dl>
<dl id="dl_addr2_0" class="dl_text">
	<dt><span><label for="addr2_0">addr</label></span></dt>
	<dd><p class="label">市町村区</p><input id="addr2_0" name="addr[2][]" value="" type="text" size="50" /></dd>
</dl>

都道府県は”pref[1][]“、市町村区は”addr[2][]“なので先の設置例の”pref01″、”addr01″部分を置き換えます。

また、記述例ではonKeyUpイベントをinput要素に記述していますがCustom Field Templateでの設定方法がよく分からなかったので郵便番号入力フィールドのid、”zipcode0_0″を使いjQueryで処理したいと思います。

というわけでテンプレートインストラクションに以下を記述して完成。

<script src="http://ajaxzip3.googlecode.com/svn/trunk/ajaxzip3/ajaxzip3.js" charset="UTF-8"></script>
<script>
jQuery(function(){
	jQuery('#zipcode0_0').keyup(function(e){
		AjaxZip3.zip2addr(this,'','pref[1][]','addr[2][]');
	});
});
</script>

郵便番号を入力すると無事住所が自動入力されました。

出来てしまうと簡単でしたがフィールドへの入力、name属性じゃなくてid属性を使うものと勘違いしてたので “AjaxZip3.zip2addr(this,”,’pref1_0′,’addr2_0′);” と指定してしまい躓きました…

参考サイト

ワードプレスのContactForm7に郵便番号自動変換-AjaxZip3編 | PHPサンプル実験室

CSS4で追加予定の:matches()擬似クラスが便利

Posted on 2012年4月26日 by Sho Doi

CSS4から追加予定のどれかのセレクタにマッチする擬似クラス:matchesが便利そうです。

既存CSSの冗長な例

CSSをコーディングしていてよくあるのが以下のケース。

INFORMATIONというページのテーブルにのみスタイルを指定したい
thとtdは基本的に共通するスタイル

CSSだと以下の様になると思います。
（普段はもう少し省略しますがあえてtable以下を全て書いています）

	body#information #content table tbody tr th,
	body#information #content table tbody tr td {
		border: 1px solid #999;
		padding: 1em;
	}

このコードで感じるのが body#information #content table tbody tr が繰り返されていて冗長だなと。2回も同じコード書きたくない…
CSS3で便利な機能が追加されたのでなにか解決方法あるのではと探しましたが現状では不可でした。
※後述のブラウザ独自実装で可能ですが現実的ではありません。

:matches()擬似クラスを使う

というわけで現状では使えませんがCSS4で追加予定の:matches()擬似クラスを使うと簡単に記述できます。

	body#information #content table tbody tr :matches(th, td) {
		border: 1px solid #999;
		padding: 1em;
	}

上記のように:matches()の引数にセレクタを指定することで先のコードと同様の指定となります。便利ですね！CSS3から実装して欲しかったです！！

ブラウザ独自実装 :any()

同機能はFirefoxがversion4から-moz-any()で独自実装していたようです。
:any – MDN
Chromeも-webkit-any()で対応しているみたいですね。

	body#information #content table tbody tr :-moz-any(th, td) {
		border: 1px solid #999;
		padding: 1em;
	}

ただ、両方対応させようとしたらベンダープレフィックスを2つ記述する必要がでてくるので本末転倒になってしまいますから現実的ではありません。IEも多分駄目でしょうし。（未確認）
しかもカンマ区切りが無理だったので以下のようなコードになってしまいます。

	body#information #content table tbody tr :-moz-any(th, td) {
		border: 1px solid #999;
		padding: 1em;
	}
	body#information #content table tbody tr :-webkit-any(th, td) {
		border: 1px solid #999;
		padding: 1em;
	}

というわけでCSS4が待ち遠しいですね。

参考サイト

「第3回WordPressお茶会 WordBench香川」を開催しました

Posted on 2012年4月24日 by Sho Doi

2012/04/21（土）[13:00～17:30]にデザインラボラトリー蒼様をお借りして「第3回WordPressお茶会 WordBench香川」を開催しました。

リピート参加者、新規ご参加合わせて計11名での開催となりました。
今回は新規の方が2名いらっしゃったのでコミュニティとしては少しずつですが前進してるかなーと。

前回、WordBench香川は（※土井主催のに関しては）だらだらーでいきましょう、ということに決まったので今回もノーテーマでコーヒーを飲みつつの雑談となりました。
ということで本当に何も決めずの開催だったのですが、いつもながら参加者の皆さんがいろいろと提供してくれるので話題には事欠きませんでした。
覚えている限りでは、WordPressについては、テーマ作成の流れ、運用、カスタム投稿タイプ周り（特に勉強になりました！）等。今回は企業でWordPressを使用されている方が参加されていたのでVPSや運用について聞けて為になりました。

後はbaserCMS、Movable Type、a-blog cms、SOY CMS、concrete5あたりの各種CMSについてやカメラについて盛り上がってたようです。WordPress好きはカメラ好きが多いというのは本当ですね。5D Mark IIだったりD800だったりでD40x所持者としては形見が狭いです…

あと、WordBench神戸さんがIT勉強会スタンプラリーに参加する、という情報をWordBenchで見かけたのでWordBench香川コミュニティも参加してみました。（IT勉強会スタンプラリー詳細についてはリンク先を参照ください。）
ただ、香川では他に参加しているコミュニティが今のところ無いはずなのでスタンプを集めようと思ったら大都会岡山に行くか神戸・大阪に行くかしないのでちょっと難しいですね。というわけで香川でも参加コミュニティ増えて欲しいです。
（スタンプラリー用シール作成に関しては@zamojojoさん、@styledesignさんにご協力頂きました。ありがとうございます！！）

photo by: style-design

ちょこっとだけ一人反省会。
いつもノーテーマの雑談だけやってていいのかなーという葛藤はあって、きちんとしたテーマ作成なり、もくもくなり、8時間耐久なりもやったほうがいいのではというのは考えるんだけどスキルが足りなかったり、しゃべるのが苦手だったりで実現するのは難しいですね。（普段の仕事をこなしつつイベント運営されている方凄い！！）
ただ、今回参加者の方からここら近郊でカンファレンス形式のイベントはあるけどお茶会みたいに交流できるイベントがないのでありがたい、と言って頂いたので励みになりました。
というわけでとりあえず「WordPressお茶会」はナンバリングで続けていきたいですね。
コミュニティがもう少し成長したら勉強会っぽいこともたまに出来るようになればいいかな。

あと、今回twitterでハッシュタグつけて実況とか全くしませんでしたが、WordPressお茶会はカンファレンスみたいに喋り手・聞き手が分かれてなくて参加者全員が喋り手であり聞き手で常に忙しいので現実的に実況は無理ですね。
まあ参加者だけが楽しんでしまうクローズド？な集まりになってしまいますが致し方ないですね。

という訳で次回「第4回WordPressお茶会 WordBench香川」の告知ですが、現在のところ2012/6/30（土）を予定しておりますので興味がありましたらご参加頂ければと思います。

* * *

WordBench香川に関してご意見・ご要望等ありましたら@show_webまでお願いします。

[自分用]Twenty Eleven表示確認用ブックマークレット

Posted on 2012年4月16日 by Sho Doi

自分用に適当に作ったので問題ある部分もあるかもしれませんが（保険）せっかくなので公開。
発端はtwitterで見かけた以下@shinichiNさんの発言。

WordPressでURLの末尾に ?preview=1&template=twentyeleven&stylesheet=twentyeleven を付けるとtwentyelevenを有効化した感じで見れる。もちろんログイン必要。

2012年3月31日 18:29 via YoruFukurou ReplyRetweetFavorite

@shinichiN

Shinichi Nishikawa

独自テーマを作成していてたまにTwenty Elevenで確認したい時ってあります？よね。
というわけでブックマークレットです。
以下をブックマークバーまでドラッグしてください。
制作中のWordPressサイト表示時にブックマークレットクリックでTwenty Elevenを有効化した場合のページが確認できます。
※西川さんのツイート内にもありますがWordPressにログインしている必要があります。
またTwenty Elevenテーマが入っていないと当然駄目なはずです。

Twenty Eleven表示確認ブックマークレットVer0.1

Twenty Eleven表示確認

wp-includes/pluggable.phpをrequire_onceしちゃ駄目という話

Posted on 2012年3月7日 by Sho Doi

INDEX

前置き
問題となったコード
やっちゃ駄目な解決方法
pluggable.phpはオーバーライドできる関数なのでreuqire_onceしちゃ駄目
修正後のコード

前置き

WordPress でスニペットを簡単に管理する方法 : dogmap.jpを参考にこれまでfunctions.phpに記述していたスニペットをプラグインで管理するようにしました。簡潔に説明するとプラグインディレクトリ下にスニペット格納用ディレクトリを設置して、スニペットが必要な時にはその中にphpファイルを保存していく、というものです。

そこでいくつかファイルを放り込んで行ったのですがとある箇所でエラーが発生したのでその解決方法なり原因をシェアします。

問題となったコード

	if ( !current_user_can( 'edit_users' ) ) {

		function remove_menus() {
			global $menu;

			unset( $menu[2] ); // ダッシュボード
			unset( $menu[5] ); // 投稿
			// 省略
			unset( $menu[80] ); // 設定
		}

		add_action( 'admin_menu', 'remove_menus' );
	}

エラーが発生したのが上記コードです。
特定権限ユーザ以下の場合、管理画面のメニューを表示しないというものです。

エラー内容は次の通り。

Fatal error: Call to undefined function wp_get_current_user() in C:\xampp\htdocs\wordpress\wp-includes\capabilities.php on line 1187

wp-includes/capabilities.phpの1187行目にあるwp_get_current_user()が未定義とのこと。
で、wp_get_current_user()はwp-includes/pluggable.phpで定義されているからどうやらpluggable.phpがプラグイン読み込み時に読み込まれていないのが問題らしい。

	function current_user_can( $capability ) {
	$current_user = wp_get_current_user();

	if ( empty( $current_user ) )
		return false;

	$args = array_slice( func_get_args(), 1 );
	$args = array_merge( array( $capability ), $args );

	return call_user_func_array( array( $current_user, 'has_cap' ), $args );
	}

やっちゃ駄目な解決方法

上記エラー内容で検索を掛けるとよく目にした解決方法がこちら。

	// プラグインの先頭でpluggable.phpをrequire_onceする
	require_once ( ABSPATH.WPINC . '/pluggable.php');
	if ( !current_user_can( 'edit_users' ) ) {
		// 省略
	}

これでエラーが出ず処理も問題なく行われるようになったのですが（実際これでしばらく動かしてしまっていました）Ktai Styleプラグインを入れると以下のエラーが出るように。
auth_redirect()の関数名が重複してしまっているとのこと。
どうやら上記解決方法は問題がある模様・・・

Fatal error: Cannot redeclare auth_redirect() (previously declared in C:\xampp\htdocs\wordpress\wp-includes\pluggable.php:731) in C:\xampp\htdocs\wordpress\wp-content\plugins\ktai-style\admin\pluggable-override.php on line 13

pluggable.phpはオーバーライドできる関数なのでreuqire_onceしちゃ駄目

ここらでよくわからなくなったのでtwitterでつぶやいて見ることに。

require_once ( ABSPATH.WPINC . '/pluggable.php'); をプラグイン先頭にというのをよく見るけどその場合Ktai Styleプラグインと競合しちゃう。

2012年3月6日 02:08 via webReply RetweetFavorite

@show_web

Sho Doi

@show_web それダメｾﾞｯﾀｲ

2012年3月6日 02:10 via webReply RetweetFavorite

@jim0912

Hitoshi Omagari

@jim0912さんからダメとのご意見を頂いたのでやはり問題のある方法みたいだったので更に調べて見ることに。

そこで参考になったのが以下のサイト。

要はpluggable.php内の関数はプラグインでの再定義を意図した関数であるから先に定義するなっ、と。
例えばwp_get_current_user()を例にとると

プラグインでwp_get_current_user関数を再定義
pluggable.php読み込み時にwp_get_current_user関数が定義されていれば飛ばし、定義されていなれけばpluggable.php内のwp_get_current_user関数を読み込む

という流れになります。
なので先のKtai Styleの場合で、pluggable.phpをrequire_onceしてしまっていると以下のような流れになってバッティングしてしまいます。

プラグインの先頭でpluggable.phpがrequire_onceされ関数が先に定義されてしまう
Ktai Styleプラグインが読み込まれpluggable.phpで使用されている関数と同じ物を定義（←バッティング）

修正後のコード

というわけでフックを使いましょう、というご意見を頂いたので以下の様にしてみました。
一応問題はないと思いますがフック等の理解がまだ微妙なので合ってるか分かりません・・・

		function remove_menus() {
			if ( !current_user_can( 'edit_users' ) ) {
				global $menu;
	
				unset( $menu[2] ); // ダッシュボード
				unset( $menu[5] ); // 投稿
				// 省略
				unset( $menu[80] ); // 設定
			}
		}
		add_action( 'admin_init', 'remove_menus' );

WordPressのセキュリティプラグインBetter WP Securityを試してみた

Posted on 2012年2月21日 by Sho Doi

INDEX

前置き
Better WP Securityプラグインインストール
ステータス確認
The admin user still exists
-ユーザ名”admin”が存在している-
Your table prefix should not be wp_.
-データベースのテーブルプレフィックスが”wp_”のまま-
Your .htaccess file is NOT secured.
-.htaccessファイルがセキュアではない-
Your site is vulnerable to brute force attacks.
-ブルートフォースアタックに対して脆弱-
Your WordPress admin area is available 24/7. Do you really update 24 hours a day?
-管理画面へのアクセスは常にできる必要はあるか-
Your WordPress admin area file is NOT hidden.
-Wordpressの管理領域のファイルが隠されていない-
You are not enforcing strong passwords.
-全てのユーザに対して強力なパスワードが強制されていない-
Your WordPress header is showing too much information to users.
-headerに多くの情報が表示され過ぎている-
Non-administrators can see all updates.
-管理者以外が全てのアップデート情報を閲覧出来る-
Your installation accepts long (over 255 character) URLS. This can lead to vulnerabilities.
-URLに送信出来る文字数が制限されていないため脆弱性に繋がる-
Users may still be able to get version information from various plugins and themes.
-ユーザはプラグインやテーマからバージョン情報を知る事が出来る-
Your site is still vulnerable to some XSS attacks.
-いくつかのXSS攻撃に対して脆弱-
You are not requiring a secure connection for logins or for the admin area.
-あなたはログインのためのまたは管理エリアの安全な接続を必要とされていません-
You are allowing users to edit theme and plugin files from the WordPress backend.
-ユーザーがWordPressのバックエンドからテーマやプラグインファイルを編集することができます-
You should rename the wp-content directory of your site.
-”wp-content”ディレクトリ名を変更する必要があります-
まとめ

前置き

ここ半年くらいでWordPressの停止中のプラグインの脆弱性を突いてデータを改竄、wp-login.phpへのブルートフォースアタック（総当たり攻撃）といった記事をいくつか目にしたのでWordPressのセキュリティについて調べてみました。
いくつか調べたうち、Better WP Securityが役立ちそうだったので機能の解説をしてみます。（プラグインが日本語化されていないのでGoogle翻訳及び英語さっぱりな当方によるなんちゃって日本語での解説となります）
なお、Better WP Securityプラグインのみでセキュリティ対策になるという訳ではありません。（悪意あるコードが含まれるテーマ・プラグインを管理者自身が導入といったケースには対応していないはずです）
また、私はPHP及びセキュリティは専門ではありませんので上記免責事項にもありますがご自身の責任に置いてご利用ください。

Better WP Securityプラグインインストール

プラグインのインストールはいつも通り”管理画面 > プラグイン > 新規追加 > Better WP Security検索 > 一覧よりインストール”ですので省略します。（2012/02/21現在バージョンは2.18を使用）
インストール完了、有効化でサイドバーにメニューが表示されます。

ステータス確認

サイドバーの”Security”をクリックで現在の

「Better WP Security System Status（現在のセキュリティ情報）」
「System Information（ユーザ・PHP・データベース・WordPress情報等）」
「Current .htaccess Contents（現在の.htaccessファイル）」

が表示されます。

上図、ローカル環境でのセキュリティ情報ですが、警告（赤）・注意（黄）だらけなのが確認出来ます。なお問題ない項目は安全（緑）で表示されます。
というわけで各警告・注意の簡単な説明です。（一部分かっていませんが。）

The admin user still exists.: ユーザ名”admin”が存在している → 詳細
Your table prefix should not be wp_.: データベースのテーブルプレフィックスが”wp_”のまま → 詳細
Your .htaccess file is NOT secured.: .htaccessファイルがセキュアではない → 詳細
Your site is vulnerable to brute force attacks.: ブルートフォースアタックに対して脆弱 → 詳細
Your WordPress admin area is available 24/7. Do you really update 24 hours a day?: 管理画面へのアクセスは常にできる必要はあるか → 詳細
Your WordPress admin area file is NOT hidden.: WordPressの管理領域のファイルが隠されていない（翻訳よくわからない？）たぶんログインURL（wp-login.php）等がデフォルトのままなので変更しなさいい、という警告。 → 詳細
You are not enforcing strong passwords.: 全てのユーザに対して強力なパスワードが強制されていない → 詳細
Your WordPress header is showing too much information to users.: headerに多くの情報が表示され過ぎている → 詳細
Non-administrators can see all updates.: 管理者以外が全てのアップデート情報を閲覧出来る → 詳細
Your installation accepts long (over 255 character) URLS. This can lead to vulnerabilities.: URLに送信出来る文字数が制限されていないため脆弱性に繋がる → 詳細
Users may still be able to get version information from various plugins and themes.: ユーザはプラグインやテーマからバージョン情報を知る事が出来る → 詳細
Your site is still vulnerable to some XSS attacks.: いくつかのXSS攻撃に対して脆弱 → 詳細
You are not requiring a secure connection for logins or for the admin area.: あなたはログインのためのまたは管理エリアの安全な接続を必要とされていません → 詳細
You are allowing users to edit theme and plugin files from the WordPress backend.: ユーザーがWordPressのバックエンドからテーマやプラグインファイルを編集することができます → 詳細
You should rename the wp-content directory of your site.: “wp-content”ディレクトリ名を変更する必要があります → 詳細

それでは上の警告から対策して行きたいと思います。各警告横のリンクまたはサイドメニュー”Security”のサブメニューより設定を行います。
※無理に全ての警告・注意を安全にする必要はないと考えています。
他のセキュリティ情報を調べるとBetter WP Securityプラグインで警告・注意されている項目でも無駄なものもあるようですので。

The admin user still exists.

-ユーザ名”admin”が存在している-

ユーザ名で”admin”を使用している場合に警告が出ます。
WordPress3.0からインストール時に任意のユーザ名を設定出来るようになりましたが、3.0まではデフォルトの管理者名が”admin”だったため狙われやすい、ということからの警告と思われます。

“Security > Admin User”よりユーザ名を変更する事で安全となります。

ただし、WordPress › フォーラム » セキリュティについての質問にある通り、http://show-web.jp/?author=1 とすると、http://show-web.jp/author/admin/ と帰ってくるように、ユーザIDを増やしていくと容易にユーザ名を知る事が出来るのでこちらの設定はあまり意味がないかもしれません。

Your table prefix should not be wp_.

-データベースのテーブルプレフィックスが”wp_”のまま-

テーブルのプレフィックスがデフォルトの”wp_”のままでは推測しやすいので警告が出ます。

“Security > Database Prefix”より変更を行います。
“Change Database Table Prefix”クリックでテーブルプレフィックスが”wp_”からランダムな値に変更されます。※要バックアップ。

ただ、この項目に関してもWordPress › フォーラム » セキリュティについての質問で解説されているようにWordPressではSQLインジェクションがほとんど起こらないらしいので必要ないかもしれません。

Your .htaccess file is NOT secured.

-.htaccessファイルがセキュアではない-

.htaccessがセキュアな状態ではありません。
“Security > .htaccess Protection”より設定を行います。
なお、次のケースでは以図の警告が出ます。

WordPressインストールフォルダに.htaccessがない場合
.htaccessファイルへの書き込み権限がない場合

“設定 > パーマリンク設定”で適当なパーマリンクを設定する事で.htaccessファイルを生成
ファイルパーミッションの設定で.htaccessファイルの書き込み権限付与

上記を行った後再度”.htaccess Protection”設定へ行くと以下の設定画面となります。
全ての項目の詳細は理解出来ていませんが、readme.htmlやwp-config.phpへのアクセスを拒否したりURLの不審なクエリ文字列を除外したりしてくれているようですので、全てにチェックを入れて保存します。

試しにwp-config.phpがある場所へアクセスしてみると403を返してくれました。

Your site is vulnerable to brute force attacks.

-ブルートフォースアタックに対して脆弱-

ブルートフォースアタック（総当たり攻撃）への対策を行います。
“Security > Limit Logins”より設定を行います。
設定をOnにすることで、特定ホストからの連続不正アクセス、特定ユーザ名での連続不正アクセスがあった際にそのホスト・ユーザに対して制限を掛ける事が出来ます。

以下設定内容です（不明な箇所あり）

Enable Limit Bad Login Attempts: 不正ログインに対して試行回数を制限するか。Onを選択。
Max Login Attempts Per Host: 1ホストあたりの最大ログイン回数
Max Login Attempts Per User: 1ユーザアカウントへの最大ログイン回数
Login Time Period (minutes): 不明（何の時間？）
Lockout Time Period (minutes): ロックアウト期間。不正ログインによる試行回数が設定数以上に達した際の閉め出し時間。
Deny All Site Access To Locked Out Hosts.: ロックアウトユーザはサイト全てを閲覧出来なくするかどうか。Onを選択。
Enable Email Notifications.: ロックアウトが発生する度に管理者へメール通知を行う。Onを選択。
Default Error Message: ロックアウトユーザがアクセスした際に表示されるテキスト。

Your WordPress admin area is available 24/7. Do you really update 24 hours a day?

-管理画面へのアクセスは常にできる必要はあるか-

24/7がよく分からなかったのですがスラングで「いつも・常に」といった意味ですね。
24/7の意味　(ネイティブのスラング辞典と英語発音辞典) | 英語 with Luke

という訳で、「WordPress管理画面は常にログイン出来る状態にしておく必要があるのか？」といったところでしょうか。
確かに企業サイトで営業時間内のみしかブログを更新しないという場合、深夜は管理画面へアクセス出来る必要はありません。

設定は”Security > Away Mode”より。

以下設定内容。

Enable Away Mode: 特定の期間管理画面にログイン出来なくする設定のOn/Off
Type of Restriction: 制限の種類。Dairy（毎日）、またはOne Time（指定の一定期間）を選択。
Start Date and Time / End Date and Time: 制限の種類でDairyを選択した場合、Start Date and Timeで設定した時間からEnd Date and Timeで設定した時間まで管理画面にアクセス出来なくなります。
同様にOne Timeを選択した場合は、Start Date and Timeで設定した日付・時間からEnd Date and Timeで設定した日付・時間まで管理画面にアクセス出来なくなります。

例えばOne TimeでStart Date and Time: February 22nd, 2012 at 12:00 am – End Date and Time: April 22nd, 2012 at 12:00 amと設定すると、Access Time Ruleの項目に以下の通り表示され、この期間一切管理画面にアクセス出来なくなってしまいますので気を付けてください。

Access Time Rule: The backend (administrative section) of this site will be unavailable from Wednesday, February 22nd, 2012 at 12:00 am until Sunday, April 22nd, 2012 at 12:00 am.

Your WordPress admin area file is NOT hidden.

-Wordpressの管理領域のファイルが隠されていない-

※私の理解不足の所為ですが、この機能をOnにしたらブログにログイン出来なくなりました。なんとかログイン出来るようにはなりましたが怖いのでこの機能は使用していません。
詳しい方いらっしゃればアドバイス頂ければ助かります。

直訳すると「WordPressの管理領域のファイルが隠されていません。」と出て来たけどいまいち分からなかったので設定画面を見てみる事に。
“Security > Hide Backend”へ。

どうやらwp-login.phpやwp-register.php、wp-admin/へのアクセスを独自のURLに変更してくれてwp-login.php等へのアクセスを404にしてくれるらしい。

機能をOnにすると.htaccessに以下とデータベースのwp_optionsにそれらしき設定が追加されます。

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

RewriteRule ^login wp3.3/wp-login.php?2outcx4j6thhy0do0456v [R,L]
RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in_.*$
RewriteRule ^admin$ wp3.3/wp-login.php?5locztyc3vlytpqcmfcap&redirect_to=/wp-admin/ [R,L]
RewriteRule ^admin$ wp3.3/wp-admin/?2outcx4j6thhy0do0456v [R,L]
RewriteRule ^register$ wp3.3/wp-login.php?2outcx4j6thhy0do0456v&action=register [R,L]
RewriteCond %{HTTP_REFERER} !^(.*)/wp-admin 
RewriteCond %{HTTP_REFERER} !^(.*)/wp-login\.php 
RewriteCond %{HTTP_REFERER} !^(.*)/login 
RewriteCond %{HTTP_REFERER} !^(.*)/admin 
RewriteCond %{HTTP_REFERER} !^(.*)/register 
RewriteCond %{QUERY_STRING} !^2outcx4j6thhy0do0456v 
RewriteCond %{QUERY_STRING} !^action=logout
RewriteCond %{QUERY_STRING} !^action=rp
RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in_.*$
RewriteRule ^wp-admin/?|^wp-login\.php not_found [L]
</IfModule>

処理の流れとしては以下の通りでしょうか。

http://localhost/wp3.3/wp-login.php → 404エラー
独自で設定したログインURL http://localhost/wp3.3/login にアクセス。
.htaccessのRewiteRuleにより http://localhost/wp3.3/login.php?2outcx4j6thhy0do0456v へ。（?2outcx4j6thhy0do0456vパラメータがある場合のみログイン画面が表示される）
通常通りユーザ名・パスワードを入力してログイン

私の環境では「ユーザ名・パスワードを入力しても再度ログイン画面が表示される」、「間違えたユーザ名・パスワードを入力してもプルプル警告が出ずログイン画面が表示される」となってしまい結局ログイン自体が出来ない状態になってしまいました。

という訳で、この機能は怖いので使用していません。

You are not enforcing strong passwords.

-全てのユーザに対して強力なパスワードが強制されていない-

ユーザ権限に対して強力なパスワードを強制するように設定します。
“Security > System Tweaks > Strong Password Tweaks”へ。

Enabled strong password enforcement: 強力なパスワードの強制をOnにします。
Strong Pass Role: セレクトボックスから権限レベルを選択し、それ以上の権限レベルに対して強力なパスワードを強制します。

権限レベルはAdministrator（管理者）, Editor（編集者）, Author（投稿者）, Contributor（寄稿者）, Subscriber（購読者）より選択、Subscriber以外を選択した場合はセキュリティステータスはYou are enforcing strong passwords, but not for all users.の注意となり、Contributor以上の権限レベルに対し強力なパスワードを強制する設定となります。
Subscriberの選択でYou are enforcing strong passwords for all usersとなり全権限レベルに対して強力なパスワードを強制する設定となります。

弱いパスワードで新規ユーザを追加しようとすると以下のようにエラーが発生します。

ただ、既存ユーザのパスワードに対しては警告は出ないようです。

Your WordPress header is showing too much information to users.

-headerに多くの情報が表示され過ぎている-

head要素にWordPressのバージョン等の情報が表示され過ぎているという警告。
“Security > System Tweaks > Header Tweaks”より設定。

Non-administrators can see all updates.

-管理者以外が全てのアップデート情報を閲覧出来る-

デフォルトでは管理者以外でもコア・テーマ・プラグインのアップデートが閲覧出来るので見えなくします。
“Security > System Tweaks > Dashboard Tweaks”より設定。

上より、テーマ、プラグイン、コアアップデートの表示を非管理者へ対して行うかの設定です。
チェックを入れる事で非管理者はアップデート情報の閲覧が出来なくなります。

Your installation accepts long (over 255 character) URLS. This can lead to vulnerabilities.

-URLに送信出来る文字数が制限されていないため脆弱性に繋がる-

勉強不足ですがハッカーはURLパラメータにSQL文を挿入することでデータベースを操作しようと狙ってくるそうです。そこでURLの文字数制限を行うように設定します。
“Security > System Tweaks > Other Tweaks > Prevent long URL strings.”をチェックして保存で設定完了。

試しにURLに長い文字列を入力してみると、ブログは表示されず真っ白な画面が表示されるのみ、となりました。

Users may still be able to get version information from various plugins and themes.

-ユーザはプラグインやテーマからバージョン情報を知る事が出来る-

デフォルトでは以下の様にcss,jsの末尾に”style.css?ver=3.3.1″といった具合にパラメータとしてバージョンが表示されます。設定により非管理者からはバージョンが閲覧出来なくします。

<link href="http://localhost/wp3.3/wp-content/themes/Automattic-_s/style.css?ver=3.3.1" rel="stylesheet" />

“Security > System Tweaks > Other Tweaks > Display random version number to all non-administrative users”をチェックして保存で設定完了。

説明を読む限り非管理者にはランダムなバージョンを見せて分からなくさせるのかな、と思ったのですが一切のバージョン番号が見えなくなるようです。

Your site is still vulnerable to some XSS attacks.

-いくつかのXSS攻撃に対して脆弱-

よく分かっていません。
設定は”Security > Intrusion Detection”でEnable 404 DetectionをOnにすればセキュリティステータスは安全になるのですが具体的に何をしているのか？XSSと404は関係あるのといった感じです。
少し調べてみたところ、こちらに書いてある事を防ぐ様な設定でしょうか。
cross-site scripting

You are not requiring a secure connection for logins or for the admin area.

-あなたはログインのためのまたは管理エリアの安全な接続を必要とされていません-

日本語はGoogle翻訳そのままでさっぱりです、がたぶん「管理エリアへの安全な接続」とあるので管理画面へはSSLで接続出来るようにといった注意だと思われます。
“Security > System Tweaks > SSL Tweaks”から設定出来るようですがこの機能を使うにはSSLサーバを契約していなければいけない旨の警告があるので今回は飛ばします。

You are allowing users to edit theme and plugin files from the WordPress backend.

-ユーザーがWordPressのバックエンドからテーマやプラグインファイルを編集することができます-

こちらもいまいち分かりません。
“外観 > テーマ編集”、”プラグイン > プラグイン編集”を行えてしまう旨の注意書きかと思われます。
“Security > System Tweaks > Other Tweaks > Turn off file editor in WordPress Back-end.”から設定出来るようですがチェックして保存しても、チェックされていない状態となってしまいます。他ファイルの書き込み権限とかが絡んでるのでしょうか・・・

You should rename the wp-content directory of your site.

-”wp-content”ディレクトリ名を変更する必要があります-

デフォルトの”wp-content”ディレクトリ名を変更するように、との警告。
“Security > Content Directory”より変更を行えます。

ただ、”wp-content”ディレクトリ名を変更しても記事に画像をアップロードしたらそこからパスが分かってしまうので意味がないような気もします。

まとめ

というわけでGoogle翻訳に頼ったり、自ら実験台となりBetter WP Securityプラグインを試してみました。
.htaccessを生成してファイルを保護してくれたり、ブルートフォースアタック対策があるのは便利かなと思えた反面、”admin”ユーザや”wp-content”ディレクトリ名について警告が出るのは厳しいなと。

また、記事中に書いていませんが特定ユーザ・ホストをBAN出来たりもするようですので保証は出来かねますが便利なプラグインではないでしょうか。

ただ、設定次第では自分自身がログイン出来なくなる状態に陥ってしまうので使用の際はあくまで自己責任でお願いします。

加えて記事中にもありますがプラグインでwp-login.phpへのアクセスを隠蔽する設定が出来なかったので現状wp-login.phpへアクセス出来る状態になっています。
ですので、いまさらながら、WordPressのセキュリティを考えてみた。その１　wp-login.phpを不正アクセスから守る | おきらくサーバー運用メモを参考に.htaccessでwp-login.phpに対して自身のIP（固定IPの場合）のみ許可する設定を記述したほうが良いと思われます。

あと、適当英語、適当PHP・セキュリティ知識で記事を書いたのでWordPressやセキュリティの偉い人達からツッコミがきたら怖いです・・・

NetBeans IDE 7.1でプラグインを無効化したら動かなくなった対処法

Posted on 2012年2月13日 by Sho Doi

NetBeans IDE 7.1は動作が軽いので愛用してるのですが更に軽くできないかと “ツール > プラグイン > インストール済み” を見ると有効になっているプラグインがいっぱい。
「PHP Smarty フレームワーク」とか使ってないし・・・と不要っぽいプラグインを無効化していったら動かなくなったので対処法を。

起動しても何も表示されないorz

プラグインを適当に無効化した後再起動すると下の様な感じに。
エディターもプロジェクトもメニューすら表示されていません。

右下を見ると何やら赤い警告が。クリックしてみると。

更に警告の詳細を見てみる。

Javaらしきエラーが表示されているようですがさっぱりわかりません。

というわけでいつものようにGoogle先生に頼ることに。
プラグインを無効にしたのだからその設定ファイルがあるはず。ということで辿り着いたのがこちら。
自分実験室 : netbeansプラグインの有効・無効化を直接切り替える

プラグインの有効・無効を直接切替える

プラグインの設定ファイルは “C:\Users\（ユーザ名）\.netbeans\7.1\config\Modules\” にxmlファイルで格納されているとのこと。

これらxmlファイルにプラグインの有効・無効の設定が保存されているので全て有効にしていくことに。
以下はzencodingプラグイン設定xmlファイルの中身です。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module PUBLIC "-//NetBeans//DTD Module Status 1.0//EN"
                        "http://www.netbeans.org/dtds/module-status-1_0.dtd">
<module name="org.lorenzos.zencoding">
    <param name="autoload">false</param>
    <param name="eager">false</param>
    <param name="enabled">false</param>
    <param name="jar">modules/org-lorenzos-zencoding.jar</param>
    <param name="reloadable">false</param>
</module>

7行目に有効・無効の設定値enabledがあるので有効にするために値をtrueに変更します。
動かなくなった原因はコアプラグインを無効化したことだろうけど、どれが原因かわからなかったので取り敢えず全ての設定をtrueに修正しました。

そしてNetBeans IDEを再起動！
みごとメニューも表示され問題なく動作もするのですがまだ右下に警告が。

キャッシュがどーとか、ロックが掛かってるとか・・・よくわかりません。
でも “C:\Users\（ユーザ名）\.netbeans\7.1\var\cache\” あたりが原因かな、ということでchcheフォルダをバックアップを取った後削除。
再度再起動。
ようやくエラーも表示されず見慣れた画面が表示されました。

というわけで、設定はあまり弄り過ぎないようにという教訓でした。

「第2回WordPressお茶会 WordBench香川」を開催しました

Posted on 2012年2月12日 by Sho Doi

2012/02/11（土）[13:00～17:30]にデザインラボラトリー蒼様をお借りして「第2回WordPressお茶会 WordBench香川」を開催しました。

前回ご参加、新規ご参加合わせて8名+主催者土井の9名での開催となりました。

今回は私が忙しかったこともあり何も準備出来なかったのでノーテーマで雑談+@dr_covaさんによる「WordPressのセキュリティ対策について」「スマホでWordPress管理」のLTという内容に。

photo by: style-design

雑談は特にネタも用意せずだったのですが、さすがにWebな人が集まっているだけあっていろいろ伺うことができました。
途中から島に分かれてだったので分かる範囲になりますが、ユーザビリティや各種CMS、WordPress FAQ、LESS・SCSS（Sass）、うどん、イベント運営、お金の話、等々。
WordBench香川独特のだらだらな流れのせいか@dr_covaさんのLTも片方の島でいつの間にか？というわけできちんと聞けずでした。また別の機会に拝聴する機会があれば。
WordPressサイト構築に関する濃ゆい話もしてたようなのでそれに関してもちょっと聞きたかったです。

今後のWordBench香川の流れについて参加者さんに意見を頂戴したところ、前回・今回みたいなだらだらーな流れで（が？）良いというご意見だったので今後も特に「勉強会」みたいなのではなく、ノーテーマで集まって雑談しましょうみたいになると思います。何かネタがあったらLTでちょこっと話してもいいですし。
というわけで「WordPress勉強会」を求めている方はきちんとされてる他Benchへのご参加をお勧めします。

いつもながら長時間の集まりになってしまいましたが参加者の皆さんありがとうございました。次回もよろしくお願いします。
また、前回に続き場所を提供頂きましたデザインラボラトリー蒼様ありがとうございました。

次回「第3回WordPressお茶会 WordBench香川」は4月予定。
今回の感じだともう少し人入れそうなので次回は13人くらいで開催したいですね。

あと、特に内緒じゃないですけどあれなイベントも是非やりましょう！！

* * *

WordBench香川に関してご意見・ご要望等ありましたら@show_webまでお願いします。

Mac OS X Lion環境NetBeans IDEにプログラミング用フォントRicty導入

Posted on 2012年1月31日 by Sho Doi

フォントにそこまでこだわりがある訳ではないですがNetBeans IDEのデフォルトの日本語はかなり見難いと感じていたところ、以下ツイートを見てRictyフォントなるものを導入してみようと思ったけど結構苦労したのでそのメモ。

MBA+NetBeansで使ってますが結構見やすいです。 RT @seltzer: Linux向け、開発用フリーフォントですって＞プログラミング用フォント Ricty http://t.co/RFMbloSz

2012年1月15日 19:11 via Echofon ReplyRetweetFavorite

@Stocker_jp

なつき

INDEX

環境
前置き
Homebrewインストール
FontForgeインストール
Rictyの生成
NetBeans IDE の設定

環境

Mac OS X Lion 10.7.2
Xcode 4.2.1
NetBeans IDE 7.1
ターミナル用エディタ nano

前置き

まず、公式のプログラミング用フォント Rictyを見てみると、これまではTrueTypeフォントで配布してたがライセンスの問題から万全を期すために最新版は生成スクリプトのみの配布、そして、生成方法としてFontForgeが必要とのこと。
FontForgeというのはフォントの作成や編集ができるアプリケーションらしい、というわけでFontForgeのインストール方法を調べてみることに。

Homebrewインストール

Google先生に尋ねてみて最初にヒットしたサイトがこちら。
Cocoa Emacs on OSX LionでRictyフォントを使ってみた！ – 空繰再繰

参考サイトを見てみるとFontForgeをインストールするにはHomebrewというパッケージマネジメントツールが必要とのこと。

早速Homebrewへ行くと中ほどに”Install Homebrew Today!”とあったのでクリック。

Install Homebrew Today!をクリック

githubのHomebrewインストール解説ページに飛ばされたので解説にある通りターミナルコマンドで以下を入力。

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"

暫し後インストール完了。
/usr/local/ にHomebrew含むファイル一式が追加されており試しにバージョン確認してみるときちんと表示されました。

$ brew -v
0.8.1

FontForgeインストール

FontForgeインストールでエラーその1

参考サイトに習ってターミナルよりFontForgeをインストール

$ sudo brew install fontforge --use-gcc --without-python

すると以下のようなエラーが

sudo: brew: command not found

sudo無しで実行すると通ったので /usr/local/ の権限がrootになっていないのが問題のよう。

$ sudo chown -R root /usr/local

で /usr/local/ の権限をrootに変更。
再度fontforgeインストールしようとすると問題なく brew は実行、しかし別のエラーが。

FontForgeインストールでエラーその2

Error: GCC could not be found

上記エラーが発生。GCCなるものが無いとのこと。
GCCについて調べてみるとフリーのコンパイラでXcodeインストール時に同時にインストールされるらしい。Xcodeはつい最近インストールしたためGCCもインストールされているはず。
念のため /Applications/Install Xcode から再度インストール。

エラー・・・

入っているはずのものが認識されないのでパスが通っていないのかな、ということでMacでパスを通す方法を調べてみることに。
どうやらホームディレクトリ（/users/ユーザ名/）に不可視ファイルで.bash_profileや.bashrcがあるとのこと。（デフォルトはないみたい）
というわけでホームディレクリに移動してファイルがあるか確認。

$ cd /users/ユーザ名
$ ls -a

ファイルが見つからなかったので新規に作って /usr/local へのパスを追加する事に。

$ nano .bashrc

で.bashrcファイルを作成して以下を記述。

export PATH=$PATH:/usr/local

反映させるためにsourceコマンドを。

source ~/.bashrc

パスも通っただろうし再度FontForgeインストール実行。

$ sudo brew install fontforge --use-gcc --without-python

エラー・・・
という訳で再びGoogle先生に聞いてみる事に。

FontForgeインストール成功

いろいろ調べてたどり着いたのがこちら。
Mac デ Homebrew ノススメ | CaCi – Takahiro’s Kitchen
Xcode4.2+GCCは問題あり、という内容でたどり着いたのですが、HomevrewインストールからFontForgeインストールまでこちらのサイトで事足りる、という程参考になりました。

まずはパスの設定から。

Homebrewで入れたパッケージを優先的に使うためには/usr/binより/usr/local/binがPATHの前になければなりません。

というわけで、先ほどの.bashrcファイルを編集します。

$ nano .bashrc

PATH=/usr/local/bin:/usr/local/share:$PATH
export PATH

続いてGitのインストールとHomebrewアップデート

$ sudo install git
$ brew update

そして問題のGCCは使えないので代替の方法を。（詳しくは参考サイトを）

$ sudo brew install --use-clang ffmpeg

ようやくFontForgeインストール！！

$ sudo brew install fontforge --use-clang

暫し後FontForgeインストール成功。
/usr/local/Celler/fontforge/ が追加されています。

Rictyの生成

プログラミング用フォント Rictyの「生成スクリプトの配布」より最新バージョンをダウンロード。（2012/01/31現在 version3.1.3）

Inconsolata 公式サイトより OpenType fileをダウンロード。

M+ と IPA の合成フォントのダウンロードより”Migu 1M”をダウンロード。

それぞれ解凍して1つのフォルダへ。（私はRitcyフォルダに入れました）

ターミナルでフォルダに移動して以下コマンドで生成。

$ ./ricty_generator.sh auto

無事生成されたので、インストール。

NetBeans IDE の設定

“NetBeans > 環境設定 > フォントと色”のフォントでRictyを選択。

NetBeans IDEのフォントをRictyに変更出来ました！！