思ったこと、調べたこと、学んだことメモ

CentOS 4.8 に apache2.2をインストールすることにした。
まずは必要になりそうなパッケージをyumで。

yum install openssl-devel

この時点で最新ソースをダウンロードして展開してconfigureしてコンパイル。
configureは既存のapache2.0.52と競合しないようにprefixだけ指定。

wget http://ftp.kddilabs.jp/infosystems/apache/httpd/httpd-2.2.15.tar.gz
tar xvzf httpd-2.2.15.tar.gz
cd httpd-2.2.15
./configure --prefix=/usr/local/httpd --enable-mods-shared=all --enable-ssl=shared --enable-suexec --with-suexec-caller=apache --with-suexec-uidmin=1000 --with-suexec-gidmin=1000 --with-suexec-docroot=/home
make
make install


これで/usr/local/httpd/にインストールされる。
–enable-mods-shared=allにしておけば必要になったときに設定ファイルだけでいつでも追加できる。
–enable-ssl=sharedはallでも入らなかったのでいれた。
suexec関係はバーチャルホストで利用しているのでいれた。

/etc/httpd/conf.d ディレクトリを
/usr/local/httpd/conf.d としてコピー

/usr/local/httpd/conf/httpd.confの修正

User daemon
Group daemon
を
User apache
Group apache
に変更。

ServerRoot “/usr/local/httpd”
の下あたりに
PidFile /var/run/httpd.pid
を追加。
これは/etc/init.d/httpdの変更をできるだけ少なくするため。

ServerAdmin に指定してあるメールアドレスを適切に変更。

DocumentRoot “/var/www/html”
に変更。どっちでもいいんだけどあまりいろいろ変更したくないので。
それに合わせて

も

に変更

Include conf.d/*.conf
を追加

下記行のコメントをはずす
Include conf/extra/httpd-mpm.conf
Include conf/extra/httpd-languages.conf
Include conf/extra/httpd-default.conf
include conf/extra/httpd-ssl.conf (sslを使ってる場合) ただしこのファイルの
DocumentRoot "/usr/local/httpd/htdocs"
ServerName www.example.com:443
ServerAdmin you@example.com
ErrorLog "/usr/local/httpd/logs/error_log"
TransferLog "/usr/local/httpd/logs/access_log"
このあたりは各バーチャルホストの設定ファイルに書いているのでコメントアウト。

SSLを使ってる場合は
server.keyやserver.crtを/usr/local/httpd/conf内に設置

/etc/init.d/httpd
を
/etc/init.d/httpd.orgとしてコピー

/etc/init.d/httpd
を変更
apachectl=/usr/sbin/apachectl
↓
apachectl=/usr/local/httpd/bin/apachectl
httpd=${HTTPD-/usr/sbin/httpd}
↓
httpd=${HTTPD-/usr/local/httpd/bin/httpd}

ここでphpを再コンパイルした。というかちょうどアップデートがでていたので最新バージョンをコンパイル。その際configureのオプションで
‘–with-apxs2=/usr/sbin/apxs’
の部分を
‘–with-apxs2=/usr/local/httpd/bin/apxs’
にしてconfigure、make、make installするとちゃんと新しいhttpd.confに
LoadModule php5_module modules/libphp5.so
を追加してくれる。

これだけだとphpはちゃんと動かないのでさらに
AddType application/x-httpd-php .php .phtml
を追加。

以上で設定は全部完了。

/etc/init.d/httpd.org stop
で今動いてる古いapacheを停止。

/etc/init.d/httpd start
で新しいのを起動。

と走り書きしましたが、いつかちゃんと読みやすく成形したいけど今はちょっと時間がなくてやってられないのですみません。必要なかたは頑張って読んでください。

symfony 1.1 のフォームを使用すると、明らかな文字化けではないが、文字列の最後に？がつくなどの文字化けをすることがありました。

原因は、サイトの都合上、phpの内部コードと外部コードを別々にしなければならない案件があり、外はSJIS、中はEUCとしていたため、htmlspecialcharsでの文字コード指定時に外側用のSJISとして適用されていたためだったようです。これを調べる過程でどこかのサイトで、理論的にはhtmlspecialcharsで文字コードの指定をしても、日本語については何の意味もないというような記事があったが、実際には変わるようです。少なくとも今回はそれで解消しました。

実際に行ったのは、下記のコードをeucForm.class.phpとして、（このフォームの使用範囲に応じて）symfonyプロジェクトディレクトリ直下のlibか、apps/appname/libか、モジュールのlibかにおいて、フォームを使用する際はsfFormをextendsして使うのではなくeucFormをextendsして使用すれば大丈夫です。他にももしかしたら方法があるのかもしれませんが、時間もなかったのでとりあえずこれで切り抜けました。

< ?php

/**
 * eucForm class
 *
 * 文字コードの指定(EUC-JP)
 *
 */
