実際に、RapidModuleUpdateがどんなものかは動画を見てみるのが早いでしょう

RapidModuleUpdateはプリロードなので、そのファイルをひとつサーバーに置いておけば、すぐさま「モジュール一括アップデート」が行えるようになり難しい知識は一切いらないのも特徴です。

プリロードだけで、管理画面でJavaScriptを動かす裏技も詰まってるので、興味のある開発者はソースコードを見てみてください(笑)

2月18日、東京在住の男性(23)自称プログラマが、自分が管理者であるはずのサイトにおいてprotectorモジュールに締め出されたことに腹を立てて、protectorの締め出しを解除するプリロードを作っていたことが当局の調査で明らかになった。なお同氏は「ついカッとなって作った。今は反省している。」と話している。protector設定によって、管理者さえも排除の対象になる点については以前からXOOPSユーザの間でたびたび問題視されてきた。protectorの機能を一時無効化するプリロードを作った例はこの件が初めてだと言う。

このプリロードについて

使うタイミング

• 自分はアクセスできないのに、他の人がアクセスできる。
• 何度かアクセスしているうちに、画面が真っ白になった。
• protectorに怒られたと思ったら、次から画面が真っ白になった。

使い方

1. FxckinBan.class.phpをFTPなどでpreloadフォルダにアップロードする
2. 締め出しを食らったサイトにアクセスする
3. 再び締め出される前に、protectorモジュールの設定を変更する
4. FTPなどでFxckinBan.class.phpを削除する

注意事項

• 一時的にprotectorの機能を無効化するので、使い終わったら直ちにFxckinBan.class.phpを削除してください。

下のプリロードはGoogleAnalytics.class.phpというファイル名で保存します。トラッキングコードを所定の場所にコピペするだけです。Google Analytics以外に、HTMLのヘッダに貼りつけたいコードがある時にも、応用できると思います。

<?php

class GoogleAnalytics extends XCube_ActionFilter
{
	public function preBlockFilter()
	{
		$this->mRoot->mDelegateManager->add('XoopsTpl.New', array(&$this, 'hook'));
	}

	public function hook(&$xoopsTpl)
	{
		$trackingCode = <<< DOC_END
//トラッキングコードをここに貼付け。
DOC_END;

		$xoopsModuleHeader = $xoopsTpl->get_template_vars('xoops_module_header');
		$xoopsTpl->assign('xoops_module_header', $xoopsModuleHeader.$trackingCode);
	}
}

?>

WhiteoutRescueプリロードは、ホワイトデイに「真っ白」画面を出さないためのプリロードです。ホワイトデイに真っ白画面に出くわしたサイトオーナーがこのプリロードをアップロードします。そして、真っ白画面のページにアクセスすると、黒背景を基調としたデバッグページが現れます。サイトオーナーはそのデバッグ情報をたよりに真っ白画面を解消します。このように、真っ白画面を直すことで、厄払いの意味になり、その年のXOOPS運が大安になると言われています。

動作要件

• XOOPS Cube Legacy 2.x
• PHP 5.1 (5.2からかも)
• UTF-8環境(EUC-JPでも動くことは動く)

WhiteoutRescueプリロードの使い方

XOOPSオーナーに伝わるWhiteoutRescueプリロードの使い方は以下のようです。

1. WhiteoutRescue.class.phpを/preloadにアップロードする
2. 真っ白のページにアクセスする
3. 表示されたデバッグ情報をもとに問題を解決する
4. 使い終わったら、WhiteoutRescue.class.phpを削除する

なお、使い終わってもWhiteoutRescueプリロードを削除しないでいると、XOOPSのセキュリティやパフォーマンスが低下し、XOOPSが白い悪魔に取り憑かれるそうなので、必ず削除するようにしましょう。

WhiteoutRescueを使っても真っ白のままの場合、以下のことが考えられます。

