I was recently notified by a fellow Clarioneer that they were unable to access the 'hub.
Obviously this was horrifying and needed immediate investigation.
It’s amazing what little things can bring down an intricate system!
tl;dr;A bug in a plugin broke the entire site for any browser requesting Dutch translations. Yuk.
It was an interesting journey and resolution though, so here’s a quick share!
grep '184.108.40.2062' access.log
A quick peek at the nginx logs for the IP address so kindly shared (the one above is fake ) didn’t really tell me more than I already knew… They were getting a 500 error.
This site has logs that are visible to admins from the web interface which are quite handy - https://clarionhub.com/logs (no, you cannot see them. Admin only!)
Right now they look like this which is a beautiful thing!
Earlier though, lots of entries like this:
The “Info” part of the log entry was the most useful:
I18n::InvalidLocaleData (can not load translations from /var/www/discourse/plugins/procourse-static-pages/config/locales/server.nl.yml: #<Psych::SyntaxError: (/var/www/discourse/plugins/procourse-static-pages/config/locales/server.nl.yml): did not find expected key while parsing a block mapping at line 3 column 5>) /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/i18n-0.8.6/lib/i18n/backend/base.rb:212:in `rescue in load_yml'
Even then it took a while to figure out what the actual problem was.
The file indicated in the message looks like this:
(SSH into digital ocean droplet, enter the running docker container, find the plugin file and open it in vi and hope you remember how to exit the damn thing)
Actually, the highlighting here makes it quite obvious. See the
Pagina's containing that single quote? That’s the bugger!
yml files you escape single quotes by using two of them so
Pagina''s. Refresh the browser… fixed!
Since the plugin is open source I was able to create a pull request so that next time ClarionHub is updated I don’t have to remember to monkey patch the plugin inside the docker container!