AdelieDebugって何？

AdelieDebug(アデリーデバッグ)は、XOOPS Cube Legacy や TOKYOPen でモジュール・プリロードなどを開発するデベロッパー向けのパワフルな開発支援ツールです。どのあたりが、パワフルかいくつか特徴を紹介しましょう。

特徴1: 見やすいデバッグ画面

XOOPS Cube標準のデバッグモードでは、PHP・MySQL・Smartyなど各モードを切り替えなければなりません。一方、AdelieDebugではPHP・MySQLをひとつの画面に出すことができます。PHPについては、エラーがあれば赤でハイライトされて表示されるので、標準のものと違い見落とす危険性が少ないです。MySQLについては、クエリーログを表示します。もちろんエラーが起こっているクエリーはハイライト表示がされます。加えて、var_dump()で確認することが多い、$_GET, $_POST, $COOKIE, $_FILES, $_SESSION, $_SERVER, 送信されたHTTPヘッダなどの環境変数も自動で表示してくれます。

PHPやSQLのログはひとつのタイムラインにまとめて表示してくれます。これにより、処理の時系列や前後関係が把握しやすくなっています。例えば、あるクエリーがどこで発行されているか知りたい場合があります。従来であれば、var_dump(__FILE__, __LINE__); を随所に仕込んだうえで、出力されたファイル名と行数をなんとなく頭の中にいれて判断するといった具合でした。AdelieDebugでは、adump() を任意の箇所に仕込めば、タイムライン上でadump()とクエリーの関係を一目で知ることが可能です。

特徴2: 便利なデバッグ関数

AdelieDebugは便利なデバッグ関数を提供します。それはvar_dump()よりも強力で、var_dump()+Xdebugよりも導入が簡単です。

adump(): var_dump()関数と同じ働きをしますが、出力内容を<pre>タグで囲むので見やすくなっています。var_dump()は、あちこちに仕込むとどこに仕込んだた分からなくなることがありました。adump()は仕込んだファイル名と行数を表示するので、見失う心配がありません。

adump($uid);

atrace(): その行がどの関数で呼ばれているかを表示します。PHPビルトイン関数のdebug_print_backtrace()と同等の働きをしますが、debug_print_backtrace()のようにメモリオーバーになる心配はありません。

atrace();

awhich(): オブジェクトやクラス、関数がどのファイルの何行目で定義されているかを表示します。awhich()を使えば、わざわざファイル全体をgrep検索する必要はありません。

awhich('Legacy_Controller');
awhich($mRoot);

asynop(): クラスやインターフェイスの概要(synopsys)を表示します。継承した親クラス、実装したインターフェイス、クラスが持っている定数・プロパティ・メソッドが一目でわかるようになります。

asynop('Legacy_Controller');
asynop($this);

特徴3: XOOPS Cube Legacyのためのツールであること

XOOPS Cube Legacy は標準出力をバッファでのみこんでしまいます。なので var_dump() しても何も表示されず、すぐあとに exit() をつけないといけませんでした。さもなければ、<{stdout}>をテーマに書く必要がありました。AdelieDebugは、そのような手間は不要です。XOOPSのob_bufferを自動的に回避するからです。

var_dump() は問答無用で文字列を出力します。なので、XML出力画面にダンプしてしまって、Ajaxのテストがうまくできない、なんてことがありました。AdelieDebugでは、AJAXリクエストのときやHTML出力以外のコンテクストではデバッグ出力を自動でオフにすることで、そういったストレスを軽減します。

特徴4: 実践で使われているツールであること

AdelieDebug は開発現場から生まれた実践的ツールです。XOOPSを用いたシステム開発を数多く手がける株式会社RYUSでは(地道な布教活動により 笑)プログラマに広く活用されています。

導入・使い方

AdelieDebug はプリロードといわれるワンファイルのXOOPS Cube用のプラグインです。ですので、導入は至って簡単。こちらのAdelieDebug.class.phpをダウンロードして、 preload フォルダに放り込むだけです。

不要になった場合は、このプリロードを削除します。

AdelieDebug

• github: https://github.com/suin/xoops-adelie-debug
• ライセンス: たぶんGPL
• 動く環境: PHP 5.2 ~
• 動くプラットフォーム: XOOPS Cube Legacy 2.1 ~, TOKYOPen 1.0 ~

