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.
git-svn-id: https://develop.svn.wordpress.org/trunk@50131 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@49992 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@49904 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@49236 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@49226 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@49154 602fd350-edb4-49c9-b593-d223f7449a82
This allows for clients to search the used post formats via the /wp/v2/search endpoint by using a type=post-format query parameter.
Fixes#51459.
Props andraganescu, zieladam, noisysocks, TimothyBlynJacobs.
git-svn-id: https://develop.svn.wordpress.org/trunk@49132 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@49109 602fd350-edb4-49c9-b593-d223f7449a82
This allows for clients to search the available terms via the `/wp/v2/search` endpoint by using a `type=term` query parameter.
Fixes#51458.
Props andraganescu, zieladam, noisysocks, TimothyBlynJacobs.
git-svn-id: https://develop.svn.wordpress.org/trunk@49103 602fd350-edb4-49c9-b593-d223f7449a82
Exposes all core blocks (excluding embeds) on the server to be used with the REST API block types endpoint.
Props spacedmonkey, timothyblynjacobs.
Fixes#50263.
git-svn-id: https://develop.svn.wordpress.org/trunk@48262 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@48242 602fd350-edb4-49c9-b593-d223f7449a82
This endpoint allows a user to retrieve the block type definition for all server-side registered block types.
Props spacedmonkey, aduth, gziolo, ocean90, TimothyBlynJacobs.
Fixes#47620.
git-svn-id: https://develop.svn.wordpress.org/trunk@48173 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@48072 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@47612 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@47568 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@47198 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@47176 602fd350-edb4-49c9-b593-d223f7449a82
Use `WP_Site_Health::get_instance()` where it's needed, instead of creating multiple instances of the class.
Props afercia, xkon, Clorith, SergeyBiryukov.
See #47606.
git-svn-id: https://develop.svn.wordpress.org/trunk@47149 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@47063 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@47018 602fd350-edb4-49c9-b593-d223f7449a82
We decided to mark Social Links block as an experimental feature in Gutenberg. In effect, we are moving all related code from WordPress 5.3 release.
Props youknowriad.
Fixes#48263.
git-svn-id: https://develop.svn.wordpress.org/trunk@46543 602fd350-edb4-49c9-b593-d223f7449a82
This allows us to use PHP 5.6+ syntax in more files, and display a proper error message on older PHP versions, instead of causing a parse error.
Fixes#48059.
git-svn-id: https://develop.svn.wordpress.org/trunk@46183 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@45678 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@45663 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@45611 602fd350-edb4-49c9-b593-d223f7449a82
- Move the (remaining) privacy tools related functions from `wp-admin/includes/file.php` to `wp-admin/includes/privacy-tools.php`.
- Move the `WP_User_Request` class to a separate file.
See #43895.
git-svn-id: https://develop.svn.wordpress.org/trunk@45519 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@45014 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@44973 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@44962 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@44717 602fd350-edb4-49c9-b593-d223f7449a82
