Credo sia ragionevole assumere che qualsiasi link relativo sia relativo alla radice della sottocartella. Quindi, se desideri un link esterno al forum, dovrai utilizzare l’URL completo.
In alternativa, penso che tu possa essere in grado di configurare un routing dei permalink /forum/downloads/* verso https://example.com/downloads/*
Non penserei che questa sia la cosa normale da aspettarsi quando il percorso relativo è ancorato, ovvero /downloads: nel mondo HTML/HTTP questo suggerisce la radice del sito, non la radice della sottocartella.
Quindi, se avessi un link sul tuo sito web principale che inizia con /t/something, come potresti capire se si tratta di un link Discourse o di un link al tuo sito web principale?
Si scriverebbe come /forums/t/something. È ciò che un utente pubblico si aspetterebbe quando scrive un post in un forum. È così che funzionano la maggior parte dei siti web: perché qualcuno dovrebbe sapere di inserire /t/something?
Questo è il problema: Discourse sta aggiungendo lo stesso prefisso /forums a più applicazioni e questo sta causando i suddetti problemi. Non capisco perché sia necessario modificare l’URL inserito in un post.
Stiamo indagando su questo problema; potrebbe essere correlato a questa correzione:
Concordo sul fatto che i link a /jobs su acme.com debbano puntare a acme.com/jobs indipendentemente dalla configurazione in sottocartella. Non dovrebbero invece puntare a acme.com/forum/jobs.
Ho fatto l’ultimo commit su get-url.js, qualche tempo dopo quello collegato.
Concordo sul fatto che i link non dovrebbero essere riscritti se sono inseriti dall’utente; forse getURL non dovrebbe essere chiamato in questi casi? Penso che getURL debba essere utilizzato per le rotte predefinite di Discourse per “convertirle” nell’impostazione della sottocartella; ci sono alcuni test che si aspettano esplicitamente questo prepending della sottocartella:
Ho indagato su questo problema questo pomeriggio e ho una correzione in questa PR:
Purtroppo, il nostro codice routeTo è progettato per funzionare con URL relativi, quindi se chiamiamo url.routeTo("/cool") e c’è una sottocartella sub configurata, verrà riscritto in /sub/cool anche se /cool sembra relativo. Non credo che questo sia corretto, ma scommetto che molto codice ne dipende.
Fortunatamente, in questo caso era il tracciatore di clic a reindirizzare perché pensava che l’URL fosse interno. Ho aggiunto un controllo per assicurarmi che il link interno abbia lo stesso prefisso e ho ripulito i test. Sembra funzionare.
Non ho idea di come sia avvenuta la regressione: ho provato a usare git blame ma non ho ottenuto risultati.
Abbiamo anche notato che i collegamenti relativi allo stesso sito, come /downloads, vengono trattati come collegamenti esterni e si aprono in una nuova scheda del browser. Non è davvero un grosso problema.
Inoltre, non è un grosso problema, ma se rimuovi l’ID del post dalla fine di un collegamento a un post del forum, come ho fatto io, la cronologia del browser viene persa quando si clicca sul collegamento, ad esempio questo collegamento.
Purtroppo non riesco a riprodurlo. In locale, quando uso esattamente lo stesso link, viene elaborato correttamente. Vorrei anche aggiungere che la mia patch non dovrebbe modificare il modo in cui i link sono scritti in HTML; gestisce solo ciò che accade quando si clicca su un link.