Author Archives: charlus

SQLite Integration 1.7 release

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

Things changed

SQLite Integration 1.7 is released. These changes were applied.

  1. WordPress 4.0 installation and compatibility checked.
  2. Added an option for memory usage rate.
  3. When the user set pcre.backtrack_limit to a huge value, it is made use of by the plugin.
  4. Fixed the bug for CREATE TABLE manipulation.
  5. Changed the procedure of BETWEEN comparison of Meta Query.
  6. Fixed the bug for changing order of the attachment files on the visual editor.


There are no drastic changes in WordPress 4.0 but a few in wpdb class, and some functions deprecated. This version follows these changes. If you are using an older version of SQLite Integration with WordPress 4.0, LIKE query might not work properly. I strongly recommend you to upgrade to the latest version. Other changes and fixes are explained below.

When destructor is called, the memory usage rate is more than 90% of the allocated and the option constant SQLITE_MEM_DEBUG is set to true, the plugin can write the information to the file. When debugging, this feature may help you.

When pcre.backtrack_limit is set to a huge value, the plugin will use that value. SQLite Integration will use up to 100 times the default value, which I think is enough. This change comes from the discussion on the forum.

The manipulation of the BETWEEN comparison of Meta Query is a little changed, which will make the excution a little faster. But I’m not sure if it works fine on the safe mode of PHP. This change also come from the discussion on the forum.

When you change the order of the attachment files in the visual editor, it wasn’t saved properly. This bug was fixed. This bug was reported on the Japanese forum.

With the fix above, I added some codes PHP 5.2.x doesn’t execute. If your PHP is version 5.2.x, edit query.class.php a little like below.


My test environment is PHP 5.5, so I can’t test with PHP 5.2.x. I recommend that you should use version 5.3 or above, if you can.

Notices about installation and upgrading

WordPress 4.0 changed the installation process a little. When you install without wp-config.php, the installation will fail. So it is required to prepare wp-config.php from this version of SQLite Integration on.

On the first stage of the installation, you are asked to choose your default language, according to which WordPress downloads appropriate catalog files. At the same time, your chosen language info will be stored in the database. According to this change, they removed the line below from wp-config-sample.php.

If you want to change the site language, you’ve got to visit "Settings » General" and select the dropdown box.

When upgrading, constant WPLANG will be set according to the rules below.

Your site is not multisite, the value of WPLANG is not sotred in the database, the value of WPLANG is defined in wp-config.php, and there’re language catalog file is in wp-content/languages directory, these conditions are all satisfied, then that value will be stored in the database. Or else the value of WPLANG in the database will be empty string.

These conditions and the change of the definition of get_locale() function might cause the different behavior from before. If so, do as the case of new installation.

If you are changing the language dynamically, e.g. according to the browser’s preference, you are required to set the language information like below in wp-config.php.

$locale is set, and you can change the site language. The value of WPLANG constant will not be enough.

About these changes, SQLite Integration does nothing. It will only behave as WordPress commands. Nothing else will be changed after upgrading, I guess.


I owe this release to many users’ feedbacks. I appreciate their contributions.

When you notice malfunctioning or bug, I’ll appreciate receiving your reports or suggestions by the comment in this site or posting to the support forum. Thank you.

SQLite Integration 1.6 released

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

SQLite Integration version 1.6 was released, and updated to 1.6.1.

For SQLite Integration 1.6, these changes were applied.

  1. WordPress3.9 installation and compatibility are tested.
  2. Fixed the bug for the incorrect paging information in some queries.
  3. Fixed the bug for the backtick removal in comments.
  4. Feature to download the backup database file is enabled.
  5. Changed the readme.txt
  6. Augmented the list of compatible plugins ( Thanks to Alex Armeda ).
  7. Some functions disabled in wp-db.php are enabled.
  8. Augmented the user defined functions for more compatible plugins.

For 1.6.1, these changes were applied.

  1. Fixed the bugs for using with WP Slimstat plugin.
  2. Display admin notice when not replacing the old db.php with the new one (if necessary).
  3. Added the new utility for updating db.php file.
  4. Fixed the Japanese translation catalog.
  5. Fixed some minor bugs.
  6. Fixed the typos in readme.txt.

This update mainly targets for WordPress 3.9 compatibility. But it also includes some bug fixes.

Alex Armeda gave me the plugin compatibility list. I merged it to the archive. I appreciate the contribution from him and his team. He gave me some other useful suggestions, which I couldn’t implement yet.

Mr/Ms Duong reported some constants in wp-config.php doesn’t have effect in Support Forum. I included some of his suggestions like below, though he/she hasn’t answered my response yet.

