We do redirect though after extracting files. That's the ENTIRE reason for using Joomla Update over extension manager :( I mean I'm not denying the issue - I think I saw something related on the forum earlier - but there's gotta be something more than just the file extraction :/

Looks like this issue happens only if you have fast computer with SSD drive in it.

For me the issue happens on every single test site I have tried, including a clean installation of 3.4 installed just minutes before. I've reproduced it a few times already. The result is always the same.

I think the issue must happen just before redirect and only with fast hardware (I guess JVersion class needs to be copied during the same/last request). Right now I have PHP 5.6.18 with opcache turned on; haven't tried with other PHP versions yet.

Alright, I just tried to upgrade another site without debug mode and it failed on the same error. Then I created a new site and tried again -- failed.

It looks like whatever I do or not do, upgrade will always fail (6 out of 6 times now).

There have been other reports (with earlier releases of joomla) that
opcache must be flushed for an update to complete

On 22 March 2016 at 09:57, Matias Griese notifications@github.com wrote:

For me the issue happens on every single test site I have tried, including
a clean installation. I've reproduced it a few times already. The result is
always the same.

I think the issue must happen just before redirect and only with fast
hardware (I guess JVersion class needs to be copied during the same/last
request). Right now I have PHP 5.6.18 with opcache turned on; haven't tried
with other PHP versions yet.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#9515 (comment)

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

Alright, now we are getting somewhere. Without opcache installation succeeds just fine.

Clearing opcache (or restarting apache) manually doesn't help though, I guess installer might be using the class somewhere.

The other issue was #8249

I am just trying to find place where I could put the following code:

        // Remove all compiled files from opcode cache.
        if (function_exists('opcache_reset')) {
            @opcache_reset();
        } elseif (function_exists('apc_clear_cache')) {
            @apc_clear_cache();
        }

This issue really bugs me as the only way to upgrade all my Joomla test sites is to turn off opcache... I'm not sure why opcache isn't detecting file changes even if its told to check the timestamp.

Just updated 3.4.8 to 3.5.0 with opcache enabled without issues.
PHP 5.6.19

i have: opcache.revalidate_freq: 0 (default is 2) | opcache.validate_timestamps: on

Looks like I have way too many PHP installations in my computer; and the version I was using for testing seemed to have default values, or opcache.revalidate_freq: 2 as I had forgot to edit the file.

Also upgrade from 3.3.6 to 3.4.8 fails, but 3.4.1 to 3.4.8 seems to be fine; so the issue here is pretty clear: opcache.revalidate_freq: 2.

I guess that this issue cannot be fixed for the older releases, but now that we know the issue, lets add opcache clear to both extension installer and joomla updater just after the files have been copied over. :)

Updating first message to get a better test case.

What are the default values? Does everything work correctly with the
default values?

It's 2
See http://php.net/manual/en/opcache.configuration.php

Just updated the first post to give more reliable test case. Default value is 2 and it takes less time to copy the files if you're using SSD drive. In fact I had empty configuration for opcache (all default values).

Also setting opcache.revalidate_freq: 0 fixes the issue.

@mahagr can you submit a PR please

I need to work today, too; I'll try to find some time tonight after my work day is over.

@mahagr did you had time to check this?

I have the code available, but testing it has proved to be really hard..

I've been able to prevent fatal error from happening, but for some reason database doesn't get updated and I don't yet know why. I also clearstatcache(); just in case, but it doesn't help either.

@nikosdion Is finalizeRestore stage in restore.php proper location to clear opcache, or is there a better location to do it? Opcache needs to be updated before Joomla gets the control back...

Please note that your issue will occur when OPcache is enabled. The same issue affects extension updates. Your solution is incorrect. The code you need to add (as you can see in FOF 2 and FOF 3 used by all of my extensions) is:

        // Always reset the OPcache if it's enabled. Otherwise there's a good chance the server will not know we are
        // replacing .php scripts. This is a major concern since PHP 5.5 included and enabled OPcache by default.
        if (function_exists('opcache_reset'))
        {
            opcache_reset();
        }

On the other hand, if your code also expect to recompile view templates (e.g. Twig, Blade, etc) based on the source's date/time stamp you also need to run clearstatcache().