PHP: array_diff - Manualをよく読むと、こんな注意書きが。

注意:

二つの要素は、(string) $elem1 === (string) $elem2 の場合のみ等しいと見直されます。言い換えると、文字列表現が同じ場合となります。

要素が配列だと、string(5) "Array"同士の比較になっちゃうのね(´・ω・｀)

If your language has not be translated yet, I hope you translate it to your language. Copy English, just translate gray parts into your language, and please post it as this blog comment below↓. With the translation, I need to know how your language is written in your language. For example, Japanese is written as '日本語' in Japanese.

How to post

今回文字列化を試す変数

今回文字列化を試す変数は、bool型・int型・float型・string型・添字配列・連想配列を含んだ連想配列です。

$data = array(
	'bool'   => true,
	'int'    => 1,
	'float'  => 1.23,
	'string' => 'foobar',
	'array'  => array('apple', 'orange', 'strawberry'),
	'key-value' => array(
		'jp' => 'Japan', 
		'us' => 'USA', 
		'cn' => 'China',
	),
);

1. serialize()

この関数は変数を文字列化できることでよく知られています。変換された文字列は型・大きさ・値を保持するようになっています。

$serial = serialize($data);
var_dump($serial);
// string(285) "a:6:{s:4:"bool";b:1;s:3:"int";i:1;s:5:"float";d:1.229999999999999982236431605997495353221893310546875;s:6:"string";s:6:"foobar";s:5:"array";a:3:{i:0;s:5:"apple";i:1;s:6:"orange";i:2;s:10:"strawberry";}s:9:"key-value";a:3:{s:2:"jp";s:5:"Japan";s:2:"us";s:3:"USA";s:2:"cn";s:5:"China";}}"

シリアライズされた文字列を、再び配列に戻すにはunserialize()関数を使います。元のデータをしっかり復元してくれます。

$serialImported = unserialize($serial);
var_dump($serialImported);
/*
array(6) {
  ["bool"]=>
  bool(true)
  ["int"]=>
  int(1)
  ["float"]=>
  float(1.23)
  ["string"]=>
  string(6) "foobar"
  ["array"]=>
  array(3) {
    [0]=>
    string(5) "apple"
    [1]=>
    string(6) "orange"
    [2]=>
    string(10) "strawberry"
  }
  ["key-value"]=>
  array(3) {
    ["jp"]=>
    string(5) "Japan"
    ["us"]=>
    string(3) "USA"
    ["cn"]=>
    string(5) "China"
  }
}
*/
var_dump($data === $serialImported); // true

2. var_export()

var_export()関数はPHPとして解釈可能な文字列に変換します。第二引数に何も指定しないと、文字列に変換した結果が出力されます。変数に代入するときは第二引数にtrueを指定します。

$php = var_export($data, true);
var_dump($php);
/*
string(267) "array (
  'bool' => true,
  'int' => 1,
  'float' => 1.23,
  'string' => 'foobar',
  'array' => 
  array (
    0 => 'apple',
    1 => 'orange',
    2 => 'strawberry',
  ),
  'key-value' => 
  array (
    'jp' => 'Japan',
    'us' => 'USA',
    'cn' => 'China',
  ),
)"
*/

var_export()関数には、unserialize()関数のようにインポートする直接的に対応する関数はありません。そのかわりに、eval()関数で文字列を評価します。

eval('$phpImported = '.$php.';');

var_dump($phpImported);

/*
array(6) {
  ["bool"]=>
  bool(true)
  ["int"]=>
  int(1)
  ["float"]=>
  float(1.23)
  ["string"]=>
  string(6) "foobar"
  ["array"]=>
  array(3) {
    [0]=>
    string(5) "apple"
    [1]=>
    string(6) "orange"
    [2]=>
    string(10) "strawberry"
  }
  ["key-value"]=>
  array(3) {
    ["jp"]=>
    string(5) "Japan"
    ["us"]=>
    string(3) "USA"
    ["cn"]=>
    string(5) "China"
  }
}
*/

var_dump($data === $phpImported); // true

3. json_encode()

json_encode()関数は、JSON形式の文字列に変換します。この関数はPHP5.2で導入されました。

