Monthly Archives: August 2013

WordPress3.7alpha開発開始を機に、頼まれもしない予想をする

English version is not available.
注意: 1950年代、60年代のジャズを知らない人には、まったく意味不明な記事です。

WordPressのSubversionリポジトリのtrunkが3.7alphaバージョンになっています。どうやら、MysqliやPDOの採用はまだないようです。3.8と平行開発という話しもありますから、Linuxカーネルのように、安定版と実験的機能を試す版を分けて開発する体制になるようです。3.8のリリース予定次期(3.7の2か月後)から考えて、Linuxの偶数バージョンと奇数バージョンのような感じになるではないでしょうか。まだ3.8のブランチはないようです。

WordPress3.6のコードネーム(*1)はオスカー・ピーターソンでした。バージョン1.0以来、WordPressは、それぞれのマイナー・バージョンにジャズ・ミュージシャンの名前をつけているのは周知のことと思いますが、それでは、次期バージョンの3.7および3.8は、誰か? というのを予想してみました(*2)

  1. リリースバージョンにつけられる名前だから、コードネームと呼ぶのは変なのですが…
  2. 忙しくて、しかも暑いので、現実逃避モードです… 🙁

歴代のバージョンをまとめると、下の表のようになります。ウィキペディアのWordPressも、その英語版WordPressも、バージョン1.0をあげていませんが、CodexのWordPress Versionsおよびその日本語版WordPress Versionsでは、1.0マイルス・ディヴィスのほか、1.0.2アート・ブレイキーも入っています。2.0.5は、ミュージシャンではないので、例外として、ここでは考えません。

WPバージョン ミュージシャン 生年-没年 楽器
1.0 マイルス・デイヴィス 1925-1991 トランペット
1.0.2 アート・ブレイキー 1919-1990 ドラムス
1.2 チャールス・ミンガス 1922-1979 ベース
1.5 ビリー・ストレイホーン 1915-1967 ピアノ
2.0 デューク・エリントン 1899-1974 ピアノ
2.0.5 Ronan Boren
2.1 エラ・フィッツジェラルド 1917-1996 ボーカル
2.2 スタン・ゲッツ 1927-1991 テナー・サックス
2.3 デクスター・ゴードン 1923-1990 テナー・サックス
2.5 マイケル・ブレッカー 1949-2007 テナー・サックス
2.6 マッコイ・タイナー 1938- ピアノ
2.7 ジョン・コルトレーン 1926-1967 テナー/ソプラノ・サックス
2.8 チェット・ベイカー 1929-1988 トランペット
2.9 カーメン・マクレエ 1920-1994 ボーカル
3.0 セロニアス・モンク 1917-1982 ピアノ
3.1 ジャンゴ・ラインハルト 1910-1953 ギター
3.2 ジョージ・ガーシュイン 1898-1937 作曲家
3.3 ソニー・スティット 1924-1982 テナー/アルト・サックス
3.4 グラント・グリーン 1935-1979 ギター
3.5 エルヴィン・ジョーンズ 1927-2004 ドラムス
3.6 オスカー・ピーターソン 1925-2007 ピアノ

ざっと見た感じでは、だいたいみな同じような世代です。モダン・ジャズ自体、この年代の演奏家たちが作り、聞き手の耳がそれに慣れるのと平行して普及していったものですから、当然といえば当然なのですが、あらためてモダン・ジャズの「若さ」がわかります。20世紀が経験した2つの世界大戦の間に生を受けた才能ある青年たちが、ほんの少しの間にビバップからハードバップを経て、フリー・ジャズまで経験してしまったわけです。なお、1901年生まれのルイ・アームストロングは父親くらいの年齢になりますが、WordPressに付属のプラグイン、Hello Dollyがあるので、ここには出てこないようです。

バージョン1.0が、チャーリー・パーカーではなくて、マイルス・ディヴィスから始まるというは、多くの人が納得すると同時に、それ以降の人選を規定したと言ってもいいかもしれません。それでも、次がアート・ブレイキーでしたから、ここからチャーリー・パーカー、ディジー・ガレスピーという選択もあったと思いますが、チャーリー・ミンガスを選んじゃったので、もうチャーリーはないのでしょうね。

