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

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プラグインインストール

プラグインのインストールはいつも通り”管理画面 > プラグイン > 新規追加 > 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”より設定を行います。
なお、次のケースでは以図の警告が出ます。

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

  1. “設定 > パーマリンク設定”で適当なパーマリンクを設定する事で.htaccessファイルを生成
  2. ファイルパーミッションの設定で.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>

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

  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. 通常通りユーザ名・パスワードを入力してログイン

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

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

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”より設定。


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

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のセキュリティを考えてみた。その1 wp-login.phpを不正アクセスから守る | おきらくサーバー運用メモを参考に.htaccessでwp-login.phpに対して自身のIP(固定IPの場合)のみ許可する設定を記述したほうが良いと思われます。

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

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

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

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

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

右下を見ると何やら赤い警告が。クリックしてみると。
エラー警告
更に警告の詳細を見てみる。
エラー警告詳細
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香川」を開催しました

2012/02/11(土)[13:00~17:30]にデザインラボラトリー蒼様をお借りして「第2回WordPerssお茶会 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導入

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

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

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!”とあったのでクリック。

Homebrew

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

WordCrab Fukui 2012に参加してきました

2012/01/21に開催されたWordCrab Fukui 2012に行ってきました。
きっかけはWordCamp Kobe 2011での@teckingさんの告知TLがぐっと来たので。

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福井運営のみなさんありがとうございました!!

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

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

Windows7でSCSS+Compass(導入編)

半年ほど前からSCSS(Sass)LESSについては聞いていたのですが腰が重く手をつけていなかったのですが最近TwitterのTLでよく見かけたので導入してみました。

明確な定義はよく分かっていませんが「CSSを拡張できるmeta言語」という説明をよく見かけたのでCSSを効率的に記述できるようになるフレームワークのようなものという認識です。

SCSSとSassが混同してしまいそうですが、Sassから派生したのがSCSS(Sassy CSS)らしく、記述方法もCSS同様 a { display: none; } の様に波括弧を使用しており慣れているので以下ではSCSSで統一します。

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

この記事を見ずとも参考サイトさえ見れば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 を導入する方法に詳しくありますが一応・・・。

Windows7にRubyをインストール

RubyInstaller for WindowsのDownlaodよりRubyInstallerをダウンロード。
rubyinstaller-1.9.3-p0.exe(12/01/17現在)を使用しました。
rubyinstaller

ダウンロードしたrubyinstaller-1.9.3-p0.exeを起動して手順どおりにインストール。
OSがCドライブの場合Cドライブ下にRuby193フォルダが生成されます。
コマンドプロンプトを起動して以下コマンドを入力。

ruby -v


上のようなエラーが出てくると思うのでRubyへのパスを通す必要があります。
“コントロールパネル > システムとセキュリティ > システム > システムの詳細”よりシステムのプロパティが開くので”詳細設定タブ > 環境変数”のシステム環境変数の中のPathの末尾に C:¥Ruby193¥bin を追加します。

環境設定を保存後再度上記コマンド入力で以下の通り現在のRubyのバージョンが表示されパスが通ったことが確認できると思います。

RubyGemsでSCSS、Compassをインストール

Rubyインストール時にRubyのパッケージ管理ツール”RubyGems”がインストールされているのでそれを用いてSCSS、Compassをインストールします。
が、その前にRubyGems自体のアップデートをしておいたほうが良いらしいのでコマンドプロンプトで以下コマンドを。

gem update --system

RubyGemsがアップデートされたら以下コマンドでSCSS、Compassをインストールできるのですが、試してみたところCompassのインストール時にSCSSもインストールされるようなのでSCSSのインストールは不要かもしれません。

gem install sass

gem install compass

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

Retinaディスプレイ時に読み込む画像を切り替えるjQueryその2

前回のRetinaディスプレイ時に読み込む画像を切り替えるjQueryでは以下の通りRethina・非Retina画像のリクエストが発生して非効率なスクリプトとなってしまっていたので修正しました。

修正後のソースは以下の通り。

[html]

<p><img src="images/grey.png" data-original="images/logo.png" alt="" width="50" height="50" /></p>

[Javascript]

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

img要素src属性にダミー画像を入れておき、カスタムデータ属性を用いて画像パスを格納しています。
3行目でカスタムデータ属性の値を取得。
4行目でRetinaディスプレイか判別。
Retinaディスプレイの場合5行目で画像パス変更。
7行目でダミー画像のsrc属性を書き換えて描画。

