@nikosdion Sorry, but I just tested as desribed above in testing instructions and it failed here, i.e. problem as described in issue #9788 still remains. Using the "Clear cache button" of the update component did not help.

Can you check if I maybe have some mistake in my testing instructions? Or if you have a bit time test yourself, or check what the problem could be?

@brianteeman Sorry I had forgotten to select category. But shoud it not be "Updating" instead of "Installation" for Joomla! Update component stuff?

I think you have an unsolvable chicken and egg issue. Your current Joomla! site has a restore_finalisation.php file which is cached by opcache. It is overwritten during the update but it's not loaded because you've misconfigured opcache. As a result the updated code cannot run. Barring the invention of a time machine there is nothing you can do here.

FWIW, you just need to set opcache.validate_timestamps=1 in your php.ini to tell OPcache to check the timestamps of files. This is how you fix this problem. Do note that all over the Internet you'll see people saying to set it to 0 on production servers because you know the files never change. Here's the catch: they are talking about production servers with a tested deployment process that clears the OPcache at the end. When we're talking about self-updating mass distributed software such as Joomla! or WordPress you CANNOT possibly believe that the files never change, therefore you MUST use validate_timestamps to 1.

In so many words, do not try to programmatically fix bad server configurations. Instead, use your brain to understand why your server configurations are bad considering the kind of application you're deploying to them.

Finally, a note on the test instructions. You do not need PHP 7 to test opcache. It's been included with PHP itself since PHP 5.5.

@nikosdion Acording to recommendations by my hosting provider, I had all the time "opcache.validate_timestamps = 2;".

I do not really get why they said 2 and not 1 but both should resolve to true, and when I checked opcached files it really seems to apply the opcache.revalidate_freq = 180; = 3 minutes. But I just tested with 1 instead of 2 and this does not change anyhting.

So it seems it is not as you described.

I'm no longer sure that the issue and the alleged cause are related at all. I've followed 3 links deep to see your error report and there is no compelling evidence that opcache is related to your issue. I think you have a different issue altogether. Sorry, I can't help with it.

@nikosdion No problem, not wanna consume too much of your time.

But I think it is opcache related at least in the way that when I exclude only the administrator/components/com_joomlaupdate and nothing else from opcache by using a blacklist file, then the problem disappears and all works fine.

This just for your info, if you are interested at least.

@Kubik-Rubik Because I constantly can reproduce the problem desribed in issue #9788 and Joomla! Update doesn't work on 3.5.0+ with PHP 7 and opcache in the support forum on my 1&1 shared hosting, I ping you.

Maybe the problem could be caused by 1&1's shared hosting's default file and folder permissions (604/705)?

As I described, all is fine as soon as I exclude administrator/components/com_joomlaupdate from opcache using a so-called blacklist file.

So at my 1&1 shared hosting there is definitely a problem with PHP7 + opcache and Joomla! Update component of 3.5.1 and earlier.

The timestamp check will work as long as the timestamps of the modified files are different to the timestamps of the files already in opcache. The file that gives you problems is restoration.php which holds the encryption keys for the browser <--> restore.php communications. If an old version is cached the wrong key is used by restore.php vs the one used by the browser. The thing is that this file is generated right after the download and right before we start extracting files. So I have two problems with your recounting of the story:
Since the timestamp is different, had OPcache checked it the new file would be recompiled and you wouldn't have this problem.
Since OPcache's maximum cache time is 3 minutes, waiting 3 minutes between installing version 3.5.1 and upgrading to 3.5.2-dev would bust the cache.
You say that neither happens which means that you're either wrong about the configuration changes you made or you're editing the wrong php.ini file. And since I do have opcache enabled on my development server (with timestamp checks enabled and cache time 180 seconds) and didn't have any problem updating Joomla! or any problems developing my extensions I do think that the problem lies in your configuration files. Either that or PHP is drunk. I don't know :p

@nikosdion Well the php ini which I change is the right one, I can see the settings in backend. And I always had more than 3 minutes between installation of 3.5.1 and starting the update, so that is not the problem. But maybe it is something caused by specials from my shared hosting provider, 1and1, so I pinged Viktor on that.