constant effect
DISALLOW_FILE_EDIT If set ‘true’, db.php editing is disabled.
DISALLOW_FILE_MODS If set ‘true’, db.php editing is disabled.
WP_PLUGIN_URL If set, stylesheet and JavaScript in the dashboard was disabled. This is fixed. Notice that if you want to set this constant, you must also set WP_PLUGIN_DIR at the same time.
WP_PLUGIN_DIR Work as you expected.

Mr/Ms steadybright reported in Support Forum that WP Slimstat doesn’t work with this plugin. I added some features to enable you to use WP Slimstat, although some of the features, e.g. database information, don’t work. You will be able to install and activate that plugin, I guess. To use the plugin, however, you’ll need some hacks to the plugin code, see the forum thread above. The author of WP Slimstat (camu) accepted my suggestion, so you won’t need hacks on the code in the next release. I appreciate camu’s generosity and steadybright’s suggestion.

When you notice malfunctioning or bug, I’ll appreciate receiving your reports or suggestions by the comment in this site or posting to the support forum. Thank you.

SQLite Integration 1.5 released

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

SQLite Integration version 1.5 was released.

  1. WordPress3.8 installation and compatibility are tested.
  2. Changed the admin panel style sheet to fit the new responsive Admin panel.
  3. Added the code to check if the SQLite’s compile option about UPDATE or DELETE with LIMIT is enabled or not.
  4. Added the functionality to change the database between SQLite and MySQL.

Some of the users reported that they succeeded in installing WordPress3.8 with an older version (thanks for reporting), I checked myself if the latest version of WordPress works fine. I found no problems about installing or upgrading.

And I also checked out the 3.9 alpha version from the subversion repository. The alpha version doesn’t use PHP mysqli library nor PDO library but still use mysql library with the suppressing of E_DEPRECATED error reporting. This means that the next version of WordPress will continue to use the same database access method and you can use SQLite Integration without radical changes.

Admin panel of WordPress3.8 is changed to a new responsive design. It has included the former MP6 plugin developed separately. I don’t know if users want to see their database status with a mobile device or not, but I changed the style sheet to fit for it as much as I could. You can also select one of the eight color schemes on your profile panel. I add some stylesheet to use the same color that you select, though a little reluctantly. 🙂

The new version of the plugin checks if your SQLite library is compiled with the option ‘ENABLE_UPDATE_DELETE_LIMIT’. If it is, the plugin will not rewrite the UPDATE or DELETE with LIMIT query. Seeing the WordPress plugin forum, there’re more and more bloggers come to use PHP 5.4 or 5.5, which means their SQLite library is upgraded and the plugin has more chances to be able to use multiple values clause and UPDATE or DELETE with LIMIT clause. If this is the case, the database manipulation will be a little safer and faster.

I’ve got the comment from Mr/Ms naillik who wants to change the database with the directive in wp-config.php. I included this functionality in the current version of the plugin. If you want to use MySQL, add the next line in your wp-config.php (of course with correct MySQL settings).

This enables you to change the database from SQLite to MySQL. WordPress installation process will run for the first time, so you’ve got to install with MySQL. But notice that the post data or other environments settings are not migrated from one database to another. And most of the patched plugins require SQLite Integration. If you want to use SQLite again, change "true" to "false" or just delete that line. Try if you like, though I give no warranty at all as usual.

I added a few lines for some of the files to check if they are called from WordPress or not. In fact, even if they are called outside your site, they can do nothing to harm your site. But crackers are accessing the vulnerable (nonexistent) plugins’ directory, targeting the vulnerable (nonexistent) php files. This site is not an exception and has illegal GET or POST access every day. It’s really annoying like a Pascal’s fly. This is only to "shew the fly the way out of the fly-bottle"(L. Wittgenstein).

I’d like to express my thanks for Mr. Alex Almeda, who has given me some hints about the plugin.

When you notice malfunctioning or bug, I’ll appreciate receiving your reports or suggestions by the comment in this site or posting to the support forum. Thank you.

SQLite Integration 1.4.2 updated

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

SQLite Integration was updated to the version 1.4.2.

  1. Tested WordPress 3.7.1 installation.
  2. Fixed the bugs of the function for displaying the server information and some minor bugs.
  3. Changed the screenshot.

When you notice malfunctioning or bug, I’ll be glad to hear from you via the comment on this site or the post to the support forum. Thank you.

SQLite Integration 1.4.1 updated

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

SQLite Integration was updated to the version 1.4.1.

  1. Rewrote the manipulation of BETWEEN funciton support introduced since version 1.3.
  2. Fixed the style corruption when using MP6 plugin.
  3. SELECT version() query returns a dummy data.

