対応するカテゴリの特定の記事に直接リンクするメインメニュー項目があるWebサイトをリファクタリングしています。
現在、これらの各メニューアイテムには、これらの各カテゴリの子ブログカテゴリメニューアイテム(非表示)があります。
昨夜まで、この設定はうまく機能していました。今朝、メインメニュー項目をクリックすると、ブラウザに"Redirect Loop"が表示されます。カテゴリブログ内から、単一の記事のメニュー項目にリンクされている記事にアクセスしようとすると、同じことが起こります。
SEF拡張機能は使用されていません。また、htaccessにこれを生成する特別なものはありません。
私の推測では、Joomlaは混乱しており、その記事の可能なURL間を行き来しています。 JoomlaのコアSEFでリダイレクトループが発生し、これらの記事の書き換えが無効になっていることにも注意してください。
したがって、次のような非SEF URLで記事にアクセスしようとします。
index.php?option=com_content&view=article&id=11catid=8&lang=en
私はそれのためのリダイレクトループを取得しています、それはURLで終わります:
index.php?option=com_content&id=18&lang=en&view=article
これは実際に私がリダイレクトされたURLであり、問題のすべての記事に対してブラウザにスタックされます。
何が起きてる?
これを整理しました。
ここで2つのことが起こりました。
最初に、モジュールからのMySQLクエリのために、Joomlaによって500エラーが生成されました。
このWebサイトには、カスタムのエラー記事ページにリダイレクトする設定(以前の開発から継承)がありました。ただし、このページは使用できなくなり、新しい404エラーが発生し、再び自分自身にリダイレクトしようとしました。
そのため、MySQLクエリでのモジュールの構文エラーは、リダイレクトループで明らかになりました。
これをトラブルシューティングするのに役立つアプローチ:
私が到達しようとしていたメニュー項目のいずれかがリダイレクトされ、同じURLへのリダイレクトループが発生するという事実:
index.php?option = com_content&id = 18&lang = en&view = article
古いサイト実装のバックアップをチェックインしたところ、記事IDが見つかりました。これは、カスタム404エラーページの記事でした。
最も一般的なデバッグ手法:サードパーティの拡張機能を無効にします。
クリーンなJoomlaインストールをセットアップし、同じ条件を再作成してみます-構成。
最後に、なぜJoomlaがエラーページの古い記事にリダイレクトしようとしているのかはまだわかりませんが、どこかに隠れていて、どこかで明らかになると思います。
また、特定の条件下で誤ったSQLクエリを生成するモジュールの特定の問題について、モジュール開発者に書いた。