This PR migrates the Style Engine PHP functions, classes and tests into Core for 6.1. It backports the original [WordPress/gutenberg#40260 PR #40260] from Gutenberg repository.
Props ramonopoly, bernhard-reiter, costdev, azaozz, andrewserong, mukesh27, aristath.
See #56467.
Built from https://develop.svn.wordpress.org/trunk@54156
git-svn-id: http://core.svn.wordpress.org/trunk@53715 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, when using `switch_to_locale()` all current loaded text domains were unloaded and added to the `$l10n_unloaded` global. This prevented the just-in-time loading for text domains after a switch. The just-in-time loading was also only possible if the translations were stored in `WP_LANG_DIR`. Both issues have been fixed.
* Adds `WP_Textdomain_Registry` to keep track of the language directory paths for all plugins and themes.
* Updates all `load_*_textdomain()` functions to store the path in `WP_Textdomain_Registry`.
* Adds `$locale` parameter to `load_textdomain()` to specify the locale the translation file is for.
* Adds `$reloadable` parameter to `unload_textdomain()` to define whether a text domain can be loaded just-in-time again. This is used by `WP_Locale_Switcher::load_translations()`.
* Extends `_load_textdomain_just_in_time()` to also support text domains of plugins and themes with custom language directories.
* Fixes the incorrect `test_plugin_translation_after_switching_locale_twice()` test which should have caught this issue earlier.
* Adds a new test plugin and theme to test the loading of translations with a custom language directory.
* Deprecates the now unused and private `_get_path_to_translation()` and `_get_path_to_translation_from_lang_dir()` functions.
Previously added in [49236] and reverted in [49236] to investigate concerns which are now addressed here.
Props yoavf, swissspidy, dd32, ocean90.
See #26511.
Fixes#39210.
Built from https://develop.svn.wordpress.org/trunk@53874
git-svn-id: http://core.svn.wordpress.org/trunk@53433 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Related Gutenberg issue: https://github.com/WordPress/gutenberg/issues/39889.
Backporting changes from the Gutenberg plugin:
- new Block Patterns REST API endpoint
- new Block Pattern Categories REST API endpoint
- updates to Query Loop related patterns
- support for custom taxonomies in Query Loop block
Props hellofromtonya, peterwilsoncc, ntsekouras, zieladam, ironprogrammer, spacedmonkey, timothyblynjacobs, antonvlasenko, jsnajdr.
See #55505.
Built from https://develop.svn.wordpress.org/trunk@53152
git-svn-id: http://core.svn.wordpress.org/trunk@52741 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Migrate spacing, border, color, dimensions, elements and typography and associated tests for block supports in the block editor.
Related changes in Gutenberg:
- Include individual serialization changes from 6de16981c7
- Skip Style Engine integration from 44925a947f%60
Props ramonopoly, aaronrobertshaw.
See #55505.
Built from https://develop.svn.wordpress.org/trunk@53076
git-svn-id: http://core.svn.wordpress.org/trunk@52665 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset decreases the chance of accidentally overwriting some variables located in `wp-settings.php`, as the chance of overriding a variable called `$_wp_plugin_file` would be lower than for `$plugin`, `$mu_plugin` or `$network_plugin`.
Props stevegrunwell, joyously, peterwilsoncc, ocean90, SergeyBiryukov, jrf, azouamauriac.
Fixes#55432.
Built from https://develop.svn.wordpress.org/trunk@53004
git-svn-id: http://core.svn.wordpress.org/trunk@52593 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Add a REST API to export site templates and template part as html files. When the REST API is requested, it responds by downloading a single ZIP file and exits early, without completing full request. To create the exported zip, the ZipArchive class is required. If this class is not present then the export will gracefully fail, returning a `WP_Error` object and 500 status error code.
Props spacedmonkey, youknowriad, Mamaduka, walbo, peterwilsoncc.
Fixes#54448 .
Built from https://develop.svn.wordpress.org/trunk@52286
git-svn-id: http://core.svn.wordpress.org/trunk@51878 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Navigation area were merged as part of full site editing and the new navigation block. This functionality is experimental and not currently used in WordPress core, so should be removed.
Props noisysocks, spacedmonkey, get_dave, zieladam.
Fixes#54506.
Built from https://develop.svn.wordpress.org/trunk@52272
git-svn-id: http://core.svn.wordpress.org/trunk@51864 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This commit introduces the `/wp/v2/menus`, `/wp/v2/menu-items` and `/wp/v2/menu-locations` REST API endpoints. These endpoints are fully available to users with the `edit_theme_options` capability, but can be read by any user who can edit a REST API available post type.
The `nav_menu` taxonomy and `nav_menu_item` post type now map their capabilities to the `edit_theme_options` primitive capability. This allows developers to provide more fine-grained access control. However, if a developer is currently dynamically removing the `edit_theme_options` capability using `map_meta_cap`, they should use the `user_has_cap` filter instead.
The `wp_update_nav_menu_item()` function has been adjusted to return an error if saving the menu item post or assigning the menu item to a menu generate an error.
Lastly, a new menu item type is introduced, `block`, that can be used to store a Block as a menu item.
Props andraganescu, antonvlasenko, dingo_d, dlh, isabel_brison, kadamwhite, Mamaduka, NateWr, noisysocks, peterwilsoncc, ryelle, schlessera, soean, Spacedmonkey, talldanwp, TimothyBlynJacobs, tobifjellner, westonruter, wpscholar, zieladam.
Fixes#40878.
Built from https://develop.svn.wordpress.org/trunk@52079
git-svn-id: http://core.svn.wordpress.org/trunk@51671 1a063a9b-81f0-0310-95a4-ce76da25c4cd
- First pass at adding the site editor from the Gutenberg plugin to
wp-admin/site-editor.php.
- Adds miscellaneous PHP changes from Gutenberg 10.1 - 11.9.
Follows [52042].
See #54337.
Props youknowriad, aristath, hellofromtonya, gziolo.
Built from https://develop.svn.wordpress.org/trunk@52069
git-svn-id: http://core.svn.wordpress.org/trunk@51661 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This renames the file containing the `WP_Http` class to conform to the coding standards.
This commit also includes:
- A new `class-http.php` that includes the new file, for anyone that may've been including the file directly.
- Replaces references to the old filename with the new filename.
Follow-up to [8516], [13274], [33748].
Fixes#54389. See #53359.
Built from https://develop.svn.wordpress.org/trunk@52026
git-svn-id: http://core.svn.wordpress.org/trunk@51618 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adds a new REST API endpoint (`/wp-block-editor/v1/url-details`) for retrieving information from an external URL.
Information retrieved:
* Title: content of the `<title>` element
* Icon: favicon image link
* Description: content of the `description` or `og:description` meta element
* Image: OG image link
This endpoint is used by the block editor for link previews.
Props get_dave, aduth, andraganescu, beaulebens, hellofromTonya, kevin940726, mamaduka, marekhrabe, mnelson4, noisysocks, obenland, ocean90, retrofox, shaunandrews, spacedmonkey, swissspidy, timothyblynjacobs, xknown, youknowriad.
Fixes#54358.
Built from https://develop.svn.wordpress.org/trunk@51973
git-svn-id: http://core.svn.wordpress.org/trunk@51562 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This ensures correct load order when style concatenation is used, e.g. when `SCRIPT_DEBUG` is off.
Additionally, make sure the `WP_CONTENT_DIR` constant is defined for use in `get_theme_root()` via `get_stylesheet_directory()`.
Follow-up to [50992], [51001], [51013].
Props nosolosw.
See #53175.
Built from https://develop.svn.wordpress.org/trunk@51056
git-svn-id: http://core.svn.wordpress.org/trunk@50665 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Add an endpoint for fetching block patterns from WordPress.org, and load the block patterns from this new API. Remove the block patterns that have already been moved to WordPress.org/patterns.
Props ryelle, iandunn, youknowriad, timothyblynjacobs.
Fixes#53246.
Built from https://develop.svn.wordpress.org/trunk@51021
git-svn-id: http://core.svn.wordpress.org/trunk@50630 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This is the first piece of landing the theme.json processing in WordPress core.
It allows themes to configure the different editor settings, allow cusomizations and define presets in theme.json file.
Props jorgefilipecosta, nosolosw.
See #53175.
Built from https://develop.svn.wordpress.org/trunk@50959
git-svn-id: http://core.svn.wordpress.org/trunk@50568 1a063a9b-81f0-0310-95a4-ce76da25c4cd
It is going to be used on the new widgets editor screen. This patch also introduced a new class WP_Block_Editor_Context that is going to be used with revised block editor filters to let extenders to keep their existing behavior. It should also allow to provide more settings through the context class as new screens get introduced like the navigation editor.
Props azaozz, chrisvanpatten, timothyblynjacobs, youknowriad.
Fixes#52920.
Built from https://develop.svn.wordpress.org/trunk@50956
git-svn-id: http://core.svn.wordpress.org/trunk@50565 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This also includes:
- The removal of the Post Author block.
- Renaming build_query_vars_from_query_block function.
- Update the block supports.
Props gziolo.
See #52991.
-This line, and those below, will be ignored--
M package-lock.json
M package.json
M src/wp-includes/assets/script-loader-packages.php
M src/wp-includes/block-supports/colors.php
AM src/wp-includes/block-supports/elements.php
D src/wp-includes/block-supports/padding.php
AM src/wp-includes/block-supports/spacing.php
M src/wp-includes/block-supports/typography.php
M src/wp-includes/blocks/column/block.json
M src/wp-includes/blocks/index.php
D src/wp-includes/blocks/post-author
D src/wp-includes/blocks/post-author.php
M src/wp-includes/blocks/post-content.php
M src/wp-includes/blocks/post-featured-image.php
M src/wp-includes/blocks/query/block.json
M src/wp-includes/blocks/query-loop/block.json
M src/wp-includes/blocks/query-loop.php
M src/wp-includes/blocks/query-pagination/block.json
M src/wp-includes/blocks/query-pagination-next.php
M src/wp-includes/blocks/query-pagination-numbers.php
M src/wp-includes/blocks/site-tagline/block.json
M src/wp-includes/blocks/site-title/block.json
M src/wp-includes/blocks.php
M src/wp-settings.php
M tests/phpunit/tests/blocks/block.php
M tools/webpack/packages.js
Built from https://develop.svn.wordpress.org/trunk@50945
git-svn-id: http://core.svn.wordpress.org/trunk@50554 1a063a9b-81f0-0310-95a4-ce76da25c4cd
It contains several changes in addition to regular update to WordPress packages:
- All newly exposed blocks are now registered on the server.
- Dutone block support was added.
- Border block support was updated.
- New shared function `construct_wp_query_args` was added for the family of Query blocks - it might need some further work.
Props youknowriad.
See #52991.
Built from https://develop.svn.wordpress.org/trunk@50929
git-svn-id: http://core.svn.wordpress.org/trunk@50538 1a063a9b-81f0-0310-95a4-ce76da25c4cd
There are several WordPress hooks defined on the server that depend on $post object that isn’t present on the new screens like edit site, edit widgets, or edit navigation. This patch deprecates existing filters and introduces replacements that are context-aware.
Props azaozz, andraganescu, jeremyfelt, nosolosw, youknowriad.
See #52920.
Built from https://develop.svn.wordpress.org/trunk@50776
git-svn-id: http://core.svn.wordpress.org/trunk@50385 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Switching a WordPress site from HTTP to HTTPS has historically been a tedious task. While on the surface the Site Address and WordPress Address have to be updated, existing content still remains using HTTP URLs where hard-coded in the database. Furthermore, updating _two_ URLs to migrate to HTTPS is still a fairly unintuitive step which is not clearly explained.
This changeset simplifies migration from HTTP to HTTPS and, where possible, makes it a one-click interaction.
* Automatically replace insecure versions of the Site Address (`home_url()`) with its HTTPS counterpart on the fly if the site has been migrated from HTTP to HTTPS. This is accomplished by introducing a `https_migration_required` option and enabling it when the `home_url()` is accordingly changed.
* A new `wp_replace_insecure_home_url()` function is hooked into various pieces of content to replace URLs accordingly.
* The migration only kicks in when the Site Address (`home_url()`) and WordPress Address (`site_url()`) match, which is the widely common case. Configurations where these differ are often maintained by more advanced users, where this migration routine would be less essential - something to potentially iterate on in the future though.
* The migration does not actually update content in the database. More savvy users that prefer to do that can prevent the migration logic from running by either deleting the `https_migration_required` option or using the new `wp_should_replace_insecure_home_url` filter.
* For fresh sites that do not have any content yet at the point of changing the URLs to HTTPS, the migration will also be skipped since it would not be relevant.
* Expose a primary action in the Site Health recommendation, if HTTPS is already supported by the environment, built on top of the HTTPS detection mechanism from [49904]. When clicked, the default behavior is to update `home_url()` and `site_url()` in one go to their HTTPS counterpart.
* A new `wp_update_urls_to_https()` function takes care of the update routine.
* A new `update_https` meta capability is introduced to control access.
* If the site's URLs are controlled by constants, this update is not automatically possible, so in these scenarios the user is informed about that in the HTTPS status check in Site Health.
* Allow hosting providers to modify the URLs linked to in the HTTPS status check in Site Health, similar to how that is possible for the URLs around updating the PHP version.
* A `WP_UPDATE_HTTPS_URL` environment variable or `wp_update_https_url` filter can be used to provide a custom URL with guidance about updating the site to use HTTPS.
* A `WP_DIRECT_UPDATE_HTTPS_URL` environment variable or `wp_direct_update_https_url` filter can be used to provide a custom URL for the primary CTA to update the site to use HTTPS.
Props flixos90, timothyblynjacobs.
Fixes#51437.
Built from https://develop.svn.wordpress.org/trunk@50131
git-svn-id: http://core.svn.wordpress.org/trunk@49810 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset introduces a filter-based Robots API, providing central control over the `robots` meta tag.
* Introduces `wp_robots()` function which should be called anywhere a `robots` meta tag should be included.
* Introduces `wp_robots` filter which allows adding or modifying directives for the `robots` meta tag. The `wp_robots()` function is entirely filter-based, i.e. if no filter is added to `wp_robots`, no directives will be present, and therefore the entire `robots` meta tag will be omitted.
* Introduces the following `wp_robots` filter functions which replace similar existing functions that were manually rendering a `robots` meta tag:
* `wp_robots_noindex()` replaces `noindex()`, which has been deprecated.
* `wp_robots_no_robots()` replaces `wp_no_robots()`, which has been deprecated.
* `wp_robots_sensitive_page()` replaces `wp_sensitive_page_meta()`, which has been deprecated. Its rendering of the `referrer` meta tag has been moved to another new function `wp_strict_cross_origin_referrer()`.
Migration to the new functions is straightforward. For example, a call to `add_action( 'wp_head', 'wp_no_robots' )` should be replaced with `add_filter( 'wp_robots', 'wp_robots_no_robots' )`.
Plugins and themes that render their own `robots` meta tags are encouraged to switch to rely on the `wp_robots` filter in order to use the central management layer now provided by WordPress core.
Props adamsilverstein, flixos90, timothyblynjacobs, westonruter.
See #51511.
Built from https://develop.svn.wordpress.org/trunk@49992
git-svn-id: http://core.svn.wordpress.org/trunk@49693 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset modifies the Site Health panel for HTTPS to provide more accurate recommendations based on whether the environment is already set up for HTTPS.
* Introduces `wp_is_using_https()` to check whether the site is configured to use HTTPS (via its Site Address and WordPress Address).
* Introduces `wp_is_https_supported()` to check whether the environment supports HTTPS. This relies on a cron job which periodically checks support using a loopback request.
Props Clorith, flixos90, miinasikk, westonruter.
Fixes#47577.
Built from https://develop.svn.wordpress.org/trunk@49904
git-svn-id: http://core.svn.wordpress.org/trunk@49603 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, when using `switch_to_locale()` all current loaded text domains were unloaded and added to the `$l10n_unloaded` global. This prevented the just-in-time loading for text domains after a switch. The just-in-time loading was also only possible if the translations were stored in `WP_LANG_DIR`. Both issues have been fixed.
* Adds `WP_Textdomain_Registry` to keep track of the language directory paths for all plugins and themes.
* Updates all `load_*_textdomain()` functions to store the path in `WP_Textdomain_Registry`.
* Adds `$reloadable` parameter to `unload_textdomain()` to define whether a text domain can be loaded just-in-time again. This is used by `WP_Locale_Switcher::load_translations()`.
* Extends `_load_textdomain_just_in_time()` to also support text domains of plugins and themes with custom language directories.
* Fixes the incorrect `test_plugin_translation_after_switching_locale_twice()` test which should have catch this issue earlier.
* Adds a new test plugin/theme to test the loading of translations with a custom language directory.
* Deprecates the now unused and private `_get_path_to_translation()` and `_get_path_to_translation_from_lang_dir()` functions.
Props yoavf, swissspidy, dd32, ocean90.
See #26511.
Fixes#39210.
Built from https://develop.svn.wordpress.org/trunk@49236
git-svn-id: http://core.svn.wordpress.org/trunk@48998 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This includes the packages that match the Gutenberg 9.2 Release.
It is going to be the last block-editor features update for WordPress 5.6.
It also updates the block-supports code base to the latest APIs.
Props isabel_brison, noisysocks, desrosj.
Fixes#51570.
Built from https://develop.svn.wordpress.org/trunk@49226
git-svn-id: http://core.svn.wordpress.org/trunk@48988 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This provides more flexibility when writing tests and benefits from running in a front-end context which is necessary for some tests like checking that updates are supported. Additionally, this provides a more robust interface for developers who want to integrate with Site Health tests.
Because the `wp/v2` endpoint is reserved for modeling core entities, site health is registered in its own `wp-site-health/v1` namespace.
The existing ajax actions have been maintained for backward compatibility.
Props Clorith, chrisvanpatten, afragen, pokhriyal, TimothyBlynJacobs.
Fixes#48105.
Built from https://develop.svn.wordpress.org/trunk@49154
git-svn-id: http://core.svn.wordpress.org/trunk@48916 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In WordPress 4.4 the REST API was first introduced. A few releases later in WordPress 4.7, the Content API endpoints were added, paving the way for Gutenberg and countless in-site experiences. In the intervening years, numerous plugins have built on top of the REST API. Many developers shared a common frustration, the lack of external authentication to the REST API.
This commit introduces Application Passwords to allow users to connect to external applications to their WordPress website. Users can generate individual passwords for each application, allowing for easy revocation and activity monitoring. An authorization flow is introduced to make the connection flow simple for users and application developers.
Application Passwords uses Basic Authentication, and by default is only available over an SSL connection.
Props georgestephanis, kasparsd, timothyblynjacobs, afercia, akkspro, andraganescu, arippberger, aristath, austyfrosty, ayesh, batmoo, bradyvercher, brianhenryie, helen, ipstenu, jeffmatson, jeffpaul, joostdevalk, joshlevinson, kadamwhite, kjbenk, koke, michael-arestad, Otto42, pekz0r, salzano, spacedmonkey, valendesigns.
Fixes#42790.
Built from https://develop.svn.wordpress.org/trunk@49109
git-svn-id: http://core.svn.wordpress.org/trunk@48871 1a063a9b-81f0-0310-95a4-ce76da25c4cd
These endpoints facilitate the Block Directory Inserter feature in Gutenberg. Users can now install, activate, deactivate, and delete plugins over the REST API. The block directoryendpoint allows searching for available blocks from the WordPress.org block directory.
Props cklee, talldanwp, noisysocks, joen, soean, youknowriad, dufresnesteven, gziolo, dd32, tellyworth, ryelle, spacedmonkey, TimothyBlynJacobs.
Fixes#50321.
Built from https://develop.svn.wordpress.org/trunk@48242
git-svn-id: http://core.svn.wordpress.org/trunk@48011 1a063a9b-81f0-0310-95a4-ce76da25c4cd
While web crawlers are able to discover pages from links within the site and from other sites, XML sitemaps supplement this approach by allowing crawlers to quickly and comprehensively identify all URLs included in the sitemap and learn other signals about those URLs using the associated metadata.
See https://make.wordpress.org/core/2020/06/10/merge-announcement-extensible-core-sitemaps/ for more details.
This feature exposes the sitemap index via `/wp-sitemap.xml` and exposes a variety of new filters and hooks for developers to modify the behavior. Users can disable sitemaps completely by turning off search engine visibility in WordPress admin.
This change also introduces a new `esc_xml()` function to escape strings for output in XML, as well as XML support to `wp_kses_normalize_entities()`.
Props Adrian McShane, afragen, adamsilverstein, casiepa, flixos90, garrett-eclipse, joemcgill, kburgoine, kraftbj, milana_cap, pacifika, pbiron, pfefferle, Ruxandra Gradina, swissspidy, szepeviktor, tangrufus, tweetythierry.
Fixes#50117.
See #3670. See #19998.
Built from https://develop.svn.wordpress.org/trunk@48072
git-svn-id: http://core.svn.wordpress.org/trunk@47839 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `register_globals` directive in PHP was deprecated in version 5.3 and removed entirely in 5.4.
Now that WordPress only supports PHP 5.6.20 and newer, the `wp_unregister_GLOBALS()` function can be deprecated.
Props ayeshrajans, desrosj, SergeyBiryukov.
Fixes#49938.
Built from https://develop.svn.wordpress.org/trunk@47612
git-svn-id: http://core.svn.wordpress.org/trunk@47387 1a063a9b-81f0-0310-95a4-ce76da25c4cd
As the WP_Site_Health class is instantiated prior to plugins being required and the `plugins_loaded` hook being fired, it prevents plugins from using the following hooks in the functions called by `maybe_create_scheduled_event()`.
Fixes#49824.
Props peterwilsoncc, whyisjake.
Built from https://develop.svn.wordpress.org/trunk@47568
git-svn-id: http://core.svn.wordpress.org/trunk@47343 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
Core did not include the navigation block PHP files.
This commit fixes the issue referred, and now the navigation block is executed on the frontend. The block still does not work as expected and throws an error during frontend execution. That problem is going to be fixed on the next WordPress package update.
This commit adds the file as it is on the npm package used.
Props gziolo.
Fixes#49348.
Built from https://develop.svn.wordpress.org/trunk@47176
git-svn-id: http://core.svn.wordpress.org/trunk@46976 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The widget informs administrators of any potential issues that should be addressed to improve the performance or security of their website, and directs them to the Site Health screen for more details.
Props Clorith, hedgefield, guddu1315.
See #47606.
Built from https://develop.svn.wordpress.org/trunk@47063
git-svn-id: http://core.svn.wordpress.org/trunk@46863 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, `wp_favicon_request()` was introduced in [13205] to avoid a performance hit of serving a full 404 page on every favicon request.
While working as intended, that implementation did not provide a way for theme or plugin authors to manage the behavior of favicon requests.
This changeset implements the following logic (only applied if WordPress is installed in the root directory):
* If there is a Site Icon set in Customizer, redirect `/favicon.ico` requests to that icon.
* Otherwise, use the WordPress logo as a default icon.
* If a physical `/favicon.ico` file exists, do nothing, let the server handle the request.
Handling `/favicon.ico` is now more consistent with handling `/robots.txt` requests.
New functions and hooks:
* Introduce `is_favicon()` conditional tag to complement `is_robots()`.
* Introduce `do_favicon` action to complement `do_robots` and use it in template loader.
* Introduce `do_favicon()` function, hooked to the above action by default, to complement `do_robots()`.
* Introduce `do_faviconico` action to complement `do_robotstxt`, for plugins to override the default behavior.
* Mark `wp_favicon_request()` as deprecated in favor of `do_favicon()`.
Props jonoaldersonwp, birgire, joostdevalk, mukesh27, SergeyBiryukov.
Fixes#47398.
Built from https://develop.svn.wordpress.org/trunk@47018
git-svn-id: http://core.svn.wordpress.org/trunk@46818 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This renames the file containing the `WP_Date_Query` class to conform to the coding standards.
This commit also includes:
- A new `date.php` that includes the new file, for anyone that may've been including the file directly.
- Replaces references to the old filename with the new filename.
Fixes#47775. See #47632.
Built from https://develop.svn.wordpress.org/trunk@45678
git-svn-id: http://core.svn.wordpress.org/trunk@45489 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This renames the file containing the `WP_oEmbed` class to conform to the coding standards.
This commit also includes:
- A new `class-oembed.php` that includes the new file, for anyone that may've been including the file directly.
- Replaces references to the old filename with the new filename.
See #47632.
Built from https://develop.svn.wordpress.org/trunk@45663
git-svn-id: http://core.svn.wordpress.org/trunk@45474 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Noteable changes:
- The `magic_quotes_runtime` and `magic_quotes_sybase` settings were removed in PHP 5.4, so no longer need to be set.
- Some functions that use external libraries can generate errors that can't be tested for, so are globally allowed to silence errors.
- Quite a few functions would cause errors if `safe_mode` was set. This setting was removed in PHP 5.4.
- Only a handful of `header()` calls needed corresponding `headers_sent()` checks for unit tests to pass, but more may need to be added as the nightlies builds are tested.
See #46732.
Built from https://develop.svn.wordpress.org/trunk@45611
git-svn-id: http://core.svn.wordpress.org/trunk@45422 1a063a9b-81f0-0310-95a4-ce76da25c4cd
If a fatal error occurs midway through a page load, or in a REST API request, it still needs to be handled internally for the recovery mode, but the custom message may conflict with already rendered output, e.g. by displaying HTML markup in an XML or JSON request.
Props spacedmonkey, flixos90, TimothyBlynJacobs.
Fixes#45989. See #44458.
Built from https://develop.svn.wordpress.org/trunk@45014
git-svn-id: http://core.svn.wordpress.org/trunk@44823 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
This changeset introduces a `WP_Fatal_Error_Handler` class that detects fatal errors and displays a more user-friendly message about the site experiencing technical difficulties.
Websites that have custom requirements in that regard can implement their own fatal error handler by adding a `fatal-error-handler.php` drop-in that returns the handler instance to use, which must be based on a class that inherits `WP_Fatal_Error_Handler`. That handler will then be used in place of the default one. Alternatively, the fatal error handler feature can be completely disable through a constant `WP_DISABLE_FATAL_ERROR_HANDLER`.
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. For more granular customization, the fatal error handler also includes new filters `wp_should_handle_php_error`, `wp_php_error_message` and `wp_php_error_args`.
Props afragen, bradleyt, flixos90, ocean90, schlessera, SergeyBiryukov, spacedmonkey, timothyblynjacobs.
See #46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44962
git-svn-id: http://core.svn.wordpress.org/trunk@44793 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
The `WP_Shutdown_Handler` name plus related function names were premature when originally committed, as there can be multiple shutdown handlers in PHP, and WordPress makes use of that feature. This changeset modifies the name to a more appropriate `WP_Fatal_Error_Handler`, and related to that changes the following names:
* The drop-in to override the handler is now called `fatal-error-handler.php`.
* The internal function `wp_register_premature_shutdown_handler` is now called `wp_register_fatal_error_handler()`.
In addition to these naming changes, a new constant `WP_DISABLE_FATAL_ERROR_HANDLER` is introduced that can be set in `wp-config.php` to entirely disable the fatal error handler. That constant's value is and should be accessed indirectly via a new `wp_is_fatal_error_handler_enabled()` function and is filterable via a new `wp_fatal_error_handler_enabled` hook. Note that disabling the fatal error handler will skip the new functionality entirely, including the potentially used `fatal-error-handler.php` drop-in.
The new set of constant, filter and function provide for an easier-to-use mechanism to disable the fatal error handler altogether, rather than requiring developers to implement a drop-in for purely that purpose.
Props afragen, flixos90, joyously, knutsp, markjaquith, ocean90, schlessera, spacedmonkey.
Fixes#46047. See #44458.
Built from https://develop.svn.wordpress.org/trunk@44674
git-svn-id: http://core.svn.wordpress.org/trunk@44505 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
* `plugin_loaded`: Fires once a single activated plugin has loaded.
* `mu_plugin_loaded`: Fires once a single must-use plugin has loaded.
* `network_plugin_loaded`: Fires once a single network-activated plugin has loaded.
Props Rarst, schlessera.
Fixes#41346.
Built from https://develop.svn.wordpress.org/trunk@44344
git-svn-id: http://core.svn.wordpress.org/trunk@44174 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`WP_REST_Block_Renderer_Controller` allows rendering of server-side rendered blocks, whilst `WP_REST_Blocks_Controller` allows retrieving of reusable blocks.
Merges [43805] and [43806] from the 5.0 branch to trunk.
Props desrosj, danielbachhuber, pento, Presskopp, swissspidy.
See #45065, #45098.
Built from https://develop.svn.wordpress.org/trunk@44150
git-svn-id: http://core.svn.wordpress.org/trunk@43980 1a063a9b-81f0-0310-95a4-ce76da25c4cd
- Adds `WP_REST_Autosaves_Controller` which extends `WP_REST_Revisions_Controller`.
- Autosaves endpoint is registered for all post types except attachment because even post types without revisions enabled are expected to autosave.
- Because setting the `DOING_AUTOSAVE` constant pollutes the test suite, autosaves tests are run last. We may want to improve upon this later.
Also, use a truly impossibly high number in User Controller tests. The number `100`, (or `7777` in `trunk`), could be valid in certain test run configurations. The `REST_TESTS_IMPOSSIBLY_HIGH_NUMBER` constant is impossibly high for this very reason.
Finally, Skip Autosaves controller test for multisite. There's a PHP 5.2 edge case where paths calculated differently, possibly caused by differing version of PHPUnit.
Props adamsilverstein, aduth, azaozz, danielbachhuber, rmccue, danielbachhuber.
Merges [43767], [43768], [43769] to trunk.
See #45132, #45131.
Fixes#45128, #43316.
Built from https://develop.svn.wordpress.org/trunk@44126
git-svn-id: http://core.svn.wordpress.org/trunk@43956 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `WP_Block_Parser` class, and the accompanying `parse_blocks()` helper function, can be used to parse an array of blocks out of a content string.
`WP_Block_Parser` is copied from the `@wordpress/block-serialization-default-parser` package. To ensure it stays in sync with the JavaScript parser, changes should be implemented in the package first, then the package version should be upgraded to include the changes.
Props pento.
Merges [43751] to trunk.
See #45109.
Built from https://develop.svn.wordpress.org/trunk@44116
git-svn-id: http://core.svn.wordpress.org/trunk@43946 1a063a9b-81f0-0310-95a4-ce76da25c4cd
These are the foundational classes allowing blocks to be registered and used throughout WordPress.
This commit also includes the `has_block()` and `has_blocks()` functions, which are required for unit testing these classes.
Merges [43742] from the 5.0 branch to trunk.
Props adamsilverstein, danielbachhuber, desrosj.
Fixes#45097.
See #45109.
Built from https://develop.svn.wordpress.org/trunk@44108
git-svn-id: http://core.svn.wordpress.org/trunk@43938 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introduces a `WP_REST_Search_Controller` class which registers a `/wp/v2/search` endpoint. Search types are handled by extending `WP_REST_Search_Handler`. The default search type is `WP_REST_Post_Search_Handler` but can be filtered by plugins or a theme.
Merges [43739,43741] from the 5.0 branch to trunk.
Props danielbachhuber, flixos90, pento, rmccue, joehoyle.
Fixes#39965.
Built from https://develop.svn.wordpress.org/trunk@44107
git-svn-id: http://core.svn.wordpress.org/trunk@43937 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In order to correctly render parts of its UI, the new editor needs to be aware of the active theme's post-formats and post-thumbnails support. This data is exposed by querying for the active theme on a new /wp/v2/themes endpoint for sufficiently privileged users.
Merges [43734], [43735] to trunk.
props desrosj.
Fixes#45016.
Built from https://develop.svn.wordpress.org/trunk@43985
git-svn-id: http://core.svn.wordpress.org/trunk@43817 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Edits to active plugins which cause PHP fatal errors will no longer auto-deactivate the plugin. Supersedes #39766.
* Introduce sandboxed PHP file edits for active themes, preventing accidental whitescreening of a user's site when introducing a fatal error.
* After writing a change to a PHP file for an active theme or plugin, perform loopback requests on the file editor admin screens and the homepage to check for fatal errors. If a fatal error is encountered, roll back the edited file and display the error to the user to fix and try again.
* Introduce a secure way to scrape PHP fatal errors from a site via `wp_start_scraping_edited_file_errors()` and `wp_finalize_scraping_edited_file_errors()`.
* Moves file modifications from `theme-editor.php` and `plugin-editor.php` to common `wp_edit_theme_plugin_file()` function.
* Refactor themes and plugin editors to submit file changes via Ajax instead of doing full page refreshes when JS is available.
* Use `get` method for theme/plugin dropdowns.
* Improve styling of plugin editors, including width of plugin/theme dropdowns.
* Improve notices API for theme/plugin editor JS component.
* Strip common base directory from plugin file list. See #24048.
* Factor out functions to list editable file types in `wp_get_theme_file_editable_extensions()` and `wp_get_plugin_file_editable_extensions()`.
* Scroll to line in editor that has linting error when attempting to save. See #41886.
* Add checkbox to dismiss lint errors to proceed with saving. See #41887.
* Only style the Update File button as disabled instead of actually disabling it for accessibility reasons.
* Ensure that value from CodeMirror is used instead of `textarea` when CodeMirror is present.
* Add "Are you sure?" check when leaving editor when there are unsaved changes.
Supersedes [41560].
See #39766, #24048, #41886.
Props westonruter, Clorith, melchoyce, johnbillion, jjj, jdgrimes, azaozz.
Fixes#21622, #41887.
Built from https://develop.svn.wordpress.org/trunk@41721
git-svn-id: http://core.svn.wordpress.org/trunk@41555 1a063a9b-81f0-0310-95a4-ce76da25c4cd
"Install" is not a noun, and while it might be acceptable to use the verb as a noun, it is not correct. Using the correct
noun, "installation", increases clarity, especially for non-native English speakers.
This change fixes the usage in user-facing text and in developer documentation.
Fixes#41620
Built from https://develop.svn.wordpress.org/trunk@41289
git-svn-id: http://core.svn.wordpress.org/trunk@41129 1a063a9b-81f0-0310-95a4-ce76da25c4cd
With the introduction of user-specific languages in [38705] it's necessary to be able to switch translations on the fly. For example emails should be sent in the language of the recipient and not the one of the current user.
This introduces a new `WP_Locale_Switcher` class which is used for switching locales and translations. It holds the stack of locales whenever `switch_to_locale( $locale )` is called. With `restore_previous_locale()` you can restore the previous locale. `restore_current_locale()` empties the stack and sets the locale back to the initial value.
`switch_to_locale()` is added to most of core's email functions, either with the value of `get_locale()` (site language) or `get_user_locale()` (user language with fallback to site language).
Props yoavf, tfrommen, swissspidy, pbearne, ocean90.
See #29783.
Fixes#26511.
Built from https://develop.svn.wordpress.org/trunk@38961
git-svn-id: http://core.svn.wordpress.org/trunk@38904 1a063a9b-81f0-0310-95a4-ce76da25c4cd