class eucForm extends sfForm
{
  public function setup()
  {
    //文字コードの指定
    foreach($this->widgetSchema->getFields() as $widget){
      $widget->setCharset('EUC-JP');
    }
    parent::setup();
  }

}

これだけです。このEUC-JPと直接書きこんでいるところを、設定ファイルからsfConfig::get(’app_internalencoding’)などとやって、app.ymlにinternalencoding: EUC-JP と書くことで汎用性を持たせるのもありかもしれませんが、そもそも内部コードにSJISを持たせることは考えにくいし、UTF-8なら変換の必要はないし、と考えるとこのようなことをやらなければならないのは、内EUC-JP、外SJISに限られるかなと思ってEUC-JP専用にしてしまいました。

symfonyを使用する際はできるだけ外も内もUTF-8を使用するようにしていますが、いろいろな都合でそうもいかないことも時にはあります。 それでもphp.iniや.htaccessで文字コードを適切に指定しておけば、あまり問題が起こることはないのですが、今回のように問題になることもあります。

symfony 1.1のRC1がでて、間もなくリリースされるという状況ではありますが、ドキュメントについては非常に少ない状態です。

1.1の大きな目玉の一つであるフォームフレームワークについては、なかなか情報が見つかりませんでした。symfonyのサイトにあるドキュメントもまだ1.0の情報のままで、1.1では特別な指定をしない限り使用できなくなりますのと注意書きがあります。

理解すると、前のにくらべてとても使いやすく自由度が高いので非常に便利です。

情報をあさっていくうちに、参考になるサイトを見つけたので紹介します。どちらも英語ですが、コードを見るだけでも参考になると思います。

• 7 Days of Symfony 1.1 – Forms, Widgets and Validators
  このリンクはDay1ですが、7までありとても詳しく解説されていて参考になります。
• symfony 1.1 form framework and the MVC pattern
  symfonyの作者であるfabien自身が自分のブログで書いた記事です。チュートリアルではなく、このフォームフレームワークがMVCモデルであることを説明しているページですが、簡潔にコードでも説明していて参考になります。

XSLTプロセッサとは

XSLTプロセッサとはXSLTを使ってXMLを他のXMLに変換するものです。タイトルではHTMLをつくるとなっていますが、実際にはHTMLでなくてもいいわけです。

XSLTとは

XSLTとは、まさに上記の目的（XMLを他のXMLに変換する）のための簡易言語で、これもXMLで書かれています。
XSLTの書き方はサンプルで覚えるXSLTプログラミングが参考になります。

phpによる変換

PHPマニュアル XSL関数より

PHP 5には、デフォルトでXSLエクステンションが含まれており、 configureに引数–with-xsl[=DIR] を追加することにより有効にすることができます。

