While `wpdb::prepare()` does not support null values (see #12819) they still appear in the wild like in the WordPress Importer and other plugins.
git-svn-id: https://develop.svn.wordpress.org/trunk@41483 602fd350-edb4-49c9-b593-d223f7449a82
Previously if you passed an array of values for placeholders, additional values could be passed as well. Now additional values will be ignored.
git-svn-id: https://develop.svn.wordpress.org/trunk@41470 602fd350-edb4-49c9-b593-d223f7449a82
This change improves code clarity by using the current naming conventions for networks.
Props lemacarl.
Fixes#41510.
git-svn-id: https://develop.svn.wordpress.org/trunk@41241 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@41162 602fd350-edb4-49c9-b593-d223f7449a82
Adds context to one string used in two different contexts for the new user and new site signup email notification.
More to come.
See #38882
git-svn-id: https://develop.svn.wordpress.org/trunk@39323 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@39275 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@38580 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@38507 602fd350-edb4-49c9-b593-d223f7449a82
[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.
git-svn-id: https://develop.svn.wordpress.org/trunk@38441 602fd350-edb4-49c9-b593-d223f7449a82
There were some cases where some local variables in `wpdb::init_charset()` could be undefined when they were used.
Props Frozzare.
Fixes#37683 for trunk.
git-svn-id: https://develop.svn.wordpress.org/trunk@38439 602fd350-edb4-49c9-b593-d223f7449a82
Replaces unsecure links in documentation and translator comments with their secure versions.
Props johnpgreen, netweb
Fixes#36993
git-svn-id: https://develop.svn.wordpress.org/trunk@37674 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@37601 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@37548 602fd350-edb4-49c9-b593-d223f7449a82
Applying these specially-crafted `@see` tags allows the Code Reference parser to recognize and link these elements as actions and filters.
Fixes#36921.
git-svn-id: https://develop.svn.wordpress.org/trunk@37544 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@37523 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@37521 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@37431 602fd350-edb4-49c9-b593-d223f7449a82
This is a partial revert of [35860], which has been causing un-catchable warnings to be generated on some server configurations.
Fixes#36629 for trunk.
See #21870.
git-svn-id: https://develop.svn.wordpress.org/trunk@37292 602fd350-edb4-49c9-b593-d223f7449a82
In the event that it was closed prematurely, `wpdb::query()` will re-open the connection automatically.
Fixes#34903.
git-svn-id: https://develop.svn.wordpress.org/trunk@36433 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@35655 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@34737 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@34655 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@34529 602fd350-edb4-49c9-b593-d223f7449a82
While it doesn't affect Core, we should also be passing the `$allow_bail` parameter, for anything that uses it differently.
Props markoheijnen, johnbillion.
Fixes#33105.
git-svn-id: https://develop.svn.wordpress.org/trunk@34478 602fd350-edb4-49c9-b593-d223f7449a82