最近、wordpressを試さないといけなくていろいろ調べていたので、そのことについて書きます。
wordpressの鬼門の一つとしてサーバ移行やドメイン移行等がありますね。もしくは、ローカルで作ったものを本番に上げるとか。

しかし、wordpressって、サーバの情報をデータベースに登録するので、そのままダンプして持っていってもダメなんですね。まぁ、マルチブログを使用していなければ、wp_config.phpでWP_HOMEとWP_SITEURLを指定してあげるだけで大丈夫そうなんだけど、マルチブログを使用していると変更箇所はそこだけじゃなくなってきます。あぁ。面倒くさい。

マルチブログを使用していない際には、上にも書きましたが、WP_HOMEとWP_SITEURLの変更でいいのですが、データベース的にはこの値は、wp_optionsテーブルに入っているので書き換えてあげましょう。例えば、example.ogに変更をしたい際には、

UPDATE wp_options SET option_value = 'example.org' WHERE option_name = 'home';
UPDATE wp_options SET option_value = 'example.org' WHERE option_name = 'siteurl';

と指定します。

また、マルチブログを使用していると上の変更だけではできません。具体的には、wp_blogsテーブル、wp_optionsテーブル、wp_[1-x]_optionsの値を変更する必要があります。複数ブログを3個持っている際には、wp_1_options、wp_2_options, wp_3_optionsの値を変更します。

UPDATE wp_1_options SET option_value = 'example.org' WHERE option_name = 'home';
UPDATE wp_1_options SET option_value = 'example.org' WHERE option_name = 'siteurl';

UPDATE wp_2_options SET option_value = 'example.org' WHERE option_name = 'home';
UPDATE wp_2_options SET option_value = 'example.org' WHERE option_name = 'siteurl';

UPDATE wp_3_options SET option_value = 'example.org' WHERE option_name = 'home';
UPDATE wp_3_options SET option_value = 'example.org' WHERE option_name = 'siteurl';

UPDATE wp_blogs SET option_value = 'http://example.org'';

この変更でブログのサーバの移行ができます。マルチブログの方は厄介ですね。しかし、wordpressって、なんでサーバ情報までテーブルに突っ込んでいるんだろう。

ちなみに今回試したwordpressは3.1.2です。まぁ、設定等を持っていかずに投稿内容だけを持っていくなら、エクスポートが楽なんですが、その際には設定をまたしないといけないので、ダンプして、ポコッとリストアするのが楽なので、やっぱりこっちの方がいいのでは、と。

まぁ、本来なら、fatal errorなんて起きないようにするのが一番いいんだけども。。。

昔、「set_error_handlerでExceptionに渡す。」というブログ記事を書いたことがありました。もう4年以上前かぁ。しかし、これでも取れないエラーが結構あるんですね。まぁ、ログには書かれるので、調査はできるのですが、すぐ知りたいと思うときには問題があるんですね。
今回あったのは、extendするクラスがない、というエラーでした。なんか反映し忘れのようなときに起こるものなんですが、この場合だとfatal errorとなってExceptionが投げられないんですね。

そこでいくつか調べていたのですが、やっぱり役に立つのはマニュアルですね。PHP: set_error_handler – Manualが使えますね。
まぁ、他の人もregister_shutdown_functionでerror_get_lastを見るってのをしているんですけど、このマニュアルで投稿された内容がもう一つ先を行くのは、

php_value auto_prepend_file auto_prepend.php

のように.htaccessで指定して、何よりも最初にこのファイルを実行することって指定していることなんですね。

実は私もauto_prepend_fileの存在を知りませんでした。エラーを指定させるためにあるわけではないのですが、最初に読み込まれるファイルになるようです。参考。また、この記事のようにキャッシュ機構の実装としても使うこともできるみたいです。

そして、auto_prepend_fileで指定したauto_prepend.phpは以下のようになります。ここではエラーが生じるとアラートメールがhogehoge@exmam.orgに送るような設定になっています。まぁ、メールアドレスは適当に変えてください。

<?php
register_shutdown_function(function () {
  if(is_null($e = error_get_last()) === false) {
    mail('hogehoge@example.org', 'Error from auto_prepend', print_r($e, true));
  }
});

なんかJavaScriptみたいな書き方をしてしまったな。。。どちらかと言うと、こっちの方が慣れているかもしれない。

I’m getting know routing cache problem now, but still struggling how to fix this. In my last post, I introduced lazy_routes_deserialize is the way to avoid this problem. Well, I believe some is true, but not everything. After I fixed my factories.yml configuration for sfPatterRouting, it seems that the performance of the application got a lot better, and I no longer across the error messages which I was frustrated very much.

However, I ran the application for a couple days, and found different problem. As the symfony blog mentioned , it generates too many routing cache files!!!!! It was more than 600000. 600000 in one directory is not very healthy. So, I changed my idea to use lazy_routes_deserialize. Instead, I decided to use sfAPCCache. The application was using APC anyway, so I thought put every routing cache in it. It worked fine, but I came across the exact same problem again, which is the size of routing cache gets huge! It ate almost 150M in 3 days, and it seems it is going to consume more in the near future. For now, I just run apache reload task one in a day, so it is working great. However, I don’t like the idea I’m using now. I have to find other strategies for this routing cache.

