Discourse rewriting url path behaviour failing due to subfolder

subfolder

(Bram Rongen) #1

Hi there!

We just migrated our forum to Discourse and I’m running into the following issue. When visiting: Talk Forums Disappearing? - Browse Talk: The Largest 3D Printing Forum | 3D Hubs the user is being redirectd to https://www.3dhubs.com/talk/t-forums-disappearing/10681 which doesn’t exist.

You can see the behaviour in practice by clicking the link. The post does exist, when you for instance search for it and navigate through it that way it works fine.

My guess is Discourse is trying to be clever about the urls and is misguided by the talk/t/talk part.

What’s the recommended way to solve this?

Cheers, Bram


(Bram Rongen) #2

Some help from my hosting:

Weird bug indeed. I don’t see where it redirects either, seems to be returning the correct page and then redirected by Javascript. It’s not the nginx config, it is reaching the application server.


(Richard - DiscourseHosting.com) #3

Using safe mode to make sure there is no plugin or theme causing this

1 - correct link is requested
2 - correct content is returned
but then:
3 - fetching 404 body

logging

[db5060] Started GET "/talk/t/talk-forums-disappearing/10681?safe_mode=no_custom%2Cno_plugins%2Conly_official" for 77.163.254.28 at 2018-08-07 20:19:10 +0000
[db5060] Processing by TopicsController#show as HTML
[db5060]   Parameters: {"safe_mode"=>"no_custom,no_plugins,only_official", "slug"=>"talk-forums-disappearing", "topic_id"=>"10681"}
[db5060]   Rendering topics/show.html.erb within layouts/application
[db5060]   Rendered topics/show.html.erb within layouts/application (6.3ms)
[db5060]   Rendered layouts/_head.html.erb (0.3ms)
[db5060]   Rendered common/_discourse_stylesheet.html.erb (0.1ms)
[db5060]   Rendered common/_special_font_face.html.erb (0.1ms)
[db5060]   Rendered application/_header.html.erb (0.2ms)
[db5060]   Rendered common/_discourse_javascript.html.erb (0.3ms)
[db5060] Completed 200 OK in 124ms (Views: 9.0ms | ActiveRecord: 26.0ms)

[db5060] Started GET "/talk/404-body?_=1533673157932" for 77.163.254.28 at 2018-08-07 20:19:12 +0000
[db5060] Processing by ExceptionsController#not_found_body as HTML
[db5060]   Parameters: {"_"=>"1533673157932"}
[db5060]   Rendering exceptions/not_found.html.erb
[db5060]   Rendered exceptions/not_found.html.erb (15.3ms)
[db5060]   Rendering html template
[db5060]   Rendered html template (0.0ms)
[db5060] Completed 200 OK in 52ms (Views: 0.3ms | ActiveRecord: 11.6ms)

(Bram Rongen) #4

Created a PR to fix it: Fix wrongful redirections when topic starts with BaseUri by bram-rongen · Pull Request #6243 · discourse/discourse · GitHub

I don’t have any prior experience in Ember or Rails or Discourse so please review carefully :slight_smile: and then :ship: it!


(Sam Saffron) #5

That fix is not ideal… @neil can you have a look at this issue

It does not make sense to me cause this topic works just fine:

I wonder if something is not configured right on your end Bram.


(Richard - DiscourseHosting.com) #7

but… but… it doesn’t:


(Sam Saffron) #8

well it was working earlier for some crazy reason, @neil will look at this


(Richard - DiscourseHosting.com) #10

It works fine when you browse to such a topic, it only fails when you come from a direct URL.


(Bram Rongen) #11

I agree, it might be better to restructure the code to not require this functionality at all but it does make the function do what it is supposed to do:

/**
    Returns the current `location.pathname` without rootURL
*/

Instead of just replacing every occurrence of Discourse.BaseUri with an empty string my version only drops the baseUri when it exists on the start of the url. The only case that this will break is when you decide to use any of the starts of system paths (/u, /t, /admin, etc) as your BaseUri. This will break your site, but not more then before.


(Neil Lalonde) #12

I pushed a fix that looks only at the beginning of the path which avoids this problem. Unless you use /t, /u, or something like that, but that would be a terrible idea for many reasons.


(Jeff Atwood) #13

This topic was automatically closed after 3 days. New replies are no longer allowed.