... except there is an instruction to clear OPcache during the update process since 3.5.1 ...

https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_joomlaupdate/restore_finalisation.php#L156

This relies on PHP's standard API and the opcache_reset() function. Anything else seems like it is NOT using the underlying OPcache API.

Txs @mbabker
I am not sure I fully understand what you mean by this (I am sorry : I am an advanced user, not a developer :-) )

So, if I understand correctly, the opcache should be cleared.

Still, I promise, at SiteGround where I run about 20 independent GrowBig accounts (ie shared hosting), the opCache is cleared automatically on none of them : in order to avoid the mentioned side-effect, I have to delete the .opcache folder manually on each site...

Did I miss something ?
Does somebody have a counter-example (ie opcache being automically cleared at SG with shared hosting) ?

My sites are on php7 with siteground. I didnt even know there was an
opcache folder to delete

You say you have "strange behaviours" but you dont say what they are?

On 19 October 2016 at 14:22, Marc Dechèvre notifications@github.com wrote:

Txs @mbabker https://github.com/mbabker
I am not sure I fully understand what you mean by this (I am sorry : I am
an advanced user, not a developer :-) )

So, if I understand correctly, the opcache should be cleared.

Still, I promise, at SiteGround where I run about 20 independent GrowBig
accounts (ie shared hosting), the opCache is cleared automatically on none
of them : in order to avoid the mentioned side-effect, I have to delete the
.opcache folder manually on each site...

Did I miss something ?
Does somebody have a counter-example (ie opcache being automically cleared
at SG with shared hosting) ?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#12474 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8dgmAYUG62g2q6ADaC4JpqrT63ndks5q1hmRgaJpZM4Ka8oD
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
https://brian.teeman.net/ http://brian.teeman.net/

Sorry you did say what they are - I missed that

On 19 October 2016 at 14:26, Brian Teeman brian@teeman.net wrote:

My sites are on php7 with siteground. I didnt even know there was an
opcache folder to delete

You say you have "strange behaviours" but you dont say what they are?

On 19 October 2016 at 14:22, Marc Dechèvre notifications@github.com
wrote:

Txs @mbabker https://github.com/mbabker
I am not sure I fully understand what you mean by this (I am sorry : I am
an advanced user, not a developer :-) )

So, if I understand correctly, the opcache should be cleared.

Still, I promise, at SiteGround where I run about 20 independent GrowBig
accounts (ie shared hosting), the opCache is cleared automatically on none
of them : in order to avoid the mentioned side-effect, I have to delete the
.opcache folder manually on each site...

Did I miss something ?
Does somebody have a counter-example (ie opcache being automically
cleared at SG with shared hosting) ?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#12474 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8dgmAYUG62g2q6ADaC4JpqrT63ndks5q1hmRgaJpZM4Ka8oD
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
https://brian.teeman.net/ http://brian.teeman.net/

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
https://brian.teeman.net/ http://brian.teeman.net/

If you go to my site https://brian.teeman.net you will see that search works correctly
Sorry I dont have any site with front end login or sobi

@brianteeman

• do you have PHP7 enabled (opcache goes together with it I think)
• is it VPS or shared hosting (maybe it could play a role)

As I said I have php7 enabled. it is a go-geek account (shared hosting)

I can't say I'm familiar with OPcache's workings but from what I remember it's a byte code cache and and doesn't use a directory like that .opcache folder from SiteGround.

I looked in my SiteGround account and found that directory, but also found the contents of several subdirectories that I checked had been modified this morning (well after the update). Also in all sanity checks I did after the update things were functioning just fine so there was no need for me to dig further yesterday.

I don't know how SiteGround's configured their OPcache stuff, but if that directory isn't tied to PHP's own API (the function we try to call during the update), then I would suggest that their configuration is the cause of the issue and it's not something we can address in the Joomla code.

if i'm not mistaken:

when one uses default opcache config the opcache gets cleared without the need to be deleted.
So you can have opcache enabled and update joomla probably with no big issues in this scenario (2 seconds to revalidate opcache). unless some file changes in the update process - where you can have issues.

See http://php.net/manual/en/opcache.configuration.php (opcache.validate-timestamps and opcache.revalidate-freq)

but when one uses more agressive opcache techiques (ex: opcache.validate_timestamps = 0) opcache needs to be cleared, and don't really know if joomla is clearing it on update.

Thank you all of you.
Actually, I downgraded one of the sites & retried the whole process : same conclusion, ie

• search not working any more
• front-end logging not working any more
• ...

I was about to give you the url to show you... when I had another idea : replace my .htaccess by Joomla's basic native .htaccess
And there, great news : no issue anymore on the front-end of the site after upgrading (so I guess the reason for it is that the postupgrade opcache management does work fine in that case).

I have already restored my site about 20 times to be sure the result was consistent.
And yes, it is :-)

So the good news is : this issue must be due to some restrictive rule in htaccess (I still have to find which one).
Consequently, this issue can be closed.

Thank you again for having put me indirectly on the way with your different comments.

PS : as soon as I identify which rule in the .htaccess file interferes, I'll post a little update here

Hi,

A little follow-up just for your information about this issue (remember : opcache not clearing after upgrade having many side-effects like search not working, login/logout not working on front-end, 404 for some extensions like SobiPro and DropFiles, ...) :

• the htaccess was not the cause
• but php.ini was !

Indeed, as soon as I renamed php.ini, I could upgrade/downgrade Joomla without having any of the side-effects.
All those side-effects used to go only when I would manually delete the .opcache directory (suggesting that Joomla was not able to clear the opCache in post-upgrade phase).
Manual intervention was a good workaround, but was not the solution...

SiteGround had told me that there was nothing to do about that...
... but the fact some of you shared their experience here (having no problem with opCache) made me experience further

BTW, here was the content of my php.ini file located in public_html (nothing suggesting me that it would make the post-upgrade opCache clearing fail :-))

display_errors=off
error_reporting=0
zlib.output_compression=off
zlib.output_compression_level=0

So lesson learned : when there is some weird issue, disable php.ini and re-test

Tomorrow, with the release of J!3.6.4, on all my sites, I will be able to check the robustness of the present explanation

I do confirm my last message, after having upgraded about 20 websites at SiteGround :
now that my php.ini (see above) is disabled, no problems anymore after upgrading Joomla !

With other words : not necessary any more to manually delete the .opCache directory above the root to solve all the side effects mentionned (search in front-end not working, log in/out in front-end not working, some extensions not working, ...).

That is not a fair test ;) there are just a few files changed :) to be sure you need to wait for the next bigger update ;)