ビッグバンドを率いたデューク・エリントン、ギタリストのジャンゴ・ラインハルト、作曲家のジョージ・ガーシュインが若干異質だけれども、全体的には、マイルス・デイヴィス、ジョン・コルトレーンを中心としたメンバといってもいいと思います。マイルスと共演、あるいはバンドに在籍した人が多いし、コルトレーン・カルテットからは、本人を含めてすでに三人が登場しています(あとはベーシストのジミー・ギャリソンのみ)。4ビートジャズを演奏する人たちがほとんどなので、『ビッチズ・ブルー(Bitches Brew)』以降にマイルスと共演した人は、可能性が薄いですね(ウェイン・ショーターは微妙です)。

ちなみに、楽器別の人数を集計すると、下のようになります。

楽器 楽器 楽器
トランペット 2 ピアノ 5 ドラムス 2
ベース 1 ギター 2 テナー/アルト・サックス 5
ボーカル 2

うーん、サックス奏者とピアニストが多いですねぇ。トロンボーン奏者がいないのは、ビッグバンド以外ではあまり活躍の場がなかったからでしょうが、J・J・ジョンソンにリーダーアルバムが少なかったこともあるかもしれませんね。ピアニストがすでに5人もいては、ビル・エヴァンスの登場も当分ないということでしょうか。エルヴィン・ジョーンズ、オスカー・ピーターソンときたら、ソニー・ロリンズという名前が浮かぶけれども、サックス奏者が5人もいて、ロリンズが出てこないというのは、彼は選ばないという表明のようにも考えられますし、単純に「ソニー」がもう使えないというだけかもしれません。それでもロリンズとスティットの比較はあったはずなので、スティットの方を選んだということでしょう。

存命の人がマッコイ・タイナーだけというのも気になります。鬼籍に入ったミュージシャンへのオマージュのリストとも考えられるからです。また、ギタリストがすでに2人いるというのもちょっと驚きです。チャーリー・クリスチャンはファースト・ネームがミンガスとかぶってしまうので、使えなかった可能性があります。ウェス・モンゴメリー、ジョー・パス、ジム・ホールなどは候補になりそうです(ジム・ホールは存命)。

デューク・エリントンが出てしまいましたから、グレン・ミラー、ベニー・グッドマン、カウント・ベイシーは当分はないのかもしれません。ミラーとグッドマンはそれぞれ、初のトロンボーン奏者、初のクラリネット奏者となりますし、「グレン」も「ベニー」もまだないので、おもしろいとは思うのですが…コルトレーンの『アセンション』以降というのも微妙ですね。ばりばりのフリー、あるいはそれに近い人が一人もいないことは一目瞭然ですから。実験バージョンの3.8がオーネット・コールマンと呼ばれたら月並みでしょうか。同様に、ハンニバル・マーヴィン・ピーターソンなども外れるでしょう。こう考えてくると、このリストは、ハードバップでジャズに目覚めた人が作っているとも見えてきます。

ベーシストが1人しかいないというのも、気になりますね。しかも、その1人がミンガスですからねぇ。いわゆるベーシストがほしい気もします。マイルスのバンドからなら、ポール・チェンバース、ロン・カーターですが、ジミー・ギャリソンでコルトレーン・カルテット完成というのもなきにしもあらずです。

さて、きりがないので、そろそろ予想に入りましょうか。

バージョン3.7および3.8のロードマップは下のように発表されています。

バージョン リリース予定
3.7 1013年10月
3.8 2013年12月

1950年代、60年代の演奏家で、既に亡くなっている人、さらにアート・ペッパーのように既出の人と呼び名が同じ人は外すことにして、こんなのでどうでしょう。

バージョン 本命◎ 対抗○ 単穴▲ 連下△
3.7 ポール・チェンバース ウェス・モンゴメリー ディジー・ガレスピー クリフォード・ブラウン
3.8 レッド・ガーランド ビル・エヴァンス エリック・ドルフィー キャノンボール・アダレイ

実際に名前を入れてみると、普通になってしまいますね。やはり音楽家は、その演奏を「聴く」ものであって、名前がどうこうとうい存在ではないようです。それぞれのプレーヤーは個性的な演奏をする人たちばかりですから、ぜひ実際に聴いてみてください。

Pluginの互換性をまとめて検証した

English version is available in Plugins compatibility checked