$json = json_encode($data);
var_dump($json);
// string(143) "{"bool":true,"int":1,"float":1.23,"string":"foobar","array":["apple","orange","strawberry"],"key-value":{"jp":"Japan","us":"USA","cn":"China"}}"

再び配列に戻すときはjson_decode()関数を使います。第二引数を指定しないと、戻り値がオブジェクト型になります。戻り値を配列型として受け取るには、第二引数にtrueを指定する必要があります。

$jsonImported = json_decode($json, true);

var_dump($jsonImported);
/*
array(6) {
  ["bool"]=>
  bool(true)
  ["int"]=>
  int(1)
  ["float"]=>
  float(1.23)
  ["string"]=>
  string(6) "foobar"
  ["array"]=>
  array(3) {
    [0]=>
    string(5) "apple"
    [1]=>
    string(6) "orange"
    [2]=>
    string(10) "strawberry"
  }
  ["key-value"]=>
  array(3) {
    ["jp"]=>
    string(5) "Japan"
    ["us"]=>
    string(3) "USA"
    ["cn"]=>
    string(5) "China"
  }
}
*/

4. http_build_query()

http_build_query()関数は、配列をクエリーストリング形式に変換します。この関数はPHP5から利用できます。

$query = http_build_query($data);
var_dump($query);
// string(170) "bool=1&int=1&float=1.23&string=foobar&array%5B0%5D=apple&array%5B1%5D=orange&array%5B2%5D=strawberry&key-value%5Bjp%5D=Japan&key-value%5Bus%5D=USA&key-value%5Bcn%5D=China"

デコードには、parse_str()関数を使います。第二引数を指定しないとextract()関数のように、配列のキーで変数を定義します。第二引数を変数すると、デコードした結果がその変数に代入されます。parse_str()関数はすべて文字列型に解釈するので注意が必要です。

parse_str($query, $queryImported);

var_dump($queryImported);
/*
array(6) {
  ["bool"]=>
  string(1) "1"
  ["int"]=>
  string(1) "1"
  ["float"]=>
  string(4) "1.23"
  ["string"]=>
  string(6) "foobar"
  ["array"]=>
  array(3) {
    [0]=>
    string(5) "apple"
    [1]=>
    string(6) "orange"
    [2]=>
    string(10) "strawberry"
  }
  ["key-value"]=>
  array(3) {
    ["jp"]=>
    string(5) "Japan"
    ["us"]=>
    string(3) "USA"
    ["cn"]=>
    string(5) "China"
  }
}
*/

var_dump($data === $queryImported); // false

うさできのmikaさんの投稿を読みながら、もう少し手軽にできるようになるといいなーと思って、XOOPS Cubeで簡単にスライドショーを作れるプリロードを作ってみました。急いで作ったので、結構テキトーです。なにか問題があったら教えてください。

ちなみに、どんなスライドショーができるかは、うさできのトップページを見てみてください。

インストール方法

ダウンロードした JquerySlideShow.class.php を/preloadフォルダにアップロードするだけです。

ちなみに、このファイルだけでは動作しません。jquery.jsが必要です。XCL2.2ならデフォルトで入ってます。XCL2.1の人でよく分からない人はJquery.class.phpを/preloadフォルダに入れといてください。

使い方

基本的にテーマのすきなところにタグを埋め込めこんで使います。編集するテーマのファイはたぶん/themes/あなたのテーマ/theme.htmlです。埋め込み方は下の説明を御覧ください。

[基本編] テーマで使う

画像の大きさを指定して、画像のURLを1行ずつ列挙するだけ

<{slideshow width=680 height=80}>
http://example.com/path/to/image1.png
http://example.com/path/to/image2.png
http://example.com/path/to/image3.png
<{/slideshow}>

[発展編] 画像のリンク先を指定する

画像のURLの次に、半角スペースを挟んでリンク先のURLを指定すると、画像にリンクがつきます。

<{slideshow width=680 height=80}>
http://example.com/path/to/image1.png http://example.com/page1.html
http://example.com/path/to/image2.png http://example.com/page2.html
http://example.com/path/to/image3.png http://example.com/page3.html
<{/slideshow}>

[応用編] 画像のURLに<{$xoops_url}>を使う

画像のURLに<{$xoops_url}>を使うと、サイトのURLが変わったときに、URLを書き換える必要がないので便利です

