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.
¿Cómo te fue, Paul? Recuerdo que este fue un problema para ti hace mucho tiempo.
Acabo de tener que hacer esto yo mismo después de usar accidentalmente delete_all en el tema FAQ/Guidelines y no descubrirlo durante un tiempo. Esta publicación fue de gran ayuda:
Nunca encontré esos temas pre-sembrados que faltaban, pero sigo contento con mi solución alternativa, así que no me motivé a intentarlo muy duro; esencialmente, ahora son temas del personal editables convencionalmente, marcados como públicos, que puedo y actualizo de vez en cuando.
Asumiendo que tienes acceso root a tu servidor, la solución tomará literalmente 5 minutos y no perderás nada de esa útil información sobre temas del personal.
Todo lo que hace es identificar esos temas como los que se deben usar.
Confieso que no sé nada sobre el uso de Rails, pero pude confirmar que los temas originales habían desaparecido realmente utilizando consultas de data-explorer (según la sugerencia de otro usuario, que ahora mismo no logro encontrar).
Por lo que puedo ver, mi configuración ahora parece ‘saber’ cuáles son los temas del personal que se deben utilizar, incluso si la metodología que seguí para lograrlo (¡que tampoco logro encontrar ahora mismo!) fue un poco menos rigurosa que la ruta de edición de Rails.