さくらも WordPress 使い始めてすぐ気になって、どこかのブログに書いてた MySQL のテーブル直接更新する方法でユーザー名変えたりしました。どのブログに書いてあったのか忘れたんでリンク貼らないけどw

で、これもっと簡単にする方法無いかなと思ってプラグインディレクトリを漁ってたら良さげなのが見つかりましたのでご紹介したいと思います。こちらの WordPress › Admin renamer extended « WordPress Plugins がそれです。

Admin renamer extended プラグインをインスコすると、簡単に管理者ユーザーのユーザー名を変更することができます。

では使い方のご説明w

まずこちらからプラグインをインスコしてください。サイドバーに Admin renamer extended というメニューが追加されます。メニューを見つけたらおもむろにクリック。

クリックしたらこちらの画面が開きます。

こちらの画面には管理者権限のユーザー名が表示されます。テキストエリアに新しいユーザー名を入力して Update をクリックすると更新されます。

ちなみに登録されてる管理者権限ユーザーは全部ここに表示されるみたいですが、さくらは一人しか管理者作ってないのでその辺は確認してません。サーセンw

最後に新しいユーザー名を入力して Update を押してください。ユーザー名が更新されます。更新後は強制的にログアウトされてログインページに移動しますので、パスワードを覚えてない方はご注意ください。

さてさて、このように一発で管理者ユーザー名変えれる便利なプラグイン Admin renamer extended なのですが、このプラグイン自体のセキュリティ的な評価というか「ぶっちゃけ大丈夫なのこれ？」みたいなのが気になったりしました。

ブログを書くにあたり、あんまヤバいプラグインをご紹介する訳には参りませんのでソース全部確認してみたのですが、とりあえず問題はないと思います。ただそんな大きいプラグインでもありませんし、PHP 読める方は（この手のセキュリティ関係のコードをインスコする際は）予めご自身で確認されることをお勧めします。

あえて問題と言えば、プラグインインスコすると外部からもインスコール済みなのが分かるので、（将来的にバージョンアップした際も含めて）そのプラグインにセキュリティホールがあると攻撃対象になるのが問題っちゃー問題かもしれません。

ただそれ言い出すとプラグイン自体まったく使えなくなるのでそこまで潔癖にする必要ないと思います。まあ気になる方は以下のブログにプラグインを使わず自力で対処する方法書いてますのでどうぞご覧ください。

• WordPressのセキュリティをアップする11のポイント | コリス
• WordPressの「admin」削除は驚くほど手軽 – カイ士伝
• WordPressでユーザー名『Admin』をやめてみる。 – HAAYA

いずれにしてもデフォルトのまま admin で管理者ユーザー使ってるのは問題ありまくリんぐなので、何らかの方法で対応されることをオヌヌメします。

0.2.1 未満のバージョンには、バージョンアップ時に編集した CSS ファイルが削除されるバグが含まれているため、プラグインをバージョンアップする前に以下の作業を行ってください。

1. wp-content/cache/external-css/css ディレクトリを作成する
2. wp-content/plugins/external-css/css/custom.css を wp-content/cache/external-css/css にコピー

　　 ｎｎ
　 　| |||　　　　　　　　予約投稿のﾖｶｰﾝ
　　（;ﾟДﾟ)
　　（●●ﾄﾞｷﾄﾞｷ
　⊂|　））
　　.∪∪

なんか最近あんまり AA 貼ってないんで、禁断症状でてきたような気がするww
まあしょうもない話はこの辺にして本題へw

つーことで調子に乗ってまたまた WordPress プラグインを公開してみちゃったりしました。

今回公開したのは External CSS プラグインです。
このプラグインをインスコすると、外部 CSS ファイルを WordPress のダッシュボードから編集できるようになります。

さくらのブログはテンプレの CSS をそれなりに弄くっちゃったりしてるのですが、テンプレ変える前から仕込んであるスタイルとかもあったりして、要は CSS の編集をテンプレと切り離したいので作ったプラグインです。

似たような機能のプラグインに Custom User CSS や Simpler CSS などがありますが、これらのプラグインは CSS を <style> タグで直接埋め込じゃうのでできれば外部の CSS ファイルに保存するような似たようなプラグイン無いかなーと探していたのですが、無さげだったので作りました。

