This should be communicated in some way before opening a bug report.
Automated replies don’t make sense either.
The user sees directly that the topic has been published successfully.
It doesn’t require an additional info.
Plus, I think that automated messages are the wrong approach in such a community.
I totally get your point @anon32808828 and I must admit here as well that I could’ve saved a good amount of time for some people already (including myself) - just by following some basic steps (e.g. the ones you mentioned).
And the fact that I know about these simple trouble-shooting basics doesn’t make it better.
@michelyweb You also need to check the hosting environment. I just shifted a Cwicly staging site from a shared hosting (just for testing stuff) to my primary VPS on Linode. Heavy pages load under 2 sec in the editor now. It was taking 10-20 seconds on the shared environment. I am sure there are faster shared hosting environment available but I prefer VPS as it allows me full control of my server.
Ouch, that’s certainly NOT good, and shouldn’t be happening. Could I possibly have a peak at the backend of that staging or not? Would highly appreciate it.
Don’t bother @Louis. I think the shared hosting I have is oversold or runs on very poor server. I pay 2 usd/m for it. So there is that. Even bricks site was taking 10-20 seconds to load on this shared hosting. Same bricks or Cwicly site on my local environment (LocalWP / Laragon) or a 5 USD/m linode vps loads instantly. No fault of Cwicly here.
I just made that post so people keep in mind that hosting also plays a big role in the site performance. It is also good if people copy their site to a different hosting server or LocalWP to test performance.
Could you possibly deactivate HTTP Auth?
Gutenberg calls editor assets through normal requests and can’t access them if they’re behind an HTTP Auth. The alternative is the whitelist your own server IP.