<{slideshow width=680 height=80}>
<{$xoops_url}>/uploads/myalbum/1.png <{$xoops_url}>/modules/pico/index.php?content_id=1
<{$xoops_url}>/uploads/myalbum/2.png <{$xoops_url}>/modules/pico/index.php?content_id=2
<{$xoops_url}>/uploads/myalbum/3.png <{$xoops_url}>/modules/pico/index.php?content_id=3
<{/slideshow}>

[応用編] カスタムブロックで使う

カスタムブロックの「コンテンツ」に次のようなコードを埋め込みます。 カスタムブロックの「タイプ」は「PHPスクリプト」を指定します。

$params = array(
  'width' => 680, // 幅指定
  'height' => 80, // 縦指定
);
$images ="
http://example.com/path/to/image1.png
http://example.com/path/to/image2.png
http://example.com/path/to/image3.png
";
JquerySlideShow::renderSlideShow($params, $images);

1. Iを接頭辞にする

interface IUser {}

• ○ 慣れればインターフェイスだと比較的分かりやすいかも。
• ○ ファイル名でソートしたときに、インターフェイスが集まる。
• × Iが見えにくい。細い。
• 感想: ハンガリアン記法っぽくて嫌い。

2. Interfaceを接尾辞にする

interface UserInterface {}

• ○ インターフェイスって分かりやすい。
• ○ もうクラスがあって、それをインターフェイスに抽象化するときは、クラス名に接尾辞つけるだけ。
• × インターフェイス定義だけ見ると冗長。
• × 長い。
• 感想: 悪くないと思う。

3. -ableを接尾辞にする

interface Countable {}

• インターフェイスは能力を表すという世界観。
• ○ 慣れればインターフェイスって分かりやすい。
• → クラスに-ableを使うことを禁止しないとごっちゃになる。
• × 英語力がないとインターフェイス名考えるのが辛い。
• 感想: なんとなくいいかも。

4. 完全に自由

interface FooBar {}

• × クラス名とかぶるとめんどくさい。
• × type-hintingとかuseとかinstanceofでインターフェイスって分かりにくい。
• → 分からなくても困らないかも？
• ○ 臨機応変に名前をつけられる。

xoopscube.jpが見れないのは不便なので、とりあえず自分のPCからだけは見られるようにする方法を紹介します。 自分がMac使いなので、Macでのやり方になります。（ここでは専用のアプリを入れますが、やっていることはhostsファイルを書き換えるだけです。Windowsにもhostsファイルがあるので同じようなことができるはずです。）

まず、Hosterというアプリをダウンロードしてください。 ダウンロードが完了したらインストールします。 インストールが終わったら起動してみましょう。起動すると下のような画面が出ます。

緑のプラスボタンをクリックします。フォームが出ると思うので、下の内容のとおりに値を入力してください。

セット名：XOOPS Cube
ホスト名：xoopscube.jp
IP: 210.143.106.113

入力が終わったら、「ホスト追加」ボタンを押してホストを追加し、「終了」でフォームを閉じます。 閉じると、「セット名」にXOOPS Cubeが追加されていると思います。

最後に、「XOOPS Cube」の左にある、グレーのまるポチをクリックします。 すると、「1件の設定をホスツファイルへ反映しました」というポップアップが表示されます。

この状態で、http://xoopscube.jp を開いてみてください。今まで通り、xoopscube.jpのサイトが見れるはずです。

なお、xoopscube.jp が復活したときは、上で追加したXOOPS Cubeセットを削除するだけです。 またHosterが起動していないときは、xoopscube.jp から 210.143.106.113へのホスティングはされないので、 xoopscube.jpを見たいときはHosterを起動するようにします。

ちなみに、xoopscube.jpのドメイン有効期間は2011/08/31までなので、ドメイン自体がなくなったわけではなさそうです。

abstractとinterfaceの言語仕様はよく似てる。とても混同しやすい。PHPで自身をもって使い分けている人はどれくらいいるかな？少なくとも自分は全部abstractでもいいと思っている（いた）。でも、interfaceはオブジェクト指向できっと重要な概念だろうから、しっかり区別したいな。Twitterでオブジェクト指向に詳しそうな人に聞きいたり、ググったりして調べて自分なりに理解した内容をまとめてみるよ。

