PHPのテクメモ

WordPress3.0あたりから、管理画面の記事投稿画面で入力する際、表画面のデザインcssを適用して、より直感的に記事投稿できるようになったとのことだったので、やり方を調べてメモ。

1. 使用するテーマフォルダ内にfunctions.phpがあるかどうかを確認し、なければ追加する。
2. functions.phpに以下の1行を追加する。
   add_editor_style();
3. テーマフォルダ内にeditor-style.cssファイルを用意し、そこに記事用のCSSを定義する。

とこんな感じ。add_editor_style関数は引数をひとつ与えることが出来るのだが、それは使用するcssファイル名。デフォルトでeditor-style.cssになっている。つまり以下のような感じ。

add_editor_style($style=’editor-style.css’)

これで使いやすくなるし、提案しやすくなる。ただ、まぁ、WordPressのテーマを作るのは、それはそれで面倒ではある。実際の実装作業は、コーディング屋さんにお願いするけどね。

何回やってもその都度忘れるのでメモ。

mysqldump db_name > dump.sql

mysql db_name < dump.sql

そしてこのエラーも毎回悩む。

ERROR 1005 at line 23: Can’t create table ‘./masters/answers.frm’ (errno: 150)

mysqldumpでは、innoDBで外部制約を使っていたとしても、それを考慮したSQL文とはなっていない（子テーブルの記述が親テーブルより先にくることがある）。結果として上記のようなエラーになる。

これを回避するには、リストアする前のSQLファイルに以下の1行を加えておく。

SET FOREIGN_KEY_CHECKS=0;

覚えられない。若い頃は「調べればわかるものは覚えない」というポリシーだったが、何度か使うと覚えていた。しかし最近はポリシーこそ変わらないけれど、一向に覚えられない。

老いた。

preg_match関数は以下のようにして使う（第三引数以降はオプション）。

preg_match($pattern,$subject,$matches,$flag,$offset);

第三引数$matchesには$subjectのうち$patternにマッチした文字が配列で格納される。例えばこんな感じ。

preg_match(‘/^(question([0-9]{2}))\.class\.php$/’,’question01.class.php’,$matches);
var_dump($matches);

array(3) {
[0]=>string(20) “question01.class.php”
[1]=>string(10) “question01″
[2]=>string(2) “01”
}

パターンマッチした箇所が配列で取得できるのだが、キーが数字なので、あとの取り扱いで少し不便。これを以下のように書きなおすことが出来る。

preg_match(‘/^(?P<name>question(?P<number>[0-9]{2}))\.class\.php$/’,’question01.class.php’,$matches);
var_dump($matches);

array(3) {
[0]=>string(20) “question01.class.php”
[“name”]=>string(10) “question01″
[1]=>string(10) “question01″
[“number”]=>string(2) “01”
[2]=>string(2) “01”
}

これでキーがnameとかnumberとか、わかりやすくて使いやすくなる。マニュアルに書いてあったのを見つけた。名前付きサブパターンというらしい。便利そうなのでメモ。

• 7月28日10時09分
  外部からのDDoS攻撃。約30分程度。
• 8月5日23時33分頃
  サーバ障害発生。原因調査と復旧作業開始（連絡が来たのが8月6日2時32分）
• 8月6日4時45分
  復旧作業完了（物理サーバの再起動）。
  障害内容は ゲストOS起動不可、ストレージへのアクセス不能。
• 8月6日13時25分
  サーバ障害発生。原因調査と復旧作業開始（連絡が来たのが8月6日15時38分）
  ただし本当はもっと前からサーバはおかしかった。つまり物理サーバ再起動は、何の解決にもなっていなかったと思われる。
• 8月6日16時45分
  復旧作業完了（物理サーバの再起動）。
  障害内容は ゲストOS起動不可、ストレージへのアクセス不能。
• 8月7日11時45分
  ゲストOS起動不可。
• 8月7日12時45分
  物理サーバ再起動。

普通にこの経緯をみただけでも「物理サーバの再起動は一時しのぎであって根本的な解決にはなっていない」とわかるのだが。どのくらいの頻度でトラブルのかちょっと見ものだな。

諸般の事情でMySQLのバイナリログをちゃんととっておかないと・・・という場面に遭遇してしまった。本来開発がメインだからセキュリティとか設定とかそういうのはやらないことにしているのだけれど、事情があってやむを得ず・・・。

MySQLはデフォルトではバイナリログを保存する設定にはなっていない。取得するための設定は/etc/my.cnfの[mysqld]セクションで以下の記述をして、MySQLを再起動。

log-bin=/home/binarylog/mysql-bin

ログを見るにはmysqlbinlogコマンドを使えばいい。

SQLだけ吐き出すにはこんな感じ（らしい）。

mysqlbinlog -D -uroot -pxxxxxxx　-database=”db_name” /backup/mysql-bin.000001 > /backup/bin.sql

まぁ、使わずにすむものなら使いたくない。