This avoids a "Cannot access offset of type string on string" fatal error in `set_theme_mod()` on PHP 8 if the `theme_mods_$theme_slug` option has an incorrect value, e.g. an empty string instead of an array.
With this change, `set_theme_mod()` should be able to resolve the issue by saving a correct value.
Follow-up to [15736], [15739], [30672], [32629], [32632].
Props xknown.
See #51423.
Built from https://develop.svn.wordpress.org/trunk@51524
git-svn-id: http://core.svn.wordpress.org/trunk@51135 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This better aligns with developer expectations, as `add_theme_support()` and `remove_theme_support()` are meant to be called within functions attached to the `after_setup_theme` hook.
This also adds the `widgets-block-editor` feature to the docblock for `add_theme_support()`.
Props kevin940726, caseymilne, jamesros161, noisysocks, Mamaduka, audrasjb, zieladam, hellofromTonya, desrosj.
Fixes#53424.
Built from https://develop.svn.wordpress.org/trunk@51214
git-svn-id: http://core.svn.wordpress.org/trunk@50823 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Account for sites enabling Gutenberg as an mu-plugin when determining whether full-site-editing themes can be enabled. This replaces the check the plugin is active with a check whether the function `gutenberg_is_fse_theme()` is defined.
Follow up to [51193].
Props noisysocks, peterwilsoncc, SergeyBiryukov.
See #53410.
Built from https://develop.svn.wordpress.org/trunk@51197
git-svn-id: http://core.svn.wordpress.org/trunk@50806 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When a theme that uses the Full Site Editing feature is activated and the Gutenberg plugin is not present, the site will currently show a text notice on the front end. The user is not made aware of this unless they visit the front end of their site.
This adds a check that will prevent a theme from being activated when the `full-site-editing` tag is present in the theme’s `style.css` header and the Gutenberg plugin is not active to prevent this scenario.
These checks can be removed once Full Site Editing is completely merged into Core.
Props desrosj, marybaum, chanthaboune.
See #53410.
Built from https://develop.svn.wordpress.org/trunk@51193
git-svn-id: http://core.svn.wordpress.org/trunk@50802 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This affects:
* `validate_plugin_requirements()`
* `validate_theme_requirements()`
Historically, the `Requires PHP` header was introduced in #meta2952 for the Plugin Directory first, so at the time it made sense to have it defined in the same place as `Requires at least`, which only existed in `readme.txt`.
Since parsing of PHP and WordPress requirements was later added to WordPress core, the core should retrieve all the necessary data from the main plugin or theme file and not from `readme.txt`, which only contains the data meant for the Plugin or Theme Directory.
The recommended place for `Requires PHP` and `Requires at least` headers is as follows:
* The plugin's main PHP file
* The theme's `style.css` file
The place for the `Tested up to` header remains in `readme.txt` for the time being, as it's not used by WordPress core.
Follow-up to [44978], [45546], [47573], [47574], [meta5841], [meta9050].
Props afragen, Otto42, joyously, williampatton, audrasjb.
Fixes#48520. See #48515, #meta2952, #meta4514, #meta4621.
Built from https://develop.svn.wordpress.org/trunk@51092
git-svn-id: http://core.svn.wordpress.org/trunk@50701 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This shows a `_doing_it_wrong()` message and also returns false instead of true if no array of formats is passed in `add_theme_support()`, avoiding a PHP error.
Post formats maintainership comes full circle. 🙃
Props Mista-Flo, sproutchris, garrett-eclipse.
Fixes#51390.
Built from https://develop.svn.wordpress.org/trunk@49344
git-svn-id: http://core.svn.wordpress.org/trunk@49104 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Using the canonical function name for PHP functions is strongly recommended, as aliases may be deprecated or removed without (much) warning.
This replaces all uses of the following:
* `join()` with `implode()`
* `sizeof()` with `count()`
* `is_writeable()` with `is_writable()`
* `doubleval()` with a `(float)` cast
In part, this is a follow-up to #47746.
Props jrf.
See #50767.
Built from https://develop.svn.wordpress.org/trunk@49193
git-svn-id: http://core.svn.wordpress.org/trunk@48955 1a063a9b-81f0-0310-95a4-ce76da25c4cd
To accommodate for the change, the `custom-logo` theme feature now accepts the `unlink-homepage-logo` parameter.
If and when the logo is linked on the home page, the link has the `aria-current` attribute for better accessibility.
Follow-up to [48039], [48283].
Props sabernhardt, audrasjb, johnstonphilip, demetris.
Fixes#37011.
Built from https://develop.svn.wordpress.org/trunk@48749
git-svn-id: http://core.svn.wordpress.org/trunk@48511 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Currently themes can declare support for a given feature by using add_theme_support(). This commit adds a register_theme_feature() API that allows plugins and WordPress Core to declare a list of available features that themes can support.
The REST API uses this to expose a theme's supported features if the feature has been registered with "show_in_rest" set to true.
Props kadamwhite, spacedmonkey, williampatton, desrosj, TimothyBlynJacobs.
Fixes#49406.
Built from https://develop.svn.wordpress.org/trunk@48171
git-svn-id: http://core.svn.wordpress.org/trunk@47940 1a063a9b-81f0-0310-95a4-ce76da25c4cd
“The WordPress open source community cares about diversity. We strive to maintain a welcoming environment where everyone can feel included.”
With this commit, all occurrences of “whitelist” and “blacklist” (with the single exception of the `$new_whitelist_options` global variable) are removed. A new ticket has been opened to explore renaming the `$new_whitelist_options` variable (#50434).
Changing to more specific names or rewording sentences containing these terms not only makes the code more inclusive, but also helps provide clarity. These terms are often ambiguous. What is being blocked or allowed is not always immediately clear. This can make it more difficult for non-native English speakers to read through the codebase.
Words matter. If one contributor feels more welcome because these terms are removed, this was worth the effort.
Props strangerstudios, jorbin, desrosj, joemcgill, timothyblynjacobs, ocean90, ayeshrajans, davidbaumwald, earnjam.
See #48900, #50434.
Fixes#50413.
Built from https://develop.svn.wordpress.org/trunk@48121
git-svn-id: http://core.svn.wordpress.org/trunk@47890 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Partially reverts [48059] as there's no full consensus on the removal of the text prefix. Further actions should be taken to improve consistency and accessibility of the admin notices. Keeps some improvements to the translatable strings from [48059].
Fixes#47656.
Built from https://develop.svn.wordpress.org/trunk@48115
git-svn-id: http://core.svn.wordpress.org/trunk@47884 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The tag was supported in phpDocumentor 1.x, but is no longer supported in 2.x and 3.x.
Usage of static variables is considered an internal implementation detail and has no information value for someone reading the docs.
Props alishanvr, jrf.
Fixes#50426.
Built from https://develop.svn.wordpress.org/trunk@48109
git-svn-id: http://core.svn.wordpress.org/trunk@47878 1a063a9b-81f0-0310-95a4-ce76da25c4cd
For a number of years, most of the WordPress error messages have been prefixed with "Error:". However, these messages appear in a context where it's already clear an error occurred. Whether it's an error, a warning, or any other classification, that's not so relevant for users. The content of the message is the relevant part. The "Error:" prefix doesn't add great value while it does add unnecessary complexity for the message readability.
Also, revises some of these messages to improve clarity and removes HTML from translatable strings.
Props garrett-eclipse, ramiy, SergeyBiryukov, afercia, sabernhardt, quadthemes, audrasjb.
See #47003, #43037, #42945, #15887.
Fixes#47656.
Built from https://develop.svn.wordpress.org/trunk@48059
git-svn-id: http://core.svn.wordpress.org/trunk@47826 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In WordPress 3.2 support for IE6 was dropped, IE7 followed a few versions later. With the 4.8 release, WordPress officially ended support for Internet Explorer versions 8, 9, and 10. Yet, we still have shipped CSS for the unsupported IE versions....until now! Goodbye to ie.css and star hacks!
* Removes ie.css and `ie` style handle.
* Removes IE specific class names and any related CSS.
* Drops support for IE8 and older in `wp_customize_support_script()`.
* Updates compatibility mode for CSS minification to `ie11`.
Props ayeshrajans, isabel_brison, afercia, netweb, peterwilsoncc, ocean90.
Fixes#17232, #46015.
Built from https://develop.svn.wordpress.org/trunk@47771
git-svn-id: http://core.svn.wordpress.org/trunk@47547 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This avoids the performance overhead of the function call every time `dirname( __FILE__ )` was used instead of `__DIR__`.
This commit also includes:
* Removing unnecessary parentheses from `include`/`require` statements. These are language constructs, not function calls.
* Replacing `include` statements for several files with `require_once`, for consistency:
* `wp-admin/admin-header.php`
* `wp-admin/admin-footer.php`
* `wp-includes/version.php`
Props ayeshrajans, desrosj, valentinbora, jrf, joostdevalk, netweb.
Fixes#48082.
Built from https://develop.svn.wordpress.org/trunk@47198
git-svn-id: http://core.svn.wordpress.org/trunk@46998 1a063a9b-81f0-0310-95a4-ce76da25c4cd
John Blackbourn
Sergey Biryukov
desrosj
Peter Wilson
Helen Hou-Sandí
TimothyBlynJacobs
Andrea Fercia
Dominik Schilling