I have tested this item successfully on e05c153

Update method: Joomla Update Component

Upgrade path: 2.5.28 (clean with sample data) -> 3.5.0 beta 5 Update package (your patched version)
Result: Upgrade success, all tables converted to utf8mb4_unicode_ci

Upgrade path: 3.2.7 (clean with sample data) -> 3.5.0 beta 5 Update package (your patched version)
Result: Upgrade success. all tables converted to utf8mb4_unicode_ci

Upgrade path: 3.4.8 (clean with sample data) -> 3.5.0 beta 5 Update package (your patched version)
Result: Upgrade success, all tables converted to utf8mb4_unicode_ci

Note: in the 3.2.7 upgrade got a blank page after upgrade instead of the login panel, but login again and everything worked. The blank page seems not to be related to this PR.

Added test for Extension Installer method with patched Beta 5 to testing instructions.

@andrepereiradasilva Can you test Extension Installer method, too? I just have updated the testing instructions.

Look for bold text before the end to find the new test.

Let me know please if you get some SQL error or internal server error or not.

Corrected typo "Fux" button -> "Fix" button

Update method: Extensions -> install from URL (your patched URL)

Upgrade path: 2.5.28 (clean with sample data) -> 3.5.0 beta 5 Update package (your patched version)
Result: 500 error, no tables converted (no utf8 table).

Upgrade path: 3.2.7 (clean with sample data) -> 3.5.0 beta 5 Update package (your patched version)
Result: 500 error, no tables converted (no utf8 table).

Upgrade path: 3.4.8 (clean with sample data) -> 3.5.0 beta 5 Update package (your patched version)
Result: Upgrade success, but no tables converted (converted = 0).

Please note: when i made a patch zip with just the sql comment corrected it worked.
@richard67 Can you make a package of your patched version + the sql comments space corrected?

@andrepereiradasilva What means "the sql comments space corrected"? Means remove all comments from the sql file? Or just some spaces in the comments "-- " -> "--"?

The result as for 3.4.8 is expected up to now - it seems the package installer uses the old script.php.

@andrepereiradasilva Or maybe you can make a PR to my repo and branch for this PR with your changes in the SQL script?

this line https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_admin/sql/updates/mysql/3.4.0-2014-09-16.sql#L6 needs a space after --

--ALTER TABLE #__redirect_links MODIFY new_url varchar(255);
should be
-- ALTER TABLE #__redirect_links MODIFY new_url varchar(255);

the same think applies to the other sql for the other databases i think

ahhh these ... yes!!! I was in the other sql file in mind I add this to my pr and update my zip, stay tuned until i report here done.

Ahh or I modify the regex to not expect a space there after the "--".

or the two things ....

Hmm is not a regex and should do it right already ... I change the sql as you suggested, for fast solution.

