Yearly Archives: 2014

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.

Explanations

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.

to

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.

Acknowledgement

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.7 リリース

English version is available in SQLite Integration 1.7 release

変更点

SQLite Integration 1.7 をリリースしました。変更点は次のとおりです。

  1. WordPress 4.0 での変更に対応しました。
  2. メモリ使用率をチェックできるようにしました。
  3. pcre.backtrack_limit が大きな値に設定されている場合、上限まで処理を続けるようにしました。
  4. テーブル作成クエリのバグを修正しました。
  5. メタクエリの BETWEEN の扱いを変更しました。
  6. ビジュアル・エディタで添付ファイルの並べ替えがうまくできなかかったのを修正しました。

変更点について

WordPress 4.0 では、大きな変更はありませんが、関数の移動や、wpdb クラスの内部変更がありました。これに合わせるための変更が SQLite Integration にも入りました。古いバージョンのまま WordPress 4.0 を使うと、LIKE クエリが正常に動作しないかもしれません。アップグレードすることをお勧めします。その他の変更は、下のとおりです。

destructor が呼ばれたときに、メモリ使用率が 90% を越えている場合、ファイルに書きだすオプションをつけました。通常は必要ないと思いますが、support forum にて、アロケートされたメモリを使い切るという現象が報告されていたので、テストするために加えたコードですが、エラーを再現できなかったので、どこかで同じような現象が起こったときに使うつもりでそのままにしてあります。通常の利用には何の効果もありません。

pcre.backtrack_limit を大きな値に設定している場合、そちらを優先するようにしました。現状では、PHP のデフォルトで不足の場合、100 倍まで引き上げて処理をしますが、莫大な値を設定している例がフォーラムに上がったので、それに対応するようにしました。

メタクエリの compare に BETWEEN を設定したときの動作を少し変更しました。若干スピードアップしたはずですが、safe mode の壁を乗り越えられるかどうかはわかりません。これもフォーラムでの議論がもとになっています。

ビジュアル・エディタで添付ファイルを並べ替えたとき、それが保存されないバグを修正しました。こちらは、日本語フォーラムでの報告で判明しました。

上の修正を入れたときに、PHP 5.2.x では使えないコードが紛れ込みました。該当のバージョンをお使いの場合は、query.class.php の該当部分をを修正してお使いください。

ここを下のように修正します。

メンテナのテスト環境は PHP 5.5 なので、5.2.x のテストができません。できれば、PHP のバージョンは、5.3 以上をお使いいただくのがお勧めです。

インストール・アップグレードの注意

WordPress 4.0 から、インストール・プロセスが若干変更になりました。ルート・ディレクトリに wp-config-sample.php だけで、wp-config.php が存在しない場合、wp-config.php の作成に失敗します。このバージョンでは、wp-config.php をあらかじめ準備することが必須ということになります

新規インストールでは、最初でデフォルトの言語を選択するようになり、言語カタログはそれに合わせてダウンロードするようになりました。また、ここで選択した言語が WPLANG 定数の値として、データベースに保存されます。これにともなって、wp-config-sample.php には、

の行がなくなっています。言語の設定をかえたい場合は、インスール後に、管理画面で「設定 » 一般」のページで「サイトの言語」を変更する仕様になっています。アップグレードの場合は、次の条件で WPLANG が設定されます。

マルチサイトではなく、かつ、データベースに WPLANG の値が保存されていない、さらに、wp-config.php の WPLANG に値が設定されいて、かつ、/wp-content/languages ディレクトリに該当の言語ファイルが存在する、という条件を満たした場合にのみ、その値がデータベースに保存されます。そうでない場合は、データベースの WPLANG のエントリは空になります。

これらの条件と、get_locale() 関数の仕様変更のため、アップグレードのときに動作が変わる場合は、新規インストールと同じ対応をしてください。

wp-config.php でブラウザの言語設定に合わせて動的に変更している場合は、たとえば、

のように、$locale を設定すると、これまでどおり表示する言語をかえることができます。定数 WPLANG の設定だけでは十分ではありません。

