I'm assuming based on your other post that when you say manual upgrade you mean the non-standard method of just unzipping 3.2.1 on top of 2,5.17

As thats not a standard or recommended way of performing an upgrade I fail to see the need for this

When your website is not allowed to perform download because the "allow_url_open" is OFF or the firewall forbid that, you need to do the unzip of 3.2.1 on top of 2.5.17.
Till the version 3.1.x, this procedure works but fails with 3.2

I have just posted the Bugtracker [#33177] that explain all that with the different steps to reproduce the unzip of 3.2.1 on top of 2.5.17 top procedure

No you dont need to do that. You use the documented procedure
http://docs.joomla.org/J2.5:Upgrading_from_an_existing_version#Method_B_-_Install_Method

In my case, I have used the Method C described in this document by applying the Unzip on top of the old version and in this case, it fails as described in my Bugtracker 33177
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=33177&start=0

This is the reason why I have tried to fix that to have an alternative working solution.

Again, you're completely masking an error situation here. I get what you're trying to do, but again, just blindly ignoring the error is not the right solution to me.

Here I don't really hide the error but let the code working like with the "DB legacy mode" enabled to avoid throwing the exception.
In this case, the "rows" value is set to FALSE when the "DB Legacy mode" is enabled like with J2.5

So I just made the code working like in J2.5 with the "db legacy" enabled.

This is because the JError::$legacy is removed in J3.2 that you have this issue.
The code is originally developed with JError::$legacy = true and therefore now, it must catch the exception to make it work like in legacy mode.

This peace of code just make it compatible with the legacy mode enabled (true).

This PR is against master? Should be staging.

I don't know which is the difference between master and staging.
Based on my knowledge the master correspond to the J3.2 (latest version).

The fix must be done in J3.2 and further release.
It does not affect the J2.5 that use the legacy mode.

I don't know which is the difference between master and staging.
Based on my knowledge the master correspond to the J3.2 (latest version).

The fix must be done in J3.2 and further release.
It does not affect the J2.5 that use the legacy mode.

The current developing branch is staging. There is a script (Jenkins -> build.joomla.org) which tests changes to this branch and merges it to master if it passes all tests. This is why all PRs need to go to staging.

The J2.5 branch works different. The staging/master thing only applies to J3.2.

Can you redo your PR to target the correct branch?

@mbabker Any clue why jissues-bot didn't catch this?

I can redo it but you can also do it and make reference to this PR for the history of the comments because this PR is also attached to a Bug tracker.

I can redo it but you can also do it and make reference to this PR for the history of the comments because this PR is also attached to a Bug tracker.

You should be able to close this one, reopen a new one and select the correct target branch (staging) in the form.
In the new PR you can then add a comment to reference this PR and in the tracker item you can do the same. That shouldn't create any problem and makes it much easier for us to merge your PR if approved.

I made some tweaks to the underlying code in the issue tracker that
triggers that check which isn't totally testable until it's on a live site;
it started working again last night (a little too well... LOL).

On Fri, Jan 24, 2014 at 5:09 AM, Thomas Hunziker
notifications@github.comwrote:

I don't know which is the difference between master and staging.
Based on my knowledge the master correspond to the J3.2 (latest version).

The fix must be done in J3.2 and further release.
It does not affect the J2.5 that use the legacy mode.

The current developing branch is staging. There is a script (Jenkins ->
build.joomla.org) which tests changes to this branch and merges it to
master if it passes all tests. This is why all PRs need to go to staging.

Can you redo your PR to target the correct branch? And I guess the others
are wrong as well then.

@mbabker https://github.com/mbabker Any clue why jissues-bot didn't
catch this?

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

On Bakual request, I have move the PR to
#2839

@jms2win Thanks