Regarding the best place to put that, since we only support using Joomla! Update to update your site, yes, finalizeRestore would be the best place. In fact, as I have repeatedly said when asked about it (do you listen @wilsonge ? :p ) , you should add a file administrator/components/com_joomlaupdate/restore_finalisation.php with the following contents

<?php
/**
 * @package     cmsupdate
 * @copyright   2014 Nicholas K. Dionysopoulos / Akeeba Ltd 
 * @license     GNU GPL version 3 or later
 */

// Require the restoration environment or fail cold. Prevents direct web access.
defined('_AKEEBA_RESTORATION') or die();

// Fake a miniature Joomla environment
if (!defined('_JEXEC'))
{
    define('_JEXEC', 1);
}

if (!function_exists('jimport'))
{
    /** We don't use it but the post-update script is using it anyway, so LET'S FAKE IT! */
    function jimport($foo = null, $bar = null)
    {
        // Do nothing
    }
}

// Fake the JFile class, mapping it to Akeeba Restore's post-processing class
if (!class_exists('JFile'))
{
    abstract class JFile
    {
        public static function exists($filename)
        {
            return @file_exists($filename);
        }

        public static function delete($filename)
        {
            $postproc = AKFactory::getPostProc();
            $postproc->unlink($filename);
        }
    }
}

// Fake the JFolder class, mapping it to Akeeba Restore's post-processing class
if (!class_exists('JFolder'))
{
    abstract class JFolder
    {
        public static function exists($filename)
        {
            return @is_dir($filename);
        }

        public static function delete($filename)
        {
            recursive_remove_directory($filename);
        }
    }
}

// Fake the JText class
if (!class_exists('JText'))
{
    abstract class JText
    {
        // No need for translations in a non-interactive script.
        public static function sprintf($foobar)
        {
            return '';
        }
    }
}

if (!function_exists('finalizeRestore'))
{
    /**
     * Run part of the Joomla! finalisation script, namely the part that cleans up unused files/folders
     *
     * @param   string  $siteRoot     The root to the Joomla! site
     * @param   string  $restorePath  The base path to restore.php
     */
    function finalizeRestore($siteRoot, $restorePath)
    {
        if (!defined('JPATH_ROOT'))
        {
            define('JPATH_ROOT', $siteRoot);
        }

        $filePath = JPATH_ROOT . '/administrator/components/com_admin/script.php';

        if (file_exists($filePath))
        {
            require_once ($filePath);
        }

        // Make sure Joomla!'s code can figure out which files exist and need be removed
        clearstatcache();

        // Remove obsolete files
        if (class_exists('JoomlaInstallerScript'))
        {
            $o = new JoomlaInstallerScript();
            $o->deleteUnexistingFiles();
        }

        // Clear OPcache
        if (function_exists('opcache_reset'))
        {
            opcache_reset();
        }
    }
}

This file is loaded by restore.php when you execute the finalizeUpdate function in media/com_joomlaupdate/js/update.js:L239 i.e. when restore.php tells you that the update archive is fully extracted. Therefore the OPcache and PHP file metadata cache resets occur before the redirection to index.php?option=com_joomlaupdate&task=update.finalise which requires the obsolete files to be removed and the caches reset.

The code that I added was:

    // Make sure that PHP has the latest data of the files.
    clearstatcache();

    // Remove all compiled files from opcode cache.
    if (function_exists('opcache_reset')) 
    {
        @opcache_reset();
    }
    elseif (function_exists('apc_clear_cache')) 
    {
        @apc_clear_cache();
    }

Its basically the same code I use in all of my extensions. Note that I also clear APC cache in PHP 5.3/5.4 as it also has option to turn off file checks.

Thanks about the hint of adding the file (and especially the contents); it seems to be much better solution than changing restore.php file. It is also really clever to have the extra file as it will not be opcached and will always run the latest code.

I hadn't had any complaints about APC code cache. Thanks for the tip :)

I've run into it maybe once or twice, but yes, its very rare to have APC set up not to check timestamps.

I'll test out your solution later today/tomorrow. I'm very happy that you shared the above code as it makes it possible to have the fix during the upgrade and not just after it -- which was my main issue when I was trying to test my code.

I have the same problem running Joomla on a docker container. I don't get how to fix the problem...

As a side note, I was hit by the same problem when updating some sites. However, the symptoms were not the same: instead of a Fatal error, the update "completed" with only a warning:

