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

01/20

福井県は初めてだったので念のため前日入り。行程は以下の通りで8時間くらい。
07:10 高松 – 09:50 三ノ宮（フットバス）
10:08 三ノ宮 – 10:28 大阪（以下JR）
11:15 大阪 – 13:15 敦賀
13:39 敦賀 – 14:30 福井

車内から雪景色を見るピカチュウの図

道中は結構雪景色が見れたんだけど福井駅に着いてみると特に雪もなく寒くもなくちょっとしょんぼり(´･ω･`)

前日あまり眠れなかったのでホテル到着後は駅周辺ぶらついたり仮眠取ったり仕事したりで終了。夜中に東京組の@jim0912さんから翌日の一乗谷へのお誘いを頂いたので同行させてもらうことに。

01/21

一乗谷朝倉氏遺跡・一乗滝

朝9時にホテルまで迎えに来て頂くことに・・・諸事情によりホテル前で目印のピカチュウ片手に30分程待ちぼうけ。
東京組の方々と合流し一路一乗谷朝倉氏遺跡、一乗滝へ。

歴史詳しくないので以下画像をつらつらーっと。
皆さん城攻めについて真面目に話してるかと思いきや雪に飛び込んだり佐々木小次郎像と戯れたりと仲良いなぁと。

井戸について考察する東京組の方々の図

一乗滝ピカー

小次郎と一緒♥

WordCrab Fukui 2012

午後から本題のWordCrab Fukui 2012開始。

プログラムは以下の通り（敬称略）。私はCreator’s Roomのセッションを拝聴。
当日のアーカイブは@khoshinoさんがYoutubeにアップされているので、“WordCrab Fukui 2011″へ。

• 恋する♥WordPress（森川徹志）
• Creator’s Room
  • お手軽チューニングで快適生活（古田一生）
  • 現場のワークフローに即したテンプレート構築方法（南部正光）
• User’s Room
  • 諸国漫遊 WordPress事例集（吉村佳志子）
  • モバイルツールでラクラクサイト管理（林美和）
• 悩めるクリエイター・ユーザーのための大質問大会
• ライトニングトーク

本編・懇親会に関しては他の方がレポート書かれていると思うので割愛。

大質問大会でのWordPressコーディング基準云々の質問は実は私がしたもので、解答としては以下を頂戴しました。ご回答ありがとうございました。（WordPressコーディング基準）

• デフォルトテーマでも違反したものがあるのであくまで参考程度でいい（@odysseyさん）
• WordPressのバージョンによって基準が変わっていることがあるので仕方ない（以下@lilyfanjpさん）
• テーマ・プラグインの場合はある程度外れてもいいのかな？
• Twenty Elevenの子テーマを作る場合にはTwenty Elevenを基準に
• インデントの取り方・括弧の書き方は統一されている

結論としてはそんなに気にしなくても、といった感じでしょうか。

ただ、以下 wp-admin/admin.php(WordPress3.3.1現在) を見ただけでも波かっこの後ろに半角スペースがある場合とない場合（あるのが正しいはず）が混じっているのが気持ち悪いなーというのはありますが、たぶんそんなに気にするほどでもないのかな？

if ( isset($_GET['import']) && !defined('WP_LOAD_IMPORTERS') )

if ( isset( $_REQUEST['post_type'] ) && post_type_exists( $_REQUEST['post_type'] ) )

あと採用されなかったもので「子テーマを使うときには親テーマのID、CLASS名、に沿う必要があるのか？」といった趣旨の質問をしてたのですが、なんでこんな質問書いたか不明だけど、以前子テーマで制作しようとしてなにかしら親テーマの制約に縛られてた気がするので書いたのかな？
ここら辺は次回の「第2回WordPressお茶会 WordBench香川」で聞いてみたいところ。

* * *

という訳で懇親会で食べたカニも美味しかったし、いろんな方々に絡んで頂けたので楽しいイベントでしたー。
WordBench福井運営のみなさんありがとうございました！！

ピカチュウもカニに大満足の図

参考にさせて頂いたサイト

この記事を見ずとも参考サイトさえ見ればSCSS/LESSが理解できる、というくらい情報が豊富だったので列挙しておきます。

Less & Sass Advent calendar 2011

昨年度のAdvent Calender。SCSS/LESSに限らずCSSmeta言語やCompassフレームワークについて等、最新・マニアック？な情報が豊富です。以下参考サイトはほぼこちらから。

CSS拡張メタ言語「SCSS(Sass)」と「LESS」の比較 – (DxD)∞
SCSSとLESSのどちらを導入するか迷って、SCSSに決めたポイント – 眠る前に布団にはいろうか

まずSCSSとLESSどちらを導入するか、という点で参考にさせて頂きました。
LESSはnode.jsが必要（node.js分からない）、もしくはクライアント側JavaScriptで動的に生成（動的なのでパフォーマンス面で不安）という理由からRubyさえあれば導入できるSCSSにしました。

Sass を今すぐ実務で使おうよ！ « NAVER Engineers' Blog

SCSSを導入して実際にどのように運用すれば良いのか、という実務について。
個人的には便利だけどクライアント側に導入してもらうには敷居が高いので制作時の効率化の為に使う、というのが現在の考えです。
サーバによってはSCSS自体導入不可なところもありますし。

hamashun.me : Windows PC に Ruby と Sass を導入する方法

既にWindowsにRubyをインストールしていたのですがバージョンが古かったこともあり最新版を導入する際に参考にさせて頂きました。

CSS書くならcompass使った方がいいよ。SASS使ってる人なら特に。 | howtohp
Compassを使ってSassのCSS出力を手軽にしよう｜Blog｜Skyward Design

SCSSを更に便利に使えるフレームワークCompassの導入・使い方について。
CSS3のborder-radiusやReset用CSSのMixinが含まれていて開発効率アップしそう、またSassコマンドより分かりやすいCompassコマンドが便利です。

NetBeansではじめるSCSS | Webエンジニアライフ

Netbeans IDE用のscss-editorの解説。プラグイン自体は便利だと思うのですが私の知識不足の為かCompass導入時にコンパイルエラーが発生してしまったので自動コンパイルは使用せずに整形の為に利用しています。

WindowにRuby、SCSS、Compassをインストールする

SCSSはRubyベースなのでWindowにRubyをインストールする必要があります。
hamashun.me : Windows PC に Ruby と Sass を導入する方法に詳しくありますが一応・・・。

ruby -v

gem update --system

gem install sass

gem install compass

以上がWindows7でSCSS+Compass（導入編）となります。
記事が中途半端ですが仕事があるので実践編は明日以降にしたいと思います。

Retinaディスプレイ用画像設定

スマートフォンサイト制作時、従来の3G/3GSのような非Retinaディスプレイ用画像を用いるとRetinaディスプレイで表示した際に滲んでしまいます。
画素数320x480pxの非Retinaディスプレイと同様の3.5インチの画面サイズに4倍の画素数である640x960pxで描画されるため画像が引き伸ばされてしまうためです。

そこで非Retinaの倍の画像を作成してimg要素width/height属性に画像の半分の値を設定することでRetinaディスプレイで画像を奇麗に表示することができます。

[html]

<p>3G用画像（50x50px）<br />
<img src="logo.png" alt="" width="50" height="50" /></p>
<p>Retina用画像（100x100px）<br />
<img src="logo@2x.png" alt="" width="50" height="50" /></p>                   

Retinaディスプレイの場合のみ専用の画像を用いる

倍サイズの画像を用いる事でRetinaディスプレイで奇麗な画像を表示する事ができますが、遅い回線でアクセスした際に表示に時間が掛かるのでRetinaディスプレイ時のみ倍サイズの画像を用いる様にjQueryで振り分けるようにします。

前提として画像は2種類（非Retina用・Retina用）を作成します。
Retina用画像は “@2x” をファイル名末尾に追加しておきます。

• logo.png（非Retina用）
• logo@2x.png（Retina用）

[Javascript]

	$(function(){
		if(window.devicePixelRatio > 1) {
			$('img').each(function(){
				var src = $(this).attr('src');
				$(this).attr('src', src.replace(/(\.jpg|\.png)/gi,'@2x$1'));
			});
		}
	});
	

ソースは上記の通り。
2行目のwindow.devicePixelRatioでRetinaディスプレイかを判別しています。iPhone4/4Sでは値が2になります。
3行目からimg要素をループして、4行目でimg要素のsrc属性を取得、5行目でRedina用画像ファイル名に書き換えています。

WordPress本体の準備

WordPress | 日本語 サイトの「WordPress 3.2.1 をダウンロード .zip — 4.2 MB」（2011/11/15現在）よりWordPressをダウンロードして解凍してください。

展開された wordpress フォルダを wbkagawa フォルダへ移動させておいてください。

データベースの準備

WordPressはMySQLデータベースを必要とします。
XAMPP、MAMPは共にMySQL管理ツールphpMyAdminがインストールされているのでこちらを使用してデータベースを作成していきます。
phpMyAdminの場所は以下を参照ください。
（なおphpMyAdminのキャプチャ画面はXAMPPのphpMyAdmin3.4.5の為、MAMP環境では多少仕様が異なります。）

Windows7 64bit環境

Mac OS X 64bit環境

phpMyAdminのログイン画面が表示されるのでXAMPPのセキュリティで設定したMySQL rootパスワードを入力してください。
（Mac OS Xではログイン画面は表示されません。（ハンズオン時に説明予定））

phpMyAdminのホーム画面です。「データベース」よりデータベースを作成していきます。

「新規データベースを作成する」のテキストボックスにデータベース名（今回はwbkagawa）を入力して「作成」をクリック。

wbkagawaデータベースが作成されました。

WordPressのインストール

WordPress本体、データベースの準備が完了したのでWordPressをインストールしていきます。
http://localhost/wbkagawa/wordpress/ へアクセスして「設定ファイルを作成する」をクリック。

データベース関連の説明を一通り読んで「次に進みましょう！」をクリック。

「データベース名」は先程作成した”wbkagawa”。
「ユーザ名」はXAMPPの場合”root”、「パスワード」はセキュリティの項で設定したパスワード、MAMPの場合は「ユーザ名」「パスワード」共に”root”（MAMPのデフォルト設定です）。
（今回はローカル環境なのでroot権限にしていますが、本番環境では別途ユーザを作成、パスワードも推測し難いものを設定してください。）
「データベースのホスト名」と「テーブル接頭辞」はデフォルトのまま。

設定に間違えがあったりMySQLを起動してない場合以下のようなエラーが表示されるので再度設定を確認してください。

問題なければインストール準備完了となるので、「インストール実行」をクリック。

「ユーザ名」はデフォルトの”admin”以外の任意のユーザ名を入力。
「メールアドレス」に登録したアドレスに本来ならログインURL、ユーザ名、パスワードが届きますが今回はローカルでのメール送信設定を行なっていないため届きません。パスワードは後程必要となるので控えておいてください。
その他入力が完了したら「WordPressをインストール」をクリック。

以上でWordPressインストール完了です。「ログイン」をクリックしてログイン画面へ。

登録したユーザ名・パスワードを入力して「ログイン」。