これらについて、SQLite Integration が何かをすることはありません。WordPress の仕様どおりに振る舞うはずです。アップグレードで挙動が変わる可能性があるのはこれだけだと思います。

謝辞

今回も、フォーラムやメールでのフィードバックが役立ちました。ご報告いただいた方たちに感謝します。ありがとうございました。

不具合やバグを発見したら、このサイトでコメントしていただいても、サポートフォーラムに投稿していただいてもかまいません。提案や感想も歓迎です。なお、日本語での投稿すると、モデレータからチェックが入るかもしれません。英語以外の投稿に対するモデレータの基準がよくわかりません(放置している場合もたくさんあります)が、気になるようだったら、日本語フォーラムをご利用ください。ありがとうございました。

Debian wheezy で Clang をビルドする

English version is not available.

はじめての Clang

Stephen Prata という方の書いた、C、C++ の入門書、『C Primer Plus 6th Edition』(2014年) と『C++ Primer Plus 6th Edition』(2012年) を読み始めたら、たいへんによくできた入門書だと感心すると同時に、C も C++ も、まったく時代についていけてないことを思い知らされました。新しい規格については、へぇ、こんなことができるのかぁ、と思うようなものもあり、リハビリテーションをかねて、ちゃんと読んでみることにしました。実は、プログラミング言語の入門書の中では、『プログラミング言語 C』(K&R)のぶっきらぼうな reticence が今でも大好きで、手放せずにいるのですが、これこそ時代遅れの典型なのでしょうね。

PC UNIX では、プログラミングをしなくても、コンパイラのお世話になることが多いので、使ったことがないという人は稀だと思いますが、Linux 標準の C、C++ コンパイラは、もちろん GCC です。それで不足に思うことはないし、それどころか、ほぼどんな環境でもソースがコンパイルできるという現実を作っているのは GCC と GNU のユーティティのおかげにほかなりません。今回は新しい規格の勉強ということで、コンパイラも新しいものを使おうと思って、Clang を試すことにしました。聞くところによると、C11 や C++11 だけでなく、C++14 のドラフトまでフルサポートしているそうです(業界では常識なのでしょうか)。ところが、これがそう簡単にはいきませんでした。以下はその顛末です。Stephen Prata さんの二冊については、また別の機会に書こうと思います。

Debian wheezyでコンパイル

メモリ256MBの壁

公式ページclang: a C language family frontend for LLVMの Get Started を参考に、Subversionリポジトリをチェックアウトして、ソースツリーを用意し、

$ gcc --version
gcc (Debian 4.7.2-5) 4.7.2

$ ../llvm/configure --prefix=/home/charlus/opt/ --enable-optimized --enable-assertions=no --enable-targets=host

$ make

として、コンパイルを始めたら、メモリもスワップもほぼ使い切った状態が丸二日間続き、しかも最後は、ほとんどのユーザアプリケーションが落ちるという始末です。mysqld のログを見ると、メモリアロケーションができず、真っ先に落ちています。カーネルだけがかろうじて生きているという状態でした。さらに、まだ unittest が終わっていません。メモリ 256MB で迂闊にコンパイルしてはいけないようです。configure オプションには unittest を省略するオプションがないようなので、どうにもなりません。

システム再起動後、もう一度途中からやり直して、ようやくコンパイルが終わりました。

Clang はすでに セルフホストできるようになっているということなので、これも試しました。Clang がインストールされている環境では、configure を走らせると、自動的に Clang を使うようになっています。ところが、make の途中、Illegal instruction で落ちます。

謎の Illegal instruction を追う

調べてみると、いろいろなコードで Illegal instruction が頻発します。条件を絞り込んで、下のコードだけで再現できるところまでは突き止めました。C の方は、float や long double では発生しませんが、printf() を呼ぶと、float、double ともに Illegal instruction となります。C++ では、float や long double にすると Illegal instruction にはならないことがわかりました。また、std::cout を使っても、使わなくても結果は同じでした。

整数ではなにも起こりませんから、明らかに浮動小数点数の扱いが原因です。

