`str_contains()` was introduced in PHP 8.0 to perform a case-sensitive check indicating if the string to search in (haystack) contains the given substring (needle).
WordPress core includes a polyfill for `str_contains()` on PHP < 8.0 as of WordPress 5.9.
This commit replaces `false !== strpos( ... )` with `str_contains()` in core files, making the code more readable and consistent, as well as better aligned with modern development practices.
Follow-up to [52039], [52040], [52326], [55703], [55710], [55987].
Props Soean, spacedmonkey, costdev, dingo_d, azaozz, mikeschroder, flixos90, peterwilsoncc, SergeyBiryukov.
Fixes#58206.
Built from https://develop.svn.wordpress.org/trunk@55988
git-svn-id: http://core.svn.wordpress.org/trunk@55500 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This amends the previous commit to avoid a warning on PHP < 7.2.18 if haystack is an empty string:
{{{
Warning: substr_compare(): The start position cannot exceed initial string length
}}}
Follow-up to [55151], [55157].
See #52506.
Built from https://develop.svn.wordpress.org/trunk@55158
git-svn-id: http://core.svn.wordpress.org/trunk@54691 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This avoids a fatal error if the file is included directly outside of WordPress core, e.g. by HyperDB.
While WordPress core does include a polyfill function, it is not directly loaded in the `wpdb` class.
This commit replaces the `str_ends_with()` calls with `substr_compare()` for now.
Follow-up to [55151].
Props Otto42.
See #52506.
Built from https://develop.svn.wordpress.org/trunk@55157
git-svn-id: http://core.svn.wordpress.org/trunk@54690 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[53575] during the 6.1 cycle was reverted in [54734] to address issues around multiple `%` placeholders not being properly quoted as reported in #56933. Since then, this issue has been resolved and the underlying code improved significantly. Additionally, the unit tests have been expanded and the inline docs have been improved as well.
This change reintroduces `%i` placeholder support in `$wpdb->prepare()` to give extenders the ability to safely escape table and column names in database queries.
Follow-up to [53575] and [54734].
Props craigfrancis, jrf, xknown, costdev, ironprogrammer, SergeyBiryukov.
Fixes#52506.
Built from https://develop.svn.wordpress.org/trunk@55151
git-svn-id: http://core.svn.wordpress.org/trunk@54684 1a063a9b-81f0-0310-95a4-ce76da25c4cd
While using reserved PHP keywords as parameter name labels is allowed, in the context of function calls using named parameters in PHP 8.0+, this will easily lead to confusion. To avoid that, it is recommended not to use reserved keywords as function parameter names.
This commit:
* Renames the `$string` parameter to `$data` in:
* `wpdb::_weak_escape()`
* `wpdb::_real_escape()`
* `wpdb::escape_by_ref()`
* Renames the `$string` parameter to `$input_string` in `wpdb::check_ascii()`.
Follow-up to [52946], [52996], [52997], [52998], [53003], [53014], [53029], [53039], [53116], [53117], [53137], [53174], [53184], [53185], [53192], [53193], [53198], [53203], [53207], [53215], [53216], [53220], [53230], [53232], [53236], [53239], [53240], [53242], [53243], [53245], [53246], [53257], [53269], [53270], [53271], [53272], [53273], [53274], [53275], [53276], [53277], [53281], [53283], [53284], [53285], [53287], [53364], [53365], [54927], [54929], [54930], [54931], [54932], [54933], [54938], [54943], [54944], [54945], [54946], [54947], [54948].
Props jrf, aristath, poena, justinahinon, SergeyBiryukov.
See #56788.
Built from https://develop.svn.wordpress.org/trunk@54950
git-svn-id: http://core.svn.wordpress.org/trunk@54502 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When using `'%%%s%%'` pattern with `$wpdb->prepare()`, it works on 6.0.3 but does not on 6.1-RC. Why? The inserted value is wrapped in quotes on 6.1-RC5 whereas it is not on <= 6.0.3.
With 6.1 final release tomorrow, more time is needed to further investigate and test. Reverting this changeset to restore the previous behavior.
This commit also adds a dataset for testing the `'%%%s%%'` pattern.
Props SergeyBiryukov, hellofromTonya, bernhard-reiter, desrosj, davidbaumwald, jorbin.
Fixes#56933.
See #52506.
Built from https://develop.svn.wordpress.org/trunk@54733
git-svn-id: http://core.svn.wordpress.org/trunk@54285 1a063a9b-81f0-0310-95a4-ce76da25c4cd
MariaDB version is reported differently between PHP versions:
* PHP 8.0.16 or later: `10.6.8-MariaDB`
* PHP 8.0.15 or earlier: `5.5.5-10.6.8-MariaDB`
The latter includes PHP 7.4.x and PHP 5.6.x as well, where the version is also reported with the `5.5.5-` prefix.
This commit makes an adjustment to `wpdb::has_cap()` to check for the correct MariaDB version.
This resolves an issue where the `utf8mb4_unicode_520_ci` collation, which is available in MariaDB since version 10.2, was previously not detected correctly.
References:
* [https://github.com/php/php-src/issues/7972 php-src: #7972: MariaDB version prefix 5.5.5- is not stripped]
* [https://github.com/php/php-src/pull/7963 php-src: PR #7963 Fix GH-7932: MariaDB version prefix not always stripped]
* [https://mariadb.com/docs/reference/mdb/collations/utf8mb4_unicode_520_ci/ MariaDB Documentation: utf8mb4_unicode_520_ci]
Follow-up to [37523], [53919].
Props jamieburchell, SergeyBiryukov.
Fixes#54841.
Built from https://develop.svn.wordpress.org/trunk@54384
git-svn-id: http://core.svn.wordpress.org/trunk@53943 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Global terms was a feature from the WordPress MU days where multisite and single site installs used different code bases.
In WordPress 3.0, WordPress MU was merged into one location and the UI [14854] and “on” switch [14880] for global terms were completely removed.
Even before this merge, global terms was bug infested and unreliable. After [14854]/[14880], the feature was no longer maintained and became increasingly broken as taxonomies progressed without it (term splitting and term meta do not work at all). At this point, the feature has not worked in 12+ years and there’s no hope for saving it.
This deprecates the remaining global terms related code and no-ops the functions.
Global terms, you don’t have to go home, but you can’t stay here.
Props scribu, wonderboymusic, SergeyBiryukov, nacin, pento, desrosj, johnjamesjacoby, johnbillion, dd32.
Fixes#21734.
Built from https://develop.svn.wordpress.org/trunk@54240
git-svn-id: http://core.svn.wordpress.org/trunk@53799 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Dynamic (non-explicitly declared) properties are deprecated as of PHP 8.2 and are expected to become a fatal error in PHP 9.0.
There are a number of ways to mitigate this:
* If it is an accidental typo for a declared property: fix the typo.
* For known properties: declare them on the class.
* For unknown properties: add the magic `__get()`, `__set()`, et al. methods to the class or let the class extend `stdClass` which has highly optimized versions of these magic methods built in.
* For unknown ''use'' of dynamic properties, the `#[AllowDynamicProperties]` attribute can be added to the class. The attribute will automatically be inherited by child classes.
Trac ticket #56034 is open to investigate and handle the third and fourth type of situations, however it has become clear this will need more time and will not be ready in time for WP 6.1.
To reduce “noise” in the meantime, both in the error logs of WP users moving onto PHP 8.2, in the test run logs of WP itself, in test runs of plugins and themes, as well as to prevent duplicate tickets from being opened for the same issue, this commit adds the `#[AllowDynamicProperties]` attribute to all “parent” classes in WP.
The logic used for this commit is as follows:
* If a class already has the attribute: no action needed.
* If a class does not `extend`: add the attribute.
* If a class does `extend`:
- If it extends `stdClass`: no action needed (as `stdClass` supports dynamic properties).
- If it extends a PHP native class: add the attribute.
- If it extends a class from one of WP's external dependencies: add the attribute.
* In all other cases: no action — the attribute should not be needed as child classes inherit from the parent.
Whether or not a class contains magic methods has not been taken into account, as a review of the currently existing magic methods has shown that those are generally not sturdy enough and often even set dynamic properties (which they should not). See the [https://www.youtube.com/watch?v=vDZWepDQQVE live stream from August 16, 2022] for more details.
This commit only affects classes in the `src` directory of WordPress core.
* Tests should not get this attribute, but should be fixed to not use dynamic properties instead. Patches for this are already being committed under ticket #56033.
* While a number bundled themes (2014, 2019, 2020, 2021) contain classes, they are not a part of this commit and may be updated separately.
Reference: [https://wiki.php.net/rfc/deprecate_dynamic_properties PHP RFC: Deprecate dynamic properties].
Follow-up to [53922].
Props jrf, hellofromTonya, markjaquith, peterwilsoncc, costdev, knutsp, aristath.
See #56513, #56034.
Built from https://develop.svn.wordpress.org/trunk@54133
git-svn-id: http://core.svn.wordpress.org/trunk@53692 1a063a9b-81f0-0310-95a4-ce76da25c4cd
From [https://mariadb.com/kb/en/mariadb-1061-release-notes/ MariaDB 10.6.1 release notes]:
> The `utf8` [https://mariadb.com/kb/en/character-sets/ character set] (and related collations) is now by default an alias for `utf8mb3` rather than the other way around. It can be set to imply `utf8mb4` by changing the value of the [https://mariadb.com/kb/en/server-system-variables/#old_mode old_mode] system variable ([https://jira.mariadb.org/browse/MDEV-8334 MDEV-8334]).
From [https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-30.html#mysqld-8-0-30-charset MySQL 8.0.30 release notes]:
> **Important Change:** A previous change renamed character sets having deprecated names prefixed with `utf8_` to use `utf8mb3_` instead. In this release, we rename the `utf8_` collations as well, using the `utf8mb3_` prefix; this is to make the collation names consistent with those of the character sets, not to rely any longer on the deprecated collation names, and to clarify the distinction between `utf8mb3` and `utf8mb4`. The names using the `utf8mb3_` prefix are now used exclusively for these collations in the output of `SHOW` statements such as `SHOW CREATE TABLE`, as well as in the values displayed in the columns of Information Schema tables including the `COLLATIONS` and `COLUMNS` tables.
This commit adds `utf8mb3_bin` and `utf8mb3_general_ci` to the list of safe collations recognized by `wpdb::check_safe_collation()`. The full list is now as follows:
* `utf8_bin`
* `utf8_general_ci`
* `utf8mb3_bin`
* `utf8mb3_general_ci`
* `utf8mb4_bin`
* `utf8mb4_general_ci`
The change is covered by existing database charset unit tests: six tests which previously failed on MariaDB 10.6.1+ or MySQL 8.0.30+ now pass.
Includes:
* Adjusting the expected test results based on MariaDB and MySQL version.
* Using named data providers for the affected tests to make test output more descriptive.
* Adding a failure message to each assertion when multiple assertions are used in the test.
References:
* [https://mariadb.com/kb/en/mariadb-1061-release-notes/ MariaDB 10.6.1 release notes]
* [https://jira.mariadb.org/browse/MDEV-8334 MDEV-8334 Rename utf8 to utf8mb3]
* [https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-30.html#mysqld-8-0-30-charset MySQL 8.0.30 release notes]
* [https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html The utf8mb3 Character Set (3-Byte UTF-8 Unicode Encoding)]
Follow-up to [30345], [32162], [37320].
Props skithund, ayeshrajans, JavierCasares, SergeyBiryukov.
Fixes#53623.
Built from https://develop.svn.wordpress.org/trunk@53918
git-svn-id: http://core.svn.wordpress.org/trunk@53477 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This renames the file containing the `wpdb` class to conform to the coding standards.
This commit also includes:
* A new `wp-db.php` that loads the new file, for anyone that may have been including the file directly.
* Replacing references to the old filename with the new filename.
Fixes#56268. See #55647.
Built from https://develop.svn.wordpress.org/trunk@53749
git-svn-id: http://core.svn.wordpress.org/trunk@53308 1a063a9b-81f0-0310-95a4-ce76da25c4cd
