User tests: Successful: Unsuccessful:
Pull Request for Issue #9402.
Fixes upgrade regressions introduced by #9402. Since the manifest is no longer in the root, the finaliseUpgrade
step needs to now look for the manifest in the manifests folder. Also in testing, I got an error at the end of the upgrade which basically read "cannot copy manifest from administrator/manifests/files/joomla.xml to administrator/manifests/files/joomla.xml" so I dumped the step that tries to copy it (at this point we're on the new manifest anyway).
On a 3.4 or 3.5 install set the custom testing URL to https://www.babdev.com/updates/joomla_list.xml and run the update.
I did NOT test this in a scenario where someone may have multiple files extensions installed. That needs to be tested, and if this fails then finaliseUpgrade()
needs more tweaks (I'm already trying to change the method to be less reliant on the lookup mechanisms and just inject the data in, stay tuned to see if it's needed).
Status | New | ⇒ | Pending |
Labels |
Added:
?
|
Labels |
Added:
?
|
@mbabker I just tested with updating a 3.4.8 to 3.5.0 RC 2 via Testing channel and could reproduce the problem, and when checking for database schema 13 probelsm and 1 sql error were shown, which has shown me that the script.php which includes schema updates and the utf8(mb4) conversions did not run.
Then I tried upgrading another copy of same 3.4.8 via your custom url.
Result: The error with the manifest file was not shown, so I thought first all is fine and wanted to set test result here to success.
But then I thought I better check db schema, and I saw the same 13 problems and 1 error as for the 1st test.
So it seems something breaks before script.php is executed?
I checked then my php error log file where i let php log errors to on my testing sited, and found following:
Can you check? And does this information help you somehow?
I have tested this item successfully on bdbf204
Only tested update from 3.4.8 to your custom 3.5.0 RC3 using your custom URL in the updater.
@andrepereiradasilva Did you check "Extensions -> Manage -> Database" at the end of your successful test? Mine was not successful. Your result makes me doubt I maybe made a mistake so I will test again Michael's custom URL.
I did NOT test this in a scenario where someone may have multiple files extensions installed. That needs to be tested, and if this fails then finaliseUpgrade() needs more tweaks (I'm already trying to change the method to be less reliant on the lookup mechanisms and just inject the data in, stay tuned to see if it's needed).
how can we test this scenario?
Failed again for me on a db not supporting utf8mb4. Now I will test with newer server supporting utf8mb4, If this is working we know that for some reason the create table statement in administrator/components/com_admin/sql/updates/mysql/3.5.0-2016-02-26.sql has not been downgraded from utf8mb4 to utf8 because the db driver being loaded still is the old one, or script.php used it the old one, or whatever else runs the schema updates is not including the utf8mb4 changes from 3.5 yet.
my test server info is:
Database Version 5.5.5-10.0.24-MariaDB
Database Collation utf8_unicode_ci
Database Connection Collation utf8mb4_general_ci
PHP Version 5.6.18
Fails also on a db supporting utf8mb4, with same problems shown:
Database schema version (3.4.0-2015-02-26) does not match CMS version (3.5.0-2016-03-01).
Database update version (3.0.3 ) does not match CMS version (3.5.0-rc2).
Table 'j3ux0_session' does not have column 'session_id' with type varchar(191). (From file 3.5.0-2015-07-01.sql.)
Table 'j3ux0_user_keys' does not have column 'series' with type varchar(191). (From file 3.5.0-2015-07-01.sql.)
Table 'j3ux0_contentitem_tag_map' should not have index 'idx_tag'. (From file 3.5.0-2015-10-26.sql.)
Table 'j3ux0_contentitem_tag_map' should not have index 'idx_type'. (From file 3.5.0-2015-10-26.sql.)
Table 'j3ux0_utf8_conversion' does not exist. (From file 3.5.0-2016-02-26.sql.)
Table 'j3ux0_redirect_links' should not have index 'idx_link_old'. (From file 3.5.0-2016-03-01.sql.)
Table 'j3ux0_redirect_links' does not have column 'old_url' with type VARCHAR(2048). (From file 3.5.0-2016-03-01.sql.)
Table 'j3ux0_redirect_links' does not have column 'new_url' with type VARCHAR(2048). (From file 3.5.0-2016-03-01.sql.)
Table 'j3ux0_redirect_links' does not have column 'referer' with type VARCHAR(2048). (From file 3.5.0-2016-03-01.sql.)
Table 'j3ux0_redirect_links' does not have index 'idx_old_url'. (From file 3.5.0-2016-03-01.sql.)
The Joomla! Core database tables have not been converted yet to UTF-8 Multibyte (utf8mb4).
It seems that the schema updates did not run at all, because 1st file mentioned in problems is "3.5.0-2015-07-01.sql", which is not one of those we made some utf8mb4 table or so.
So it is not related to utf8mb4 stuff.
Also same 3 PHP errors "Undefined variable: manifestClass" as shown in my comment above.
Maybe it is related to caching?
But the other test was on a system with Joomla! cache off. also no opcache or so for PHP, so only js and css in browser are cached.
@richard67 are you sure you're using "Custom URL" with Michael custom package (https://www.babdev.com/updates/joomla_list.xml) in joomla update channel?.
I just tested again, this time from 2.5.28 to Michael patched 3.5.0 RC 2 and worked fine again.
Note: for this test i created a custom update channel for this test since Michael update channel doesn't provide an update path for 2.5 (used https://raw.githubusercontent.com/andrepereiradasilva/update.joomla.org/master/www/core/test/list_test.xml)
@andrepereiradasilva Sure I did, as I wrote. Just have changed some stuff in my test environment which also could have caused this, will report back here in a few minutes.
No change here, tested again on clean system, with Michael's custom URL as before, and still have same problem (3 PHP errors "Undefined variable: manifestClass") as described in comment to my test result.
What causes the PHP errors are the statements like "if ($manifestClass && method_exists($manifestClass, ...))", because $manifestClass is not set here for some reason.
So one useful thing could be maybe to change the "if ($manifestClass && ..." to "if (isset($manifestClass) && ...", but am not sure. @mbabker can you check?
Another thing is I have to find out why the variable is not set. Most likely the reason is that the manifest file could not have been copied.
Because I am testing on a shared hosting environment I have to use ftp layer in global settings for extension installer and in joomla update component whenever I install an update. Maybe this is the reason, that there is a file permissions problem with writing the file on my side?
@mbabker Shall I set my test result to "not tested" while I investigate so I do not keep others from testing because they think "ha, it does not work anyway so I do not take the time for a test"?
OK So this makes a lot of sense - JInstaller can not longer find the manifest file (we moved to from the root of the package to stop extension manager updates - so returns false/null (unsure exactly what) here) https://github.com/joomla/joomla-cms/blob/Update-Component-Manifest-Lookup/administrator/components/com_joomlaupdate/models/default.php#L558
As a result neither the SQL update file paths nor the manifest script can be found.
converted
FROM #__utf8_conversion
WHERE converted
= 2@franz-wohlkoenig has exactly same error as I have.
@wilsonge Yes, must be like you say, because the $manifestClass variable is set only if ($manifestScript).
But in addition to solving this problem Michael also should change the 3 "if ($manifestClass && ..." statements to "if (isset($manifestClass) && ..." so in case if it is not set there is no PHP error, or we return from the function before if it is not set so not run into this error, or am I wrong?
Honestly as Joomla Update is only for updating Joomla I'm hugely tempted to just hardcode the damn class :P alternatively we can manually set the manifest path in JInstaller here.
This PR has received new commits.
New package just finished uploading. Went ahead and pushed my alt patch with more hardcoding references in it. Test it.
I have tested this item successfully on bccb2c3
Works like a charm here now (happy).
After successful update message, this time the statistics plugin question message came up, and this time Extensions -> Manager -> Database shows following, as it should be, and also the queries counts are correct:
Database table structure is up to date.
Database schema version (in #__schemas): 3.5.0-2016-03-01.
Update version (in #__extensions): 3.5.0-rc2.
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/9414.
I have tested this item successfully on bccb2c3
Got once more "Table '#_session' should not have index 'whosonline'. (From file 3.0.0.sql.)", after "Fix" its solved. Also indexer running with success.
Status | Pending | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-03-14 14:17:09 |
Closed_By | ⇒ | wilsonge |
Milestone |
Added: |
Merged - thanks guys!
I can confirm that this error exists on 3.5.0RC2 with default testing channel, and that this PR solves the problem, 1 about manifest and the other that @andrepereiradasilva mentioned on #9402 , about missing "#__utf8_conversion' doesn't exist "
Labels |
Removed:
?
|
FWIW if this bombs in the scenario I mentioned https://gist.github.com/mbabker/d39f8b74837ee272a9ce is the alternative approach.