」というタグがついている記事一覧

Symfony と WordPressの連携の際に重なってしまう関数

Symfony と WordPressの連携の際に重なってしまう関数として esc_js()がある。

Symfonyのコアファイルのlib/helper/EscapingHelper.phpで定義されている。

これをdefine(’ESC_JS’, ‘esc_js’);とともにコメントアウトしてしまえば大丈夫なのだけど、こうするとコアファイルをいじることになるので、アップグレードの時に面倒になる。

ほんとはコアファイルに手をいれずに変更できればいいのだけど、EscapingHelper.phpの読み込みはlib/view/sfPHPView.class.phpの44行目あたりの

    $helpers = array_unique(array_merge(array('Helper', 'Url', 'Asset', 'Tag', 'Escaping'), sfConfig::get('sf_standard_helpers')));

で指定されていて、settings.ymlのstandard_helpersで指定しても追加されるだけになってしまう。

と思いきやlib/config/sfApplicationConfiguration.class.phpをみるとgetHelperDirsでhelperを読み込むディレクトリをとってきてる。というわけでプロジェクトディレクトリのapps/front/lib/helper/にEscapingHelper.phpをコピーして該当行をコメントアウトすることで対応できた。

ただ、このファイルがバージョンアップしたときには、ここにコピーし直して同じ作業を擦る必要があるので注意しておかないとまずそう。

タグ
コメントはありません。 »

symfonyをウェブルートディレクトリではなく、一つ下の階層に入れた場合とかの設定(特にルーティング)のメモ

久々に書きますが、時間がないのでメモレベルで。
いつか時間とニーズがあればWordPressとSymfonyの連携の方法なんかも書いてみたいと思ってます。

たとえば、symfonyをabcというディレクトリに入れたとして、

apps/front/config/factories.yml

inc:
  routing:
    param:
      context:
        prefix:                         '/shop'

のようにして

symfony以外のプログラム(たとえばwordpressとか)では、ファイルの最初に

< ?php
//autoload symfony core class
require_once(dirname(__FILE__).'/../config/ProjectConfiguration.class.php');

sfCoreAutoload::register();
// add autoload my project class
$dir = dirname(__FILE__).'/../';
$sfSimpleAutoload = sfSimpleAutoload::getInstance();
$sfSimpleAutoload->addDirectory($dir);
$sfSimpleAutoload->register();

$configuration = ProjectConfiguration::getApplicationConfiguration('front', 'inc', true);
sfContext::createInstance($configuration);
?>
とかいうのを書いとく。
そうすれば、たとえばテンプレートで
< ?php
echo sfContext::getInstance()->getController()->getPresentationFor('parts','sidebar');
?>

とかしたときに、url_for()とかで指定したリンク先が
/index.php/test/aaa
とかならずに
/abc/test/aaa
となってくれる。

タグ
コメントはありません。 »

symfony 1.1 でのsfFormを使用する際の文字化けの解消

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で文字コードを適切に指定しておけば、あまり問題が起こることはないのですが、今回のように問題になることもあります。

タグ
コメント数:2 »

symfony 1.1 のsfFormの情報

タグ: ,

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モデルであることを説明しているページですが、簡潔にコードでも説明していて参考になります。
タグ
コメント数:1 »

symfonyでUnable to convert value at column * to timestampのエラー

タグ: ,

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がリリースされていた

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

タグ
コメントはありません。 »