i can't reproduce this in latest staging.

PHP 7.0.10 (cli) (built: Aug 19 2016 09:19:29) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
    with Zend OPcache v7.0.10, Copyright (c) 1999-2016, by Zend Technologies

The line you're refering is https://github.com/joomla/joomla-cms/blob/staging/libraries/cms.php#L59

That error would mean your server isn't setting up the $_SERVER variable correctly.

Thanks Michael for the good pointer. Perhaps I should contact SiteGround (web host) about this? Or perhaps something still on my end?

I tweaked cms.php (the if statement attempting to call $_SERVER) which removed the error but made the backend unnavigable. I replaced a fresh copy of cms.php in attempts to get things back to as they were, but instead have the backend visible but unnavigable (URL updates, but not content). Swapping back to PHP 5.6.25 again fixes the issue. :-P I've tried a separate browser in case of cookie issues. I even tried reinstalling Joomla via the new re-install feature.

This issue does not occur on a separate site of mine that has way more extensions and would seem like a much more likely candidate for this to occur on. Errrr hmmmm, I guess this means it's a personal site issue.

I'm on SiteGround and I'm not having this issue at all. So it definitely seems site specific.

mmmh, exactly (exactly) same error message today when trying to access the backend of one of my sites (also hosted at SiteGround).
Switching to PHP5.6 was indeed a workaround.
Once I gained access again to the backend, I tried different things :

• cleaning cache
• disabling jSG cache (SiteGround cache handler)
• I even disabled pagespeed on the cPanel Result : no improvement : as soon as PHP7.0.10 was reenabled, the same error message was coming.

So I found the rootcause : I delete (well, renamed) the .opcache folder above the root.
And the backend immediately worked again :-)

So I guess that after some recent upgrade of some extension, something went wrong.
All my sites are always uptodate (Joomla & extensions) and I had accessed the backend of that site a couple of days ago.

I think of two recent updates (made with myJoomla) which have been installed recently :

• Akeeba Backup yesterday
• JCE today But maybe the issue with opcache is independent of those two updates.

The only thing I know is that I have already had issues with opcache after upgrades of Joomla itself in August (3.6.2), but I had seen that there were long discussions about that Opcache with Joomla... when the servers are really SUPER fast (like at SiteGround).
But I had undestood more or less that this upgrade cache issue was solved now.

So maybe still something wrong somewhere ?

@woluweb Thank you!! ? ? ? This whole time I've had SG cache also disabled for the sake of reducing potential break points. I keep my extension count very low to make it easier to identify issues and for performance reasons. For some unknown reason the issue went away without renaming the folder mentioned. Is OPCache enabled by default on SiteGround? It looks like a really cool extension.

@JoshuaLewis : sorry, I am no expert in PHP or in OpCache, but to sum it up : OpCache is the cache system of PHP.
As far as I know, your issue (which I also experienced) comes from the fact that SiteGround's servers as so fast that when we upgrade Joomla for example, it goes so fast that the system has not seen that there was a change.
So the server serves kind of a mix of (cached versions of) old files and of new files.

Theoretically, before applying any upgrade (Joomla and/or extension), one should disable Opcache, and then reenable it after.
But as far as I know, on shared hosting you can not play with the Opcache parameters (well, you can delete .opcache directory, which cleans the cache).

But is there still an issue with Joomla or some extensions, I don't have Michael's level to tell :-)
@mbabker : is there still some issue with Joomla & Opcache ? Or is there some best practices, or know issues with certain extensions or so ?

Txs,

Marc

No idea. Personally I haven't done anything to explicitly enable OPcache anywhere and AFAIK each of the Joomla sites I'm running are all functioning just fine on PHP 5.6 and 7.0 (can't speak for older versions, I try to not run unsupported software ? ).

Txs for the feedback Michael.

Actually, in particular when I upgraded to Joomla 3.6.2, I faced many issues on different sites... which were all solved by deleting that .opcache directory. Examples of those issues :

• front-end connexion not working any more on several sites
• disconnexion on front-end not working on some sites
• backend connexion not working any more on one site
• search would not work any more on several sites
• plus some issues on several extensions, giving error messages : SobiPro, FlexiContent, Dropfiles, eDcoman

So I don't know if it is possible to add an automatic post-install "clean cache" instruction which would be for example triggered by Joomla itself, but I guess it would help avoiding all those issues.
(but I am no Developer as such, so maybe I am oversimplifying :-)

The update system already has this cache flushing directive - https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_joomlaupdate/restore_finalisation.php#L156

This requires you to update through the update component and not any other alternative though.

Txs Michael !

I update mainly via myJoomla for extensions (but often manually for Joomla as such).
I think myJoomla does trigger the regular native Joomla Update Component, but if I face again some similar issue in the future, I'll check that with Phil :-)

Thanks renaming the opcache folder helped with this

I've had to rename the folder several times now. Perhaps I should contact SiteGround about OPCache?

@JoshuaLewis I think eventually it catches up, but if you're developing it can be a bit of a bane. At the moment my dev site has an error on it so I needed to speed the process up. For the record deleting the cache takes a lot longer than renaming it :)