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をダウンロードしてお使いください。

Leave a Reply