これだけ明らかな現象なのに、どうやら、あまり困っている人がいないようです。調べてもそれらしい報告があまり見当たりません。しかも、Illegal instruction で調べると、古い情報ばかりヒットします。最適化オプションをつけたときに Illegal instruction になるという例が多くありましたが、上の例では、

$ clang -O3 test.c
$ clang++ -O3 test.cpp

と、最適化オプションをつけるとちゃんと実行できるファイルができます。この問題について触れていると思われる投稿記事を手がかりに整理してみました。

Google で "clang illegal instruction" をキーワードに検索すると、Machine Cycle というブログのIllegal Instruction in Code Compiled with Clangという投稿が似たような症状を報告しています。valgrind と objdump でチェックして、pxor 命令が犯人だとつきとめていて、たいへん役立ちました。使っている CPU は、32bit Mobile AMD Athlon XP で、64bit CPU でコンパイルすると、問題なく動作するということです。調べてみると、Mobile Athlon XP は、MMX、SSE、3DNOW! をサポートしているようです。作者によると、-mno-sse オプションでちゃんと動作したとのことです。後で述べるように、この PXOR という命令は SSE というよりも、MMX で導入された命令のようですが、MMX をサポートする Mobile Athlon XP でこれがエラーになる理由はわかりません。

私の Debian マシンは、Pentium III ですから、MMX、SSE はサポートしていますが、SSE2 ~ SSE4 はサポート外です。cpuinfo の結果は下の通り、sse のフラグはありますが、調べるまでもなく、32bit プロセッサです。

$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Pentium III (Coppermine)
stepping        : 6
microcode       : 0x8
cpu MHz         : 996.591
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pse36 mmx fxsr sse up
bogomips        : 1993.18
clflush size    : 32
cache_alignment : 32
address sizes   : 36 bits physical, 32 bits virtual
power management:

Machine Cycle と同じテストをしてみると、次のような結果でした。

$ clang --version
clang version 3.5.0 (trunk 207087)
Target: i386-pc-linux-gnu
Thread model: posix

$ clang -g test.c

$ valgrind --tool=memcheck ./a.out
...省略...
vex x86->IR: unhandled instruction bytes: 0xF3 0xF 0x5A 0x45
==6590== valgrind: Unrecognised instruction at address 0x8048441.
==6590==    at 0x8048441: main (test.c:4)
...省略...

$ objdump -d -S a.out | grep 8048441
 8048441:       f3 0f 5a 45 f8          cvtss2sd -0x8(%ebp),%xmm0

同様に、C++ でも実験すると、下のようになります。

$ clang++ -g test.cpp

$valgrind --tool=memcheck ./a.out
...省略..
vex x86->IR: unhandled instruction bytes: 0xF2 0xF 0x2A 0xC1
==7416== valgrind: Unrecognised instruction at address 0x80484a0.
==7416==    at 0x80484a0: main (test.cpp:2)
...省略...

$ objdump -d -S a.out | grep 80486d1
 80484a0:       f2 0f 2a c1          cvtsi2sd %ecx,%xmm0

インテルが公開している、Intel® 64 and IA-32 Architectures Software Developer Manualsの 11章、12章、13章がそれぞれ SSE、SSE2、SSE3 の説明にあてられているので、これを参照すると、PXOR は、MMX の命令として、CVTSS2SD と CVTSI2SD の二つは SSE2 の命令として説明が出てきます。アセンブリは詳しくないので、間違いないかどうかはわかりませんが、MMX は 64 ビットのレジスタに、8 ビットの整数を 8 つ、16 ビットの整数を 4 つ、32 ビットの整数を 2 つ、それぞれパックしたデータとして格納し、平行して演算が実行できるようにしたものだそうです。SSE はそれの浮動小数点数版ということで、こちらは 128 ビットのレジスタになっていて、単精度浮動小数点数を平行して計算できるそうです。32 ビットだとすると、4 つをパックしてあるということになります。XMM0 ~ XMM7 がここで使われるレジスタです。