なのでとても簡単にできます。下記が例です。($xml に xmlの内容が格納されており、/path/to/xslfile.xslにxsltファイルがあることを想定しています。）

$doc = new DOMDocument();
$xsl = new XSLTProcessor();

$doc->load('/path/to/xslfile.xsl');
$xsl->importStyleSheet($doc);

$doc->loadXML($xml);
echo $xsl->transformToXML($doc);

ここでは、$doc->loadXML($xml);としていますが、これは$xml内に既にXMLの内容が格納されていると想定しているからです。たとえばDBからとってきた場合などです。ファイルから直接読み込むのであれば、XSLTの読み込みと同じように$doc->load(’/path/to/xmlfile.xml’);でもOKです。
これだけで、変換が完了します。

SugarCRMにSUGAREXCHANGEでダウンロードしたモジュールを、モジュールローダーからインストールすると、ロケール設定が日本語でログインしたときには、タブに文字が表示されなくなっていた。無理やり空のスペースをクリックすると後は正常に動作していた。

解決法

下記の作業を行うことで解決した。

• custom/application/Ext/Language/en_us.lang.ext.php を custom/application/Ext/Language/ja.lang.ext.phpとしてコピー
• custom/Extension/application/Ext/Language/en_us.forums.php を custom/Extension/application/Ext/Language/ja.forums.phpとしてコピー

タブの日本語化

さらに日本語化する際は、「管理」より「開発者向けツール」の中の「タブの名前を変更」をクリック。ここで日本語にできる。ちなみに、先ほどの作業を行う前まではここにも（Japaneseを選択した際には）表示されてこなかった。
変更してもすぐに反映しなかったが、一度ログアウトしてログインしなおすと無事日本語化された。

ずっと前からSugarCRMを使用していたのだが、今回、新たに入れなおす必要がでた。

SugarCRM 5.0 RCはやめてSugarCRM 4.5.1をインストール

SugarCRM 5.0 RCがでていたので、これをインストールしたのだが、Asertiva Thunderbird Extension が使用できなかった。Asertiva Thunderbird Extensionはどうしても使いたかった。間もなく5.0も正規リリースされるだろうし、そうなればAsertiva Thunderbird Extensionも対応してくれるだろう。
さらには、4.5.1から5.0へのアップグレードも楽そうだったので、今回は4.5.1をインストールしなおした。

Japanese Language Packがない！

ここで問題になったのが、このバージョンのJapanese Language Pack（日本語化パック）がないこと。SugarForge: Japanese Language Pack: ファイルリストに5.0用のはあるのだが、それ以外のはない。
みんなで使用したいと思っていたので、できたら日本語化したい。

5.0用を使って日本語化

そこで、SugarCRM 5.0用のJapanese Language Packを使用して日本語化しようと思った。そのままアップロードしてみると、予想通りだめ。というわけで、他言語の4.5用のLanguage Packを参考に作成しなおした。

1. ダウンロードしたLANGPACK JAPANESE OSS500beta2 alpha1.zipを解凍
2. manifest.phpだけ変更して再圧縮

変更した後のmanifest.phpは下記の通り。

<?php

$manifest = array(

 'name' => 'Japanese',

 'description' => 'Sugar Community Edition 4.5.1 Japanese Language Pack',

 'type' => 'langpack',

 'is_uninstallable' => true,

 'version' => '4.5.1',

 'acceptable_sugar_flavors' => array(),

 'published_date' => '2007-10-22',

 'author' => 'CareBrains Inc.',

 'acceptable_sugar_versions' => array(),

 'lang_file_suffix' => 'ja',

 'icon' => '',

);

?>

後は、.zipに圧縮する際にフォルダを圧縮するのではなくて、フォルダの中身だけを圧縮するように注意する。

圧縮してできたファイルをアップロードしたら、きれいに日本語になった。まだ、あまり試してはないのだけど、おそらく問題ないだろう。

この日本語化パック、正規版になったときもケアブレインズが提供してくれるかどうか微妙なところのようだ。過去のファイルも消されているようだし、一応、今回ダウンロードした5.0用のファイルもとっておいた方がいいかもしれない。

phpのバージョンを5.2.4に上げたときにmysqlを使用しているサイトでsymfonyのエラーがでるようになった。

内容は次のようなもの。

Unable to convert value at column * to timestamp: 0000-00-00 00:00:00

調べてみると「Warning about PHP 5.2.4 and Creole」という記事が見つかった。

どうやら、php 5.2.3以前のバグを5.2.4で修正したのが原因らしい。strtotime　で’0000-00-00 00:00:00′を指定したときに、今まではなぜか、「943905600」が返されていたが、5.2.4以降はFALSEが返されるようになったため。

そこで、symfonyのディレクトリで（うちの場合は、/usr/share/pear/symfony）

grep -rn 'Unable to convert value at column' *

で調べると
vendor/creole/common/ResultSetCommon.php
vendor/creole/drivers/mysqli/MySQLiResultSet.php
vendor/creole/drivers/mysql/MySQLResultSet.php
vendor/creole/drivers/mssql/MSSQLCallableStatement.php
が該当した。
ここでは、mysqlが問題になるので、上の3つのファイルの

if ($ts === -1 || $ts === false) { // in PHP 5.1 return value changes to FALSE
	throw new SQLException("Unable to convert value at column " . (is_int($column) ? $column + 1 : $column) . " to timestamp: " . $this->fields[$idx]);
}

という個所（ファイルによっては2か所以上ある）を

if ($ts === -1 || $ts === false) { // in PHP 5.1 return value changes to FALSE
	//throw new SQLException("Unable to convert value at column " . (is_int($column) ? $column + 1 : $column) . " to timestamp: " . $this->fields[$idx]);
	return '943916400';
}

とした。

一応これで動くようになったがこれはあくまでも仮の処理。おそらくsymfony側でも対応するだろう。とおもっていたら、既に修正されていた。 そして、昨日symfony 1.0.9がリリースされていた。

さっそくアップデートしてみよう。