JInstaller: :Install: Can't find Joomla XML setup file.
Unable to detect manifest file.

The database was not updated however, and the "Collect data" plugin prompt was not shown. Using the Fix database feature allowed to, well, fix the database and get a seemingly working 3.5.0 install (which I don't think can be trusted for a real live site).

I think the failure may happen at different stages of the update process, depending on the opcache cache content at the time of update, and so many different errors can appear due to to this issue.

Cheers

Merged the restore_finalisation proposed by Nic with a couple of tweaks. Thanks guys (especially Nic!)

Thanks @wilsonge and @nikosdion

Hi All,

Tried to update from 3.4.8 to 3.5.1 this morning (with the Joomla updater component), and same problem still occurs. Disabling opcache allows upgrading fine.

In my case:
JInstaller: :Install: Can't find Joomla XML setup file.
Unable to detect manifest file.

Rgds

I too have the exact same issue when trying to update from 3.4.8 to 3.5.1. I have no APC cache installed. System is running PHP Version 5.4.45 and LiteSpeed V6.9. I have tried this using the Updater component, downloading the update package and installing via upload, as well as extracting the update package to a directory and installing from there.

All of these give the same results of:

JInstaller: :Install: Can't find Joomla XML setup file. Unable to detect manifest file.

@natiki No, that's a different issue. You are doing something that was never meant to work. Joomla! 3.5 update packages do not include a joomla.xml file in the root, meaning that you can NOT install them through the Extensions Manager. The official Joomla! download page has a MASSIVE yellow banner reading:

Updating to 3.5.x cannot be done by the extension manager.
You have to update via the Joomla! Update component or by manual action which is explained in our documentation:
UPDATING FROM JOOMLA! 3.4.X TO 3.5

Click the link on that banner for more information.

I believe that both you and @weeblr also made the same mistake. As of Joomla! 3.5 you CANNOT go to Extensions, Manage, Update to update Joomla!. You MUST go through Components, Joomla! Update.

I don't know if @wilsonge cares to elaborate on the reasoning behind this decision, but it has mainly to do with the extensions updater trying to use an old version of the database driver to run the database upgrade scripts of the new Joomla! version. This caused a massive problem with the update to UTF8MB4 (the old driver didn't support it), so the only possible course of action was to remove that update method which had been deprecated anyway since Joomla! 2.5.1 more than 3 years ago.

@nikosdion Update also failed when doing it via the Components, Joomla! Update. A suggestion would be NOT to include the download link in the update manager by itself, but to also add the disclaimer that the extension manager cannot be used to update J!.

So my issue still stands. I cannot upgrade from 3.4.8 to 3.5.1 via the update manager as it does not work with the above error message.

As I said, upgrading through the extensions update manager (Extensions, Manage, Update) WILL NOT WORK by design. You need to go to Components, Joomla! Update to update. If you did that and it downloaded the package, extracted it and then displayed this message your site is almost updated. First ask your host how to reset OPcache. Then go to Extensions, Manage, Database and click on the Fix button. This should complete the update process.

@wilsonge Can you please take a look at my instructions? I know that we discussed that this should work but I never got the chance to actually try it for myself :)

@nikosdion OPcache does not come up in PHP information when I look in the J! back end so as far as I can tell it is not installed / enabled.