CVTSS2SD は単精度浮動小数点数を倍精度に変換する命令、CVTSI2SD は 32 ビットの整数を倍精度浮動小数点数変換する命令で、SSE では単精度しか扱えないのに対して、SSE2 では倍精度が扱えるようになっています。SSE2 は、Pentium 4 以上でないとサポートされません。

GCC を使っても同じ instruction を生成できるかどうか確認してみました。SSE2 コードを出力するには、-mfpmath=sse と -msse2(-msse3…) をコマンドラインオプションに指定すればいいようです(3.17.17 Intel 386 and AMD x86-64 Optionsを見ると、x86-64 ではこれがデフォルト)。まずは、C ファイル。

$ gcc -g -mfpmath=see -msse2 test.c
...
$ objdump -d -S a.out | grep 8048434
 8048434:       0f 5a c0                cvtps2pd %xmm0,%xmm0

次に C++。

$ g++ -g -mfpmath=sse -msse2 test.cpp
...
$ objdump -d -S a.out | grep 8048495
 8048495:       f2 0f 10 05 40 85 04    movsd  0x8048540,%xmm0

どちらも Illegal instruction を再現できますが、Opcode が違います。CVTPS2PD も MOVSD も、インテルのマニュアルでは、上と同じく SSE2 で扱える命令として扱われています。

これで、Debian のバグリポート、clang: defines SSE macros with -m32 on amd64(2011年7月なので、ちょっと古いですが) で言われていることが理解できます。i386 Pentium の GCC はデフォルトのマクロ定義で、__SSE__ や __SSE2__ が外されているけれども、Clang では、デフォルトでマクロが定義されていて、たぶんこれを外す configure オプションがないということでしょう。

$ gcc -m32 -E -dM - < /dev/null | grep SSE

$ clang -m32 -E -dM - < /dev/null | grep SSE
#define __SSE2__MATH__ 1
#define __SSE2__ 1
#define __SSE_MATH__ 1
#define __SSE__ 1

たぶんこれは Debian 固有の問題ではないので、Clang パッケージのメンテナがパッチを作ってパッケージングし直しているかもしれません。これがバグと認定されるか、あるいは、少なくとも Debian では修正が必要と認定されればのことですが(*1)。 さて、原因はわかりましたが、Clang の configure では、

$ uname -a
Linux debian 3.2.0-4-686-pae #1 SMP Debian 3.2.54-2 i686 GNU/Linux

$ ../llvm/configure --enable-targets=host

としてもお構いなしに、デフォルトで SSE2 命令を吐き出すのが仕様ということのようです。もう少し調べると、cfe-dev メーリング・リストのログに、[cfe-dev] Preventing clang from generating SSE2 symbols(2012年3月)で始まるスレッドを見つけました。最後は、

CFLAGS に -march=i586 をつければいいじゃね?

で終わっています。もう Pentium みたいな古い CPU はサポートしない、ということですかね。諦めて -march=i(3|4|5|6)86 や -march=pentiumpro みたいなオプションをつけて実行するか、オプションつきのエイリアスを作るしかなさそうです(*2)。i686 には、SSE2 をサポートする Pentium 4 や Celeron も含まれていますが、実際に -march=i686 オプションをつけると、SSE2 命令は吐かず、Illegal instruction で止まることもなくなります。

  1. Debian の Clang パッケージを使ってみたくなりますが、バージョンが古いのでいまいち手が伸びません。
  2. -mcpu=cpu_type オプションは存在しません。

セルフホストしてみる

CFLAGS を設定しろ、というアドバイスをもとに、もう一度セルフホストしてみました。configure を実行すると、ルートにできる Makefile.config を下のように書き換えて、make しました。もちろん、これで SSE2 命令を使わない Clang ができるわけではありませんが、少なくとも、コンパイルは通るはずです。

$ ../llvm/configure --prefix=/home/charlus/opt/ --enable-optimized --enable-assertions=no --enable-targets=host
$ make

