Crashed my discourse while changing settings in admin section


Hi guys,

It seems I crashed discourse while changing some settings related to categories


Initially I was trying to remove all options from Top menus. As I was getting an error saying that I can’t remove “latest” from top menu, I changed “category style” to “Categories only”. Then I removed all top menus. However my discourse became really unstable and finally I ended up getting “Error 500”.

In the nginx logs, I can see some “connections refused”. We tried rebuilding the container, restarting the whole machine. nothing worked.

Any idea?


(Stephen) #2

It’s pretty simple, the first entry in the top menu is also the ‘home’ when you visit / - if you were able to remove everything from that list (which shouldn’t be possible, right?) then your site would no longer have a default page to serve up.

Changing the desktop category page style only does that, the style of the categories page, which isn’t necessarily the page served from the root (/).

From my phone I can’t check how you revert that setting, although I’m pretty sure it can be done. Wiser minds than mine can interject on that front.

(Ayaz Maroof) #3

@steve_pd Thanks for pointing @sebastien and I in the right direction.

We were able to fix the problem by going directly to the docker container and opening a rails console. In the rails console we reset SiteSetting.top_menu to “latest” and that fixed the problem :slight_smile:

(Richard - #4

Some old topics about this: Top Menu Removal Crashes Site
and Home page 404s if top_menu is garbage
and Deleting all entries from top menu results in 500 error

Apparently never got implemented?

(Joffrey Jaffeux) #5

I warned about it the other day when I replaced this kind of inputs with select-kit, sorry it got lost, probably should have created a bug issue about it.

discourse/string_setting_validator.rb at master · discourse/discourse · GitHub is returning before regex_match? if value is nil. So in the case where you remove all values it’s never hitting the regex validation.

Not sure how to fix this as we have settings like ga_universal_tracking_code which rely on this behavior:

    client: true
    default: ''
    regex: "^UA-\\d+-\\d+$"

We will validate it once user enters one setting, otherwise we bypass validation. We could add a site setting option valid_blank: true, what do you think @neil ?

(Joffrey Jaffeux) #6

As a temp fix to your issue you can do the following:

in your /discourse

bundle exec rails c
SiteSetting.top_menu = "latest"

It should fix the error.

(Richard - #7

Just make it so that the validator is okay whenever the regex matches OR the setting has its default value.
No need to add any options then.

(Joffrey Jaffeux) #8

That’s a possibility, not sure it will cover all the cases though, hence why I’m asking neil who knows the subject more than me.

(Neil Lalonde) #9

Since this is a list setting, maybe an option to have min number of items in the list?

(Jeff Atwood) #10

Maybe but if the only item in the list is a weird one, it may still not work.