Issue confirmed i am getting it as well

@gwsdesk @parthlawate can you have a look into this file? It should look like: https://github.com/joomla/joomla-cms/blob/3.4.0-beta2/libraries/cms/version/version.php

@zero-24 No pull id yet? Since I do not see it in Patch tester component?

Updating beta versions has never been supported.

beta is ONLY intended for testing and there is no upgrade path from Beta.

Testing update from 3.3.6 to beta 2 correctly shows the version as beta 2

Closed

Re-opening since the WSOD (White Screen Of Death) occurs when updating from Joomla 3.3.6 to Joomla 3.4.0-beta1. The error JHtmlBehavior::formvalidator not found. is shown when going from Joomla 3.3.6 to Joomla 3.4.0-beta2.

Under investigation but it appears to be tied to APC caching.

@parthlawate Can you confirm/check if the server you tested it on uses APC?

FYI
I did an upgrade without APC and no WSOD

On 4 February 2015 at 16:53, RolandD notifications@github.com wrote:

Re-opening since the WSOD (White Screen Of Death) occurs when updating
from Joomla 3.3.6 to Joomla 3.4.0-beta1. The error
JHtmlBehavior::formvalidator not found. is shown when going from Joomla
3.3.6 to Joomla 3.4.0-beta2.

Under investigation but it appears to be tied to APC caching.

@parthlawate https://github.com/parthlawate Can you confirm/check if

the server you tested it on uses APC?

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

—
Reply to this email directly or view it on GitHub
#5960 (comment).

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

Brian,
As discussed with Roland on Skype we are removing entirely APC from our
testing server (the one Roland used as well for testing) we use for
this (remove from PHP.ini and the install itself) and will re-test
tomorrow (here 00.06 am) and will post back results after done. @Roland
As soon as we are done recompiling tomorrow I will post back to you. We
are removing APC since we think it is APC related but we want to make
sure it is as such. However if IT is APC related we might be in trouble
either because APC is configured incorrectly or otherwise runtime
issues. If so we as Joomla will face many issues since APC is so widely
used (!) ut lest's not ring alarms before we have fire?

Leo
On 2/4/2015 11:55 PM, Brian Teeman wrote:

FYI
I did an upgrade without APC and no WSOD

On 4 February 2015 at 16:53, RolandD notifications@github.com wrote:

Re-opening since the WSOD (White Screen Of Death) occurs when updating
from Joomla 3.3.6 to Joomla 3.4.0-beta1. The error
JHtmlBehavior::formvalidator not found. is shown when going from Joomla
3.3.6 to Joomla 3.4.0-beta2.

Under investigation but it appears to be tied to APC caching.

@parthlawate https://github.com/parthlawate Can you confirm/check if

the server you tested it on uses APC?

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

—
Reply to this email directly or view it on GitHub

#5960 (comment).

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

—
Reply to this email directly or view it on GitHub
#5960 (comment).

Leo Lammerink
MD GWS - Enterprise Ltd
Skype: gwsgroup
www.gws-desk.com http://www.gws-desk.com | www.gws-host.com
http://www.gws-host.com | www.gws-deals.today http://gws-deals.today

@gwsdesk Indeed not ringing any alarms, just stating the progress of our investigation. It is the same reason I asked Parth for his configuration.
Let's see what tomorrow brings.

Hi.. No there was no APC .. infact i did not get a white screen of death. Just a error that the package was corrupt and the update apparently failed..

Just tried again later.. Got the same package corrupt error but when i refreshed the version showed correctly as Beta 2

@all The PR that changed the formvalidation to formvalidator is #5626 which was truthfully tested in a dev environment with no opcode cache. I will try to test it with APC and OP cache

@brianteeman Can you please stop closing issues when you (Mr . Brian Teeman himself!) cannot reproduce an issue? Are you the Messiah of testing? If so I will ask next time permission to Mr. Teeman to "test" ? Jeezzzzz Are you here the ""UPPER GOD" ? We all have to adhere to your opinion or otherwise you close Issues as you wish? If so I stop testings (!)

Your opinion is only the right opinion? (phew....)

He closed it based on the available information at the time. The original post states that the issue was found while testing a beta 1 to beta 2 update, which is unsupported. Would you mind editing the original post to update it with more accurate information based on what has been found in testing?