External CSS ではユーザーが編集した CSS を wp-content/plugins/external-css/css/custom.css に保存します。この CSS ファイルは管理パネルを除いたすべてのブログエントリ（ページ含む）から <link> タグで読み込まれます。

そのため <style> タグで埋め込む形式のプラグインと比べネットワークやサーバへの負荷が低く、自分用 CSS を結構な量書く方には特に SEO 面で有利なプラグインとなってると思います。

ぜひご利用くださいませ！

インストール

以下のいずれかの方法でインストールできます。

• wordpress.org の External CSS からプラグインをダウンロードし、Zip ファイルを wp-content/plugins/ ディレクトリで展開
• WordPress のプラグイン検索で "External CSS" を検索しインストールリンクをクリック

簡単なので、プラグイン検索がオヌヌメです。
インストール後はプラグインを有効にしてください。

使い方

インストールすると、ダッシュボードの 外観 (Appearance) メニューに External CSS メニュー項目が追加されます。追加されたメニュー項目をクリックすると、textarea ベースの簡単な CSS エディタが開きますので CSS を入力し保存してください。

保存された内容は wp-content/plugins/external-css/css/custom.css に記録されます。この CSS ファイルはプラグインを有効にした時点から、管理用ページを除くブログのすべてのページから <link> タグにより読み込まれます。

細かいこと気にしてハゲそうな人向けのプラグインの一部の実装に関する説明

以下は wp-content/plugins/external-css/custom.css ではなく wp-content/plugins/external-css/css/custom.css に CSS ファイルを保存する実装になってる理由の説明です。プログラム的な話に興味無い方は無視しちゃってください。

このプラグインではファイルの更新をアトミックに行うため、入力された内容を一度テンポラリファイルに保存してから rename 関数を使って CSS ファイルを更新してます。そのため WordPress プログラムから、CSS ファイルを保存するディレクトリに対して書き込める状態になっていないとプラグインが動作しません。

従って wp-content/plugins/external-css/custom.css に保存しようとすると wp-content/plugins/external-css ディレクトリに WordPress から書き込めるようにする必要があるのですが、それは仕様的に何か微妙なため、wp-content/plugins/external-css/css ディレクトリに CSS ファイルを作成するようにしてます。

あと将来的に編集できるファイルを増やそうかなーとか思ってるのですが、その時プラグインディレクトリを直接更新するのが問題になりそうなの

