For me, in Settings/Legal, the url to a separately hosted FAQ page (and presumably URLs to the Terms of Service and Privacy Policy pages as well) seem to have stopped working on the forum landing page.
I have tried several test urls pointing to other web pages, but none now seem to do anything, and on my forum landing page the login_required.welcome_message text is always displayed, whereas until recently the FAQ at that nominated url had been what appeared instead.
I can still place a manual link to the same custom pages in the login required dialog, if these are published as posts within Discourse and set to public.
Has this issue been resolved for you? On my test site I’m finding that I can set the tos url and privacy policy url settings to point to an external site. I am not noticing issues with the external links being ignored on either the site’s signup modal or the site’s About page.
Hi Simon
This issue never resolved for me, so I ended up copy pasting from the FAQ (which is actually a public ‘published’ page within the site) directly into the welcome dialog text. Not very efficient, but it works
Interestingly, on clicking to sign up, links to TOS and privacy policy (also public, published pages) were still working from the sign up dialog - so my issue seems to be confined to landing page.
I had no choice, as all pre seeded topics dissapeared for me during an upgrade. Has been working ok, untill more recent upgrade stopped them working from landing page.
Oh no. I was going to ask why you were using published pages for the TOS and FAQ pages, but it makes sense now. Using published pages for these topics seems less than ideal though. I’m fairly sure it is possible to recreate the pre-seeded topics. They are set by some hidden site settings. The following settings can be used to reset the Terms of Service and Privacy topics:
tos_topic_id
privacy_topic_id
I’m unsure of the settings name for setting the FAQ topic ID, but we can track that setting down for you if you’d like to make this change. My understanding is that you would create the new topics in your Staff category, then set the hidden site settings to those topic ids.
If it is possible to track down the FAQ topic ID, that would be good - if only for anyone else striking the same issue of messed up pre seeded topics.
With the landing page issue, a few days ago I turned the problem into a sort of benefit, by generating a much shorter version of the FAQ (mostly for someone not sure if they are in the right place), with links at the bottom to the full FAQ staff topic, TOS staff topic and privacy policy topic from there.
Previously my FAQ was the entirety of the landing page (replacing the welcome dialog text)
It might be best to first check to see if the old TOS, Privacy, and FAQ topics exist. You could do that by checking the value of each of these site settings from the Rails console, then checking to see if you can find the deleted topics via the UI:
tos_topic_id
privacy_topic_id
guidelines_topic_id
With the ID that is returned from each setting, you can try to find the deleted topic by going to /t/-/<topic_id_from_setting_value>. If the topic exists, it should be possible to undelete it through the user interface. If the topics do not exist, my assumption is that new topics can be created in the Staff category. You will then be able to set those topic ids as the value of each of the settings I listed above. I have not tried doing this myself, but I can test it out on my local dev site if you are unsure about making the change on your site.
How did you get on, Paul? I remember this being an issue for you ages ago.
I’ve just had to do this myself after accidentally using delete_all the FAQ/Guidelines topic and not discovering it for a while. This post was super helpful:
I never located those missing pre-seeded topics, but am still happy with my workaround, so was not motivated to try very hard - essentially they are now conventionally editable staff topics, marked as public, which I can and do update from time to time.
I confess I don’t know anything about using rails, but I was able to confirm the original topics were really gone using data-explorer queries (per another user’s suggustion, that I can’t seem to track down right now).
As far as I can tell, my setup now does seem to ‘know’ which staff topics are the ones to use, even if the methodology I followed to make that happen (which I also can’t seem to track down right now!) was a bit less hardcore than the rails edit route.