今度は落ちずに、確かに最後までコンパイルができました。コンパイルの速度が速く、半日(12時間くらいか?)で終わります。カーネルのコンパイルと同じくらいでしょうか。何より、メモリの使用量が少ないのが驚きです。モニタしていたわけではないのではっきりしませんが、256MB でも余裕でしたし、スワップもほとんど使っていないと思われます。FreeBSD が Clang に移行したというのも、ライセンスの問題だけではないような気がしてきます。ちなみに、Linux のカーネルは、まだビルドできないようです。

libc++を作る

C++14 ドラフトを100%実装したという、libc++ ライブラリを作ってみました。公式ウェブサイトでは、サポートプラットフォームが、Mac OSX i386 と Mac OSX x86_64 としか書いてありませんが、Linux でもビルドできます。基本的には、公式のサイトに書いてある通りですが、わが家のマシン特殊事情ということで、CFLAGS と CXXFLAGS を追加してあります。

$ CC=clang CXX=clang++ CFLAGS="-march=i686" CXXFLAGS="-march=i686" cmake -G "Unix Makefiles" -DLIBCXX_CXX_ABI=libstdc++ -DLIBCXX_LIBSUPCXX_INCLUDE_PATHS="/usr/include/c++/4.7.2/;/usr/include/c++/4.7.2/i486-linux-gnu/" -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local ../libcxx
$ sudo make install

問題なくインストールされました。試してみると...

$ cat hello.cpp
#include <iostream>
int main() {
  std::cout << "Hello, libc++!" << std::endl;
  return 0;
}
$ clang++ -stdlib=libc++ hello.cpp
hello.cpp:1:10: fatal error: 'iostream' file not found
#include <iostream>
         ^
1 error generated.

あらあら、インクルードファイルが見つけられません。clang++ のサーチパスを確認すると、ちゃんと /usr/local/include があります。

$ echo | clang++ -Wp,-v -x c++ - -fsyntax-only
clang -cc1 version 3.5.0 based upon LLVM 3.5.0svn default target i386-pc-linux-gnu
ignoring nonexistent directory "/usr/lib/gcc/i486-linux-gnu/4.7/../../../../include/i486-linux-gnu/c++/4.7"
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
  .
  /usr/lib/gcc/i486-linux-gnu/4.7/../../../../include/c++/4.7
  /usr/lib/gcc/i486-linux-gnu/4.7/../../../../include/c++/4.7/i486-linux-gnu
  /usr/lib/gcc/i486-linux-gnu/4.7/../../../../include/c++/4.7/backward
  /usr/local/include
  /home/kjm/opt/bin/../lib/clang/3.5.0/include
  /usr/include/i386-linux-gnu
  /usr/include
  End of search list.

/usr/local/include ディレクトリを見ると、libc++ のヘッダファイルは、/usr/local/include/c++/v1 ディレクトリにインストールされています。この v1 というのは、ソースツリーの include/CMakeLists.txt で定義されていました。まあ、そういうことなのでしょう。

ということで、インクルードパスを指定してやり直しです。

$ clang++ -stdlib=libc++ hello.cpp -I/usr/local/include/c++/v1
$ ./a.out
./a.out: error while loading shared libraries: libc++.so.1: cannot open shared object file: No such file or directory

おっと、こんどは実行するのに、ライブラリが見つかりません。自動的に ldconfig を実行してくれるわけではないのですね。サイトの文書では、インストールパスの prefix が、/usr になっていましたっけ。

$ sudo /sbin/ldcofnig
$ ./a.out
Hello, libc++!

やっと終わりました。

$ ldd a.out
  linux-gate.so.1 =>  (0xb77c3000)
  libc++.so.1 => /usr/local/lib/libc++.so.1 (0xb76fb000)
  libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xb76d5000)
  libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb76b8000)
  libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb7554000)
  libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb7468000)
  libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb744e000)
  librt.so.1 => /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xb7445000)
  /lib/ld-linux.so.2 (0xb77c4000)

C++ABI ライブラリに、libc++abi(Clang)やlibcxxrt(FreeBSD)を使うと、GCC とは非互換となるので、今回は使いませんでした。

使ってみる

node.js をビルドしてみました。

