Support

I believe this is a bug on our end. Can you please retry now and let me know if that worked for you?

This is actually a completely different issue. Something on your site is causing a Javascript error which prevents the configuration page from rendering.

I suggest upgrading to Akeeba Backup 5.0.2 and then clear your browser's cache. Go back to the Configuration page. If it appears empty try disabling third party system plugins one by one until you find the culprit.

To be absolutely honest, I don't believe it is a Joomla! issue. This issue has not happened on any of my Joomla! 3.5 sites (3.5.0 and 3.5.1) during development and testing. With the intensity of the testing I performed I have visited that page at least 300 times every day for three weeks. If there was a problem I'd have most assuredly noticed.

On top of that, the way this page is rendered has not changed since December 2009 when I first wrote it: the server generates a JSON string, it outputs it to the page body and then a script file reads it and renders the configuration interface fields. Since you're from the USA I assume that you're using Akeeba Backup in English so there's no chance that some exotic character is screwing up the JSON. That does leave us with either a Javascript error or a stale browser cache. Which brings us to the next point.

Akeeba Backup 5.0.2 was released 9 hours ago and is of course fit for use on production. This is what we are running on our own site (and yes, the configuration page does work!). Please remember to also clear your browser's cache. This is important, since the browser may be serving the cached interface script file from an older version of Akeeba Backup which is NOT compatible with Akeeba Backup 5.

Have you ever heard of an internet provider caching pages?

As a matter of fact I have, but it was back in 2006 and we were still on dial-up. Ten years later I am more likely to come across one of the following:

• PHP code caching, such as OPcode. This accounts for 90% of "weird" issues we've seen with our clients.
• Broken PHP installations. For example, I've seen some versions of PHP 5.5 having a miscompiled cURL module which returns a-ok for PUT requests even though it transfers no data (whaaaaaaat?!)
• Hosting providers putting a page cache –such as Varnish– in front of a site. Goodbye sanity, hello weird page refresh issues.
• Same as above with a CDN. Bonus BDSM points if they have CDN in front of Varnish in front of NginX configured as reverse proxy in front of Apache (I've had the misfortune of debugging such a monstrosity).
• BONUS ROUND! Transparent caching proxies installed by the IT department without telling the web site management team.

The next time this happens I will try a different machine first then if the problem persists, I will try another internet provider.

If you have a mobile data (3G/4G/LTE) connection that supports tethering try using that, ideally with another machine. That's a fast way to see if the problem is on the network or the server.