is the zip ready?
(don't forget to commit the changes to the PR)

This PR has received new commits.

CC: @andrepereiradasilva

Zip is ready, same URLs. Just committed changes to here, too.

Update method: Extensions -> install from upload (your patched zip)

Upgrade path: 2.5.28 (clean with sample data) -> 3.5.0 beta 5 Update package (your patched version)

Result:

• Upgrade success.
• No tables converted. Only #__utf8_conversion in utf8mb4_unicode_ci (converted = 0).
• Pressed Fix, All tables in utf8mb4_unicode_ci (converted = 2).

Upgrade path: 3.2.7 (clean with sample data) -> 3.5.0 beta 5 Update package (your patched version)

Result:

• Upgrade success (blank page - see note).
• No tables converted. Only #__utf8_conversion in utf8mb4_unicode_ci (converted = 0).
• Pressed Fix, All tables in utf8mb4_unicode_ci (converted = 2).

Note: in the 3.2.7 upgrade got a blank page after upgrade instead of the login panel, but login again and everything worked. The blank page seems not to be related to this PR.

Upgrade path: 3.4.8 (clean with sample data) -> 3.5.0 beta 5 Update package (your patched version)

Result:

• Upgrade success.
• No tables converted. Only #__utf8_conversion in utf8mb4_unicode_ci (converted = 0).
• Pressed Fix, All tables in utf8mb4_unicode_ci (converted = 2).

I have tested this item successfully on 42e6bcd

As results above.

so the 500 error has really the missing space in the sql comments!!

@andrepereiradasilva This is the expected result for the Extension Installer method, so your test result is still good.

Thanks for testing.

c.c. @wilsonge For the long term we should keep this in mind and see why the "--" comments caused a server error 500 and the "-- " comments do not.

And the still open point to be solved with another PR if necessary is that after update with Extension Installer, the conversion has to be done with the "Fix" button. Can it be because the old "script.php" is loaded?

More testers please!!! This should go into 3.5.0 RC.

BTW, meanwhile discovered why the 3.2.7 was returning blank page after update.
Just to inform if this problem happens to anyone else.

If seems in PHP 5.6.x the iconv_set_encoding function throws a deprecated notice (http://php.net/manual/en/function.iconv-set-encoding.php), and because of that was generating some errors in the error log and returned a blank page after update.

PHP message: PHP Deprecated:  iconv_set_encoding(): Use of iconv.internal_encoding is deprecated in /path/to/joomla-327/libraries/joomla/string/string.php on line 27
PHP message: PHP Deprecated:  iconv_set_encoding(): Use of iconv.input_encoding is deprecated in /path/to/joomla-327/libraries/joomla/string/string.php on line 28
PHP message: PHP Deprecated:  iconv_set_encoding(): Use of iconv.output_encoding is deprecated in /path/to/joomla-327/libraries/joomla/string/string.php on line 29

Just by removing the deprecated log from php configuration: error_reporting = E_ALL & ~E_DEPRECATED and restarting php, the 3.2.7 update worked fine also.

Ya, 3.3.4 was the first release fully tested with PHP 5.6 (including dealing with those deprecations); 2.5.28 also got the needed patch before that last release. So that'd be something to keep in mind.

So in theory: update from 3.0.x to 3.3.3 to higher versions in PHP 5.6 = blank page if PHP deprecated log active?

Good possibility if the log messages are being echoed out. If you've got a combo where you have E_DEPRECATED being logged but display_errors off (truthfully I don't even think you can do that with Joomla because of the stuff run in the app bootstraps) it could work.

My blank page scenario in 3.2.7 upgrade (php-fpm configuration)

php_admin_value[log_errors]         = on
php_value[error_reporting]          = E_ALL
php_value[display_errors]           = off

Joomla error reporting: System default

My upgrade success scenario in 3.2.7 upgrade (php-fpm configuration)

php_admin_value[log_errors]         = on
php_value[error_reporting]          = E_ALL & ~E_DEPRECATED
php_value[display_errors]           = off

Joomla error reporting: System default

In other words the errors were not being echoed out

either way the upgrade was successfully in both cases, just got a blank page in first scenario.

Like I said, Joomla changes some stuff during the bootstrap process...

https://github.com/joomla/joomla-cms/blob/3.2.7/administrator/includes/framework.php#L51

ok i see.

Well don't want to hijack this PR more with this, just wanted to post that information here for anyone with the same problem.

More testers please!!!

maybe adding the golden shiny 3.5.0 blocker label will help ;)

Can I add it myself?

Done

I have tested this item successfully on 42e6bcd

Test OK

Some test notes:

Joomla_3.5.0-beta5-Beta-Update_Package.zip

• In the initial test, I have manually downloaded and updated to Joomla_3.5.0-beta5-Beta-Update_Package.zip

• In the log/joomla_update.php

  #
  #<?php die('Forbidden.'); ?>
  #Date: 2016-03-08 18:36:05 UTC
  #Software: Joomla Platform 13.1.0 Stable [ Curiosity ] 24-Apr-2013 00:00 GMT

  #Fields: datetime priority clientip category message
  2016-03-08T18:36:05+00:00 INFO 127.0.0.1 update COM_JOOMLAUPDATE_UPDATE_LOG_DELETE_FILES