SQLiteでWordPressを動かす事がおすすめできない理由』というページがあります。PDO for WordPressプラグインを使った様子を述べているのでが、たいへん的確でよい文書です。2年以上も放置されているプラグインを使って、うまく動作しないなどと難癖つけるのは大人げない、と考える人がいないとも限りませんが、現実にそれを勧めているサイトがあり、もっともらしい修正方法まで書いてあったら、使ってみようという人が出てくるのは当然のことでしょう。でも、ユーザには、使ってみた結果、これは使うべきではないと判断したら、さっさと別の方法を試す自由があります。その判断をウェブで公開してくれたYHR氏の報告は、大人げないどころか、そのコンパクトな記述と明快な論理から、投稿者がたいへんに聡明な方だというのがよくわかるものになっています。PDO for WordPressを苦労しながらインストールして、情報を公開している方には申し訳ないけれども、こちらの方が遙かに説得力があります。

さて、このページで引用されている『WordPress3.5をSQLiteで使う』に、PDO for WordPressで動作しなかったプラグインのリストがあります。これをまとめて検証してみました。

  • WordPress Popular Posts
  • Broken Link Checker
  • WP-PostViews
  • Better Delete Revision
  • Redirection
  • DB Cache Reloaded Fix

WordPress Popular Postsについては、不具合と修正案をすでに書いてありますので、そちらを参照してください。DB Cache Reloaded Fixについては、SQLite Integrationのドキュメントに書きましたので、そちらをご覧ください。残る4つについては、下の通りです。

WP-PostViews

最新バージョン(1.65)を見る限り、使えなかった理由がわかりませんでした。いくつかPHP Noticeが出ていますが、非推奨の関数を使っていたり、配列のインデックスが未定義であったり、変数が初期化されていないために未定義のまま使われてしまったりといった部分だけなので、データベースへの接続には支障がありません。

インストール、アクティベートして、一通りチェックしただけなので、まだ発見できていない不具合があるのかもしれませんが、SQLite Integrationで使えると判定しておきます。不具合を発見したら、お知らせください。

Broken Link Checker

PDO for WordPressでは、テーブルを作る段階でエラーになったと思われます。手動でテーブルを作ったとしても、ALTER TABLE ステートメントやSHOWクエリを使っていますので、使いものにならなかったはずです。

1か所だけ、バージョン 0.9.5 からのアップグレードをする部分で、JOINをともなったUPDATEクエリが使われていますが、現行のバージョンが 1.8.2 ということで、影響はないと思われますので、書き換えはしません。

何もしなくても SQLite Integration で使えるはずです。

Better Delete Revision

最終更新日が 2010-10-22 です。普通なら使うのをためらうはずですが、一応確認してみました。SQLite Integrationで使うとしたら、下の修正が必要です。

削除コマンドに LEFT JOIN が使われています。PDO for WordPressはもちろん、SQLite Integrationでも動作しません。

このクエリは、確認なしに全てのリビジョンを削除します。思い切りがよい、というか、前回のリビジョンくらいは残しておきたいという人には勧められません。また、autosaveデータが残ります。SQLiteのDELETE文では、このJOINとテーブルエイリアスが使えず、複数テーブルの削除も対応していないので、もし書き換えるとすると、下のように、4つのクエリが必要になります。上ではget_results()が使われていますが、削除クエリなので、query()に変えてあります。エラー処理もありません。

さらに、CHECK TABLEでデータベースの整合性チェックができるのと、テーブルの最適化をするおまけがついていますが、SQLite では意味がありません。整合性チェックはSQLite Integrationの管理画面で見ることができますし、最適化もできますから、書き換えるまでもなく、単に削除するだけです。

上のリビジョンを全て削除する機能にしても、wp-config.phpに下のように書けばリビジョンは作られないので、プラグイン自体が必要ないのではないか、と思えてきます。

ということで、このプラグインのパッチはありません。SQLite Integrationでは使えない、としておきます。

Redirection

テーブルを作る段階でエラーになっていたと思われますが、アップグレード関数で使われているクエリがALTER TABLEですから、PDO for WordPressでは、エラーだらけだったはずです。その中に、また、下のようなクエリがあったので、調べてみました。

prefix_redirection_groupsテーブルのmodule_idカラムにインデックスを作る命令ですが、インデックスの名前がありません。

ALTER TABLE 構文を見ると、下のような例がありました。

この場合、インデックス名がどうなるかは、記述がありません。試してみましょう(出力は省略してあります)。

mysql> create table test (id int);

mysql> show columns from test;
+--------+---------+------+-----+---------+-------+
| Field  | Type    | Null | Key | Default | Extra |
+--------+---------+------+-----+---------+-------+
| id     | int(11) | YES  |     | NULL    |       |
+--------+---------+------+-----+---------+-------+