似てる点

• そのままでは呼び出せない。abstractはextends、interfaceはimplementsしてはじめて使える。
• 抽象メソッドを定義できる(see code.1)。ちなみにそれらは子クラスで必ず実装しないといけない。

// code.1
abstract class AbstractFoo
{
	abstract public function bar();
}

interface InterfaceFoo
{
	public function bar();
}

異なる点

• classはabstractを1つだけextendsできるが、classはinterfaceを複数implementsできる(see code.2)。
• abstractは具体的な実装があるメソッドを持てる。interfaceは単に抽象メソッドを列挙するだけ(see code.3)。

// code.2
class Hoge extends AbstractFoo
{
}

class Hoge implements InterfaceFoo, InterfaceFoo2, InterfaceFoo3
{
}

// code.3
abstract class AbstractFoo
{
	abstract public function bar();

	public function baz()
	{
		echo 'baz!';
	}
}

interface InterfaceFoo
{
	public function bar();
	public function baz();
}

この言語仕様を踏まえてどう使い分けるか?

「interfaceを使うくらいなら、abstract一辺倒でよくない？いざとなったらabstractに具体的な実装もできるしね」と思っている人はきっと自分だけじゃないと思う。ここではabstractじゃなくてinterfaceを使ったほうがいい、って例を説明していくよ。だから、interfaceのほうにフォーカスした内容になってる。読者はabstractの使い方をよく知っているし、よく使っているという前提ね。

仕様書はinterfaceにできるかも

interfaceは具体的な実装を持てない。これは設計書として利用できるかも知れない。今までドキュメントに書いていたクラスの仕様はinterfaceにすることができるってこと。例えば、こんな仕様書があったとする。

仕様書

• データベースクライアントクラスは次の4つのメソッドを提供しなければなりません。
• 書き込みメソッド。メソッド名: create()。引数は保存するデータ(連想配列)。
• 読み込みメソッド。メソッド名: load()。引数は読み込む行のID(整数)。
• 上書きメソッド。メソッド名: update()。引数は上書きする行のID(整数)と保存するデータ(連想配列)。
• 削除メソッド。メソッド名: delete()。引数は削除する行のID(整数)。

文書の仕様書を否定するつもりはないけど、人の言葉で書かれた仕様書は曖昧だったりする。上の仕様書でも、戻り値がよくわかんないし、update()の引数の順番は曖昧だし、引数は必須なのか任意なのか分かんない。

紙の仕様書は、メンテナンスされないこともあるよね。仕様書がなくともプログラムは正常に動作するから。もし、仕様書がプログラムに組み込まれたらどうだろう？仕様書がメンテナンスされなければプログラムが動かないので、仕様書をメンテするようになるよね、きっと。

上の仕様書は、interfaceに翻訳することができるんだ(code.4)。下の例のほうが文書の仕様書より曖昧性が低いよね。それに、仕様変更があったときもエラーとして気が付きやすい。例えば、複数行を取得したくなって、メソッドfind(array $condition)を追加したとする。find()を実装していないサブクラスはエラーになるんだ。

// code.4
interface DatabaseClient
{
	/**
	 * テーブルに行を追加する
	 * @returns bool 保存に成功したらtrue、失敗したらfalse
	 */
	public function create(array $data);

	/**
	 * テーブルの行のデータを取得する
	 * @returns mixed 読み込みに成功したら配列、失敗したらfalse
	 */
	public function load($id);

	/**
	 * テーブルの行を更新する
	 * @returns bool 保存に成功したらtrue、失敗したらfalse
	 */
	public function update($id, array $data);

	/**
	 * テーブルの行を削除する
	 * @returns bool 削除に成功したらtrue、失敗したらfalse
	 */
	public function delete($id);
}

これはabstractでも同じような書き方ができるね。でも、具体的な実装を持たないならinterfaceにしたほうがいいかもしれないよ。interfaceは実装を持てない。これって、シンプルという長所でもあるよね。仕様を提供する側のコストがミニマムになる。それに、プログラマは最低限のリードタイムで「ここだけ実装しておけばいいのね」ということが分かるようになる。abstractだったら、そのクラスの内部実装にまで目を配らないといけないよね。つまり、interfaceのほうが設計者とプログラマの両者にとってストレスが少ないってことになるね。（ひとりで開発する場合は別かもしれないけど）