I think the base of this problem is my routing configuration. It gets so huge, and I need to find out better way to avoid it. The more specific URL you have, the bigger your routing cache gets. I understand it, but it seems the number it grows exponentially! It is not fair!

Is there any way to optimize my routing cache issue?

O.K, I found an answer. Do not use routing cache. Set sfNoCache instead.

I was struggling with this trouble for almost 2 months!!!! My current project uses symfony as always, but I had a big problem with memory issue.

I am engaging this project for almost a year. This application was first created with symfony1.1, but now it is compatible with 1.2. Currently it uses many only 1.2 features such as routing, cache, and etc. I was very satisfied with symfony1.2, except this memory problem.

There were many out of memory error lines in my httpd error log.

 PHP Fatal error:  Allowed memory size of 100663296 bytes exhausted (tried to allocate 5926568 bytes) in /xxxxx/cache/frontend/prod/config/config_core_compile.yml.php on line 3366

Because of this error, I increased memory_limit to 96M in php.ini. However, it was not enough. Plus, because my server was a bit old and has only 512M, it always uses swap, and gets really bad sometimes. I was so frustrated with this problem, and googled this a lot. It is still a guess, and I don’t know the solution I did was the exact one. BUT, It is working very good so far.

After I googled this issue, I found a couple similar topics in symfony forum as follows:

• Routing cache lifetime and memory issues
• Memory problems using cache

The first one was the problem with symfony1.2.4, and it said routing cache files size gets huge and takes too much memory to serialize it. At first, I did not know this post relates with my problem, because I was too lazy to look inside of line 3366 in config_core_compile.yml.php. After checking line 3366, I found it was the same problem. Too much memory consumption exceeded allowed memory size. One of this fix is using SQLite to handle this cache, but in my understanding, symfony1.2.7 provides different way to solve this problem, which you can find symfony 1.2.7 – more power.

all:
  routing:
    class: sfPatternRouting
    param:
      generate_shortest_url:            true
      extra_parameters_as_query_string: true
      lazy_routes_deserialize:          true
      lookup_cache_dedicated_keys:      true

I checked how this fix affects. This fix generate many routing cache files in cache/app_name/prod/config/routing/. The file size was not huge, but number of files is huge, as the symfony blog says. I might need to use different storage for this cache handling, but now the memory error is disappeared. I am very happy with it.

Man, i should have noticed symfony1.2.7 fix.

BUT, it did not fix, but it is working now, The answer is “Do not use routing cache. Set sfNoCache instead.”

To make the symfony1.1 base application compatible with symfony1.2 is not very difficult. Because symfony1.2 considers backward compatibility. If you look inside of symfony, you will find many strange implements, such as link_to1, link_to2. In this case, link_to1 is for symfony1.1 base application, and link_to2 is for symfony1.2.

It made us easy to move on to symfony1.2. And I also upgrade the application I developed with symfony1.1 to symfony1.2. One of the new symfony1.2 feature is routing. Yeah! When I did Jobeet tutorial, it took a bit time to understand the new routing framework. I understand it after I implemented askeet with symfony1.2. When I developed askeet with symfony1.2, I used pure symfony1.2, so the generated codes are symfony1.2 base, and did not have any problems. However, an application I’m currently working on was developed with symfony1.1 first. It works with symfony1.2 now , but routing ruling is still syfmony1.1 base, and there are other symfony1.1 base code as well.

One of the routing features which added in symfony1.2 is sfPropelRouteCollection. Before the emergence of the useful class, I had to write many CRUD and more rule in routing.yml, but sfPropelRouteCollection helped me a lot to implement model base module. I was trying my symfony1.1 base application to upgrading routing rule for symfony1.2. After adding sfPropelRouteCollection in routing.yml, it seemed it is working great, and result of app:routes command is just what I was expected. However, urls displayed converted with link_to or url_for are not what I wanted. These helper functions add “.html” for urls. I don’t want them! I struggled to removing this for a bit. Well, It was easy, but it took me two hours to find this fix. When I found the solution, I was so happy that I could not write post related with my problems.

The problem is generate_shortest_url and extra_parameters_as_query_string values in factories.yml. Well, if you used symfony1.2 to generate application using generate:app, you do not have this problem, because symfony1.2 generate factories.yml with this values. However my application was generated with symfony1.1 almost half year ago, and generate_shortest_url and extra_parameters_as_query_string was not in factories.yml.

As you find in symfony1.2 base application’s factories.yml, you need following values in your symfony1.1 base factories.yml.

all:
  routing:
    class: sfPatternRouting
    param:
      generate_shortest_url: true
      extra_parameters_as_query_strings: true

O.K, that’s it! It is very simple, if you know the reason.