Jeans CMS 製作日記 自分のための次世代CMS製作メモ

現在の仕様では、新しいクラスが呼び出されたときに、init()メソッドが存在すればそれを呼び出す仕組みになっている。クラスによっては、init()メソッドは必要ではないのであるが、その場合は、init()メソッド呼び出しの際の命令でWarningが発生する（@を用いているので、表示されない）。

このようなケースに、空の内容のinit()メソッドを記述しておいたほうが早いのか、何も記述しないほうが早いのか、調べてみた。

<クラスに空の内容のメソッドを持たせるべきか持たせざるべきか のつづき>

スキン変数<%blog%>を作成して、テストしてみた。新たにblog.phpを作成したが、これは将来的にskin.phpに統合する可能性が高い。

<テンプレート機能の動作を確認 のつづき>

スキンパースの、<% %>→<?php ?>変換部分をjit.phpとして独立させ、テンプレートのパースルーチンもここに加えた。

アイテムのパースは、ここでは行えない。というのは、コンパイルされたindex.phpではスキンパース・テンプレートパースはすでに行われているが、アイテムのパースは表示するごとに行う必要があるためである。アイテムのパースに同じルーチン（jit.php）を呼び出すと、スピードの上で効率が良くない。

そこで、アイテムパース時に必要なitemvarの情報は、各アイテムに埋め込むことにして、アイテムパース部分はjit.phpから独立させることにする。例えば、

testitemvar|class::method/testitemvar2|class::method/

などの文字列を記事保存時にアイテム用のテーブルに保存しておき、アイテムをパースする時に、この情報に従ってpreg_replaceする。

…かな？現在のところ、jit.phpは１７０行ほどだから、これをskin.phpに戻してアイテムパースもここから行うほうがいいのかも。

考え中。

<jit.php のつづき>

手元の環境で調べたところ、PHPコードのパース（JITによるコンパイル）には、平均して一行あたり約２．５μ秒かかっている。一方で、一つのクラスをファイルから呼び出すのに、最低５００μ秒が必要。例えば、１００行からなるファイルだと、２．５×１００＋５００＝７５０μ秒。現在までに８つほどクラスを作成したが、コードのパースにかかる時間は、ほぼこの計算値と一致している。

どの機能を別のクラスに分けて、どの機能は分けずに同じＰＨＰファイル内に置くかの決断が難しい。別のクラスに分けることで５００μ秒のロスがあるわけだから、クラスを分ける場合、このロスを解消できるだけの見返りが必要である。あまり細かくファイルを分けてしまうと、かえってスピードが遅くなってしまう。

<別ファイルに分けるべきか、分けざるべきか のつづき>

Jeans CMSで、コア・プラグインを書くときの規約（案）

１）グローバル変数、グローバル関数は利用しない（スーパーグローバルは除く）。

２）include, require, include_once, require_once は使用しない（index.php, config.php, core.php を除く）。

３）echo, print は使用しない（core.php を除く）。HTMLタブを出力するときは『core::echohtml()』を、タブ以外を出力するときは『echo::p()』を利用する。

４）SQLクエリーを作成するときは、『sql::fill()』もしくは、『sql::query()』の、フィリング機能を利用する。

５）『sqlite_query()』などのデータベース関連関数は直接利用せず、代わりに『sql::query()』などを利用する（sqlite.phpは除く）。

６）SQLiteでクエリー用の関数を作成する場合、原則としてMySQLやPostgreSQLなどでも利用できるものを使う。ただし、SQLiteの機能を最大限に利用するようなプラグインを作成する場合はこの限りではない。

７）プラグイン名は『jp_』から始まり、英数字のみ（アンダースコアは含まない）。『jp_プラグイン名_クラス名』という名のクラスを『jp_プラグイン名_クラス名.php』というファイル名で記述し、このphpファイルをプラグイン管理領域におけば、インクルードはコアが自動的に実行してくれる。