これで非Retina画像のリクエストを発生させることなくRetinaディスプレイ時にRetina用画像を表示することが出来ました・・・けどRetinaディスプレイ対応自体どんな手法が正しいのか分かっていないので詳しい方いらっしゃいましたらご教授お願いします。

Retinaディスプレイ時に読み込む画像を切り替えるjQuery

2012/01/05追記

下記で記述しているスクリプトでは読み込み時に非Retina用画像のリクエストが発生してしまいます。 結果、無駄なリクエストとなるので非効率なスクリプトとなってしまいます。

2012/01/12追記

二重にリクエストが発生しないスクリプトをかいてみました。
Retinaディスプレイ時に読み込む画像を切り替えるjQueryその2

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用画像ファイル名に書き換えています。

以上がRetinaディスプレイの場合のみに専用の画像を用いる処理となりますが、iOSシミュレータでの確認のみですので実機での動作及び処理が正しいかは保証しかねますのでご了承ください。
また、日本で発売されているAndroid端末の場合全てではありませんがwindow.devicePixelRatio値が1.5らしいのでAndroid用に1.5倍サイズの画像を作成して、それ用の分岐も用意しておいた方が良いかもしれません。

第1回WordPressお茶会@WordBench香川を開催しました

2011/11/19(土)にデザインラボラトリー蒼様をお借りして「第1回WordPerssお茶会@WordBench香川」を開催しました。

参加者8名(WordBench香川初参加5名、県外から参加2名、ディレクター、デザイナー、プログラマ、他業種の方)と第1回にしては幅広い層の方にお集まり頂きました。

今回はキックオフミーティング時の「次回はお茶会で」との意見からカフェをお借りしてのお茶会形式に、twitterでハンズオンやりたいと呟いたところ是非というお声を頂いたので初心者向けハンズオンを、ハンズオンだけだと場所・自分のキャパに無理があったので雑談も交えてというかたちとしてみました。


ダークサイド土井の図
photo by: style-design

初心者向けハンズオンはWindows・Mac環境でローカル環境を構築してWordPressをインストールしてなにかしよう (第1回WordPressお茶会 – WordBench香川 – INDEX) という内容だったのですが環境周りの準備不足によりWordPressインストールまだで精一杯という結果に・・・(イベント進行がグダグダになるのは想定済み)

また以下の流れから作成をお願いすることになったわぷーWordBench香川バージョンについても大方の意見が集約されましたので近いうちにお披露目できると思われます。

期待!! RT @: ああ、それつくりましょうかねえ。RT @: WordBench香川用にうどんをすすってるわぷーが欲しいところです。 RT @: わぷーをダルメシアンにしたろかな。
@show_web
Sho Doi

以下反省点・今後の課題で思いついたものをつらつらと箇条書きです。

  • ハンズオン組が多くなり過ぎたため、雑談組が少人数になってしまった。
  • ハンズオンだと1対2くらいが限界で御相手できない方が居たので申し訳なかったなと。
  • 主催者がMac初心者なのでトラブルに対応できない。
  • サポート役は数人必要(今回は参加者さんで詳しい方がいらっしゃったのでヘルプして頂きました)
  • 自前の無線LAN環境は必要。(WiMAXルータ安価で性能良いのないかな?)
  • ローカル環境構築というテーマで必要かなと思えるものを考えていったら初心者向けじゃなくなってた。
  • twitterハッシュタグ決めてたけどバタバタしすぎてツイートできず。
  • 参加者が10名超えるようなら会議室借りなきゃ厳しい。
  • 個人的には勉強会みたいなのじゃなくて少人数でわいわいと、というのが好きだけど今後はどうしていったらいいのだろうか。
  • WordPressはやれることが広いので次回ハンズオンはテーマを絞らなきゃ。

参加者の皆さん長時間のお付き合いありがとうございました。
また、場所を提供頂きましたデザインラボラトリー蒼様ありがとうございました。

次回WordBench香川は来年1月あたりに開催予定です。(いつもながら内容は未定ですので要望ありましたらコメントや@show_webよりお願いします)

第1回WordPressお茶会 – WordBench香川 – WordPressのインストール

ローカル環境が整ったのでWordPressをインストールしていきます。
今回はドキュメントルートの確認(Windows7 64bit環境 / Mac OS X 64bit環境)の項で作成した wbkagawa フォルダにWordPressをインストールしたいと思います。

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インストール完了です。「ログイン」をクリックしてログイン画面へ。

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