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

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

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

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

[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">

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>

また、記述例では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サンプル実験室

既存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が待ち遠しいですね。

参考サイト

• CSS4セレクタ (Selectors Level 4) の新機能
• Selectors Level 4

前置き

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' );
	}
	

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

エラー内容は次の通り。

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()の関数名が重複してしまっているとのこと。
どうやら上記解決方法は問題がある模様・・・

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

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

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

2012年3月6日 02:08 via webReplyRetweetFavorite

@show_web

Sho Doi

@show_web それダメｾﾞｯﾀｲ

2012年3月6日 02:10 via webReplyRetweetFavorite

@jim0912

Hitoshi Omagari

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

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

• WordPress › フォーラム » [Ktai Style]と[Events Calendar]でバッティングが起きる
• オーバーライドできる関数 – プラグイン API – WordPress Codex 日本語版

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

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

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

1. プラグインの先頭でpluggable.phpがrequire_onceされ関数が先に定義されてしまう
2. 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' );
	

INDEX

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

前置き

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

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

ステータス確認

サイドバーの”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プラグインで警告・注意されている項目でも無駄なものもあるようですので。

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

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

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

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

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

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

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

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

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

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

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

ブルートフォースアタック（総当たり攻撃）への対策を行います。
“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

ロックアウトユーザがアクセスした際に表示されるテキスト。

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.

※私の理解不足の所為ですが、この機能を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>

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

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

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

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

ユーザ権限に対して強力なパスワードを強制するように設定します。
“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となり全権限レベルに対して強力なパスワードを強制する設定となります。

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

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

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

<meta content="WordPress 3.3.1" name="generator">等を削除してくれるそうですがバージョン情報削除するのあんまり意味無いと思うのでどうだろう。全てチェック入れてもマイナス要素はないと思います。

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

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

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

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

デフォルトでは以下の様に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”をチェックして保存で設定完了。

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

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

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

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

デフォルトの”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やセキュリティの偉い人達からツッコミがきたら怖いです・・・

起動しても何も表示されない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フォルダをバックアップを取った後削除。
再度再起動。
ようやくエラーも表示されず見慣れた画面が表示されました。

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

INDEX

1. 環境
2. 前置き
3. Homebrewインストール
4. FontForgeインストール
   1. FontForgeインストールでエラーその1
   2. FontForgeインストールでエラーその2
   3. FontForgeインストール成功
5. Rictyの生成
6. 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インストール

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

sudo: brew: command not found

$ sudo chown -R root /usr/local

Error: GCC could not be found

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

$ nano .bashrc

export PATH=$PATH:/usr/local

source ~/.bashrc

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

$ nano .bashrc

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

$ sudo install git
$ brew update

$ sudo brew install --use-clang ffmpeg

$ sudo brew install fontforge --use-clang

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に変更出来ました！！