mysql> alter table test add index(id);

mysql> show index from test;
+-------+------------+----------+---
| Table | Non_unique | Key_name | ...
+-------+------------+----------+---
| test  |          1 | id       | ...
+-------+------------+----------+---

カラム名と同じ名前のインデックスが作られるのですね。

これは、SQLite Integrationでは実装していなかったので、カラムの名前をインデックス名にするように変更しました。

さらにコードを読み進めると、models/log.phpに下のようなインデックスヒントを使っている部分を見つけました。

SQLiteでは、インデックスヒントが意味を持ちませんので、USE INDEXを削除するようになっていましたが、ついでなので、残りのIGNOREとFORCEも削除できるように変更を入れました。

これでRedirectionが使えるようになったはずです。Redirection本体の修正は必要ありませんが、Plugin Directoryで公開しているSQLite Integration 1.2.1 には、上の修正が入っていませんので、すぐにRedirectionを使いたいという場合は、開発版のページからDevelopment Versionをダウンロードしてお使いください。

Plugins compatibility checked

Japanese version is available in Pluginの互換性をまとめて検証した

I happened to read an article called "The reason I don’t recommend you to run WordPress with SQLite"(written in Japanese) reporting the results from using PDO for WordPress, which is very precise and impresses me favorably. Some people may say it’s selfish to complain about the plugin not maintained for more than two years. We, however, can easily find quite a few sites that recommend that plugin and give plausible instructions about the correction of the codes, so it’s very likely that one is inclined to try installing and using it. When he/she finds it useless, no one or nothing prevents him/her from throwing it away and trying another way. He/She is not to blame. That report written by Mr/Ms YHR is far from selfish and its compact description and clear logic shows the author is very intelligent and smart. It’s far more cogent than the articles that copy and paste the incomplete instructions.

BTW, the article "Using WordPress3.5 with SQLite"(written in Japanese) Mr/Ms YHR cites gives the list of the plugins that didn’t work with PDO for WordPress. I checked them with SQLite Integration. The list is below:

  • WordPress Popular Posts
  • Broken Link Checker
  • WP-PostViews
  • Better Delete Revision
  • Redirection
  • DB Cache Reloaded Fix

As for WordPress Popular Posts, see my post WordPress Popular Posts, and for DB Cache Reloaded Fix, I wrote in the documentation of SQLite Integration. I checked the other four.

WP-PostViews

Seeing the latest version(1.65), I can’t find the reason of the malfunction with PDO for WordPress. PHP puts out some notice messages: use of unrecommended function, undefined index of an array and undefined variable. They are not concerned with the database access methods.

I only installed, activated and checked the basic behavior(no problem). There may be a flaw or two I couldn’t specify. If you find one, please let me know. I count this plugin in the list of the plugin that works fine with SQLite Integration.

Broken Link Checker

PDO for WordPress can’t create the required tables. Even if you create them manually, it uses ALTER TABLE statements and SHOW query which PDO for WordPress can’t manipulate.

UPDATE query with JOIN statement is used only once in the upgrade function from 0.9.5, but I think this function will never be executed because current version is 1.8.2. So you don’t have to rewrite the code.

As for other queries, SQLite Integration can manipulate. I also count this plugin in the list of the plugin that works fine with it.

Better Delete Revision

It’s last updated 2010-10-22. I checked if it can be used with SQLite Integration, but I recommend you not to use it. You need to change some codes like below:

There’s DELETE command with JOIN statement. Not only PDO for WordPress but also SQLite Integration can’t execute it.

This statement will remove all the revisions without notice. Decisive and resolute, but if you want the latest revision to remain, don’t use it. Autosaved data will not be removed. SQLite doesn’t support DELETE with JOIN and table aliases, and can’t delete from multiple tables at a time. If you rewrite this statement, you need four separate statements like below. get_results() is meaningless, so I changed it with query() and without error trapping.

This plugin gives the utility to check the integrity of the database and optimize it with CHECK TABLE command, which is meaningless to SQLite. SQLite Integration gives the integrity information on the dashboard and can also do optimization there. You don’t have to rewrite the codes but removing them is enough.

In my personal opinion, when you use SQLite, you’ll do fine without this plugin. If you don’t want the revision, you will add one line in wp-config.php like below:

So, I don’t make a patch file for this plugin, and I count it in the list of the plugins that doesn’t work with SQLite Integration.

Redirection

PDO for WordPress can’t create the required tables and manipulate ALTER TABLE statement. I came across one query below and checked what it does.

