askeetチュートリアル バグ修正-route-

ichikawaです。
バグを修正したのでレポートです。

【バグの発生】
tagerr1
tagerr2
チュートリアルでいうと13日目に追加したタグですが、タグを新規追加すると404エラーが出てしまう。
【ログを見る】
devbar
(よし、デバッグツールだ)と”logs&msgs”をクリックして中を見てみました。devmsg(クリックで拡大)
……しかし、データベースへのアクセスの詳細などが書いてありましたが、404エラーがどうやって出ているのかが詳しく分からず、
シェル上でログを見ることにしました。
コマンドは
$ tail -f log/frontend_dev.log
これでページをリロード。
するとこのような結果になりました。
shellLog(クリックで拡大)
“404″という文字がたくさん出ていて、何か見つけ出せそうです。
【原因発見】
注目すべきはどこで404を出すメソッドが呼び出されているかです。

call “defaultActions->executeError404()”

ここです。
この少し前を見てみると

action “tag_add/index” does not exist

ありました。こいつが原因です。

【修正箇所を探す】
ログを見てどこを直せば良いのかということがsymfonyを使い始めて最初のうちはなかなか分かりませんでしたが今なら多少見当がつきます。
これを見ておかしいのは、tag_addというモジュールは入れていないことです。
(つまり入力ミスでtag_addと書いてはないか。)
そこでまずはフォームから送信される場所(askeet/apps/frontend/module/sidebar/_question.php)をチェック。
するとありました。
templateTagAdd
これが送信先を示す部分です。
しかしこれはurlが@指定で書いてるのでrouting.ymlを参照する必要があります。(呼ばれるmodule/actionがこれだけでは分からない)
こちらがrouting.ymlのtag_addの部分です
routingTagAdd
予測だと、ここがおかしくなっていると思ったのですが、うまく繋がっているように見えます。
(困った。)
【探せなかったので先輩にヘルプ】
先輩に聞きましたところ、default_indexが影響していると指摘されました。
routingDefault
確かに、これだとモジュールが送信されたURL”tag_add”になり、アクションが”index”になるのでログメッセージのrequest parametersに合致します。
でもなぜこれが繋がっているのでしょうか。
調べてみたところ、routing.ymlに書く順番は意味があって、この場合だとフォームから送られてきたtag_addが、ルーティングルールのtag_add: より先にdefault_indexを先に読み込んでいるようです。確かに、このとき default_index: は tag_add: よりも上部に書かれていました。
(なるほど。)
そこで二つの位置を逆にしてみると
addTagsuccess
うまくいきました。無事繋がったようです。
ところで、今気づいたのですがシェルでログを見た時に、request parameter を送る前に”match route”という記述があり、ここでどのrouteに接続されたのか書いてあることに気づきました。
エラーの時は、

match route [default_index] “/:module”

となっていて、丁寧に表示されていました。

またうれしい発見をしました。これでバグの起因場所をもう少し早く探せそうです。

コメントをどうぞ

名前: (Required)

eMail: (Required)

Website:

Comment:

Spam Protection by WP-SpamFree