Other question: If your changes I put into this PR here are OK and you say they should be merged anyway, regardless if they solve my problem or not, because they make sense, shall I change testing instructions to "to be merged by review" and decouple this PR from my issue?

Possibly a plesk issue then

On 7 April 2016 at 17:28, Richard Fath notifications@github.com wrote:

@nikosdion https://github.com/nikosdion Well the php ini which I change
is the right one, I can see the settings in backend. And I always had more
than 3 minutes between installation of 3.5.1 and starting the update, so
that is not the problem. But maybe it is something caused by specials from
my shared hosting provider, 1and1, so I pinged Viktor on that.

Other question: If your changes I put into this PR here are OK and you say
they should be merged anyway, regardless if they solve my problem or not,
because they make sense, shall I change testing instructions to "to be
merged by review" and decouple this PR from my issue?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#9790 (comment)

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

Hmm, could be also the case.

@nikosdion Shall I close this PR now, or do you want me to leave it open and change description so it is decoupled from my issue, and change testing instructions to "to be merged by review", because you recommend your changes to be merged anyway?

There is always a way to work around this issue -- even if we cannot fix the issue for current version, we can always add opcache clean just before the file gets loaded and have it to work next time.

So the question is: if you install yet another version after the fixed one, would it work that time?

@mahagr No, see my testing instructions. They already describe this, update a fixed version by a newer fixed version.

What i would do is actually revert the old code as the new code has issues in it (busy sites will end up loading opcache before files get copied) and just use

// Compile installer file into bytecode cache
if (function_exists('opcache_compile_file')) {
    opcache_compile_file($filePath);
} elseif (function_exists('opcache_invalidate')) {
    // PHP <5.5.5
    opcache_invalidate($filePath, true);
} elseif (function_exists('apc_compile_file')) {
    // PHP 5.4
    apc_compile_file($filePath);
}

before loading the file.

PS. I'm using that code myself (elsewhere) and it works even with no file checks. Similar code is also being used in twig & others on dynamically generated php files.

The key is still to clear cache also after installation.

@mahagr "before loading the file." means where would you insert your code?

Basically I would do 2 things:

1) revert all the current changes so that opcache clear happens after full installation (including deleting old files etc).
2) put my code before you call require_once ($filePath); but after you know the path. You can even put it just before the line.

The fix would apply not on the first installation attempt but the second.

@mahagr OK, I'll try later and tomorrow.

... or tomorrow I meant.

@mahagr I tried that locally here, means not committed to this PR, exactly as you advised, but it does not help anything. I also tried to use your code in restore.php, function masterSetup, for the $setupFile, but this also did not help. Problem is I neither have something in error log of PHP (switched on error loggin into file and set error_erporting to E_ALL in my php.ini) nor something in the opcache log which I enabled into another log file.

I am short before giving it up, because in principle the issue is not a problem for me. I disable opcache on my real site anyway for the "administrator" folder and all below that, so opcache is used for my frontend only, and then the issue does not occur for me.

It really can be related to specials of my hosting provider's shared hosting so maybe it is also not an issue for most of the others.

I have tested this item unsuccessfully on 7e3de7b

Does not work yet as it is now, so I set my own test result to failed in order to avoid other wasting time with testing.

Why dont you close it for now and reopen it when at least you can
successfully test it

On 7 April 2016 at 23:05, Richard Fath notifications@github.com wrote:

I have tested this item [image: ] unsuccessfully on 7e3de7b
7e3de7b

Does not work yet as it is now, so I set my own test result to failed in

order to avoid other wasting time with testing.

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/9790
https://issues.joomla.org/tracker/joomla-cms/9790.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#9790 (comment)

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

Because @wilsonge closed the issue and wanted us to continue the topic here, so I was not sure if I should close it. And maybe discussion continues here and a solution is provided by someone.

But feel free to close it if you want, I would not be angry.

Maybe there is something else we are missing? I may have some time tomorrow to test if I can make up something.

We can close this one and reopen the original issue. As long as the discussion is in one place and not 2/3 :P

Done

Closing because this PR does not help. @mahagr If you can find out something would be really helpful. You could report that in the issue #9788 , which I will reopen now..