There are other opcode caches such as APC. OPcache is available since PHP 5.5 (there was also a version for 5.4 but I've not seen it in the wild). APC was available up to and including PHP 5.6 if I recall correctly. So depending in your PHP version you may have APC, not OPcache.

@nikosdion No APC either.

@nikosdion Nicholas, please give us a bit of credit here. My message (as well as the one from @natiki ...I have tried this using the Updater component,...) was very clear about the fact this happen using the Joomla update component.
I know fairly well the extension manager cannot be used to update Joomla any longer.

So again, to restate: it appears that in some situation to be determined, but:

• on (multiple) otherwise long running and operational sites,
• successfully updated at each previous Joomla version for the last year (always using the Joomla update component, without having to disable opcache),
• using opcache - as a module, I'm on php 5.4.45 on those machines,

updating from 3.4.8 to either 3.5.0 or 3.5.1 can only be done if the opcache module is disabled.

Note that on those same machines, going 3.4.8 to 3.5.0 (with opcache disabled), then re-enabling opcache, lets you update from 3.5.0 to 3.5.1.

Those are VPS, I can easily switch opcache on/off, and so updating is not a real issue, but it maybe more problematic for others.

Rgds

The two ways that can happen with Joomla! Update are:

• Some kind of opcode caching
• Unwriteable files in the administrator/components/com_joomlaupdate or com_admin folder

I assumed that the latter is pretty obvious and you've already checked it. So, did you check it?

@weeblr Well said mate! I am exactly in the same boat:

• on (multiple) otherwise long running and operational sites,
• successfully updated at each previous Joomla version for the last year (always using the Joomla update component, without having to disable opcache, apc etc.)

I have very little control over the destination environment as it is shared hosting and not my own VPS.... I will have to go through Method A..C on https://docs.joomla.org/J3.x:Upgrading_from_Joomla_3.4.x_to_3.5 to see if I can get this going.

Guys, you're telling me that you do not have opcode caching, you do not have a CDN, caching proxy or anything in front of your site which might be serving an old cached reply, every file is writeable but your site magically decides to execute the old contents of a file, even though it's only first loaded AFTER it has been overwritten. If you were me what would you believe given this input?

using opcache - as a module, I'm on php 5.4.45 on those machines,

updating from 3.4.8 to either 3.5.0 or 3.5.1 can only be done if the opcache module is disabled.

If you were me what would you believe given this input?

The actual input is very believable. What you probably very quickly read through would not.

In addition to the above, and to reply to your question, the folders you mentioned are writeable. The download happens, as well as the decompression of the files. It's only after decompression that this error pops up and the site is half updated.

Rgds

[EDIT] @natiki indeed does not have opcache, and so I don't think their problem can be related to this specific issue. Mine is caused by opcache, seemingly, which is why I posted here, instead of opening a new issue

I don't think you read what I wrote ;)

Let's go again. The error you get can only happen if the old code of com_admin/script.php is executed. However, the com_admin/script.php file only runs AFTER the update is extracted. The question is, if you don't have opcode caching how is it even possible that code that's no longer on your server gets executed?

Moreover, I've seen the update work on several servers, from SiteGround and Rochen VPS, to cheap shared hosting and on all of my test and dev sites on Mac OS X, Linux and Windows. I've upgraded from 3.4.8 to 3.5.0, 3.4.8 to 3.5.1 and 3.5.0 to 3.5.1. If it was a systemic error in Joomla! Update or specific Joomla! versions combinations I should have bumped into this.

So far we've established that this issue does happen to those who have caching enabled. In another issue I've established that the code that was merged when this issue we're commenting on (gh-9515) was closed doesn't address all cases. To the best of my knowledge a solution was proposed and is being tested by @richard67 I can't find his PR, maybe he can point you to it.

So, if you DO have caching then YES, you are right, you are affected by this half-solved issue. But telling me that you have neither opcode caching nor unwriteable files but somehow you get old code no longer on your server executed doesn't make any sense. How exactly does PHP find the old code? Are you doing anything funky with your operating system's filesystem? Do you have some exotic load-balanced setup where files across all nodes are not replaced at the same time? Or is your server possessed? Because we've exhausted any reasonable explanation :/

To the best of my knowledge a solution was proposed and is being tested by @richard67 I can't find his PR, maybe he can point you to it.

The proposed solution which @nikosdion refers to was put by me in PR #9790 , but this PR I have closed meanwhile, see discussion there.

I have not deleted the branch so it can be repopened at any time.

So shall I reopen it, @nikosdion ? If so, then you should help me to convince @wilsonge to merge it by review, because I have not found a way to sucessfully test it here.

@nikosdion

The question is, if you don't have opcode caching

Nicholas, come on please. I have already told you multiple times that I DO have opcache running.

using opcache - as a module, I'm on php 5.4.45 on those machines,

Coming back to this, I saw that there are now other issues opened (#9788), that were not there when I initially created my post, so I think the problem is covered then?

@weeblr Argh! Between yours and @natiki's posts I got confused and thought that you also said that you don't have OPcode caching because you're in control of your VPS. Sorry, man. Yes, what you are experiencing with code cache enabled is what we were discussing with @richard67 last week

@richard67 It is a chicken and egg issue for the testers. If you try to sequentially test an update without the PR and with the PR you will always get a failure because the old (unpatched) file is still in the opcode cache. I worked around that with timestamp checks in my opcache configuration but when I do that I can no longer reproduce the original issue (since the new com_admin/script.php file has a different timestamp than the old file). @wilsonge would have to merge that code taking us on our word for it, without tests.

The process of testing itself will trigger the issue even with the patched files, unless you wait "long enough" (where "long enough" depends on your opcache configuration). But here's the catch: if the time limit on a server is too long (longer than between two Joomla! releases) AND the size of the opcode cache is large enough for all PHP files executed by Joomla! THEN we cannot programmatically fix this issue.

The best we could do would be busting the opcode cache in com_joomlaupdate when we are writing the restoration.php file. But even then we cannot be sure that the updated code is running. So we'd need to perform an AJAX request to a new task that doesn't exist in Joomla! 3.5.1 from our Javascript code. However that would also be unreliable if the Javascript code is itself cached because of a CDN, browser cache etc.

Basically, any way you dice it we're screwed. We cannot reset the opcode cache from a file that's already in the opcode cache because the cached version of the file doesn't tell the opcode cache to clean itself and recompile the file, seeing the code which clears the opcode cache.

The only solution I see is asking people to disable or clear their opcode cache before updating Joomla!. In fact, this is exactly how opcode caches are SUPPOSED to be used, i.e. disable cache – update code – clear cache – enable cache. The cache is meant to speed up the stable (deployed) state of your site, not the transient (deploying) state. And that's why I said last week that I consider this issue unsolvable. Any solution has as much chance to succeed as not implementing any solution at all :(

@nikosdion So I shall reopen my PR #9790 , right?

I was also elaborating with @mahagr on a different approach, see discussion in issue #9788 , you can check the code here: staging...richard67:fix-jupdate-opcache-2.

Maybe your code in my PR #9790 and these changes could (or should) be combined? Let us know your opinion, please.

Just a comment, I'm afraid I'm not enough into this to participate really, but:

We cannot reset the opcode cache from a file that's already in the opcode cache because the cached version of the file doesn't tell the opcode cache to clean itself and recompile the file, seeing the code which clears the opcode cache.

Can't this be worked around by having a "variable" filename? Instead of "script.php" (or restoration.php rather), use script.xxxx.php, where xxxx is a hash based on the newly installed Joomla version, hence reproducible and predictable, but guaranteed to not be cached already?
Or if you need multiple files, store them in a similar folder, so that they are all guaranteed to not be cached already?

Rgds

@richard67 This approach is the one that I told you wouldn't work because of the chicken and egg issue :(

@weeblr That's just one part of the problem. We are calling script.php from two places in Joomla! Update:

• restoration_finalization.php. This file name has to be constant otherwise restore.php won't find it and won't run it. We can't change restore.php's file name since that would cause the restoration to fail (the Javascript already loaded expects to load restore.php). We can't change the Javascript because it's both in the old version of Joomla! being updated and even if it weren't it might be cached by the browser. We can't bust the browser's cache without appending a media version query parameter which can only happen through the PHP code. The PHP code is, of course, cached with OPcache.
• The restoration model which is called after the end of the update. This is definitely cached in OPcache because we had to use the restoration model to start the update. So this cached code will try to load script.php. The contents of script.php are cached in OPcache so even if we had changed this file's contents with include 'script.123.php' our server still sees the old file which is the problem we were trying to solve.

And we're back in square one in both cases. DOH! >_<

This approach is the one that I told you wouldn't work because of the chicken and egg issue :(

@nikosdion You mean the other approach I linked above, not yours from my closed PR, right? So I shall reopen my closed PR with your approach? If so, please confirm, and if not, please let me know, too.

@richard67 Both approaches. In fact, it's the same thing. We are trying to clear the cache (fully or selectively) from code that's already cached. Since the already cached code doesn't include the instructions to clear the cache we can't clear the cache. If the cache wasn't enabled or we didn't have to clear it then we'd be able to clear it with either code approach BUT in both cases that would be needless.

When you realize what is going on you'll see that the only reasonable solution is asking people to use opcode caching as it was designed to be used: disable it before updating PHP code, re-enable it afterwards.

@nikosdion However, this is a one-off situation, right? as I experienced, once you reach 3.5.0, this problem is gone - as I gather the update script now has opcache_reset or similar, to make room for the new update files.

So this "disable or clear opcache" before you upgrade would only apply once to anyone upgrading from pre-3.5.0 to 3.5.0+.

@nikosdion So I should leave my PR closed and also close my issue? I have no problem with that, just let me know.

Just an off the wall comment..... How is it that Opcode caches are an issue "now"? Why has this not been a problem with the updater until now? I find it really hard to understand how the J! updater has become so susceptible to caching (opcode caches, proxies etc. etc.). Caching is a fact. It will always be there. A work around of getting people to turn opcode caching off is not going to hack it. Surely the fact that until 3.5.0 there was no issue indicates that whatever was done in those versions should be reverted to > 3.5.1?

It also seems incongruent that the updater is so flaky (this is not the first problem with the updater). I have been trying to think when ever I have had a WordPress updater issue and cannot think of one instance. It is problems like this with J! that still prevent me from either allowing clients to update their installs or allow automated tasks to do the same.

I have yet to do the manual steps as described by the wiki page, so hopefully that works. :-)

For me opcache has become an issue now and not earlier because my hosting provider started to offer it with PHP 7 and not for earlier PHP versions, and Joomla! supports PHP 7 since 3.5.0, so all the time before Joomla 3.5.0 I did not have PHP 7 with opcache in use.

@natiki The opcode cache has always been a problem, ever since APC's opcode caching had been available in PHP 5.3. It wasn't very frequent because it was an optional, external PHP module that had to be installed, configured and activated separately. Most hosts didn't.

The issue became more prominent when PHP 5.5 included Zend OPcache and enabled it by default. Many hosts didn't bother changing the default settings and that caused a lot of issues. However, at that point PHP 5.5 had a very low share among Joomla!'s user base and the problem wasn't visible.

Nowadays nearly HALF of Joomla! users are on PHP 5.5, 5.6 or 7.0 which include Zend OPcache and have it turned on by default. Moreover, there are many more context-lacking blog posts out there singing the praises of using OPcache with very aggressive caching settings to boost performance – but say nothing about the deployment of new code, assuming that they are targeting engineers who understand this stuff, not end users with a Joomla! site and too much time on their hands.

Regarding why the problem exploded now: I already answered that but you were too busy not reading my replies... Since Joomla! 3.5.0 the joomla.xml XML manifest file was removed from the root of the update package and I explained why. Using the extensions updater to update Joomla! was outright dangerous and something that no other software is doing because, simply put, no software engineer in his right mind would trust his old and potentially broken code to deploy the new code. Have you seen the problem yet? Any bugs in the extensions updater of Joomla! version X would prevent version X+1 from being installed. This bit Joomla! hard two times and @mbabker, @wilsonge and me were busting our asses trying to find a solution that didn't include instructions like "OK, you just need to open a Terminal and type this...". You can't ask Joomla! to go back there. It was the wrong approach and marked for death for three years.

Anyway. Now that the manifest is removed the script.php file had to be updated not to expect it. Due to caching the change wasn't loaded and you get an error.

HOWEVER this is NOT the first time script.php changes and caching causes updates to fail miserably. In fact, com_admin/script.php is changing in every single Joomla! release and it contains the list of obsolete files to be removed. By PURE LUCK none of the file deletions that never took place caused a massive "can't log into my site's backend" problem yet. They DO cause other strange issues, though. This is why the Extensions, Manage, Database, Fix button does something crazy: it runs script.php's function to remove obsolete files. We have already been in the Twilight Zone where a database fixing feature runs a script to fix filesystem issues because people use opcode caching outside its intended scope.

So, before saying that Joomla! Update was broken AFTER 3.5.1 please stop and do some fact checking and proper thinking. The fact is that Joomla! Update didn't address opcode caching BEFORE 3.5.1 but it does AFTER 3.5.1. You are asking Joomla! to revert two major fixes and remain forever broken instead of putting up with the last ever problem regarding core updates and opcode caching. My conclusion is that you're simply misguided.

@nikosdion I appreciate you taking the time to explain things. However what I would suggest is that you stop the personal attacks on people asking for help, trying to understand a problem or asking a question. Go back yourself and read the posts from both myself, @weeblr and others. Because it is abundantly clear that you also don't understand what is being said. I'll wait....

OK. I am not going to hijack this thread to refute all your inconsistencies, misinterpretations and misunderstandings. So take a deep breath and think about that next time before you put pen to paper and call people irresponsible and misguided.

I will watch with interest how there will no longer be any problems with the "Joomla Updater" and how "..version X would prevent version X+1..." in the "Joomla Updater" from working. ;-)

