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.


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.


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.

Leave a Reply