A couple weeks back I attempted to update to the version previous to 2.2.0beta4 (2.2.0beta3 ?) and the same thing happened so I thought I would wait to see if the next one helped fix this.
Suggestions on correcting this would be appreciated, thanks in advance.
Can you please use your browser’s “view source” command to get the HTML source of the home page and provide it here? That will help us pinpoint anything unusual about your setup. Thanks.
Test using safe mode /safe-mode and if that works visit /admin to disable any customisations. Just create a new theme with no changes and temporarily set it to default.
If safe mode works and disabling customisations doesn’t restore your front page you need to start disabling plugins to pinpoint the cause.
Ok, I don’t currently use any customizations, it’s bone stock. I will certainly still try this though and see what happens.
I do use cloudflare and I set the caching to dev mode ( no caching ) and also purged all cached data to see if that would help. It did not.
Any other suggestions are appeciated, I will let you know what the results are when I try testing using safe mode later. I’m currently AFK and it takes a bit of time.
Well, turning off the orange cloud defeats the purpose of using Cloudflare and significantly elevates risk. I’ll test though using a burner domain or something, thank you for the suggestion. I would not recommend people doing this as it will reveal your servers IP to crawlers immediately and the damage will be done once logged. Even if you turn orange cloud back on afterwards and have not cycled your IP, Cloudflare will no longer protect your server as the IP will be known.
It wouldn’t help to give the URL at the moment because I reverted back to a good snapshot, as users are using the site at the moment. I’ll need to do maintenance in the early hours of the morning.
Thank you again, I will report back later. If anyone has suggestions related to those errors shown, I will gladly test other things as well.
For now it’s a diagnostic step. It doesn’t significantly elevate risk unless you’ve increased the attack surface of your server and done some very silly things. There are no nefarious ‘crawlers’ out to get you, the period of time this would be done for is minimal.
Your server isn’t protected by Cloudflare, it actually does nothing to protect the server itself, it only proxies the FQDN, the server IP is still as vulnerable with or without it turned on. The kinds of attack you should be worried about are bots scanning entire subnets of machines, which priorities the ranges allocated to VPS services.
That’s an exaggeration, Discourse only needs one rule to work with cloudflare, there are plenty of servers which use it with Discourse.
It’s always stuff added beyond that, such as apps and other rules which cause the problems. This week alone we’ve had a number of good examples.
Either way, Cloudflare doesn’t do anything to harden a server beyond masquerade the FQDN. Servers which which use it are easily identifiable. Assuming it affords some additional level of protection beyond the proxy demonstrates why it can lull people into a false sense of security and actually make you more vulnerable, instead of less.
I respectfully disagree with you. There are in fact crawlers whose job is to continuously crawl domains, resolve the IP and log the DNS info. In fact, it’s a huge market.
If you use Cloudflare properly, no one should ever know your servers true IP. Hence, it’s security through obscurity. I could give you a domain which has properly used Cloudflare and even the class B subnet the server is on and I doubt you will be able to correlate the two, unless of course, you slip and create an A record which has the servers true IP in it, which will get logged very quickly.
I digress, the intent of this topic is derailing. If you would like to discuss passive DNS, crawlers and opsec. I will be happy to do so in another category/thread.
That’s 19 addresses over 9 years for the front end site, and even viewdns admits that they don’t track subdomains. I don’t think you’re making the point you think you are.
Either way, it looks like you’re on your own fixing this. Good luck!
Discourse works with Cloudflare, it’s almost certainly something you’ve done to yourself, as to what we can’t say without more information that you’re either unwilling or unable to provide.
We’re not really ones for tech support whilst blindfold and at least one arm tied behind our back(s). At least not for free.
You don’t want anything interfering with the javascript or how the page is loaded, which minification and rocket loader will do. Both usually end up with the issue you’re reporting.
If you want to cache assets then only turn that on after proving the site works with the above, and even then only use standard caching with /uploads/* - caching other stuff isn’t supported.
Knowing the FQDN helps us use other tools to look, but as we don’t have it we will skip that stage entirely.
That should be the only rule touching your site. If you have any others which risk overlapping then for now just shut them off.
If that doesn’t work then it’s time to look at apps.
Because your upgrade triggered the problem though it’s also still possible this is due to an old plugin. You said your install is bone stock, but do you mean just in terms of customisations? Are there any plugins added to the app.yml beyond the defaults? Broken plugins are also going to rear their heads during an upgrade.
I thought this page rule was already set but it was not. So I added this page rule for the domain and it seems to be working again . Also, it had worked fine up until two updates ago, .
Great suggestion and thank you for your time. I’ll continue to test and monitor.
. Also, it had worked fine up until two updates ago, 
.