This statement creates INDEX to module_id column in redirection_groups table but it doesn’t specify the index name.

MySQL document ALTER TABLE Syntax doesn’t say that index_name is optional. We only see an example below in the users’ comments.

The documents doesn’t say what the index_name is in this case. So I tried it.

mysql> create table test (id int);

mysql> show columns from test;
+--------+---------+------+-----+---------+-------+
| Field  | Type    | Null | Key | Default | Extra |
+--------+---------+------+-----+---------+-------+
| id     | int(11) | YES  |     | NULL    |       |
+--------+---------+------+-----+---------+-------+

mysql> alter table test add index(id);

mysql> show index from test;
+-------+------------+----------+---
| Table | Non_unique | Key_name | ...
+-------+------------+----------+---
| test  |          1 | id       | ...
+-------+------------+----------+---

The index_name is the same as the column name.

SQLite Integration doesn’t execute this type of statement properly. I changed the procedure to manipulate it as above.

Reading the codes further, I came across the index hinting in modules/log.php.

This index hinting is meaningless to SQLite, so SQLite Integration simply removes USE INDEX hinting. But not IGNORE or FORCE. I changed the regular expression to remove (USE|IGNORE|FORCE) INDEX(index_name).

Now, here we are. You can use Redirection without changing the code. Notice current released version(1.2.1) of SQLite Integration doesn’t have the modifications above. If you want to use Redirection immediately, please download Development Version from Developers page.

SQLite Integration 1.2.1 アップデート

English version is available in SQLite Integration 1.2.1 updated

SQLite Integration を 1.2.1 にアップデートしました。WordPress 3.6 の変更に合わせました。

  1. real_escape 変数宣言がない、と PHP notice が出力されていました。

WordPress 3.6 では、includes/wp-db.php で使われていた real_escape プロパティが廃止されたので、これを使っていた _real_escape() 関数の定義が少し変更になっています。SQLite Integration は、wpdb クラスを継承し、同関数をオーバーライドしているので、これに合わせた定義に変えました。

SQLite Integration 1.2.1 updated

Japanese version is available in SQLite Integration 1.2.1 アップデート

Updated SQLite Integration to version 1.2.1 to catch up with WordPress 3.6.

  1. SQLite Integration was putting out PHP notice: no such variables…

They removed the property real_escape in wp-db.php in WordPress 3.6, which property _real_escape() function used. Accordingly, the definition of _real_escape() function was a little changed. SQLite Integration, which inherits the wpdb class and overrides that function, also changed the definition.

SQLite Integration 1.2 リリース

English version is available in SQLite Integration 1.2 released

SQLite Integrationを1.2にアップデートしました。変更は下の通りです。

  1. パッチファイルをサーバにアップロードするとき、ダッシュボードでunknown variableだと怒られます。
  2. Windowsマシンで運用している場合、アップロードしたパッチファイルが削除できませんでした。
  3. ON DUPLICATE KEY UPDATEをともなった複数行のqueryの書き換えに失敗します。
  4. その他、文書などの修正。

最初のものは、global宣言なしにglobal変数を使っていました。

二番目のものは、Windowsマシンに存在しない rm コマンドを使っていたためです。Windows には、del または erase という削除コマンドしかありません。UNIX でも Windows でも共通して使えるように、PHP の unlink() 関数を使うように修正しました。

三番目のものは、正規表現の使い方が原因でした。WP Emmetを使っているときに、発見しました。対応するように正規表現を書き換えましたが、これで100%安全かどうか自信が持てません。問題が出たら教えてください。

SQLite Integration 1.2 released

Japanese version is available in SQLite Integration 1.2 リリース

I updated SQLite Integration to 1.2. Below is the changes.

  1. When you upload a patch file to the server, you’ll get unknown variable error on the dashboard.
  2. When you use Windows machine, you can’t remove the uploaded patch file(s).
  3. Fails in rewriting the query string with ON DUPLICATE KEY UPDATE when it is multi line query.
  4. Other minor changes.

The first one is from the use of the global variable without global declaration.

The second is from the use of rm command on the Windows machine, which only has del or erase command but no rm. I changed the function to use PHP unlink that works both UNIX server and Windows server.

The third is from the use of the PHP regular expression. I found this when I try to use WP Emmet that uses the multi line query with ON DUPLICATE KEY UPDATE. I changed the regular expression, but I can’t sure this is 100% safe. If you have a problem, please let me know.