　　　　　　　/ﾆＹﾆヽ
　 　(ヽ　 　/（ ﾟ )( ﾟ ）ヽ　　　/)
　　(((i ) ／::::⌒｀´⌒::::＼ 　( i)))　　でっていうｗｗｗｗｗｗｗｗ
　／∠_|　,-）＿＿＿（-，|＿ゝ ＼
( ＿＿＿､　　|-┬-|　　　　,＿＿ ）
　　　　|　　　　`ー’´　　 /´
　　　　|　　　　　　　　　/

理由もあります。

まあ将来どうなるか、さくら17才だしまだ考えてないw

これでテーマを変えるたびにしてた
CSS をコピペする作業から開放される…
リベレーション！！

WP Super Cache WordPress プラグインの生成する mod_rewrite ルールにバグがあるみたいだったから報告するわね。

まず現象から言うけど、WP Super Cache をインスコしたら 404 Not Found になるってことね。実際さくらも痛い目見たわよww

んでもうキャッシュ使うのヤーメピとか思ってたんだけど、他にも同じ現象で困ってる人がいるみたいだから調べてみることにしたの。

WP Super Cache をインスコしたときに 404 Not Found が発生する条件

バグフィックス方法とか説明する前に、このバグ、必ず悪さをする訳では無いみたいなんで、404 Not Found になる条件から説明するわね。

WordPress のインストール方法に依存します

まずこのバグは、WordPress をインスコするときに、別のディレクトリにホームページを設定してたら発生するの。

ダッシュボードの [設定] → [一般] から上のキャプチャみたいな感じに設定したら、別のディレクトリにホームページを設定できるの。この辺の設定した記憶が無かったら問題は発生しないと思うわ、たぶんwww

WP Super Cache の設定にも依存します

わざわざ説明するまでも無いと思うんだけど、WP Super Cache って HALF ON とか言うふざけたモードがあるのね。

今回問題にしてる 404 Not Found になるバグは、HALF ON 時は発生しないわ。ちなみに HALF ON って WP Cache と同じ機能だけ有効にするってことみたいよ。

バグ発生条件のまとめ

発生条件をまとめるわね。

1. WordPress をインストールするときに、別ディレクトリにホームページを設定した
2. WP Super Cache を ON にした

この条件に該当してて、WP Super Cache をインスコしたら 404 Not Found になった人は、これから説明する方法で直ると思うわよ。

条件に該当してなかったら、別のバグか設定ミスが原因だと思うからさくらは直し方知らないわ。悪いけど自分で調べてねww

直し方

バグの修正方法なんだけど、手作業で直す方法だけ説明することにしたわ。パッチ書いてもいいんだけど、WP Super Cache って割と頻繁にアップデートしてるみたいだし、その都度パッチを作り直すのも面倒だし、そんな大した作業じゃないし、って感じよwww

とりあえず WP Super Cache をインスコしたところ辺りから説明するわね。

まず WP Super Cache を ON にして (Update Status ボタンを押して) 変更を確定させてから、もうちょっと下の方にある Update Mod_Rewrite Rules ボタンは押したかしら？これ押さないと WP Super Cache はキャッシュファイル作ってるだけで完全に有効になってないわよ。

Update Mod_Rewrite Rules を押したらブログのトップページにアクセスして 404 Not Found になってないかすぐ確認してね、すぐよ！すぐ！！ 404 Not Found になってなかったらトラブルには巻き込まれてないから安心してちょうだいww

この時注意して欲しいんだけど、WP Super Cache を有効にしたとき同時に Don’t cache pages for logged in users. オプションを有効にしてたら、WordPress にログインしてる間は 404 Not Found にならないから、一度ログオフしてから確認する必要があるわよ。

で、404 Not Found になってたら、Update Mod_Rewrite Rules を押した際に WP Super Cache プラグインは .htaccess ファイルを間違った設定で更新してる可能性があるわ。.htaccess を開いて、以下の青く塗った部分を確認してね。

# BEGIN WPSuperCache
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
AddDefaultCharset utf-8
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}/hoge/blog/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f
RewriteRule ^(.*) /hoge/blog/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz [L]

RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{DOCUMENT_ROOT}/hoge/blog/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f
RewriteRule ^(.*) /hoge/blog/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html [L]
</IfModule>

# END WPSuperCache

この例だと /hoge/blog/wp-content/cache/supercache/.. って部分が問題になるんだけど、このパスをサイト上の 絶対 URL として見たときに、存在しない URL を指してると 404 Not Found になるわ…この説明で分かるかしら？

例えば sakuratan.biz だと上の部分は /blog/wp-content/cache/supercache/.. ってなってないといけないの。頭の /hoge が余分ってことね。

どう直すのが正しいかはサイトの設定によるわ。直し方が分かったら .htaccess をエディタで開いて下の例みたいな感じに書き換えるといいわよ。

# BEGIN WPSuperCache
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
AddDefaultCharset utf-8
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}/hoge/blog/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f
RewriteRule ^(.*) /blog/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz [L]

RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{DOCUMENT_ROOT}/hoge/blog/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f
RewriteRule ^(.*) /blog/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html [L]
</IfModule>

# END WPSuperCache

.htaccess を書き換えて再度ブログにアクセスしてみて、404 Not Found にならずにちゃんとブログが表示されたら直ったと思ってもらっていいわよ。逆に 404 のままなら RewriteRule の修正方法を見直してね。

この説明でいまいちよく分かんない人は、Apache の mod_rewrite のマニュアル見るか、WP Super Cache を使うのは諦めた方が懸命だと思うわ。坊やにはまだ早いってことねww

さくら

P.S. 言っちゃ悪いけど、このバグってまったくもって PHP クォリティよね。誰もテストしてないのかしら？ PHP プログラマって一括りにされてダンコーガイにあれやこれや言われてもしょうがないような気もするわね、これじゃww