? Failure

User tests: Successful: Unsuccessful:

avatar OctavianC
OctavianC
9 Nov 2016

Pull Request for Issue # .

Summary of Changes

Checks if the string utf8mb4 exists in the query - no need to do a regex replacement otherwise.
How I came across this: had a client that was attempting to install any extension and received the following errors:

JInstaller: :Install: Error SQL SQL=
Extension Install: SQL error processing query: DB function reports no errors.

The SQL is empty because the database did not support utf8mb4 AND the PCRE library the PHP was using was outdated and didn't understand (*SKIP)(*FAIL). Thus, preg_replace() returned false instead of the original $query.

It won't make much of a difference in the long run, but I've seen plenty of times this error on the Joomla! forum and perhaps this will solve it.

Testing Instructions

Install any extension that creates tables in the database. Make sure it installs correctly and the tables are created. Make sure utf8mb4 tables are downgraded to utf8 if the database does not support the character set (MySQL < 5.5 if I recall correctly).

Documentation Changes Required

None.

avatar OctavianC OctavianC - open - 9 Nov 2016
avatar OctavianC OctavianC - change - 9 Nov 2016
Status New Pending
avatar joomla-cms-bot joomla-cms-bot - change - 9 Nov 2016
Category Libraries
avatar mehranfazili
mehranfazili - comment - 13 Nov 2016

Worked fine here.

avatar franz-wohlkoenig
franz-wohlkoenig - comment - 26 Aug 2018

@mehranfazili please mark your Test as successfully:

  • open Issue Tracker
  • Login with your github-Account
  • Click on blue "Test this"-Button above Authors-Picture
  • mark your Test as successfully
  • hit "submit test result"
avatar richard67 richard67 - test_item - 30 Jun 2019 - Tested successfully
avatar richard67
richard67 - comment - 30 Jun 2019

I have tested this item successfully on 4cd6dd8

Hacked the db driver so it returns always false for utf8mb4 support.
Both with and without this PR, a new installation of the CMS resulted in tables having utf8 character set and collations, so SQL statements are correctly downgraded with and without this PR.
Finally a code review tells me this change makes sense.
We are on the safer side in cased descibed in this PR, and in there might be also a performance gain according to PHP manuals.


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/12847.

avatar richard67
richard67 - comment - 30 Jun 2019

@franz-wohlkoenig I think @mehranfazili will not mark his successful test result in the issue anymore after more than 2 years. But theroetically it is still valid, and as the guy who worked much on that utf8mb4 stuff in past I can say this change is good and still valid, plus I've just tested as described in my test result.
=> Please set RTC.

avatar richard67
richard67 - comment - 30 Jun 2019

Pity I did not notice this PR before, but end of 2016 I had a very passive phase here on GitHub because of new job.

avatar Quy Quy - change - 30 Jun 2019
Status Pending Ready to Commit
avatar Quy
Quy - comment - 30 Jun 2019

RTC


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/12847.

avatar HLeithner HLeithner - change - 30 Jun 2019
Status Ready to Commit Fixed in Code Base
Closed_Date 0000-00-00 00:00:00 2019-06-30 17:17:47
Closed_By HLeithner
avatar HLeithner
HLeithner - comment - 30 Jun 2019

thx

avatar richard67
richard67 - comment - 30 Jun 2019

@mbabker Does this need re-integration back to the framework database package, and if so for which versions, master and 2.0-dev or only one of both? If I know what to do I will make the necessary PR(s) to the framework package.

avatar mbabker
mbabker - comment - 30 Jun 2019

Any changes made in this repo should go to the Framework repo, in whatever branch(es) the change impacts. There should not be selective porting of changes, that's how things get inconsistent.

avatar richard67
richard67 - comment - 30 Jun 2019

@mbabker I checked and saw in the framework database package it is different anyway, and the change from this PR here is not really needed there. So nothing to do, it seems to me. Thanks for advising.

Add a Comment

Login with GitHub to post a comment