MySQL 5 – Strict Mode

“Didn’t anyone realize that the database code was severely cracked, if not actually broken?”

Well, it seems to be working for millions of people. Your language is rude. Think for a second if a new version of MySQL causes “hundreds” of PHP apps to break then maybe it’s changed the rules?

WordPress has always been built with baseline MySQL 3.23 compatibility.

If you can’t be civil please go away. If you can calm down a little bit, please file a patch to this bug:

https://trac.www.ads-software.com/ticket/1953

Sorry, but it’s really bugging me.

By “hundreds”, I do mean hundreds. A google for the error message itself turns up thousands of results, and every single PHP app I’ve tried with MySQL 5/strict has broken, most of them to the point where they simply won’t function.

Yes, WP works for millions of people using anything but MySQL 5/strict, no argument there. But all of those previous versions of MySQL (possibly excepting 3.x, since I haven’t personally tested it with WP) give warnings, while 5/strict gives errors (which is, technically, the proper behaviour).

Effectively, this means that all of these PHP apps are not coded properly. I know it’s strong language, but if you turn warnings into errors and things break that badly, there is no other conclusion to draw. And as far as I can tell, that is *all* that strict-mode does. With strict-mode turned off, everything works just fine ?? Except that a bunch of warnings are generated by MySQL.

Matt, I am always civil here. But this issue has happened more than once. When people (and hosts) started moving to PHP5, the same damn thing happened, and we were told to downgrade. This was not because there was a bug in PHP5, but because the code took shortcuts it shouldn’t have, and when the bug was fixed, things broke. This is the same thing that’s happening with the switch from MySQL 4 to 5. And there’s no reason for it, aside from either bad or lazy coding.

I’m not *just* pinpointing WordPress, but of all the apps I’ve tried, it’s the one I like best. phpMyAdmin, phpBB, SMF, TextPattern, etc. *all* have problems with strict mode for the exact same reason.

I’m surprised no one realizes how serious the problem could end up being.

And I’m still asking if this bug will be fixed by the 2.0 release.

First off
Q. “How the hell did this get past Q/A anyways?”
A. You are the Q/A, this is called “beta” for a reason.

Second, on the PHP4 vs PHP5 issue, you have been ill informed. Code did not break because the WP devs took shortcuts, it broke because of a serious change in the Zend Engine that, if you watch the PHP internals list or any of the more serious PHP sites, you would know intentionally broke backwards compatability in order to add new features.

“And there’s no reason for it, aside from either bad or lazy coding.”
Sure there is. Not every person is capable of keeping up with hundreds of versions of PHP and/or hundreds of versions of mySQL. Hvae you seen the size of the mysql changelog from minor version to minor version? Its usually 2-3 pages, imagine the size of the 4 to 5 changelog.

“I’m surprised no one realizes how serious the problem could end up being.”
https://trac.www.ads-software.com/ticket/1953 is the ticket, place your input, instead of fussing here, as it will get you a lot further.

Your disreguard for the open source development model really shows. WP developers place changes like this in the code and release betas to find out how it functions for everybody. They are not in some huge corperate environment with tons of testbeds and dedicated testing staff sitting around. These betas are released so that people like you can report back to the developers, and problems can be pinpointed and fixed.

If you’d like to see the bug fixed, voice your input on the ticket for the bug. Calling developers lazy isn’t going to get you anywhere.

If MySQL strict breaks every web app known to man, I’m not terribly worried about any hosts upgrading to it just yet. If compliance means changing more than a few lines of code, which I don’t know as you haven’t submitted any patches yet, it’ll probably be held to the next release.

Arg. Fine, I’ll lay off the opinionating and simply use facts. I warn that it is far less colourful reading.

On the PHP4 to PHP5 change: the error that most commonly broke PHP apps was the allow_call_time_pass_reference setting. In the PHP ini file, since 4.0-ish, it has stated clearly that having that turned on would *not* be supported in the future. This was an override behaviour that was being deprecated in future versions (and clearly noted as such), but was still taken advantage of extensively by many (or possibly most) PHP devs. So WP broke if this was turned off (the default value as of 4.1 or thereabouts). The fix is easy, and it was done for *most* projects (including WP) very quickly.

On the MySQL 4 to 5/strict change: this is simply (mostly) a matter of properly inserting rows into the database. Strict mode simply changes many warnings into errors. There is no other behavioural change that affects WP (that I know of), since 5.0x is primarily a feature-addition/bug-fix version. This error is the only one I see in both 1.5.2 and 2.0B2 (and SK2, incidentally). Turning strict-mode off corrects the problem. Again, how hard is it to write valid SQL? I’ve written a *lot* of SQL for MySQL, SQL Server, and Oracle, and I’ve never seen this error before. Just make sure the inserts are valid (based on the table schema), and this problem goes away.

So yes, I would like to see this bug fixed. If I have time this weekend or during the week, I’ll grab the latest from SVN and see if I can do it myself. I’m not all that educated in PHP, but I’ll give it a go if no one else will.

Matt: I’m sure not *every* PHP app that uses MySQL is broken, but so far it seems that most are. SMF (forum software), for example, is only slightly broken – only a couple of queries were malformed, and a patch was available something like 2 hours after the problem was noticed. phpBB, on the other hand, breaks horribly every time PHP or MySQL get upgraded, and this time was no exception.

In the case of WP, much of it still works to a fair degree. I’ll do what I can over the weekend.

https://somethingunpredictable.com/archives/25/11/2005/on-backwards-compatability-php-mysql-and-open-source-software/

Here’s my thoughts on the whole subject, and perhaps after reading it, you’ll lighten up a bit. And perhaps if/when you become more educated in PHP, you’ll realize that its not as easy as it all seems just looking at error messages. ??

masquerade, I’m getting a 404 at your posted link….

Refresh, the permalink changed, you hit it in about the 30 second period before I edited this post (I realized I had a problem with timezones cause of DST.)

Ack. Okay…. figures, my luck! Just read it, thanks for a cogent explanation – I asked my host just today if they were considering upgrading to the 5.0s, and got mostly “rolling eyes” etc. They’re waiting a while…. which is fine from my own P O V. One less thing to worry about.

Matt: having read the link to Trac that you posted, and the link within that page, I’m not sure which way to go with it. On one hand, it makes sense to modify the upgrade-schema.php file and simply remove the DEFAULT declaration from the necessary fields, but I wonder if it’s more “proper” to modify the INSERT queries in WP to adhere to the database schema. The first option is easier, though it still doesn’t fix all the bugs. The second option is, to my mind, the better one since it means that all of the INSERT queries will be well-formed against the schema. Any input would be appreciated. I already have WP2.0 installing properly under PHP 5.1 and MySQL 5.0 with both methods, although commenting doesn’t work yet.

Good work so far. In the aftermath of all that bitter arguing, at least this is getting sorted out ??

What would really help is if you posted a list of the errors you’re getting. Show us which inserts fail, and we can probably track them to functions. If you’re interested, a lot of DB calls happen within wp-admin/admin-db.php, and all the files in wp-includes with ‘functions’ in their name (so functions.php, comment-functions.php, functions-post.php etc). Grepping for “\$wpdb.*INSERT” should turn up a few.

https://somethingunpredictable.com/xrefs/wptrunk/_functions/query.html
I pointed him in the direction of that last night on IRC, which has all the INSERT and SELECT queries ( its a cross reference of wpdb::query() )