サイトの相対パスがサブフォルダでクライアントサイドで誤って書き直されました

これは以前は正しく動作していましたが、最近のアップデートで再び壊れたようです。

相対リンクの追加

[Full version 1.9.2 change history](/downloads/continuaci/continua-ci-version-history-v192)

を追加すると、リンクは正しくレンダリングされ、マークアップも正しく表示されます。しかし、クリックするとリンクが以下のように変換されてしまいます。

https://www.finalbuilder.com/forums/downloads/continuaci/continua-ci-version-history-v192

当社の Discourse インスタンスは forums 配下のサブフォルダとしてインストールされています。

今年の初めにこの分野でいくつかの変更があり、それが関連している可能性があります。

現在、2.8 beta1 を実行しています - Commits · discourse/discourse · GitHub

「いいね!」 3

相対リンクはサブフォルダのルート相対であると考えるのが妥当でしょう。したがって、フォーラム外へのリンクを作成する場合は、完全修飾URLを使用する必要があります。

あるいは、/forum/downloads/* のパーマリンクルーティングを https://example.com/downloads/* に設定できるかもしれません。

「いいね!」 2

以前は機能していたのに、なぜ変更されたのですか?

相対パスがアンカーされている場合(例:/downloads)、HTML/HTTPの世界ではこれはサブフォルダのルートではなく、サイトのルートを示すのが通常だと考えられます。

「いいね!」 1

つまり、メインのウェブサイトに /t/something から始まるリンクがあった場合、それが Discourse のリンクなのか、それともメインのウェブサイトへのリンクなのかをどうやって見分けますか?

「いいね!」 1

/forums/t/something と記述されます。これは、フォーラムに投稿する一般ユーザーが期待する形式です。ほとんどのウェブサイトがこう動いているため、なぜ人が /t/something と入力する方法を知っている必要があるのでしょうか?

「いいね!」 1

@RGJ の意見に同意します。複数のアプリケーションで同じサブフォルダプレフィックスを共有するのは、トラブルを招くだけです。

私にとっては「修正しない(won’t fix)」です。

「いいね!」 2

まさか?URL を / から始めたら、設計上それはサイトのルートにあるはずです。HTML リンクの動作を再定義しているんですか?

この仕組みは、最近の破壊的変更が起きるまで、2年半にわたり当サイトでも問題なく機能していました。

「いいね!」 1

まさにその問題です。Discourse が複数のアプリケーションに同じプレフィックス /forums を追加していることが、前述のトラブルの原因となっています。なぜ投稿内で入力された URL を変更する必要があるのか、私には理解できません。

「いいね!」 1

この問題について調査中です。おそらく、以下の修正に関連している可能性があります:

サブフォルダの設定に関わらず、acme.com 上の /jobs へのリンクは acme.com/jobs に遷移し、acme.com/forum/jobs には遷移しないべきだと私も同意します。

「いいね!」 7

get-url.js への最後のコミットは、リンクされているコミットの少し後に行われました。

ユーザーが入力したリンクは書き換えないべきだと私も考えます。もしかすると、こうした状況では getURL を呼び出さない方が良いかもしれません。getURL は、Discourse のデフォルトルートをサブフォルダ構成に変換するために使用されるもので、このサブフォルダのプレフィックス追加を明示的に期待するテストがいくつか存在します。

何かお手伝いできることがあれば、お知らせください。

本日はこれを調査し、以下のPRで修正を行いました:

残念ながら、当社の routeTo コードは相対URLを前提に設計されているため、url.routeTo("/cool") を呼び出した際に sub というサブフォルダが設定されている場合、/cool が相対URLに見えるにもかかわらず /sub/cool に書き換えられてしまいます。これは正しい動作ではないと思いますが、多くのコードがこの挙動に依存している可能性が高いです。

幸いなことに、今回のケースでは内部リンクだと誤認したクリックトラッカーがリダイレクトを引き起こしていました。内部リンクが同じプレフィックスに存在することを確認するチェックを追加し、テストも整理しました。動作しているようです。

ただし、なぜこの問題が再発したのかはわかりません。git blameで調査を試みましたが、原因を特定できませんでした。

「いいね!」 6

関連があるかどうかはわかりませんが、アップデートを適用した後、リンクエディタが機能しなくなりました(空表示になるか、フィールドが区切られない状態になります)。

これはさらに悪化しているようです。

リンクを追加すると

[forum relative link](/forums/t/continua-ci-v1-9-2-664-released/7058)

[forum relative link](https:///forums/t/continua-ci-v1-9-2-664-released/7058)

となってしまい、href 属性なしでレンダリングされてしまいます。

なお、上記のテストは Commits · discourse/discourse · GitHub で実行されました。

また、/downloads のように同じサイトへの相対リンクが外部リンクとして扱われ、新しいブラウザタブで開く現象も確認しました。これは特に大きな問題ではありません。

同様に、ささいな点ですが、フォラム投稿へのリンクから投稿 ID を末尾から削除した場合(私が行ったように)、リンクをクリックするとブラウザの履歴が失われてしまいます。例えば、このリンク がそうです。

残念ながら、私はこれを再現できません。ローカルで全く同じリンクを使用すると、正しく処理されます。また、私のパッチはリンクの HTML としての書き方を変更するものではなく、リンクをクリックした際に何が起こるかを処理するだけであることも付け加えておきます。

これは既に検討されていると思います。ありがとうございます:

「いいね!」 2