Page does not load after v2.2.0 beta 4-31 upgrade due to Cloudflare

Received notice to upgrade to the latest version via email.

However, the system forced a rebuild via CLI.
Navigating to /var/discourse kept popping me into /var/www/discourse. So I had to Exit and it popped me back into the default directory. But I did manage to get the rebuild done.

Then upgrade to the latest version via the site front end. Receiving the “Waiting for Unicorn to reload” message. But again the upgrade continued successfully.

That being said, I cannot load the main forum page. All I see if a grey page.

Selecting as a random page, loads.
But again, navigating to the main page does not load. Checking the browser console produces the following JS errors.

Any help would be great.

r.get(...) is undefined

I would ask if you had tried safe mode but Cloudflare is having problems contacting the server.

Turn the orange cloud on Cloudflare off, it’s not going to help you troubleshoot.

Did you use launcher enter app at any point? The above suggests you might have.

Once Cloudflare is off I would ssh back in and:

cd /var/discourse
git pull
./launcher rebuild app

No need to update again from /admin


One tweak, and I need to re-discipline myself on this as well… you only need two lines

cd /var/discourse
./launcher rebuild app

The script does a git pull for you.

1 Like

Thanks for the reply Stephen,

git pull

Already up-to-date.

I just completed the rebuild via:

./launcher rebuild app

And I also did turn off the orange cloud on Cloudflare. Same issue.

Working here.

Restart your browser?

Any desktop specific customisations?

Don’t forget safe mode if desktop still won’t comply:


If that works it’s likely to be a plug-in or customisation at fault.

1 Like

Okay… so it seems that disabling the Orange cloud in Cloudflare DNS, resolves the issue.

I did try safemode before… but alas.

Forum | Linux Game Consortium

Hmmm… and this means that I’m running the forum without Cloudflare. Just DNS.

Either way… thanks Stephen. :slight_smile:

We’re not quite done yet.

How did you have Cloudflare configured?

Any page rules? What about mirage and rocket loader?

I would recommend the following at a minimum:

That will stop Cloudflare from interfering with code and server comms.

Then if you want to create a caching rule for /uploads/* go for it.


I did try again with the Orange cloud enabled in Cloudflare. Alas, same issue.

Adding the Minimum rule, Disabling Performance. This Disables Mirage and Rocket Load.
But again, the same issue, unable to load the main page.

So I had to Disable the Orange Cloud in Cloudflare.

Adding a caching rule for /uploads/* is a good idea.
But with just DNS service only. No real need.

Bad idea, don’t put Discourse behind Rocket Loader.


The Disabling Performance rule disables Rocket Loader. But does not resolve the issue here.

Are there any other rules in place?

Apps enabled on the domain in Cloudflare?

Disable Performance does more than disable the deferred loading from Rocket Loader, it also shuts off minification. You don’t want anything interfering with the javascript or when it’s loaded.


There are other rules but they pertain to the root domain.

I did try a couple of rule entries for the forum:


But neither had any effect unless I disabled the Cloudflare and only used their DNS.
And there are NO Apps even installed.

Cache Everything

Disable Performance

And yes, I already looked into Disable Performance rules:

Disable Performance:
Disables the following features:
Rocket Loader

Which is odd, with all of this being disabled, everything should work. Alas, this is not the case.

So the Orange cloud option is disabled.

Your top rule collides with the last. Forum will match *. Fix your wildcard or disable that rule.

Are you using the WordPress plug-in for cloudflare to control the cache?


Ironic, Cloudflare does not issue a conflict notice.

You’re suggesting using https:// instead of the * wildcard?

What is your recommendation for the primary domain and forum subdomain rules?

And yes to the Wordpress plugin for cloudflare cache?


  • Your site uses https
  • you use the root domain and don’t use www.

Your rule can enable full SSL and begin with https:// rather than *

Cloudflare won’t report a conflict because despite it overlapping in a way you hadn’t anticipated it’s a valid rule.


That’s a different way of looking at things. Thanks for the heads up.

Keeping to using the * wildcard just made sense to use. But the https definition with Full SSL makes sense.
The Full SSL came to mind earlier in the discussion. But I do appreciate a different view.

Thanks again Stephen. :slight_smile:

Full SSL just means that the connection into Cloudflare and to the destination server are both HTTPS, and that clients will need to connect by HTTPS.

Using * in that way will match both protocols and subdomains, there’s no reason not to specify the protocol and force all traffic to be HTTPS assuming that you’ve told the Google Search console to use HTTPS.

Sites which are available with and without the www record on both HTTP and HTTPS are in for a whole world of SEO hurt. Might as well have Cloudflare do all the hard work with a 301 redirect.


Your site now appears to be working, and looking at cURL it’s proxying through Cloudflare correctly - is everything back to normal for you now?

* SSL connection using TLSv1.2 / ECDHE-ECDSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
*  subject: OU=Domain Control Validated; OU=PositiveSSL Multi-Domain;
*  start date: Oct 26 00:00:00 2018 GMT
*  expire date: May  4 23:59:59 2019 GMT
*  subjectAltName: host "" matched cert's "*"
*  issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO ECC Domain Validation Secure Server CA 2
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7f94ec006600)
> GET / HTTP/2
> Host:
> User-Agent: curl/7.54.0
> Accept: */*
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< date: Thu, 08 Nov 2018 02:19:55 GMT
< content-type: text/html; charset=utf-8
< set-cookie: __cfduid=df9bd7bd1691978adaa50ddaf3ce598791541643594; expires=Fri, 08-Nov-19 02:19:54 GMT; path=/;; HttpOnly
< vary: Accept-Encoding
< x-frame-options: SAMEORIGIN
< x-xss-protection: 1; mode=block
< x-content-type-options: nosniff
< x-download-options: noopen
< x-permitted-cross-domain-policies: none
< referrer-policy: strict-origin-when-cross-origin
< x-discourse-route: list/latest
< cache-control: no-cache, no-store
< x-request-id: 2c0c298c-d272-4784-8bb7-8dc8e14d7586
< x-runtime: 0.148661
< x-discourse-trackview: 1
< strict-transport-security: max-age=31536000
< expect-ct: max-age=604800, report-uri=""
< server: cloudflare
< cf-ray: 47648eb36cb6542c-LAX

For sure, Full SSL is a connection based service. Not server based.
Enabling this in the rule is a usable feature. So we’re already on the same page there.

Using * is a general fix, whereas setting HTTPS is specific. For sure. Thanks for the reminder though. That should have been changed a while ago.

Ah yes cURL. :slight_smile:

Thanks again. Everything is back to normal again.