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

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でつぶやいて見ることに。

https://twitter.com/#!/jim0912/status/176716235998900225

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

2012年2月21日2012年10月17日

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

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

2012年2月13日2012年2月13日

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

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

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