<規約 のつづき>

member.phpのログイン部分は完成。こちらの方は、Nucleus SHA encryption edition で経験済みだったので、それほど時間はかからず。特筆する点はそれほど無い（Nucleusとほとんど代わらない）が、一つの特徴は、メンバーログイン用のデータベースは、他のものから独立していること。これはセキュリティーを考えてのことで、仮にどこかでSQLインジェクションがあっても、パスワードやメールアドレスなどが洩れないようになっている。

また、skin.phpを少し改良し、parse_ifメソッドの中で呼び出しメソッド名の解決を行っていたのを、コンパイル時に解決しておくようにした。

次にテンプレート周りを完成させれば、あとはNucleusのスキン変数・テンプレート変数処理部分を次々と移植していくだけ。で、ここ２－３日、テンプレートの仕様を考えている。

<テンプレート のつづき>

スキンのパース部分がほぼ出来上がったので、メモ。

スキンの仕様としては、Nucleusのスキンのアッパーコンパチブルにすることをめざす。すなわち、<%skinvar%>の様な記述で書き上げるやり方をとる。

一方で、<?php … ?>のような、PHP直書きの表記も使えるようにする。したがって、スキンに特別な機能を入れたい場合に、PHPでガリガリ書くことも可能。

もう一つの特徴は…。これはもし完成した場合にJeans CMS の大きな特徴になると思うのだけれど…。スキンをコンパイルして、PHPファイルに変換できるようにしたい。つまり、コンパイルの結果、コアやプラグインの機能を直接呼び出すようなindex.phpが作成される。これをサーバーにおけば、ZAPAさんの改造のように、１００倍とまでは行かないものの、かなりのスピードアップが期待できると思われる。

<skin.php のつづき>

とりあえず、３つの対策を用意。

１）リモートコードインサーション対策
２）XSS対策
３）SQLインジェクション対策

何も考えずにコアの機能を利用することで、これらのセキュリティー対策が行えるようなツールを目指す。理想としては、意識せずにコードを書けば脆弱性はでず、何か特別なことを仕様としたときだけに脆弱性が出てしまうようなものにしたい。規約として、echo 命令はライブラリやプラグインでは使用禁止にするつもり。

<セキュリティー対策 のつづき>

最初の記事でたいそうなことを書いたが、要するに開発するためのメモをするところを準備したというところ。まず、特徴となることをいくつか挙げると

１）言語としては、PHP5を利用。データベースエンジンは、SQLite。
２）ライセンスは、GPL（Nucleus のコードを幾分か移植して使うため）。
３）軽さを追求したツールにする。
４）グローバル変数とグローバル関数は利用しない。代わりに、定数もしくはクラスのスタティックプロパティとクラスのスタティックメソッドを用いる。
５）SQLインジェクション、XSS、リモートコードインサーションなどの脆弱性が出にくくなるような仕組みを、コア側で用意する。
６）スキンはデータベースに保存せず、ファイルとして保存する。
７）Nucleusのテンプレートの概念は使わず、かわりにスキンを多層化する。
８）管理画面もスキンで記述し、自由にカスタマイズできるようにする。

<特徴 のつづき>

自分流のCMSを、ほぼスクラッチの状態から製作することにした。Nucleusに似たものになると思うけれど、Nucleusの良いと思うところは残し、そうではないところに改良を加えたものにしてみたいと思う。

このツールの名前であるが、Nucleusの考え方を受け継ぐようなものにした。お手本にするツールであるNucleusは、『核』という意味であるが、文字通りブログツールやCMSとしての核の部分だけを提供し、その他の多くの機能をプラグインで補おうという考え方である。ここで開発するツールは、核（細胞核）をさらに分解し、遺伝子のレベルまで細かくして扱っていこうという考え方を取りたい。コアに含まれる複数のクラスを遺伝子としてとらえるので、Genes。同じ発音でつづりを変えて、Jeansと命名した。