• プリロード読み込み以前にXOOPSがこけてる
• PHPのパースエラー（セミコロンがダブルコロンだ、など）この場合はPHPのエラーログを参照
• サーバーの問題 (.htaccessの設定ミスなど)
• そもそもXOOPS Cube Legacyじゃない
• しかるべくして真っ白なページ

ライセンス

GNU GPL2ライセンスです。動作無保証です。あなたは、GPL2の条件をみたせばこのプログラムを改変・頒布することができます。

リポジトリ

[訂正 2010/03/12]

XOOPSオーナーの間で、3月14日が厄日などの記述がありましたが、実際にはそんな習慣はないそうです。教えてくれたwhite_devilさんありがとうございます。

I will introduce you how to develop preloads with Subversion. If you put your preloads under /preload directory, it is difficult to manage the versions of its. Because, Subversion treats not only your preload but also the other ones. In such a case, you can make subdirectories under /preload. This way helps you to increase your manageability.

配布することを考えれば、サブディレクトリにLicense.txtやReadme.txtを置くといいでしょう。そうしておくと、svn -exportでプリロードの配布パッケージが簡単に生成できます。

If you plan to distribute your preload, you may put License.txt or Readme.txt under the subdirectory. It is a smart way. You only have to command "svn -export" at the subdirectory when you distribute it.

ディレクトリの構成方法

/XOOPS_ROOT_PATH
	/preload
		/VersionedPreload.class.php (a)
		/VersionedPreload
			/.svn
			/VersionedPrelaod.class.php (b)
			/License.txt
			/Readme.txt

VersionedPreload.class.php (a)のソース

<?php

$file = basename(__FILE__);
$dir  = str_replace('.class.php', '', $file);

require $dir.'/'.$file;

?>

(a)はただ、requireするだけです。（プロキシと言ったラインだろうか。）このサンプルソースはどんなプリロードにもそのまま流用できます。なぜなら、ファイル名を動的に取得しているからです。/preloadディレクトリに(a)をひとつ作っておけば、新しくプリロードを作る度に、コピーして名前を変更するだけでいいので便利です。

The (a) only includes your preload. You can apply this sample to your any other preloads. Because, this sample get the file name dynamically. If you create the (a) once, you only have to copy and rename it, when you create a new preload. It is useful.

VersionedPreload.class.php (b)のソース

<?php
/**
 *
 * @package    Versioned Preload
 * @author     Foo Bar <http://example.com/>
 * @copyright  2010 Foo Bar
 * @license    http://www.gnu.org/licenses/gpl-2.0.html GNU GPL v2 or later
 *
 */

if ( !defined('XOOPS_ROOT_PATH') ) exit;

class VersionedPreload extends XCube_ActionFilter
{
	public function preBlockFilter()
	{
		$this->mRoot->mDelegateManager->add('Delegate.Name', array(__CLASS__, 'doSomething'));
	}

	public static funciton doSomething(&$param)
	{
		// Do something here.
	}
}
?>

(b)では、プリロードを作るときの普段どおりの書き方をするだけです。とくに変わったことをする必要もありません。

• この情報は古いです。新しい情報を御覧下さい。

パスワードは定期的に変更するほうがより安全と言われています。PasswordLimitterは、XOOPSのユーザのパスワードに期限を設け、期限がすぎたユーザに対しては、ログイン時にパスワード変更を促すメッセージを表示します。

インストール方法

1. PasswordLimitter.class.phpを/preloadにアップロード
2. 管理アカウントで、http://あなたのXOOPS/misc.php?password_limitter=adminにアクセス
3. 「INSTALL」をクリックしてインストールを実行
4. その後、設定ページで期限日数を設定する

アンインストール方法

1. 管理アカウントで、http://あなたのXOOPS/misc.php?password_limitter=adminにアクセス
2. 「UNINSTALL」をクリックしてインストールを実行
3. PasswordLimitter.class.phpを/preloadから削除

開発情報

• リポジトリ