From one software developer/solution architect to another - remember to stop treating users like idiots - it ain't right. And sometimes the user ain't a dumb old user after all.

You see, all I ever asked of Joomla! was to leave me the hell alone. Unfortunately, people are dragging me into issues despite my wish. I am not PERSONALLY attacking you, I am just pissed off that for the 4th time in 7 days I have to explain how opcode caching works and why –barring a time machine– we can't fix this programmatically. And people think that it's OK to drag me into these conversations because 3 years ago I made the mistake of contributing my Joomla! Update code to Joomla! 2.5.1. I can't possibly be the only person who understands how a simple download-extract-archive-run-a-script trivial component works?!

I stand by my conclusion that your suggestion to go back to the way updates worked in 3.4.8 is misguided. It's not a personal attack by any means. If you are not fully informed you can be misguided. The same applies to me and everyone else. I wanted to fix that, that's why I spent half an hour of my day writing down the history of opcode caching and updates, as experienced by a developer who has been affected by this stuff and collecting hard data about it for over two years. I could simply respond with "You're wrong, it's been an increasingly common issue for 5 years that's only addressed since 3.5.1". Would that make you any wiser as to what was going on and why it's fixed now? It would only make me sound like a condescending asshole. I'd rather be the pedantic asshole instead of the condescending one. * shrug *