$ curl http:/nodejs.org/dist/v0.10.28/node-v0.10.28.tar.gz -o node-v0.10.28.tar.gz
$ tar zxvf node-v0.10.28.tar.gz
$ cd node-v0.10.28
$ CC=clang CXX=clang++ CFLAGS=-march=i686 CXXFLAGS=-march=i686 ./configure --prefix=/home/charlus/opt
$ make

Illegal instruction で止まります。よく見ると、flags が configure に無視されて、_DARWIN_USE_64_BIT_INODE=1 という妙なオプションがついています。

直接 common.gypi を編集して、cflags と cflags_cc に -march=i686 を設定して、やり直すと、ちゃんと Linux の clang だと思ってくれたようです。コンパイルも無事終了します。

$ make install
$ node
> process.versions
{ http_parser: '1.0',
  node: '0.10.28',
  v8: '3.14.5.9',
  ares: '1.9.0-DEV',
  uv: '0.10.27',
  zlib: '1.2.3',
  modules: '11',
  openssl: '1.0.1g' }
>

SQLite Integration 1.6 リリース

English version is available in SQLite Integration 1.6 released

SQLite Integrationを 1.6 をリリースし、1.6.1 にアップデートしました。

1.6 での変更点は以下の通りです。

  1. WordPress3.9 でのインストールと動作テストをしました。
  2. 一部のクエリでページング情報が正確でなかったのを修正しました。
  3. コメントでバッククォートが削除されるバグを直しました。
  4. データベースのバックアップファイルをダウンロードできるようにしました。
  5. readme.txt のドキュメントを修正しました。
  6. プラグインの互換性リストを増補しました(Alex Armeda氏に感謝します)。
  7. これまで使えないようにしていた wp-db.php の関数を使えるようにしました。
  8. ユーザ定義関数を増やしました。

1.6.1 での変更点は以下のとおりです。

  1. WP Slimstat プラグインを使えるようにしました。
  2. 古い db.php を新しいものと入れ替えていない場合は、ダッシュボードに注意を出すようにしました。
  3. db.php をアップデートするユーティリティを追加しました。
  4. 日本語カタログファイルを更新しました。
  5. その他のバグを修正しました。
  6. readme.txt のタイプミスを修正しました。

主な修正点は、WordPress 3.9 の変更に合わせたものですが、その他のバグ修正をも含みます。

Alex Armeda 氏より、プラグイン互換性のチェックリストを頂きました。これをマージしてあります。Alex と彼のチームに感謝します。その他にも提案をしてもらいましたが、実装してありません。

サポート・フォーラムにて、Duong 氏より、wp-config.php でプラグインの編集を無効にしたいが、wp-content/db.php が編集できてしまう、との指摘がありました。下のように修正しました。Duong 氏からの応答はありませんが。

定数 効果
DISALLOW_FILE_EDIT 指定すると、db.php の編集を無効にします。
DISALLOW_FILE_MODS 指定すると、db.php の編集を無効にします。
WP_PLUGIN_URL 指定したときに、ダッシュボードのスタイルシートとJavaScriptが無効になるのを修正しました。使用する場合は、必ずWP_PLUGIN_DIRとともに指定してください。
WP_PLUGIN_DIR 通常どおりの動作です。

サポート・フォーラムで、steadybright 氏より WP Slimstat を使いたいという要望がありました。テーブルサイズなどのデータベース情報は SQLite では意味がないので、使えませんが、インストール、運用はできるようになっていると思います。このプラグインを使うには、ソースコードの変更が一部必要です。詳しくは、上のサポートフォーラムでのスレッドを参照してください。WP Slimstat の作者(camu)が、修正を入れてくれると言ってくれました。次回のリリースでは、修正しなくても使えるようになる予定です。camu の鷹揚さに感謝します。また、steadybright 氏の提案に感謝します。

不具合やバグを発見したら、このサイトでコメントしていただいても、サポートフォーラムに投稿していただいてもかまいません。提案や感想も歓迎です。なお、日本語での投稿にはチェックが入るようですので、日本語フォーラムをご利用ください。ありがとうございました。

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.