呼び出し方は同じだけど、内部の処理は全然ちがう場合はinterface

最近のウェブアプリはログインするものが多いよね。内部的なこと言ったら認証処理だね。認証処理ってのは、アプリ側が「あなたはだれ？」が特定できればよくて、それ以外の関心はない処理なんだけど、一方で、認証処理は様々なものがある。アプリ独自の認証方式、OpenID、LDAP、Basic認証、Twitter認証、Facebook認証、社内独自認証などなど。

このケースだと、interfaceを活用できる。ウェブアプリは、認証方法の詳細について口出ししない。その代わり、「interfaceに実装してほしいauthorize()っていうメソッドを定義しておいたよ。」っていう約束だけ決めて(code.5)、「うちはそれだけを呼び出すから、あとはうまいことやってね」と具体的な認証方法は各認証オブジェクトにまるなげする。

// code.5
interface Auth
{
	/**
	 * 認証処理を行う
	 * @returns bool 成功したらtrue、失敗したらfalseを返す
	 */
	public function authorize();
}

それで、各認証方式を受け持つオブジェクトは、authorize()を独自に実装する(code.6)。

// code.6
class OpenID implements Auth
{
	public function authorize()
	{
		if ( $this->_openIdAuth() )
		{
			return true;
		}

		return false;
	}

	protected function _openIdAuth()
	{
		// オープンIDで認証する処理
	}
}

この例では、abstractはほとんど役に立たないよね。だって、ウェブアプリは認証方式の詳細に口出し（具体的な実装を提供）することができないから。各認証処理は全く異なった実装になるだろうね。具体的な実装の共通化は容易じゃない。無理して共通化に心を砕くくらいなら、interfaceにしたほうがいさぎよい、と思う。

まとめ

今回、調べていて気づいた点をまとめると、interfaceの出番は次のようになる。もっと、勉強してinterfaceを上手く使えるようになりたいな。

• 仕様書はinterfaceにできるかも
• 呼び出し方は同じだけど、内部の処理は全然ちがう場合はinterface

参考になるページ

• PHPのinterfaceとabstractを正しく理解して使い分けたいぞー ::ハブろぐ
• PHPにはインターフェイスというものがありますよ、という話 - id:anatooのブログ
• ふじやん雑記帳 - とりあえずインターフェース入門
• ５章　インターフェース --Interface--

WeeklyCMS 6/24 マイクロソフト本社特番03

Check Secure Code (04:47〜)

$_POST/GETをforeach展開

foreach ( $_POST as $key => $value )
{
	$$key = $value;
}

「見かけたら即デリート」ということで、危険性と置き換え方がはしょられてる。時間の都合かなーと思いつつ…。

こういうコードの危険性としては、$_SERVERなどの変数を容易に乗っ取られてしまう点。置き換え方は、必要な変数だけ定義するようにすること。たとえば、下の例のように。

// title, text, posterだけがあればいいとき
$title  = $_POST['title'];
$text   = $_POST['text'];
$poster = $_POST['poster'];

intvalはエースケープ関数じゃない^^;

bluemoonさんによると、下の例がまずいらしい。

$hoge = isset($_GET['hoge']) ? $_GET['hoge'] : 0 ;

そして、整数を受け取る前提のものは、次のように書き換えるべきだとしてる

$hoge = isset($_GET['hoge']) ? intval($_GET['hoge']) : 0 ;

最初に整数にしといたほうが安全になるのは確か。HTMLに出すとき、SQLのクエリに入れるときのどちらにも対応できるから。でも、ユーザの入力を勝手に書き換えるのはあまりベストじゃない。だから、この場合は$_GETから取るときはintvalしないでおいて、HTMLに出すときにhtmlspecialchars($hoge, ENT_QUOTES, 'UTF-8')、SQLのクエリにするときにmysql_real_escape_string($hoge)しておくのがいいと思う。

htmlspecialchars()はHTMLに出す直前に

「文字列だったら、htmlspecialcharsで」とのこと。そしてそのサンプルがこれ。

$hoge = isset($_GET['hoge']) ? htmlspecialchars($_GET['hoge'], ENT_QUOTES) : "" ;