The issue was closed because the issue as stated originally was for
something that is not and has never been supported - the update of a beta
version.

I never said I could not reproduce the error. I didnt even try because the
issue as reported is not something that is supported

On 4 February 2015 at 17:39, Leo Lammerink notifications@github.com wrote:

@brianteeman https://github.com/brianteeman Can you please stop closing
issues when you (Mr . Brian Teeman himself!) cannot reproduce an issue? Are
you the Messiah of testing? If so I will ask next time permission to Mr.
Teeman to "test" ? Jeezzzzz Are you here the ""UPPER GOD" ? We all have to
listen too or you close Issues as you wish? If so I stop testings (!)

—
Reply to this email directly or view it on GitHub
#5960 (comment).

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

@mbabker read JBS chat and others . I do not need to whip ego's . I have spend over 5 hours on this so please read properly otherwise let me out of here.... You guys are so encouraging in having people testing your shit!

Than don't close it Mr. Teeman.You have now managed to get me completely off this Github and Testing....... Au revoir Bug Squad

Based on Brian Teemans's approach I resign from Joomla BS

On the same server and domain - wiped between tests

Upgrading a clean Joomla 3.3.6 site with cache DISABLED to beta 2 - No problem

Enable Cache_lite and Progressive Caching - Upgrade fails

Fatal error: Cannot use object of type stdClass as array in libraries/cms/component/helper.php on line 433

https://www.dropbox.com/s/ik6bfrq48botjrp/cachelite.mp4?dl=0

Actually I am not 100% certain that the upgrade failed. Reloading the site shows it to be on 3.4beta2 but that there are still database changes to be applied - hope that info helps

From a simple search
JHtml::_('behavior.formvalidator');
is NOT used in administrator/com_installer and com_joomlaupdate, so how this code conflicts with the update process?

@dgt41 I don't think it has anything to do with the formvalidator, it just happens to stop there.

@roland-d but formvalidator didn’t exist in 3.3.6, so where is the call?

@roland-d Also why the updater doesn’t purge the cache before initiating the update process ?

@dgt41 I have not been able to look any deeper but I am quite convinced it has to do with server caching. This is a cache the updater can't purge I think. The WSOD isn't really a white screen but a 500 Internal Server Error, I have the actual error but can't make head or tails from it

can you sent it at d.grammatiko - gmail.com?

    /**
     * Purge all cache items.
     *
     * @return  boolean  True if successful; false otherwise.
     */
    public function purge()
    {
        $cache = JFactory::getCache('');

        return $cache->gc();
    }

Shouldn’t we run this at https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_joomlaupdate/models/default.php#L538

@nikosdion any thoughts on this?

This issue is not related to my code. Please do not drag me into this. Thanks.

$cache->gc() only runs the garbage collector and thus removes cache entries which timestamp are out of date, but that does not clear your cache.

@Hackwar Yes you are right, I realize that later on when I went over all the functions on cache folder. Never the less, I think this might be a good approach (besides this particular problem and maybe for 3.5?) :
1. When the update process is initiated, site should be set on offline mode
2. Clean cache (if cache is not file ?) as a first step on finaliseUpgrade()
The second one requires a function to enable flushing the cache

As far as I can see, there is no way to purge the cache unless its file based, since we don't know the cache IDs and without those, that data is unreachable.

@Hackwar Hannes I assume that coming up with a helper that does exactly that won’t be the hardest think. After all, there is at least one module in the directory that does exactly that

No, it doesn't. The cache IDs of our caching system are depending on a lot of different variables, which we can't know and thus can't generate existing cache IDs. Last time I looked, I couldn't find a method in memcached to retrieve a list of all cache IDs, which means that we can't purge the cache without knowing the IDs beforehand and thus it is not possible.

So I tried to do an upgrade on MAMP with OPC turned on but the update went without a hitch. Anybody has any reproducible steps on this for a localhost system?

@roland-d OP is just opcode cache, you need to test it with user cache as well e.g. APCu

I showed in my video that it is 100% reproducible on localhost with mamp
just by turning on cache

Thanks guys, having a real Monday here, glad the day is almost over :P Going to check.

Closing this thread as we have a PR in #6031.