I added the support for BETWEEN function for NewStatPress plugin. The function rewrites the post content when it contains ‘between A and B’ phrase, and the post data disappears, which I think is critical and needs upgrading. This bug was informed in the support forum. I appreciate zoomosis’ report.

New procedure will split the SQL statement into tokens, count the single quote and check if the BETWEEN is in the post content or a part of SQL statement. This will make the system a little slower, but I prefer the safety to the speed.

Other minor bug fixes are included.

SQLite Integration 1.4 released

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

SQLite Integration was updated to the version 1.4.

  1. Added the database utility to fix the database caused by upgrading WordPress 3.5.x to 3.6.
  2. Fixed the bugs of ALTER TABLE query.
  3. Changed the manipulation of SHOW INDEX with WHERE clause.

When you insatalled WordPress 3.5.x with this plugin and updated to WordPress 3.6, upgrading was not well finished and there’re some columns that lost default values property. Ordinary usage of the database shows no mulfunction or error messages, but some plugins depending the default value of the column will cause the problem. The bug report of the support forum gave me a clue about this problem.

You’ve got to access your database to fix this problem, but it’s a little difficult to do the job. SQLiteManager distributed as a utility for manipulating SQLite databases can’t change the property of the column. It doesn’t behave as you expected and seems to be a bug, I guess. SQLite Manager, a Firefox Addon, doesn’t seem to do this job. So I added the new page on the admin dashboard and let the users do the fixing database job by clicking the buttons. If above is your case, please be sure to visit the dashboard and do this job.

If you are using WordPress 3.5.x or install a new WordPress 3.6, you don’t have to do this job.

I changed some codes for other plugins to work fine.

Just after I committed the version 1.4, WordPress is upgrade to 3.6.1 (!). I did try upgrading it without problem. This table shows the conbinations of S(QLite) I(ntegration) with W(ord)P(ress) and if the above fix is necessary or not. Version 1.3 means 1.3 or lesser.

SI WP Current => WP Updated Fixing job
1.3 3.5.x => 3.6 Need updating to 1.4 and fixing
1.3 3.5.x => 3.6.1 Need updating to 1.4 and fixing
1.3 3.6 => 3.6.1 Not necessary; upgrading to 1.4 is recommended
1.4 3.5.x => 3.6 Not necessary
1.4 3.5.x => 3.6.1 Not necessary
1.4 3.6 => 3.6.1 Not necessary

Further more, if you are using MP6 plugin, selected dashboard menu is displayed indented. I’ll fix it at next release. If you fix it right away, please download a development version from and replace three files below.

  • styles/doc.css
  • styles/style.css
  • utilities/documentation.php

When you notice mulfunctioning or bug, I’ll be glad to receive your report by the comment in this site or posting to the support forum. Thank you.

SQLite Integration 1.3 released

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

SQLite Integration was updated to the version 1.3.

  1. Added the database backup utility.
  2. Changed the dashboard style to match MP6 plugin.
  3. Fixed the alter table query manipulation.
  4. Added the support for BETWEEN function of MySQL.
  5. Modified the definition of _rewrite_field_types() in query_create.class.php.
  6. Changed the error message manipulation.
  7. Changed the regular expression to remove all the index hints from the query string.

SQLite is really a file in the disk file system. So you can only backup your database by creating a copy of that file; you don’t have to export or import data like a database server system. The backup utility creates the current snapshot of your database file as the zipped archive if your PHP has zip extension or as the plain copy if it doesn’t. The snapshot is put in the same directory that your database file is in.

The experimental WordPress UI is developed with a plugin called MP6(*1). I changed the styles of SQLite Integration to fit that design. If you don’t like it, removing sqlite-integration/styles/ directory will make your dashboard look like WordPress default style.

  1. This page reads: "This plugin is a secret; don’t tell anybody about it.". This seems to be a joke. Ms. Takano Naoko from Automattic Inc. wrote an introduction article about this plugin, see New dashboard design developed by WordPress UI team: What’s it like, "MP6" plugin?(in Japanese).

ALTER TABLE CHANGE COLUMN query didn’t work properly so that the WordPress function dbDelta() didn’t work as you intended when upgrading the database. This is fixed.

BETWEEN function is added and _rewrite_field_types() function is changed for NewStatPress plugin to work, though this plugin needs rewriting a little. See also Plugins for a patch file.

When installing, we couldn’t use the language catalog until the function __() is loaded. So if you have a problem while installing, the very install process will stop. I changed it so that the error messages are only put out in English.

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.

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 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.

1 / 212