[wp-trac] [WordPress Trac] #35249: Unit tests should pass

[WordPress Trac]

#35249: Unit tests should pass
------------------------------+------------------------------
 Reporter:  jrf               |       Owner:
     Type:  defect (bug)      |      Status:  new
 Priority:  normal            |   Milestone:  Awaiting Review
Component:  Build/Test Tools  |     Version:
 Severity:  normal            |  Resolution:
 Keywords:                    |     Focuses:
------------------------------+------------------------------

Comment (by jrf):

 @dossy

 > I suppose the question is whether or not it's a good idea to have the
 default character set on a database set to utf8mb4 - do all of the text
 columns really need to use that character set? Or, if we're going to say
 "it's 2015, we should be able to shove utf8mb4 in any text column" then we
 probably should be defining our database schema to use more conservative
 prefix indexes on text columns that aren't FULLTEXT indexes.

 I think the *real* question is: does WP want to be compatible with all
 possible configurations out there ? So far in my experience, the answer to
 this has always been "Yes".
 If so, IMHO, it's not an issue of the test failing, but of WP failing to
 deal correctly with the possibility that there are databases with
 utf8mb4-like collations out there.


 > I'm curious, how did your test database get its default character set
 changed to utf8mb4 anyway? That's definitely unusual, otherwise these
 tests would have failed for more people ...

 I'm not sure.

 > It would be dirty, but we could force the column's character set in
 tests/phpunit/tests/dbdelta.php for the sake of the test:
 > Maybe just adding a check to the setUpBeforeClass() that checks the
 character_set_database (using `SHOW CHARACTER SET LIKE 'name'`'s Maxlen
 value ...

 I don't think fixing the test is the way to go.

 What about this: if the `DB_CHARSET` constant is set to `utf-8`, in the
 WP_INSTALL routine - before adding any tables -, check the DB charset
 with:
 {{{
 USE `database_name`
 SELECT @@character_set_database, @@collation_database
 }}}


 If the charset is not `utf8`, run:

 {{{
 ALTER DATABASE `database_name` CHARACTER SET `utf8` COLLATE
 `utf8_general_ci`
 }}}


 That would prevent the issue altogether without causing issues for people
 who have the DB_CHARSET set to something other than `utf8`.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/35249#comment:20>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform