WordPress.org

Make WordPress Core

Opened 9 years ago

Closed 5 years ago

Last modified 3 months ago

#8857 closed enhancement (wontfix)

Make WP MySQL strict mode compliant

Reported by: ghostks Owned by:
Milestone: Priority: lowest
Severity: minor Version: 2.7
Component: Database Keywords:
Focuses: Cc:

Description

Incorrect Mysql scheme during Wordpress installation on DBMS with strict date/datetime format settings will result in errors and will be unable to finish succesfully. Existing default date and datetime values are '0000-00-00' and '0000-00-00 00:00:00' which are not supported any more. Please see official Mysql dev documentation for more information:

The DATE type is used when you need only a date value, without a time part. MySQL retrieves and displays DATE values in 'YYYY-MM-DD' format. The supported range is '1000-01-01' to '9999-12-31'.

http://dev.mysql.com/doc/refman/5.0/en/datetime.html

Change History (16)

#1 @ryan
9 years ago

Other parts of that page seem to suggest the 0 values are still valid. "As of MySQL 5.0.2, MySQL does not accept timestamp values that include a zero in the day or month column or values that are not a valid date. The sole exception to this rule is the special value '0000-00-00 00:00:00'."

#2 @ryan
9 years ago

  • Milestone changed from 2.7.1 to 2.8

#3 @Denis-de-Bernardy
9 years ago

  • Keywords needs-patch added
  • Milestone changed from 2.8 to Future Release
  • Priority changed from normal to lowest
  • Severity changed from normal to minor
  • Summary changed from Incorrect Mysql scheme to Make WP MySQL strict mode compliant

the reported bug is valid if and only if you switch mysql's strict mode off. but when that is on, essentially nothing works in WP anyway.

this is one of those huge changes, like getting rid of magic quotes at some point. we'd need to do things such as:

  • use null values for dates and datetimes rather than the 0000-00-00 00:00:00 equivalents
  • not use single quotes on integer values
  • make sure data will fit in the columns
  • the list goes on and on

if you're in for a good laugh, hop to:

http://sql-info.de/mysql/gotchas.html

suggesting wontfix, myself. else needs a big patch and lots of testing, because quite a few plugins have come to expect null dates to return 0000-00-00 00:00:00.

#5 @Denis-de-Bernardy
9 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Please re-open when we drop MySQL 4 support

#6 follow-up: @Elpie
7 years ago

  • Cc Elpie added
  • Component changed from General to Database
  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Type changed from defect (bug) to enhancement

With WP 3.2 under development this should be looked into more closely.

#7 @scribu
7 years ago

  • Milestone set to Future Release

#8 in reply to: ↑ 6 ; follow-up: @Ramoonus
6 years ago

Replying to Elpie:

With WP 3.2 under development this should be looked into more closely.

you mean 3.3?

#9 in reply to: ↑ 8 @Elpie
6 years ago

Replying to Ramoonus:

Replying to Elpie:

With WP 3.2 under development this should be looked into more closely.

you mean 3.3?

It was 3.2 when I wrote that and now, of course, MySQL5 is the minimum requirement. Two years ago, when this ticket was opened, it was fair enough to wait. Now that MySQL4 support has been dropped this will need to be addressed.

#11 @pento
5 years ago

  • Keywords needs-patch removed
  • Resolution set to wontfix
  • Status changed from reopened to closed

This is not viable to fix - there are thousands of plugins that expect the zero date format, which will all break horribly if we switch to NULL dates.

#12 @nacin
5 years ago

  • Milestone Future Release deleted

Yeah, WordPress just pretty simply does not support strict mode.

#13 @felixq
4 years ago

Changelog MySQL 5.6.17:

Incompatible Change: The deprecated ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, and NO_ZERO_IN_DATE SQL modes now do nothing. Instead, their previous effects are included in the effects of strict SQL mode (STRICT_ALL_TABLES or STRICT_TRANS_TABLES). In other words, strict mode now means the same thing as the previous meaning of strict mode plus the ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, and NO_ZERO_IN_DATE modes. This change reduces the number of SQL modes with an effect dependent on strict mode and makes them part of strict mode itself.

#15 @dd32
3 months ago

#41785 was marked as a duplicate.

#16 @dd32
3 months ago

#41785 was marked as a duplicate.

Note: See TracTickets for help on using tickets.