Fixed Opcode cache invalidation before add-on install or upgrade

[Xon]

Affected version

2.0 Beta 1

In XF1, I've encountered some errors which can only be explained by the user's opcode caching applying before the install/upgrade function is called.

Can XF2 do a opcache_reset()/apc_clear_cache() before invoking the add-on's Setup.php just to ensure the environment is in a sane state?

And definitely before any XenForo upgrade!

 

[Liam W]

In XF1, I've encountered some errors which can only be explained by the user's opcode caching applying before the install/upgrade function is called.

Can XF2 do a opcache_reset()/apc_clear_cache() before invoking the add-on's Setup.php just to ensure the environment is in a sane state?

And definitely before any XenForo upgrade!

There are some changes in Beta 1 that are supposed to do this, it just doesn’t work all of the time

Liam

 

[Chris D]

Those changes only apply specifically to the dev output system.

 

[Xon]

I just noticed; this should also be done anytime a template file is written to disk.

 

[Chris D]

In XF1, I've encountered some errors which can only be explained by the user's opcode caching applying before the install/upgrade function is called.

Can XF2 do a opcache_reset()/apc_clear_cache() before invoking the add-on's Setup.php just to ensure the environment is in a sane state?

And definitely before any XenForo upgrade!

We made some changes for this in Beta 6 which means that the opcache should be reset before an add-on action (install, upgrade, rebuild) is performed. Additionally we run it when the XF upgrade system is accessed.

I just noticed; this should also be done anytime a template file is written to disk.

We already do this. See XF\FsMounts::handleWriteAction() where we invalidate the opcache of any files being written out to the local code-cache adapter (which notably includes compiled templates).