Q2A switch to mysqli - beta available

Question

Hi everyone, for those that have been asking about MySQL deprecation warnings, I have now updated the code to use MySQLi instead. It's currently on the dev branch of Q2A and will be rolled into Q2A 1.6.4 (haven't decided on a release date yet).

However, if you want to test the code now you can! Only one file has changed so it's very simple:

1. Backup the file qa-include/qa-db.php (e.g. rename to qa-db.php.bak) so you can restore it if anything goes wrong.
2. Replace the qa-db.php file with this one from the repo.

This is a beta 'release' so it may not be suitable for use in production - make sure to test it first. Also note, the new minimum supported version of PHP required for Q2A is 5.1.6.

If you find any issues/errors, please let me know. Thanks!

Comments

Thats great news . Thank you Scott .

Answer 1

I just did the upgrade on my Testing Playground QA site https://digitizormedia.com/qa and things look good as of now. Thanks for this Scott :-) Just out of curiosity, prepared statements are supported already?

Comments

Q2A does not use any prepared statements.

---

Thanks again :-)

Answer 2

I agree starting de-deprecating the core is great step in the right direction.

However, I believe doing this in 1.6.4 is a HUGE mistake. Let me explain why. Although anyone can version the software in any way there are certain mini-standards to follow. EG: If using versions with 3 numeric positions, the digit on the right is usually incresed when there have been done only bug fixes, the digit on the middle involve minor features added and the digit in the left implies major features or changes.

I believe most people will assume chaning from 1.6.3 to 1.6.4 will only result in a couple of bugs fixed but that the upgrade will still be compatible with their current version. However, this will not be the case. Anyone hosting the application on a hosting server using PHP 4, or even PHP 5 earlier than the 5.1.6 will find their sites not working after the upgrade.

I believe the best approach would be to create a 1.7-dev branch and also a 1.6.4-dev branch (to add the latest very minor changes). Then, whenever 1.7 is ready, release this PHP 4 support drop (making sure every piece of documentation is updated... particularly the q2a home page that states it runs in PHP 4).

As a side note, I believe there should be a clearer understanding on what each number in the version means. That would help people understand the impact of upgrading.

Just my 2 cents.

Comments

Hi pupi, thanks for the input. You make a good point about PHP compatibility. I doubt we have anyone still on PHP 4 but changes in minimum requirements should be kept to a 0.1 version, not 0.0.1. The other change I made also required a change to the language file, which Gideon has been keeping to major releases.

So I may forgoe the 1.6.4 release and roll it into 1.7 instead.

---

I think that you should not classify such a big change into 1.6.4, too. As for it, 1.7 will be proper.

Answer 3

Its worked for me. Thanks.

Answer 4

It is worth to note:

  IN qa-install.php, line 189 ,  the  

is_resource(false)

shoulde also be changed if you want to use mysqli (eg. qa_db_connection(false) instanceof mysqli ).

Hope it may be helpful since I have spent almost one day to figure out why some plugins "init_queries" doesn't work.

Comments

This was actually fixed a while ago and is in the latest dev version. Thanks for reporting anyway :)