WPCS 1.0.0 includes a bunch of new auto-fixers, which drops the number of coding standards issues across WordPress significantly. Prior to running the auto-fixers, there were 15,312 issues detected. With this commit, we now drop to 4,769 issues.
This change includes three notable additions:
- Multiline function calls must now put each parameter on a new line.
- Auto-formatting files is now part of the `grunt precommit` script.
- Auto-fixable coding standards issues will now cause Travis failures.
Fixes#44600.
Built from https://develop.svn.wordpress.org/trunk@43571
git-svn-id: http://core.svn.wordpress.org/trunk@43400 1a063a9b-81f0-0310-95a4-ce76da25c4cd
A new global multisite table `wp_blogmeta` is added to the database schema, and a set of `*_site_meta()` API functions are introduced.
The implementation fails gracefully when the new table is not yet available, which may happen especially shortly after the core update, before the network has been upgraded to the new database schema. The presence of the table is detected once and stored as a global setting on the main network.
Core does not yet use site metadata, but there are several use-cases to be implemented or explored in the near future, and it allows plugins to extend sites with arbitrary data, which will come in particularly handy with the upcoming REST API endpoint for sites.
Props spacedmonkey, johnjamesjacoby, jeremyfelt, flixos90.
Fixes#37923.
Built from https://develop.svn.wordpress.org/trunk@42836
git-svn-id: http://core.svn.wordpress.org/trunk@42666 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This change makes WordPress use `mysqli` on PHP <5.5 when available, instead of only in PHP 5.5+ and development installs.
WPDB includes a fallback to `mysql` in the event that the database connection fails with `mysqli` so incompatibilities should be few and far between.
Fixes#42812 for trunk.
Built from https://develop.svn.wordpress.org/trunk@42388
git-svn-id: http://core.svn.wordpress.org/trunk@42217 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The WPCS `WordPress.WhiteSpace.PrecisionAlignment` rule throws warnings for a bunch of code that will likely cause issues for `wpcbf`. Fixing these manually beforehand gives us better auto-fixed results later.
See #41057.
Built from https://develop.svn.wordpress.org/trunk@42228
git-svn-id: http://core.svn.wordpress.org/trunk@42057 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In `wpdb::placeholder_escape()`, the key for `hash_hmac()` defaults to `AUTH_SALT`, but `hash_hmac()` will return an empty string if the key is empty.
This had the side effect of the string `{}` being incorrectly replaced with a `%` character in queries just about to be run on the database.
Props jsonfry.
Fixes#42431.
Built from https://develop.svn.wordpress.org/trunk@42120
git-svn-id: http://core.svn.wordpress.org/trunk@41949 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In `wpdb::placeholder_escape()`, the key for `hash_hmac()` falls back to `rand()` when `AUTH_SALT` is undefined. `hash_hmac()` requires the key to be a string, however, so we need to cast it as such.
Props mkomar.
Fixes#42401.
Built from https://develop.svn.wordpress.org/trunk@42119
git-svn-id: http://core.svn.wordpress.org/trunk@41948 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[41496] removed support for numbered placeholders in queries send through `wpdb::prepare()`, which, despite being undocumented, were quite commonly used.
This change restores support for numbered placeholders (as well as a subset of placeholder formatting), while also adding extra checks to ensure the correct number of arguments are being passed to `wpdb::prepare()`, given the number of placeholders.
See #41925.
Built from https://develop.svn.wordpress.org/trunk@42056
git-svn-id: http://core.svn.wordpress.org/trunk@41885 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This fixes a change in behaviour introduced by [41629].
The host is set to an empty string when it isn't defined, this continues existing behaviour. In particular, the mysqli library treats a `null` host as being the same as `localhost`, which is not always the intended behaviour.
Props birgire, markjaquith, pento.
Fixes#41722.
Built from https://develop.svn.wordpress.org/trunk@41820
git-svn-id: http://core.svn.wordpress.org/trunk@41654 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`wpdb::prepare()` currently gives no information if the number of arguments passed doesn't match the number of placeholders in the query. This change gives an explicit notice that the call was incorrect.
Also fixes an enrelated term meta test that was triggering this new notice.
Props thekt12 for the initial patch.
Fixes#42040.
Built from https://develop.svn.wordpress.org/trunk@41662
git-svn-id: http://core.svn.wordpress.org/trunk@41496 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Prior to about 2013, many class methods lacked even access modifiers which made the `@access` notations that much more useful. Now that we've gotten to a point where the codebase is more mature from a maintenance perspective and we can finally remove these notations. Notable exceptions to this change include standalone functions notated as private as well as some classes still considered to represent "private" APIs.
See #41452.
Built from https://develop.svn.wordpress.org/trunk@41162
git-svn-id: http://core.svn.wordpress.org/trunk@41002 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `SHOW TABLES LIKE` query can be used to search for tables that match a pattern, `wp\_123\_%`, for example. While this isn't the name of an actual table, the `wp_123_` prefix can be used by database drop-ins to direct the query correctly. This change removes the escaping and `%` modifier, to provide this usable prefix.
Props andy, pento.
Fixes#38751.
Built from https://develop.svn.wordpress.org/trunk@39275
git-svn-id: http://core.svn.wordpress.org/trunk@39215 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Sometimes, `DB_CHARSET` will be set to `utf8mb4`, even if the current setup doesn't support `utf8mb4`. After [38442], this can cause significant character set failures, causing the connection to fall back to `latin1`.
Instead of doing this, we now check that the connection supports `utf8mb4` before trying to use it, and fall back to `utf8` when we need to.
Fixes#37982 for trunk.
Built from https://develop.svn.wordpress.org/trunk@38580
git-svn-id: http://core.svn.wordpress.org/trunk@38523 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, `wpdb::get_table_from_query()` would not find the correct table name in the query `DELETE a FROM table a`, due to not recognising the table alias immediately after the `DELETE` as correct syntax.
Fixes#37660.
Built from https://develop.svn.wordpress.org/trunk@38507
git-svn-id: http://core.svn.wordpress.org/trunk@38448 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[37320] corrected some behaviour in how PHP and MySQL character sets are matched up. This was correct, but had the side effect of causing some incorrectly configured sites to start failing.
Prior to [37320], if `DB_CHARSET` was set to `utf8mb4`, but the PHP version didn't support `utf8mb4`, it would fall back to the default character set - usually `latin1`. After [37320], the `SET NAMES` query would force MySQL to treat the connection character set as `utf8mb4`, even if PHP wasn't able to understand it.
By checking if `mysqli_set_charset()` succeeded, we can simulate the old behaviour, while maintaining the fix in [37320].
Props danielkanchev fo helping to diagnose this issue.
Fixes#37689 for trunk.
Built from https://develop.svn.wordpress.org/trunk@38441
git-svn-id: http://core.svn.wordpress.org/trunk@38382 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The logic for determining the appropriate character set and collation to use is becoming more complex, particularly with the recent additions of [37522] and [37523]. As `init_charset()` has side effects, and makes use of constants instead of parameters, it's not possible to unit test this logic.
This commit splits the logic part of `init_charset()` out into a new method, `wpdb::determine_charset()`, along with appropriate unit tests.
See #32105, #37522.
Fixes#36917.
Built from https://develop.svn.wordpress.org/trunk@37601
git-svn-id: http://core.svn.wordpress.org/trunk@37569 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In the event that the database has gone away for some reason, calls to `mysqli_errno()` and `mysqli_error()` (and their `ext/mysql` equivalents, of course), will generate PHP warnings, which are unsightly, and not how we do things in these parts.
Props mbijon, craig-ralston for the original patch.
Fixes#23085.
Built from https://develop.svn.wordpress.org/trunk@37548
git-svn-id: http://core.svn.wordpress.org/trunk@37516 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `utf8mb4_unicode_520_ci` (Unicode Collation Algorithm 5.2.0, October 2010) collation is an improvement over `utf8mb4_unicode_ci` (UCA 4.0.0, November 2003).
There is no word on when MySQL will support later UCAs.
Fixes#32105.
Built from https://develop.svn.wordpress.org/trunk@37523
git-svn-id: http://core.svn.wordpress.org/trunk@37491 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Some sites prefer to use locale-specific location settings. For example, the Swedish WordPress package use `utf8_swedish_ci`, instead of `utf8_unicode_ci`. When upgrading the connection to `utf8mb4`, we were overriding this to be `utf8mb4_unicode_ci`, instead of maintaining the use of the `_swedish_ci` variant.
The locale-specific collations do have extra collation rules just for that language, so it's useful to maintain compatibility.
Fixes#32405.
Built from https://develop.svn.wordpress.org/trunk@37521
git-svn-id: http://core.svn.wordpress.org/trunk@37489 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Also use 'back-compat' in some inline comments where backward compatibility is the subject and shorthand feels more natural.
Note: 'backwards compatibility/compatibile' can also be considered correct, though it's primary seen in regular use in British English.
Props ocean90.
Fixes#36835.
Built from https://develop.svn.wordpress.org/trunk@37431
git-svn-id: http://core.svn.wordpress.org/trunk@37397 1a063a9b-81f0-0310-95a4-ce76da25c4cd
If `DB_CHARSET` isn't defined (or is empty), `wpdb::$charset` will be empty, too. `wpdb::strip_invalid_text()` assumes that it isn't empty, however, so we need to fall back to the connection character set when we're running our sanity checks.
Fixes#34708.
Built from https://develop.svn.wordpress.org/trunk@35655
git-svn-id: http://core.svn.wordpress.org/trunk@35619 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Specifically, `::insert()`, `::replace()`, `::update()`, and `::delete()` can now set a column to `NULL`, or add the `IS NULL` condition to the `WHERE` clause.
This is based on [backpress 279].
Props pento, nbachiyski, sorich87.
Fixes#15158.
Built from https://develop.svn.wordpress.org/trunk@34737
git-svn-id: http://core.svn.wordpress.org/trunk@34701 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, we'd run the sanity checks if `is_mysql` was not set to `false`. This caused problems for DB drop-ins that didn't define `is_mysql` at all. Instead, we can just check if `is_mysql` is `empty()`.
Also fix some unit tests that accidently ran correctly because of the strict `false ===` comparison.
Fixes#33501.
Built from https://develop.svn.wordpress.org/trunk@34655
git-svn-id: http://core.svn.wordpress.org/trunk@34619 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adds a new table to the database schema (`wp_termmeta`), and a set of
`*_term_meta()` API functions. `get_terms()` and `wp_get_object_terms()`
now also support 'meta_query' parameters, with syntax identical to other
uses of `WP_Meta_Query`.
When fetching terms via `get_terms()` or `wp_get_object_terms()`, metadata for
matched terms is preloaded into the cache by default. Disable this behavior
by setting the new `$update_term_meta_cache` paramater to `false`.
To maximize performance, within `WP_Query` loops, the termmeta cache is *not*
primed by default. Instead, we use a lazy-loading technique: metadata for all
terms belonging to posts in the loop is loaded into the cache the first time
that `get_term_meta()` is called within the loop.
Props boonebgorges, sirzooro.
See #10142.
Built from https://develop.svn.wordpress.org/trunk@34529
git-svn-id: http://core.svn.wordpress.org/trunk@34493 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This change does the following things
* Allows utf8mb4 for the MySQL extension
* Re-runs the utf8->utf8mb4 conversion for single sites, this will do nothing for tables already converted
* Re-runs the utf8->utf8mb4 conversion for global tables in multisite when the environment supports utf8mb4
* Removes upgrade_420() calling as upgrade_430() will perform those changes now instead
The index shortenings should have still taken place on utf8 sites previously, so there's no need to run those again.
Props kovshenin, pento, dd32
Fixes#32127 for trunk.
Built from https://develop.svn.wordpress.org/trunk@33055
git-svn-id: http://core.svn.wordpress.org/trunk@33026 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`num_queries` is accessed publicly in core.
`num_rows` is accessed publicly in `ms-settings.php`.
`insert_id` is accessed publicly in core.
`prefix` is accessed publicly in `upgrade.php` and `capabilities.php`.
See #32444.
Built from https://develop.svn.wordpress.org/trunk@32640
git-svn-id: http://core.svn.wordpress.org/trunk@32610 1a063a9b-81f0-0310-95a4-ce76da25c4cd