FWIW, regarding users being idiots... Not at all. Joomla! still has many bugs regarding caching (data and opcode). The opcode caching issue that affects Joomla! Update is also true with extension updates. However, extension developers like me work around it by exploiting the way the installer works (putting the extension's installation script in a new, randomly named folder, allowing us to bust the cache there and then). Other caching bugs are more subtle: try disabling an extension with conservative cache enabled and then use JComponentHelper in the front-end to check if the extension is enabled. Surprise! None of these issues make any sense to a user. What common sense tells them is a lie. It's very reasonable for me to assume that if you're bitten by one of these crazy issues you have no idea what's going on.

In so many words, I don't think the users are idiots, I think that they are using a buggy piece of software which makes them act like idiots unless they know how said software works inside out. It's not the users' fault that Joomla! does some things so unexpected as to completely throw off their reasoning and common sense. So yeah, I will assume that a user who tells me what they think happened instead of giving me just a cold account of steps followed and the output is involuntarily and unconsciously lying. In 99% of cases this is the case. That's different than assuming they are idiots. Do you remember the quote from the tV show Dr. House, MD? "Patients lie". When he elaborated he said pretty much the same thing. So please don't make assumptions about what I think of you. If I actually thought you were an idiot I wouldn't reply to you at all.

Finally, let me conclude this by making another observation having re-read your messages: even though you adamantly claim that you do not have any kind of opcode caching you are experiencing the opcode caching issue. If you take a REALLY HARD LOOK at your configuration you'll see that I am right. There are many opcode caches: APC, eAccelerator, XCache, OPcache and possibly something else I've not heard of. While the most common are APC (PHP 5.3, 5.4) and Zend OPcache (PHP 5.5, 5.6, 7.0) they are not the only ones. Look into your configuration and you'll see that my assumptions that you're inadvertently lying is correct. Also, if you are not using APC or OPcache I'm pretty sure you'll bump into a similar problem in the future.

Over and out. Have fun.

This caching issue just might rear its head again because Opcache and APC are not the only caches in use, so for to minimize the possibility, I suggest adding the well respected Doctrine Cache library to clear all opcode and web content caches on the server - Opcache, APCu, APC, Xcache, Wincache, Memcache, Redis, Varnish, etc. Then, the joomla update will be sure that no cached opcodes or web content will reach the user after it unpacks this archive and runs the new php code.

For those of you who are not able to turn off Opcache: I ran into this problem when upgrading to 3.5.1 from the option within the Joomla administrator panel. As it turned out, my hosting provider also offered the option to upgrade the Joomla software from their control panel and that somehow worked...

@Drakis The server control panel app installer probably ran php-cli from the CLI environment, without any opcache, or with an empty one, unzipped the new 3.5.1 files, and ran the joomla update php script, without ever touching the outdated stale opcache cache in the php-cgi environment... no problems