• In Extensions -> Manage -> Database

  Warning: Database is not up to date!

  The Joomla! Core database tables have not been converted yet to UTF-8 Multibyte (utf8mb4).

• Fix, and it worked OK

Joomla_3.5.0-beta5-Beta-Update_Package_test1.zip

• In the log/joomla_update.php

  #
  #<?php die('Forbidden.'); ?>
  #Date: 2016-03-08 18:55:16 UTC
  #Software: Joomla Platform 13.1.0 Stable [ Curiosity ] 24-Apr-2013 00:00 GMT

  #Fields: datetime priority clientip category message
  2016-03-08T18:55:16+00:00 INFO 127.0.0.1 update COM_JOOMLAUPDATE_UPDATE_LOG_DELETE_FILES

• In Extensions -> Manage -> Database

  Database table structure is up to date.

  Other Information

  Database schema version (in #__schemas): 3.5.0-2016-03-01.
  Update version (in #__extensions): 3.5.0-beta5.
  Database driver: mysqli.
  93 database changes were checked successfully.
  145 database changes did not alter table structure and were skipped.
  

  ---

  _{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/9332.}

I have tested this item successfully on 42e6bcd

@richard67 I have just completed a series of tests as per your instructions with mixed results, because I only got good results when using your packages I am marking this as Successful

Update method: Joomla Update Component

Upgrade path: 2.5.28 (clean with sample data) -> 2.5.x to 3.5.0-beta5: https://downloads.joomla.org/updates/cms/test/list_test_25to3x.xml
Result: Fail: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '--ALTER TABLE #__redirect_links MODIFY new_url varchar(255)' at line 5 SQL=-- -- The following statement has to be disabled because it conflicts with -- a later change added with Joomla! 3.5.0 for long URLs in this table -- --ALTER TABLE #__redirect_links MODIFY new_url varchar(255);
With multiple 500 errors across many pages, both in the front and back end. Database tables all utf8_general_ci

I performed this test twice and I had the same result both times.

Upgrade path: 3.4.8 (clean with sample data) -> 3.x to 3.5.0-beta5: https://downloads.joomla.org/updates/cms/test/list_test.xml
Result: Upgrade success. all tables converted to utf8mb4_unicode_ci

Upgrade path: 2.5.28 (clean with sample data) -> 2.5.x to 3.5.0-beta5 + this PR: http://test5.richard-fath.de/list_test1_j25.xml
Result: Upgrade success, all tables converted to utf8mb4_unicode_ci

Update method: Extensions -> install from URL

Upgrade path: 2.5.28 (clean with sample data) -> 3.5.0 beta 5 Update package http://test5.richard-fath.de/Joomla_3.5.0-beta5-Beta-Update_Package_test1.zip

Result: Upgrade partial Success, The Joomla! Core database tables have not been converted yet to UTF-8 Multibyte (utf8mb4). Clicking Fix solves the issue leading to Upgrade Success.

Upgrade path: 3.4.8 (clean with sample data) -> 3.5.0 beta 5 Update package (your patched version)
Result: Upgrade partial Success, The Joomla! Core database tables have not been converted yet to UTF-8 Multibyte (utf8mb4). Clicking Fix solves the issue leading to Upgrade Success.

I have tested this item successfully on 42e6bcd

Tested only for joomla update component (both URLs).

So all tests as expected @richard67 right? RTC?

Yes, even if I am not happy with my solution, is a kind of hack. But it works for now. Later the database driver's splitSql function has to be improved regarding comment handling. May @wilsonge or other maintainer reject it if he thinks my solution is bad.

... at least the part that resolves the 500 error is very important!

I don't like it - but what needs to be done....

Yeah, better this solution than no solution! Thanks @richard67.