その後原因を調査したところ、驚愕の事実が判明。

wandboardにimport後にwandboardでもwebadmで投稿の編集が出来なくなる症状が出たdatabase dumpファイルを精査したところ、webadmユーザーのxoops_wp_usersテーブルエントリに削除マークがセットされていることが判明。

wordpressモジュールを利用できるユーザーは、予めxoopsにユーザー登録したユーザーが自動的に反映される仕組みだけど、ユーザーを削除してもxoops_wp_usersテーブルの当該エントリはX_DELETED_Xマークがセットされた状態になる。

このX_DELETED_XマークがセットされたWebmasterグループのユーザーがwordpressでなにか記事を変更しようとすると問題のページが表示されるということらしい。

xoops_usersテーブルからは、webadmユーザーは削除されていないためログインは出来るものの、wordpress上では削除されたユーザー扱いのために想定しない挙動が出たと思われる。

その後いろいろユーザーアカウントの編集操作を行った時点でxoops_wp_usersのwebadmエントリからはX_DELETED_Xマークは消失したので、以降は問題が解消したことに。

ちなみにuser_levelを10にすると、wordpressの管理画面では-10と表示される。webadmはWebmasterグループなので、その値は無視されて自動的に10に昇格するので関係なかった。

要するに、何者かが（自分か？）xoops_wp_usersテーブルのwebadmエントリにX_DELETED_Xマークをセットしたのが原因と思われる。

部外者が外部からそうした操作が可能なのかもしれない、やはりSQL injectionか、はたまた自分がぼけて操作ミスしたのか？

SQL injectionというハッキングの常套手段は、サーバー上のプログラムで、最終的にSQL inqueryの中に挿入されるような文字列にあたかも別の任意のSQL inqueryを挿入して実行させるもの。

昔はそんなことをする悪意を持った人間が現れることを想定していなかったので、どんどんやりまくられていたんだけどね。

その後は用心して外部から与えられた文字列は精査して悪意のあるSQL inqueryが含まれていないかチェックしたり、あった場合には拒否するか取り除くなどの面倒な処理を施すことが必須になった。

もしかして誰かにやられたのかも。

古いxoopsやwordpressは、SQL injectionが猛威を振るう前の時代に書かれたものなので、実装は単純明快なため穴だらけということに。

やれやれ（´Д｀；）