そのとおりなんだけど、$_GETから取った直後にhtmlspecialchars()をかけることはXOOPSのモジュールではほとんどない。Smartyに変数を渡す直前でやるのが通常かなと。なぜなら、リクエストをもとに何かデータをこねくり回す(DBを参照したり)ことが多いから。そのとき、HTMLエンコードされた文字列だといろいろ不便だから。なので、やっぱりこれもintval同様に$_GETから値をとった段階では生にしとく。

$hoge = isset($_GET['hoge']) ? $_GET['hoge'] : "" ;

// $hogeをもとにデータをこねくり回す処理

$hoge = htmlspecialchars($hoge, ENT_QUOTES, 'UTF-8');

$xoopsTpl->assign('hoge', $hoge); // smartyに$hogeを渡す

SQL Injection (6:01〜)

addslashes()じゃなくてmysql_real_escape_string()を使おう

録画の中でSQLインジェクションの対策として、addslashes()関数をつかうことを勧めてる。addslashes()でも、SQLのエスケープをうまくやってくれる。実際に、XOOPSのコードのいたるところにaddslashes()がある。でも、addslashes()はクエリエスケープ用の関数じゃないので、SQLインジェクション対策に使うのはちょっと意味が違う。やっぱり、ここはMySQL専用エスケープ関数のmysql_real_escape_string()を使おう。

Mac大好きなmikageさんが会場がMicrosoftなのに「PCじゃなくてMacです、PCというとWindowsです」と言っちゃってるとこを見て、ポカリふきそうになったｗ そのあと、Microsoftの武田さんが発表の前振りで「すいません、PCでっ」ってｗｗ6/24ほんとに行きたかったし、行けなくてもリアルタイムで放送見たかったよーT_T

ます、前提としてConcrete5(5.4.0.5)は多言語対応機能がないみたいです。ググった範囲ですが。 (本気で日英対応しようと思ったらXOOPSCubeホダ塾ディストリ、MODxがいんじゃないかな...(´・ω・｀))さておき、多言語対応ない状況下で日英サイトを作る場合は次のようなサイトマップ構成にするのが定石みたいです。確かな情報じゃなくてすみません、なんせ初心者なので。

├── en
│   ├── page1
│   ├── page2
│   └── page3
└── ja
    ├── page1
    ├── page2
    └── page3

次に、サイトタイトル日英対応とはどういうものか簡単に説明します。日本語ページ(/ja以下)では「○○研究室」、英語ページ(/en以下)では「xxx Laboratory」といったように、サイトのタイトルを切り替える仕組みです。<title>タグはもちろん、<h1>タグに現れるタイトルを切り替えます。

最後に、サイトタイトル日英対応の実装方法を説明します。直感からするとテーマのテンプレートをいじるだけでできそうですが、titleタグをレンダリングしているLoader::element('header_required')が簡単にオーバーライドできないようなので、ちょっとまどろっこしい対応になります。

/config/site.phpに英語の時だけSITE定数を定義する処理を実装します。SITE定数はtitleタグに表示されるサイトタイトルとなります。Concrete5の仕様として、SITE定数が定義することでサイトタイトルをオーバーライドできるみたいです。なので、日本語ページのときは、管理画面で設定したサイトタイトルをそのままつかうことになります。コードの例としては次のようになります。

function is_english()
{
	$requestUri = '/'.trim($_SERVER['REQUEST_URI'], '/').'/';
	return ( strpos($requestUri, '/en/') !== false );
}

if ( is_english() === true )
{
	define('SITE', 'English Site Title');
}

これで、サイトタイトルが現れる部分は一括して日英対応できるはずです。Concrete5のView、もうちょっと拡張性に融通がきくようになるといいなぁ〜

@domifara (すごい活発な人)
@bluemooninc (weeklycmsの人)
@love_marijuana (デベロッパーズバイブルの人)
@umotti (うさできの人)
@nbuy (eguideの人)
@naaon (d3diaryの人)
@AXYZ_SAK (アクシズの人)
@naomi_xoops (テーマの人)
@kilica (XCL2.2コアの人)
@naopon (xpWikiの人)
@nunoluciano (XCL2.2コアの人)
@ohwada (OpenIDの人)
@tohokuaiki (D3ブログの人)
@RyujiAMANO (ryusの偉い人)