The list item separator is a locale property, and it doesn't make much sense to translate it separately in multiple projects. This changeset implements the following modifications:
- Define list item separator as a new WP_Locale property
- Add `wp_get_list_item_separator()` as a wrapper for `WP_Locale::get_list_item_separator`
- Replace `$wp_locale->get_list_item_separator()` calls with `wp_get_list_item_separator()`
- Added a compatibility layer for bundled themes
Props SergeyBiryukov, swissspidy, rsiddharth, johnbillion, audrasjb.
Fixes#39733.
Built from https://develop.svn.wordpress.org/trunk@52929
git-svn-id: http://core.svn.wordpress.org/trunk@52518 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This method calls get_block_templates once and uses block template properties
directly for filtering. This way, we can avoid hitting the database for each
public post type.
The previous method is useful when we already know the current post type we
request templates for, like when using REST API.
Follows [52334].
See #54335.
Props mamaduka, youknowriad.
Built from https://develop.svn.wordpress.org/trunk@52365
git-svn-id: http://core.svn.wordpress.org/trunk@51957 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This commit renames the following method and function to better represent block theme terminology:
* `WP_Theme::is_block_based()` to `WP_Theme::is_block_theme()`
* `wp_is_block_template_theme()` to `wp_is_block_theme()`
It also changes `wp_is_block_theme()` to be a helper wrapper (sugar syntax) for `wp_get_theme()->is_block_theme();`. Why? To ensure both the method and function behave the same, to help Gutenberg maintain WordPress cross-version compatibility, and to make it less cumbersome to port changes from Gutenberg to Core.
Follow-up to [52069], [52247], [52279].
Props antonvlasenko, costdev, hellofromTonya, noisysocks.
Fixes#54550.
Built from https://develop.svn.wordpress.org/trunk@52330
git-svn-id: http://core.svn.wordpress.org/trunk@51922 1a063a9b-81f0-0310-95a4-ce76da25c4cd
For block themes (like Twenty Twenty-Two), Customizer menu item is removed and replaced with the Site Editor menu item. However, other links exist in the Dashboard's welcome panel "Customize Your Site" button and the "Customize" button in each theme listed in the Appearance > Themes interface.
This commit changes each of those remaining links to link to the Site Editor interface instead of the Customizer.
To help identify block vs non-block themes, two method methods are introduced in `WP_Theme`:
* `WP_Theme:: is_block_based()` which identifies if the theme is a block theme or not.
* `WP_Theme::get_file_path()` which is similar to `get_theme_file_path()` but uses the directories within the theme object.
Both of these new methods include test coverage including the addition of a parent and child block theme in test data.
Follow-up to [18749], [35483], [42013], [42169].
Props antonvlasenko, jameskoster, hellofromTonya, matveb, noisysocks, poena, sergeybiryukov.
Fixes#54460.
Built from https://develop.svn.wordpress.org/trunk@52279
git-svn-id: http://core.svn.wordpress.org/trunk@51871 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This fixes the "Deprecated: Return type of `WP_Theme::[METHODNAME]($offset)` should be compatible with `ArrayAccess::[METHODNAME](): type`" warnings on PHP 8.1.
PHP native interfaces now have declared return types and methods in classes implementing these interfaces need to either have the return type declared (in a covariant compatible manner with the PHP native interface method declaration), or need to silence the deprecation warning using the `#[ReturnTypeWillChange]` attribute.
Follow-up to [51517].
Props jrf.
See #53635.
Built from https://develop.svn.wordpress.org/trunk@51529
git-svn-id: http://core.svn.wordpress.org/trunk@51140 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Add support for uploading, editing and saving WebP images when supported by the server.
Add 'image/webp' to supported mime types. Correctly identify WebP images and sizes even when PHP doesn't support WebP. Resize uploaded WebP files (when supported) and use for front end markup.
Props markoheijne, blobfolio, Clorith, joemcgill, atjn, desrosj, spacedmonkey, marylauc, mikeschroder, hellofromtonya, flixos90.
Fixes#35725.
Built from https://develop.svn.wordpress.org/trunk@50810
git-svn-id: http://core.svn.wordpress.org/trunk@50419 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
* Add missing translator comments.
* Fix placement of some translator comments. Translator comments should be on the line directly above the line containing the translation function call for optimal compatibility with various `.pot` file generation tools. The CS auto-fixing, which changed some inconsistent function calls to multi-line function calls, is part of the reason why this was no longer the case for a select group of translator comments.
Includes minor code layout fixes.
Polyglots, rejoice! All WordPress core files now have translator comments for all strings with placeholders!
Props jrf, subrataemfluence, GaryJ, webdados, Dency, swissspidy, alvarogois, marcomartins, mihaiiceyro, vladwtz, niq1982, flipkeijzer, michielatyoast, chandrapatel, thrijith, joshuanoyce, FesoVik, tessak22, bhaktirajdev, cleancoded, dhavalkasvala, garrett-eclipse, bibliofille, socalchristina, priyankkpatel, 5hel2l2y, adamsilverstein, JeffPaul, pierlo, SergeyBiryukov.
Fixes#44360.
Built from https://develop.svn.wordpress.org/trunk@45926
git-svn-id: http://core.svn.wordpress.org/trunk@45737 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Using the new fatal handler introduced in [44962], an email is sent to the admin when a fatal error occurs. This email includes a secret link to enter recovery mode. When clicked, the link will be validated and on success a cookie will be placed on the client, enabling recovery mode for that user. This functionality is executed early before plugins and themes are loaded, in order to be unaffected by potential fatal errors these might be causing.
When in recovery mode, broken plugins and themes will be paused for that client, so that they are able to access the admin backend despite of these errors. They are notified about the broken extensions and the errors caused, and can then decide whether they would like to temporarily deactivate the extension or fix the problem and resume the extension.
A link in the admin bar allows the client to exit recovery mode.
Props timothyblynjacobs, afragen, flixos90, nerrad, miss_jwo, schlessera, spacedmonkey, swissspidy.
Fixes#46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44973
git-svn-id: http://core.svn.wordpress.org/trunk@44804 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Due to the high number of follow-up tickets and associated security concerns, it was decided to reschedule the fatal error recovery feature for WordPress 5.2, in order to address these issues properly. The feature will continue to be developed, with iterations being merged into trunk early in the 5.2 release cycle.
Fixes#46141. See #44458, #45932, #45940, #46038, #46047, #46068.
Built from https://develop.svn.wordpress.org/trunk@44717
git-svn-id: http://core.svn.wordpress.org/trunk@44548 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset introduces a `WP_Shutdown_Handler` class that detects fatal errors and which extension (plugin or theme) causes them. Such an error is then recorded, and an error message is displayed. Subsequently, in certain protected areas, for example the admin, the broken extension will be paused, ensuring that the website is still usable in the respective area. The major benefit is that this mechanism allows site owners to still log in to their website, to fix the problem by either disabling the extension or solving the bug and then resuming the extension.
Extensions are only paused in certain designated areas. The frontend for example stays unaffected, as it is impossible to know what pausing the extension would cause to be missing, so it might be preferrable to clearly see that the website is temporarily not accessible instead.
The fatal error recovery is especially important in scope of encouraging the switch to a maintained PHP version, as not necessarily every WordPress extension is compatible with all PHP versions. If problems occur now, non-technical site owners that do not have immediate access to the codebase are not locked out of their site and can at least temporarily solve the problem quickly.
Websites that have custom requirements in that regard can implement their own shutdown handler by adding a `shutdown-handler.php` drop-in that returns the handler instance to use, which must be based on a class that inherits `WP_Shutdown_Handler`. That handler will then be used in place of the default one.
Websites that would like to modify specifically the error template displayed in the frontend can add a `php-error.php` drop-in that works similarly to the existing `db-error.php` drop-in.
Props afragen, bradleyt, flixos90, ocean90, schlessera, SergeyBiryukov, spacedmonkey.
Fixes#44458.
Built from https://develop.svn.wordpress.org/trunk@44524
git-svn-id: http://core.svn.wordpress.org/trunk@44355 1a063a9b-81f0-0310-95a4-ce76da25c4cd
After [44149], we can now make twentynineteen the default theme. Twentyseventeen has been a great default, but 5.0 and twentynineteen is guten.
Merges [43809,43954] from the 5.0 branch to trunk.
Fixes#45152.
Props jorbin, SergeyBiryukov, pento, mcsf.
Built from https://develop.svn.wordpress.org/trunk@44151
git-svn-id: http://core.svn.wordpress.org/trunk@43981 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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
audrasjb
John Blackbourn
Sergey Biryukov
noisysocks
youknowriad
hellofromTonya
desrosj
Adam Silverstein
Andrea Fercia
Gary Pendergast
Felix Arntz