WordPress/wp-settings.php

745 lines
29 KiB
PHP
Raw Normal View History

<?php
/**
* Used to set up and fix common variables and include
* the WordPress procedural and class library.
*
* Allows for some configuration in wp-config.php (see default-constants.php)
*
* @package WordPress
*/
/**
* Stores the location of the WordPress directory of functions, classes, and core content.
*
* @since 1.0.0
*/
define( 'WPINC', 'wp-includes' );
/**
* Version information for the current WordPress release.
*
* These can't be directly globalized in version.php. When updating,
Docs: Revise comments using “we” in WordPress root directory files. This updates some inline comments to better match the guidelines and recommendations set forth in the make/core and make/docs handbooks: > In general, use second person in your documentation. Second person depicts a friendly tone, with a perfect focus on the reader. In addition to this, directly addressing the reader helps avoid passive voice; thereby preventing unwanted confusion. > ... > the word “we” should be avoided (...) unless its made very clear which group is speaking. Includes: * Replacing first-person usage of "we" with second person point of view. * Making small clarification adjustments where the voice is much too casual or lacks clear context, especially for non-native English speakers. References: * [https://make.wordpress.org/docs/style-guide/language-grammar/grammatical-person/ Style Guide: Grammatical person] * [https://make.wordpress.org/docs/handbook/documentation-team-handbook/handbooks-style-and-formatting-guide/ Handbooks & HelpHub Style and Formatting Guide] * [https://make.wordpress.org/core/handbook/best-practices/post-comment-guidelines/#style-and-substance Post & Comment Guidelines: Style and Substance] Follow-up to [2176], [3430], [4676], [6009], [7991], [12688], [12762], [26008], [28978], [44488], [44962], [51979], [53131], [53132], [53156], [53131], [54200]. Props ironprogrammer, costdev, jorbin, SergeyBiryukov. See #57052. Built from https://develop.svn.wordpress.org/trunk@54866 git-svn-id: http://core.svn.wordpress.org/trunk@54418 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-11-23 16:43:13 +01:00
* include version.php from another installation and don't override
* these values if already set.
*
* @global string $wp_version The WordPress version string.
* @global int $wp_db_version WordPress database version.
* @global string $tinymce_version TinyMCE version.
* @global string $required_php_version The required PHP version string.
* @global string $required_mysql_version The required MySQL version string.
* @global string $wp_local_package Locale code of the package.
*/
global $wp_version, $wp_db_version, $tinymce_version, $required_php_version, $required_mysql_version, $wp_local_package;
require ABSPATH . WPINC . '/version.php';
require ABSPATH . WPINC . '/compat.php';
require ABSPATH . WPINC . '/load.php';
// Check for the required PHP version and for the MySQL extension or a database drop-in.
wp_check_php_mysql_versions();
// Include files required for initialization.
require ABSPATH . WPINC . '/class-wp-paused-extensions-storage.php';
Code Modernization: Fix trigger_error() with E_USER_ERROR deprecation in wp_trigger_error(). PHP 8.4 deprecates the use of `trigger_errror()` with `E_USER_ERROR` as the error level, as there are a number of gotchas to this way of creating a `Fatal Error` (`finally` blocks not executing, destructors not executing). The recommended replacements are either to use exceptions or to do a hard `exit`. WP has its own `wp_trigger_error()` function, which under the hood calls `trigger_error()`. If passed `E_USER_ERROR` as the `$error_level`, this will hit the PHP 8.4 deprecation. Now, there were basically three options: * Silence the deprecation until PHP 9.0 and delay properly solving this until then. This would lead to an awkward solution, as prior to PHP 8.0, error silencing would apply to all errors, while, as of PHP 8.0, it will no longer apply to fatal errors. It also would only buy us some time and wouldn't actually solve anything. * Use `exit($status)` when `wp_trigger_error()` is called with `E_USER_ERROR`. This would make the code untestable and would disable handling of these errors via custom error handlers, which makes this an undesirable solution. * Throw an exception when `wp_trigger_error()` is called with `E_USER_ERROR`. This makes for the most elegant solution with the least BC-breaking impact, though it does open it up to the error potential being "caught" via a `try-catch`. That's not actually a bad thing and is likely to only happen for those errors which can be worked around, in which case, it's a bonus that that's now possible. The third option is implemented which: * Introduces a new `WP_Exception` class. * Starts using `WP_Exception` in the `wp_trigger_error()` function when the `$error_level` is set to `E_USER_ERROR`. This change is covered by pre-existing tests, which have been updated to expect the exception instead of a PHP error. Why not use `WP_Error`? Well, for one, this would lead to completely different behaviour (BC). As `WP_Error` doesn't extend `Exception`, the program would not be stopped, but would continue running, which would be a much bigger breaking change and carries security risks. `WP_Error` also doesn't natively trigger displaying/logging of the error message, so in that case, it would still need an `exit` with the error message, bringing us back to point 2 above. Introducing `WP_Exception` provides (essentially) the same behaviour in that it retains the fatal error and error message displaying/logging behaviors. It also introduces a base Exception class, from which future exception classes can extend. References: * https://wiki.php.net/rfc/deprecations_php_8_4#deprecate_passing_e_user_error_to_trigger_error * https://www.php.net/manual/en/migration80.incompatible.php Follow-up to [56530]. Props jrf, hellofromTonya. See #62061. Built from https://develop.svn.wordpress.org/trunk@59107 git-svn-id: http://core.svn.wordpress.org/trunk@58503 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2024-09-27 21:28:14 +02:00
require ABSPATH . WPINC . '/class-wp-exception.php';
require ABSPATH . WPINC . '/class-wp-fatal-error-handler.php';
require ABSPATH . WPINC . '/class-wp-recovery-mode-cookie-service.php';
require ABSPATH . WPINC . '/class-wp-recovery-mode-key-service.php';
require ABSPATH . WPINC . '/class-wp-recovery-mode-link-service.php';
require ABSPATH . WPINC . '/class-wp-recovery-mode-email-service.php';
require ABSPATH . WPINC . '/class-wp-recovery-mode.php';
require ABSPATH . WPINC . '/error-protection.php';
require ABSPATH . WPINC . '/default-constants.php';
require_once ABSPATH . WPINC . '/plugin.php';
/**
* If not already configured, `$blog_id` will default to 1 in a single site
* configuration. In multisite, it will be overridden by default in ms-settings.php.
*
* @since 2.0.0
*
* @global int $blog_id
*/
global $blog_id;
// Set initial default constants including WP_MEMORY_LIMIT, WP_MAX_MEMORY_LIMIT, WP_DEBUG, SCRIPT_DEBUG, WP_CONTENT_DIR and WP_CACHE.
wp_initial_constants();
Docs: Revise comments using “we” in WordPress root directory files. This updates some inline comments to better match the guidelines and recommendations set forth in the make/core and make/docs handbooks: > In general, use second person in your documentation. Second person depicts a friendly tone, with a perfect focus on the reader. In addition to this, directly addressing the reader helps avoid passive voice; thereby preventing unwanted confusion. > ... > the word “we” should be avoided (...) unless its made very clear which group is speaking. Includes: * Replacing first-person usage of "we" with second person point of view. * Making small clarification adjustments where the voice is much too casual or lacks clear context, especially for non-native English speakers. References: * [https://make.wordpress.org/docs/style-guide/language-grammar/grammatical-person/ Style Guide: Grammatical person] * [https://make.wordpress.org/docs/handbook/documentation-team-handbook/handbooks-style-and-formatting-guide/ Handbooks & HelpHub Style and Formatting Guide] * [https://make.wordpress.org/core/handbook/best-practices/post-comment-guidelines/#style-and-substance Post & Comment Guidelines: Style and Substance] Follow-up to [2176], [3430], [4676], [6009], [7991], [12688], [12762], [26008], [28978], [44488], [44962], [51979], [53131], [53132], [53156], [53131], [54200]. Props ironprogrammer, costdev, jorbin, SergeyBiryukov. See #57052. Built from https://develop.svn.wordpress.org/trunk@54866 git-svn-id: http://core.svn.wordpress.org/trunk@54418 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-11-23 16:43:13 +01:00
// Register the shutdown handler for fatal errors as soon as possible.
wp_register_fatal_error_handler();
// WordPress calculates offsets from UTC.
// phpcs:ignore WordPress.DateTime.RestrictedFunctions.timezone_change_date_default_timezone_set
date_default_timezone_set( 'UTC' );
// Standardize $_SERVER variables across setups.
wp_fix_server_vars();
Docs: Revise comments using “we” in WordPress root directory files. This updates some inline comments to better match the guidelines and recommendations set forth in the make/core and make/docs handbooks: > In general, use second person in your documentation. Second person depicts a friendly tone, with a perfect focus on the reader. In addition to this, directly addressing the reader helps avoid passive voice; thereby preventing unwanted confusion. > ... > the word “we” should be avoided (...) unless its made very clear which group is speaking. Includes: * Replacing first-person usage of "we" with second person point of view. * Making small clarification adjustments where the voice is much too casual or lacks clear context, especially for non-native English speakers. References: * [https://make.wordpress.org/docs/style-guide/language-grammar/grammatical-person/ Style Guide: Grammatical person] * [https://make.wordpress.org/docs/handbook/documentation-team-handbook/handbooks-style-and-formatting-guide/ Handbooks & HelpHub Style and Formatting Guide] * [https://make.wordpress.org/core/handbook/best-practices/post-comment-guidelines/#style-and-substance Post & Comment Guidelines: Style and Substance] Follow-up to [2176], [3430], [4676], [6009], [7991], [12688], [12762], [26008], [28978], [44488], [44962], [51979], [53131], [53132], [53156], [53131], [54200]. Props ironprogrammer, costdev, jorbin, SergeyBiryukov. See #57052. Built from https://develop.svn.wordpress.org/trunk@54866 git-svn-id: http://core.svn.wordpress.org/trunk@54418 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-11-23 16:43:13 +01:00
// Check if the site is in maintenance mode.
wp_maintenance();
// Start loading timer.
timer_start();
Docs: Revise comments using “we” in WordPress root directory files. This updates some inline comments to better match the guidelines and recommendations set forth in the make/core and make/docs handbooks: > In general, use second person in your documentation. Second person depicts a friendly tone, with a perfect focus on the reader. In addition to this, directly addressing the reader helps avoid passive voice; thereby preventing unwanted confusion. > ... > the word “we” should be avoided (...) unless its made very clear which group is speaking. Includes: * Replacing first-person usage of "we" with second person point of view. * Making small clarification adjustments where the voice is much too casual or lacks clear context, especially for non-native English speakers. References: * [https://make.wordpress.org/docs/style-guide/language-grammar/grammatical-person/ Style Guide: Grammatical person] * [https://make.wordpress.org/docs/handbook/documentation-team-handbook/handbooks-style-and-formatting-guide/ Handbooks & HelpHub Style and Formatting Guide] * [https://make.wordpress.org/core/handbook/best-practices/post-comment-guidelines/#style-and-substance Post & Comment Guidelines: Style and Substance] Follow-up to [2176], [3430], [4676], [6009], [7991], [12688], [12762], [26008], [28978], [44488], [44962], [51979], [53131], [53132], [53156], [53131], [54200]. Props ironprogrammer, costdev, jorbin, SergeyBiryukov. See #57052. Built from https://develop.svn.wordpress.org/trunk@54866 git-svn-id: http://core.svn.wordpress.org/trunk@54418 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-11-23 16:43:13 +01:00
// Check if WP_DEBUG mode is enabled.
wp_debug_mode();
/**
* Filters whether to enable loading of the advanced-cache.php drop-in.
*
* This filter runs before it can be used by plugins. It is designed for non-web
* run-times. If false is returned, advanced-cache.php will never be loaded.
*
* @since 4.6.0
*
* @param bool $enable_advanced_cache Whether to enable loading advanced-cache.php (if present).
* Default true.
*/
if ( WP_CACHE && apply_filters( 'enable_loading_advanced_cache_dropin', true ) && file_exists( WP_CONTENT_DIR . '/advanced-cache.php' ) ) {
// For an advanced caching plugin to use. Uses a static drop-in because you would only want one.
include WP_CONTENT_DIR . '/advanced-cache.php';
// Re-initialize any hooks added manually by advanced-cache.php.
if ( $wp_filter ) {
$wp_filter = WP_Hook::build_preinitialized_hooks( $wp_filter );
}
}
// Define WP_LANG_DIR if not set.
wp_set_lang_dir();
// Load early WordPress files.
require ABSPATH . WPINC . '/class-wp-list-util.php';
require ABSPATH . WPINC . '/class-wp-token-map.php';
require ABSPATH . WPINC . '/formatting.php';
require ABSPATH . WPINC . '/meta.php';
require ABSPATH . WPINC . '/functions.php';
require ABSPATH . WPINC . '/class-wp-meta-query.php';
require ABSPATH . WPINC . '/class-wp-matchesmapregex.php';
require ABSPATH . WPINC . '/class-wp.php';
require ABSPATH . WPINC . '/class-wp-error.php';
require ABSPATH . WPINC . '/pomo/mo.php';
require ABSPATH . WPINC . '/l10n/class-wp-translation-controller.php';
require ABSPATH . WPINC . '/l10n/class-wp-translations.php';
require ABSPATH . WPINC . '/l10n/class-wp-translation-file.php';
require ABSPATH . WPINC . '/l10n/class-wp-translation-file-mo.php';
require ABSPATH . WPINC . '/l10n/class-wp-translation-file-php.php';
/**
* @since 0.71
*
* @global wpdb $wpdb WordPress database abstraction object.
*/
global $wpdb;
// Include the wpdb class and, if present, a db.php database drop-in.
require_wp_db();
/**
* @since 3.3.0
*
* @global string $table_prefix The database table prefix.
*/
$GLOBALS['table_prefix'] = $table_prefix;
// Set the database table prefix and the format specifiers for database table columns.
wp_set_wpdb_vars();
// Start the WordPress object cache, or an external object cache if the drop-in is present.
wp_start_object_cache();
// Attach the default filters.
require ABSPATH . WPINC . '/default-filters.php';
// Initialize multisite if enabled.
if ( is_multisite() ) {
require ABSPATH . WPINC . '/class-wp-site-query.php';
require ABSPATH . WPINC . '/class-wp-network-query.php';
require ABSPATH . WPINC . '/ms-blogs.php';
require ABSPATH . WPINC . '/ms-settings.php';
} elseif ( ! defined( 'MULTISITE' ) ) {
define( 'MULTISITE', false );
}
register_shutdown_function( 'shutdown_action_hook' );
Docs: Revise comments using “we” in WordPress root directory files. This updates some inline comments to better match the guidelines and recommendations set forth in the make/core and make/docs handbooks: > In general, use second person in your documentation. Second person depicts a friendly tone, with a perfect focus on the reader. In addition to this, directly addressing the reader helps avoid passive voice; thereby preventing unwanted confusion. > ... > the word “we” should be avoided (...) unless its made very clear which group is speaking. Includes: * Replacing first-person usage of "we" with second person point of view. * Making small clarification adjustments where the voice is much too casual or lacks clear context, especially for non-native English speakers. References: * [https://make.wordpress.org/docs/style-guide/language-grammar/grammatical-person/ Style Guide: Grammatical person] * [https://make.wordpress.org/docs/handbook/documentation-team-handbook/handbooks-style-and-formatting-guide/ Handbooks & HelpHub Style and Formatting Guide] * [https://make.wordpress.org/core/handbook/best-practices/post-comment-guidelines/#style-and-substance Post & Comment Guidelines: Style and Substance] Follow-up to [2176], [3430], [4676], [6009], [7991], [12688], [12762], [26008], [28978], [44488], [44962], [51979], [53131], [53132], [53156], [53131], [54200]. Props ironprogrammer, costdev, jorbin, SergeyBiryukov. See #57052. Built from https://develop.svn.wordpress.org/trunk@54866 git-svn-id: http://core.svn.wordpress.org/trunk@54418 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-11-23 16:43:13 +01:00
// Stop most of WordPress from being loaded if SHORTINIT is enabled.
if ( SHORTINIT ) {
return false;
}
// Load the L10n library.
require_once ABSPATH . WPINC . '/l10n.php';
I18N: Introduce `WP_Textdomain_Registry` to store text domains and their language directory paths. 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
2022-08-11 14:39:12 +02:00
require_once ABSPATH . WPINC . '/class-wp-textdomain-registry.php';
require_once ABSPATH . WPINC . '/class-wp-locale.php';
require_once ABSPATH . WPINC . '/class-wp-locale-switcher.php';
// Run the installer if WordPress is not installed.
wp_not_installed();
// Load most of WordPress.
require ABSPATH . WPINC . '/class-wp-walker.php';
require ABSPATH . WPINC . '/class-wp-ajax-response.php';
require ABSPATH . WPINC . '/capabilities.php';
require ABSPATH . WPINC . '/class-wp-roles.php';
require ABSPATH . WPINC . '/class-wp-role.php';
require ABSPATH . WPINC . '/class-wp-user.php';
require ABSPATH . WPINC . '/class-wp-query.php';
require ABSPATH . WPINC . '/query.php';
require ABSPATH . WPINC . '/class-wp-date-query.php';
require ABSPATH . WPINC . '/theme.php';
require ABSPATH . WPINC . '/class-wp-theme.php';
require ABSPATH . WPINC . '/class-wp-theme-json-schema.php';
require ABSPATH . WPINC . '/class-wp-theme-json-data.php';
require ABSPATH . WPINC . '/class-wp-theme-json.php';
require ABSPATH . WPINC . '/class-wp-theme-json-resolver.php';
require ABSPATH . WPINC . '/class-wp-duotone.php';
require ABSPATH . WPINC . '/global-styles-and-settings.php';
require ABSPATH . WPINC . '/class-wp-block-template.php';
require ABSPATH . WPINC . '/class-wp-block-templates-registry.php';
require ABSPATH . WPINC . '/block-template-utils.php';
require ABSPATH . WPINC . '/block-template.php';
require ABSPATH . WPINC . '/theme-templates.php';
require ABSPATH . WPINC . '/theme-previews.php';
require ABSPATH . WPINC . '/template.php';
require ABSPATH . WPINC . '/https-detection.php';
Security, Site Health: Make migrating a site to HTTPS a one-click interaction. 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
2021-02-02 01:10:01 +01:00
require ABSPATH . WPINC . '/https-migration.php';
require ABSPATH . WPINC . '/class-wp-user-request.php';
require ABSPATH . WPINC . '/user.php';
require ABSPATH . WPINC . '/class-wp-user-query.php';
require ABSPATH . WPINC . '/class-wp-session-tokens.php';
require ABSPATH . WPINC . '/class-wp-user-meta-session-tokens.php';
require ABSPATH . WPINC . '/general-template.php';
require ABSPATH . WPINC . '/link-template.php';
require ABSPATH . WPINC . '/author-template.php';
Robots: Introduce Robots API. 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
2021-01-21 02:37:00 +01:00
require ABSPATH . WPINC . '/robots-template.php';
require ABSPATH . WPINC . '/post.php';
require ABSPATH . WPINC . '/class-walker-page.php';
require ABSPATH . WPINC . '/class-walker-page-dropdown.php';
require ABSPATH . WPINC . '/class-wp-post-type.php';
require ABSPATH . WPINC . '/class-wp-post.php';
require ABSPATH . WPINC . '/post-template.php';
require ABSPATH . WPINC . '/revision.php';
require ABSPATH . WPINC . '/post-formats.php';
require ABSPATH . WPINC . '/post-thumbnail-template.php';
require ABSPATH . WPINC . '/category.php';
require ABSPATH . WPINC . '/class-walker-category.php';
require ABSPATH . WPINC . '/class-walker-category-dropdown.php';
require ABSPATH . WPINC . '/category-template.php';
require ABSPATH . WPINC . '/comment.php';
require ABSPATH . WPINC . '/class-wp-comment.php';
require ABSPATH . WPINC . '/class-wp-comment-query.php';
require ABSPATH . WPINC . '/class-walker-comment.php';
require ABSPATH . WPINC . '/comment-template.php';
require ABSPATH . WPINC . '/rewrite.php';
require ABSPATH . WPINC . '/class-wp-rewrite.php';
require ABSPATH . WPINC . '/feed.php';
require ABSPATH . WPINC . '/bookmark.php';
require ABSPATH . WPINC . '/bookmark-template.php';
require ABSPATH . WPINC . '/kses.php';
require ABSPATH . WPINC . '/cron.php';
require ABSPATH . WPINC . '/deprecated.php';
require ABSPATH . WPINC . '/script-loader.php';
require ABSPATH . WPINC . '/taxonomy.php';
require ABSPATH . WPINC . '/class-wp-taxonomy.php';
require ABSPATH . WPINC . '/class-wp-term.php';
require ABSPATH . WPINC . '/class-wp-term-query.php';
require ABSPATH . WPINC . '/class-wp-tax-query.php';
require ABSPATH . WPINC . '/update.php';
require ABSPATH . WPINC . '/canonical.php';
require ABSPATH . WPINC . '/shortcodes.php';
require ABSPATH . WPINC . '/embed.php';
require ABSPATH . WPINC . '/class-wp-embed.php';
require ABSPATH . WPINC . '/class-wp-oembed.php';
require ABSPATH . WPINC . '/class-wp-oembed-controller.php';
require ABSPATH . WPINC . '/media.php';
require ABSPATH . WPINC . '/http.php';
require ABSPATH . WPINC . '/html-api/html5-named-character-references.php';
require ABSPATH . WPINC . '/html-api/class-wp-html-attribute-token.php';
require ABSPATH . WPINC . '/html-api/class-wp-html-span.php';
require ABSPATH . WPINC . '/html-api/class-wp-html-doctype-info.php';
require ABSPATH . WPINC . '/html-api/class-wp-html-text-replacement.php';
require ABSPATH . WPINC . '/html-api/class-wp-html-decoder.php';
require ABSPATH . WPINC . '/html-api/class-wp-html-tag-processor.php';
HTML-API: Introduce minimal HTML Processor. This patch introduces the //first// of //many// iterations on the evolution of the HTML API, the HTML Processor, which is built in order to understand HTML structure including nesting, misnesting, and complicated semantic rules. In the first iteration, the HTML Processor is arbitrarily limited to a minimal subset of functionality so that we can review it, ship it, test it, and collect feedback before moving forward. This means that this patch is more or less an extension to the Tag Processor query language, providing the ability not only to scan for a tag of a given name, but also to find an HTML element in a specific nesting path. The HTML Processor also aborts any time it encounters: - a tag that isn't a `P`, `DIV`, `FIGURE`, `FIGCAPTION`, `IMG`, `STRONG`, `B`, `EM`, `I`, `A`, `BIG`, `CODE`, `FONT`, `SMALL`, `STRIKE`, `TT`, or `U` tag. this limit exists because many HTML elements require specific rules and we are trying to limit the number of rules introduced at once. this work is targeted at existing work in places like the image block. - certain misnesting constructs that evoke complicated resolution inside the HTML spec. where possible and where simple to do reliably, certain parse errors are handled. in most cases the HTML Processor aborts. The structure of the HTML Processor is established in this patch. Further spec-compliance comes through filling out //more of the same// kind and nature of code as is found in this patch. Certain critical HTML algorithms are partially supported, and where support requires more than is present, the HTML Processor acknowledges this and refuses to operate. In this patch are explorations for how to verify that new HTML support is fully added (instead of allowing for partial updates that leave some code paths non-compliant). Performance is hard to measure since support is so limited at the current time, but it should generally follow the performance of the Tag Processor somewhat close as the overhead is minimized as much as practical. Props dmsnell, zieladam, costdev. Fixes #58517. Built from https://develop.svn.wordpress.org/trunk@56274 git-svn-id: http://core.svn.wordpress.org/trunk@55786 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-07-20 15:43:25 +02:00
require ABSPATH . WPINC . '/html-api/class-wp-html-unsupported-exception.php';
require ABSPATH . WPINC . '/html-api/class-wp-html-active-formatting-elements.php';
require ABSPATH . WPINC . '/html-api/class-wp-html-open-elements.php';
require ABSPATH . WPINC . '/html-api/class-wp-html-token.php';
HTML API: Report real and virtual nodes in the HTML Processor. HTML is a kind of short-hand for a DOM structure. This means that there are many cases in HTML where an element's opening tag or closing tag is missing (or both). This is because many of the parsing rules imply creating elements in the DOM which may not exist in the text of the HTML. The HTML Processor, being the higher-level counterpart to the Tag Processor, is already aware of these nodes, but since it's inception has not paused on them when scanning through a document. Instead, these are visible when pausing on a child of such an element, but otherwise not seen. In this patch the HTML Processor starts exposing those implicitly-created nodes, including opening tags, and closing tags, that aren't foudn in the text content of the HTML input document. Previously, the sequence of matched tokens when scanning with `WP_HTML_Processor::next_token()` would depend on how the HTML document was written, but with this patch, all semantically equal HTML documents will parse and scan in the same exact manner, presenting an idealized or "perfect" view of the document the same way as would occur when traversing a DOM in a browser. Developed in https://github.com/WordPress/wordpress-develop/pull/6348 Discussed in https://core.trac.wordpress.org/ticket/61348 Props audrasjb, dmsnell, gziolo, jonsurrell. Fixes #61348. Built from https://develop.svn.wordpress.org/trunk@58304 git-svn-id: http://core.svn.wordpress.org/trunk@57761 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2024-06-03 21:47:15 +02:00
require ABSPATH . WPINC . '/html-api/class-wp-html-stack-event.php';
HTML-API: Introduce minimal HTML Processor. This patch introduces the //first// of //many// iterations on the evolution of the HTML API, the HTML Processor, which is built in order to understand HTML structure including nesting, misnesting, and complicated semantic rules. In the first iteration, the HTML Processor is arbitrarily limited to a minimal subset of functionality so that we can review it, ship it, test it, and collect feedback before moving forward. This means that this patch is more or less an extension to the Tag Processor query language, providing the ability not only to scan for a tag of a given name, but also to find an HTML element in a specific nesting path. The HTML Processor also aborts any time it encounters: - a tag that isn't a `P`, `DIV`, `FIGURE`, `FIGCAPTION`, `IMG`, `STRONG`, `B`, `EM`, `I`, `A`, `BIG`, `CODE`, `FONT`, `SMALL`, `STRIKE`, `TT`, or `U` tag. this limit exists because many HTML elements require specific rules and we are trying to limit the number of rules introduced at once. this work is targeted at existing work in places like the image block. - certain misnesting constructs that evoke complicated resolution inside the HTML spec. where possible and where simple to do reliably, certain parse errors are handled. in most cases the HTML Processor aborts. The structure of the HTML Processor is established in this patch. Further spec-compliance comes through filling out //more of the same// kind and nature of code as is found in this patch. Certain critical HTML algorithms are partially supported, and where support requires more than is present, the HTML Processor acknowledges this and refuses to operate. In this patch are explorations for how to verify that new HTML support is fully added (instead of allowing for partial updates that leave some code paths non-compliant). Performance is hard to measure since support is so limited at the current time, but it should generally follow the performance of the Tag Processor somewhat close as the overhead is minimized as much as practical. Props dmsnell, zieladam, costdev. Fixes #58517. Built from https://develop.svn.wordpress.org/trunk@56274 git-svn-id: http://core.svn.wordpress.org/trunk@55786 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-07-20 15:43:25 +02:00
require ABSPATH . WPINC . '/html-api/class-wp-html-processor-state.php';
require ABSPATH . WPINC . '/html-api/class-wp-html-processor.php';
require ABSPATH . WPINC . '/class-wp-http.php';
require ABSPATH . WPINC . '/class-wp-http-streams.php';
require ABSPATH . WPINC . '/class-wp-http-curl.php';
require ABSPATH . WPINC . '/class-wp-http-proxy.php';
require ABSPATH . WPINC . '/class-wp-http-cookie.php';
require ABSPATH . WPINC . '/class-wp-http-encoding.php';
require ABSPATH . WPINC . '/class-wp-http-response.php';
require ABSPATH . WPINC . '/class-wp-http-requests-response.php';
require ABSPATH . WPINC . '/class-wp-http-requests-hooks.php';
require ABSPATH . WPINC . '/widgets.php';
require ABSPATH . WPINC . '/class-wp-widget.php';
require ABSPATH . WPINC . '/class-wp-widget-factory.php';
require ABSPATH . WPINC . '/nav-menu-template.php';
require ABSPATH . WPINC . '/nav-menu.php';
require ABSPATH . WPINC . '/admin-bar.php';
require ABSPATH . WPINC . '/class-wp-application-passwords.php';
require ABSPATH . WPINC . '/rest-api.php';
require ABSPATH . WPINC . '/rest-api/class-wp-rest-server.php';
require ABSPATH . WPINC . '/rest-api/class-wp-rest-response.php';
require ABSPATH . WPINC . '/rest-api/class-wp-rest-request.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-posts-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-attachments-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-global-styles-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-post-types-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-post-statuses-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-revisions-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-global-styles-revisions-controller.php';
REST API: Fix issue with Template and Template Part Revision/Autosave REST API controllers. The Template and Template Part REST API controllers have unique characteristics compared to other post type REST API controllers. They do not rely on integer IDs to reference objects; instead, they use a combination of the theme name and slug of the template, like 'twentytwentyfour//home.' Consequently, when the post types template and template part were introduced in [52062], it led to the registration of REST API endpoints for autosaves and revisions with invalid URL structures. In this commit, we introduce new functionality to enable custom autosave and revisions endpoints to be registered at the post type level. Similar to the 'rest_controller_class' parameter, developers can now define 'revisions_rest_controller' and 'autosave_rest_controller.' This empowers developers to create custom controllers for these functionalities. Additionally, we introduce a 'late_route_registration' parameter, which proves helpful when dealing with custom URL patterns and regex pattern matching issues. This commit registers new classes for template and template part autosave and revisions controllers, differentiating them from standard controllers in the following ways: * The response shape now matches that of the template controller. * Permission checks align with the template controller. * A custom URL pattern is introduced to support slug-based identification of templates. Furthermore, we've updated the utility function '_build_block_template_result_from_post' to support passing revision post objects. This enhancement ensures compatibility with the custom revisions controller. Props spacedmonkey, revgeorge, andraganescu, hellofromTonya, antonvlasenko, kadamwhite, ironprogrammer, costdev, mukesh27, timothyblynjacobs, adamsilverstein. Fixes 56922. Built from https://develop.svn.wordpress.org/trunk@56819 git-svn-id: http://core.svn.wordpress.org/trunk@56331 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-10-10 16:05:21 +02:00
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-template-revisions-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-autosaves-controller.php';
REST API: Fix issue with Template and Template Part Revision/Autosave REST API controllers. The Template and Template Part REST API controllers have unique characteristics compared to other post type REST API controllers. They do not rely on integer IDs to reference objects; instead, they use a combination of the theme name and slug of the template, like 'twentytwentyfour//home.' Consequently, when the post types template and template part were introduced in [52062], it led to the registration of REST API endpoints for autosaves and revisions with invalid URL structures. In this commit, we introduce new functionality to enable custom autosave and revisions endpoints to be registered at the post type level. Similar to the 'rest_controller_class' parameter, developers can now define 'revisions_rest_controller' and 'autosave_rest_controller.' This empowers developers to create custom controllers for these functionalities. Additionally, we introduce a 'late_route_registration' parameter, which proves helpful when dealing with custom URL patterns and regex pattern matching issues. This commit registers new classes for template and template part autosave and revisions controllers, differentiating them from standard controllers in the following ways: * The response shape now matches that of the template controller. * Permission checks align with the template controller. * A custom URL pattern is introduced to support slug-based identification of templates. Furthermore, we've updated the utility function '_build_block_template_result_from_post' to support passing revision post objects. This enhancement ensures compatibility with the custom revisions controller. Props spacedmonkey, revgeorge, andraganescu, hellofromTonya, antonvlasenko, kadamwhite, ironprogrammer, costdev, mukesh27, timothyblynjacobs, adamsilverstein. Fixes 56922. Built from https://develop.svn.wordpress.org/trunk@56819 git-svn-id: http://core.svn.wordpress.org/trunk@56331 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-10-10 16:05:21 +02:00
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-template-autosaves-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-taxonomies-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-terms-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-menu-items-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-menus-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-menu-locations-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-users-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-comments-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-search-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-blocks-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-block-types-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-block-renderer-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-settings-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-themes-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-plugins-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-block-directory-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-edit-site-export-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-pattern-directory-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-block-patterns-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-block-pattern-categories-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-application-passwords-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-site-health-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-sidebars-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-widget-types-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-widgets-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-templates-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-url-details-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-navigation-fallback-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-font-families-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-font-faces-controller.php';
require ABSPATH . WPINC . '/rest-api/endpoints/class-wp-rest-font-collections-controller.php';
require ABSPATH . WPINC . '/rest-api/fields/class-wp-rest-meta-fields.php';
require ABSPATH . WPINC . '/rest-api/fields/class-wp-rest-comment-meta-fields.php';
require ABSPATH . WPINC . '/rest-api/fields/class-wp-rest-post-meta-fields.php';
require ABSPATH . WPINC . '/rest-api/fields/class-wp-rest-term-meta-fields.php';
require ABSPATH . WPINC . '/rest-api/fields/class-wp-rest-user-meta-fields.php';
require ABSPATH . WPINC . '/rest-api/search/class-wp-rest-search-handler.php';
require ABSPATH . WPINC . '/rest-api/search/class-wp-rest-post-search-handler.php';
require ABSPATH . WPINC . '/rest-api/search/class-wp-rest-term-search-handler.php';
require ABSPATH . WPINC . '/rest-api/search/class-wp-rest-post-format-search-handler.php';
require ABSPATH . WPINC . '/sitemaps.php';
require ABSPATH . WPINC . '/sitemaps/class-wp-sitemaps.php';
require ABSPATH . WPINC . '/sitemaps/class-wp-sitemaps-index.php';
require ABSPATH . WPINC . '/sitemaps/class-wp-sitemaps-provider.php';
require ABSPATH . WPINC . '/sitemaps/class-wp-sitemaps-registry.php';
require ABSPATH . WPINC . '/sitemaps/class-wp-sitemaps-renderer.php';
require ABSPATH . WPINC . '/sitemaps/class-wp-sitemaps-stylesheet.php';
require ABSPATH . WPINC . '/sitemaps/providers/class-wp-sitemaps-posts.php';
require ABSPATH . WPINC . '/sitemaps/providers/class-wp-sitemaps-taxonomies.php';
require ABSPATH . WPINC . '/sitemaps/providers/class-wp-sitemaps-users.php';
require ABSPATH . WPINC . '/class-wp-block-bindings-source.php';
require ABSPATH . WPINC . '/class-wp-block-bindings-registry.php';
require ABSPATH . WPINC . '/class-wp-block-editor-context.php';
require ABSPATH . WPINC . '/class-wp-block-type.php';
require ABSPATH . WPINC . '/class-wp-block-pattern-categories-registry.php';
require ABSPATH . WPINC . '/class-wp-block-patterns-registry.php';
require ABSPATH . WPINC . '/class-wp-block-styles-registry.php';
require ABSPATH . WPINC . '/class-wp-block-type-registry.php';
require ABSPATH . WPINC . '/class-wp-block.php';
require ABSPATH . WPINC . '/class-wp-block-list.php';
Editor: Allow registering PHP manifest file for block metadata collections for enhanced performance. Typically, when registering a new block type, its metadata is read from the provided `block.json` file. The more block types are registered on a site, the more costly becomes this process, as it involves filesystem reads and parsing JSON. WordPress Core's built-in blocks have in the past worked around that by having a auto-generated PHP manifest file that includes the already parsed JSON data for all blocks. This changeset effectively allows plugins to do the same, by introducing a new API function `wp_register_block_metadata_collection()`. The WordPress Core block manifest is now handled using this API as well, rather than custom logic baked into `register_block_type_from_metadata()`. The `wp_register_block_metadata_collection()` function requires two parameters: * `$path`: The base path in which block files for the collection reside. * `$manifest`: The path to the manifest file for the collection. Every `block.json` file that is supposed to be part of the collection must reside within the provided `$path`, within its own block-specific directory matching the block name (without the block namespace). For example, for a collection `$path` of `/wp-content/plugins/test-plugin` and a block `test-plugin/testimonial`, the block file could be `/wp-content/plugins/test-plugins/blocks/testimonial/block.json`. It is recommended that plugins use the new API function for enhanced performance, especially if they register several block types. However, the use of the function is entirely optional. Not using it will not result in any difference in user-facing behavior. Props mreishus, flixos90, gziolo, spacedmonkey, azaozz, mukesh27. Fixes #62002. Built from https://develop.svn.wordpress.org/trunk@59132 git-svn-id: http://core.svn.wordpress.org/trunk@58528 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2024-09-30 19:08:26 +02:00
require ABSPATH . WPINC . '/class-wp-block-metadata-registry.php';
require ABSPATH . WPINC . '/class-wp-block-parser-block.php';
require ABSPATH . WPINC . '/class-wp-block-parser-frame.php';
require ABSPATH . WPINC . '/class-wp-block-parser.php';
require ABSPATH . WPINC . '/class-wp-classic-to-block-menu-converter.php';
require ABSPATH . WPINC . '/class-wp-navigation-fallback.php';
require ABSPATH . WPINC . '/block-bindings.php';
require ABSPATH . WPINC . '/block-bindings/pattern-overrides.php';
require ABSPATH . WPINC . '/block-bindings/post-meta.php';
require ABSPATH . WPINC . '/blocks.php';
require ABSPATH . WPINC . '/blocks/index.php';
require ABSPATH . WPINC . '/block-editor.php';
require ABSPATH . WPINC . '/block-patterns.php';
require ABSPATH . WPINC . '/class-wp-block-supports.php';
require ABSPATH . WPINC . '/block-supports/utils.php';
require ABSPATH . WPINC . '/block-supports/align.php';
require ABSPATH . WPINC . '/block-supports/custom-classname.php';
require ABSPATH . WPINC . '/block-supports/generated-classname.php';
require ABSPATH . WPINC . '/block-supports/settings.php';
require ABSPATH . WPINC . '/block-supports/elements.php';
require ABSPATH . WPINC . '/block-supports/colors.php';
require ABSPATH . WPINC . '/block-supports/typography.php';
require ABSPATH . WPINC . '/block-supports/border.php';
require ABSPATH . WPINC . '/block-supports/layout.php';
require ABSPATH . WPINC . '/block-supports/position.php';
Block Editor: Updated the WordPress packages from Gutenberg 10.7.0 RC. 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
2021-05-21 12:14:23 +02:00
require ABSPATH . WPINC . '/block-supports/spacing.php';
require ABSPATH . WPINC . '/block-supports/dimensions.php';
require ABSPATH . WPINC . '/block-supports/duotone.php';
require ABSPATH . WPINC . '/block-supports/shadow.php';
require ABSPATH . WPINC . '/block-supports/background.php';
require ABSPATH . WPINC . '/block-supports/block-style-variations.php';
require ABSPATH . WPINC . '/style-engine.php';
require ABSPATH . WPINC . '/style-engine/class-wp-style-engine.php';
require ABSPATH . WPINC . '/style-engine/class-wp-style-engine-css-declarations.php';
require ABSPATH . WPINC . '/style-engine/class-wp-style-engine-css-rule.php';
require ABSPATH . WPINC . '/style-engine/class-wp-style-engine-css-rules-store.php';
require ABSPATH . WPINC . '/style-engine/class-wp-style-engine-processor.php';
Introduce font-face styles generator and printer. Introducing Font Face, a server-side `@font-face` styles generator and printer. tl;dr: * Introduces Font Face. * Deprecates `_wp_theme_json_webfonts_handler()`. **Introduce Font Face** From an array of fonts (i.e. each font-family and its font variations to be processed), it: 1. Validates each `font-face` declaration, i.e. the CSS property and value pairing. If validation fails, processing stops with no font-face styles printed. 3. Generates the `@font-face` CSS for each font-family. 4. Prints the CSS within a `<style id="wp-fonts-local">` element. The entry point into Font Face is through a new global function called `wp_print_font_faces()`, which is automatically called: * when the `'wp_head'` hook runs (for the front-end). * when the `'admin_print_styles'` hook runs (for the back-end). * when `_wp_get_iframed_editor_assets()` runs to inject the `@font-face` styles into the iframed editor. Once called, it gets the fonts from Theme_JSON merged data layer, which includes theme defined fonts and user activated fonts (once the Font Library #59166 is introduced into Core). For classic sites, themes and plugins can directly call `wp_print_font_faces()` and pass their fonts array to it for processing. **Deprecates `_wp_theme_json_webfonts_handler()`.** As Font Face is a direct replacement, the stopgap code in `_wp_theme_json_webfonts_handler()` (introduced in 6.0.0 via [53282]) is deprecated and unused in Core. **Props note:** There's a long multiple year history baked into Font Face, which dates back to the early versions of a web font API (see #46370 and [https://github.com/WordPress/gutenberg/issues/41479 roadmap]. The props list includes those who contributed from those early versions up to this commit. **References:** * #46370 original (Web)Fonts API proposal for registering and enqueuing web fonts. * [https://github.com/WordPress/gutenberg/issues/41479 Gutenberg tracking issue] which includes the evolution from Webfonts API to Fonts API to Font Face. * [53282] / #55567 Added the stopgap code `_wp_theme_json_webfonts_handler()` in 6.0. * [https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face @font-face on mdn web docs] * #59166 Font Library: Font manager for WordPress Follow-up to [53282]. Props aristath, jonoaldersonwp, hellofromTonya, andraganescu, annezazu, antonvlasenko, arena, askdesign, azaozz, bph, bradley2083, colorful-tones, costdev, davidbaumwald, desrosj, dingo_d, djcowan, domainsupport, dryanpress, elmastudio, flixos90, francina, garrett-eclipse, gigitux, grantmkin, grapplerulrich, gziolo, ironprogrammer, jb510, jeffpaul, jeremyyip, jffng, joostdevalk, jorgefilipecosta, juanmaguitar, mamaduka, matveb, mburridge, mitogh, ndiego, ntsekouras, oandregal, ocean90, oglekler, paaljoachim, pagelab, peterwilsoncc, poena, priethor, scruffian, SergeyBiryukov, shiloey, simison, skorasaurus, soean, westonruter, wildworks, zaguiini. Fixes #59165. Built from https://develop.svn.wordpress.org/trunk@56500 git-svn-id: http://core.svn.wordpress.org/trunk@56012 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-08-31 23:49:20 +02:00
require ABSPATH . WPINC . '/fonts/class-wp-font-face-resolver.php';
require ABSPATH . WPINC . '/fonts/class-wp-font-collection.php';
Introduce font-face styles generator and printer. Introducing Font Face, a server-side `@font-face` styles generator and printer. tl;dr: * Introduces Font Face. * Deprecates `_wp_theme_json_webfonts_handler()`. **Introduce Font Face** From an array of fonts (i.e. each font-family and its font variations to be processed), it: 1. Validates each `font-face` declaration, i.e. the CSS property and value pairing. If validation fails, processing stops with no font-face styles printed. 3. Generates the `@font-face` CSS for each font-family. 4. Prints the CSS within a `<style id="wp-fonts-local">` element. The entry point into Font Face is through a new global function called `wp_print_font_faces()`, which is automatically called: * when the `'wp_head'` hook runs (for the front-end). * when the `'admin_print_styles'` hook runs (for the back-end). * when `_wp_get_iframed_editor_assets()` runs to inject the `@font-face` styles into the iframed editor. Once called, it gets the fonts from Theme_JSON merged data layer, which includes theme defined fonts and user activated fonts (once the Font Library #59166 is introduced into Core). For classic sites, themes and plugins can directly call `wp_print_font_faces()` and pass their fonts array to it for processing. **Deprecates `_wp_theme_json_webfonts_handler()`.** As Font Face is a direct replacement, the stopgap code in `_wp_theme_json_webfonts_handler()` (introduced in 6.0.0 via [53282]) is deprecated and unused in Core. **Props note:** There's a long multiple year history baked into Font Face, which dates back to the early versions of a web font API (see #46370 and [https://github.com/WordPress/gutenberg/issues/41479 roadmap]. The props list includes those who contributed from those early versions up to this commit. **References:** * #46370 original (Web)Fonts API proposal for registering and enqueuing web fonts. * [https://github.com/WordPress/gutenberg/issues/41479 Gutenberg tracking issue] which includes the evolution from Webfonts API to Fonts API to Font Face. * [53282] / #55567 Added the stopgap code `_wp_theme_json_webfonts_handler()` in 6.0. * [https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face @font-face on mdn web docs] * #59166 Font Library: Font manager for WordPress Follow-up to [53282]. Props aristath, jonoaldersonwp, hellofromTonya, andraganescu, annezazu, antonvlasenko, arena, askdesign, azaozz, bph, bradley2083, colorful-tones, costdev, davidbaumwald, desrosj, dingo_d, djcowan, domainsupport, dryanpress, elmastudio, flixos90, francina, garrett-eclipse, gigitux, grantmkin, grapplerulrich, gziolo, ironprogrammer, jb510, jeffpaul, jeremyyip, jffng, joostdevalk, jorgefilipecosta, juanmaguitar, mamaduka, matveb, mburridge, mitogh, ndiego, ntsekouras, oandregal, ocean90, oglekler, paaljoachim, pagelab, peterwilsoncc, poena, priethor, scruffian, SergeyBiryukov, shiloey, simison, skorasaurus, soean, westonruter, wildworks, zaguiini. Fixes #59165. Built from https://develop.svn.wordpress.org/trunk@56500 git-svn-id: http://core.svn.wordpress.org/trunk@56012 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-08-31 23:49:20 +02:00
require ABSPATH . WPINC . '/fonts/class-wp-font-face.php';
require ABSPATH . WPINC . '/fonts/class-wp-font-library.php';
require ABSPATH . WPINC . '/fonts/class-wp-font-utils.php';
Introduce font-face styles generator and printer. Introducing Font Face, a server-side `@font-face` styles generator and printer. tl;dr: * Introduces Font Face. * Deprecates `_wp_theme_json_webfonts_handler()`. **Introduce Font Face** From an array of fonts (i.e. each font-family and its font variations to be processed), it: 1. Validates each `font-face` declaration, i.e. the CSS property and value pairing. If validation fails, processing stops with no font-face styles printed. 3. Generates the `@font-face` CSS for each font-family. 4. Prints the CSS within a `<style id="wp-fonts-local">` element. The entry point into Font Face is through a new global function called `wp_print_font_faces()`, which is automatically called: * when the `'wp_head'` hook runs (for the front-end). * when the `'admin_print_styles'` hook runs (for the back-end). * when `_wp_get_iframed_editor_assets()` runs to inject the `@font-face` styles into the iframed editor. Once called, it gets the fonts from Theme_JSON merged data layer, which includes theme defined fonts and user activated fonts (once the Font Library #59166 is introduced into Core). For classic sites, themes and plugins can directly call `wp_print_font_faces()` and pass their fonts array to it for processing. **Deprecates `_wp_theme_json_webfonts_handler()`.** As Font Face is a direct replacement, the stopgap code in `_wp_theme_json_webfonts_handler()` (introduced in 6.0.0 via [53282]) is deprecated and unused in Core. **Props note:** There's a long multiple year history baked into Font Face, which dates back to the early versions of a web font API (see #46370 and [https://github.com/WordPress/gutenberg/issues/41479 roadmap]. The props list includes those who contributed from those early versions up to this commit. **References:** * #46370 original (Web)Fonts API proposal for registering and enqueuing web fonts. * [https://github.com/WordPress/gutenberg/issues/41479 Gutenberg tracking issue] which includes the evolution from Webfonts API to Fonts API to Font Face. * [53282] / #55567 Added the stopgap code `_wp_theme_json_webfonts_handler()` in 6.0. * [https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face @font-face on mdn web docs] * #59166 Font Library: Font manager for WordPress Follow-up to [53282]. Props aristath, jonoaldersonwp, hellofromTonya, andraganescu, annezazu, antonvlasenko, arena, askdesign, azaozz, bph, bradley2083, colorful-tones, costdev, davidbaumwald, desrosj, dingo_d, djcowan, domainsupport, dryanpress, elmastudio, flixos90, francina, garrett-eclipse, gigitux, grantmkin, grapplerulrich, gziolo, ironprogrammer, jb510, jeffpaul, jeremyyip, jffng, joostdevalk, jorgefilipecosta, juanmaguitar, mamaduka, matveb, mburridge, mitogh, ndiego, ntsekouras, oandregal, ocean90, oglekler, paaljoachim, pagelab, peterwilsoncc, poena, priethor, scruffian, SergeyBiryukov, shiloey, simison, skorasaurus, soean, westonruter, wildworks, zaguiini. Fixes #59165. Built from https://develop.svn.wordpress.org/trunk@56500 git-svn-id: http://core.svn.wordpress.org/trunk@56012 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-08-31 23:49:20 +02:00
require ABSPATH . WPINC . '/fonts.php';
JavaScript: Add new Modules API. This changeset adds a new API for WordPress, designed to work with native ES Modules and Import Maps. It introduces functions such as `wp_register_module`, and `wp_enqueue_module`. The API aims to provide a familiar experience to the existing `WP_Scripts` class, offering similar functionality. However, **it's not intended to duplicate the exact functionality of `WP_Scripts`**; rather, it is carefully tailored to address the specific needs and capabilities of ES modules. For this initial version, **the current proposal is intentionally simplistic**, covering only the essential features needed to work with ES modules. Other enhancements and optimizations can be added later as the community identifies additional requirements and use cases. == Differences Between WP_Script_Modules and WP_Scripts === Dependency Specification With `WP_Script_Modules`, the array of dependencies supports not only strings but also arrays that include the dependency import type (`static` or `dynamic`). This design choice allows for future extensions of dependency properties, such as adding a `version` property to support "scopes" within import maps. === Module Identifier Instead of a handle, `WP_Script_Modules` utilizes the module identifier, aligning with the module identifiers used in JavaScript files and import maps. === Deregistration There is no equivalent of `wp_deregister_script` at this stage. == API === `wp_register_module( $module_identifier, $src, $deps, $version )` Registers a module. {{{ // Registers a module with dependencies and versioning. wp_register_module( 'my-module', '/path/to/my-module.js', array( 'static-dependency-1', 'static-dependency-2' ), '1.2.3' ); }}} {{{ // my-module.js import { ... } from 'static-dependency-1'; import { ... } from 'static-dependency-2'; // ... }}} {{{ // Registers a module with a dynamic dependency. wp_register_module( 'my-module', '/path/to/my-module.js', array( 'static-dependency', array( 'id' => 'dynamic-dependency', 'import' => 'dynamic' ), ) ); }}} {{{ // my-module.js import { ... } from 'static-dependency'; // ... const dynamicModule = await import('dynamic-dependency'); }}} === `wp_enqueue_module( $module_identifier, $src, $deps, $version )` Enqueues a module. If a source is provided, it will also register the module. {{{ wp_enqueue_module( 'my-module' ); }}} === `wp_dequeue_module( $module_identifier )` Dequeues a module. {{{ wp_dequeue_module( 'my-module' ); }}} == Output - When modules are enqueued, they are printed within script tags containing `type="module"` attributes. - Additionally, static dependencies of enqueued modules utilize `link` tags with `rel="modulepreload"` attributes. - Lastly, an import map is generated and inserted using a `<script type="importmap">` tag. {{{ <script type="module" src="/path/to/my-module.js" id="my-module"></script> <link rel="modulepreload" href="/path/to/static-dependency.js" id="static-dependency" /> <script type="importmap"> { "imports": { "static-dependency": "/path/to/static-dependency.js", "dynamic-dependency": "/path/to/dynamic-dependency.js" } } </script> }}} == Import Map Polyfill Requirement Even though all major browsers already support import maps, an import map polyfill is required until the percentage of users using old browser versions without import map support drops significantly. This work is ongoing and will be added once it's ready. Progress is tracked in #60232. Props luisherranz, idad5, costdev, neffff, joemcgill, jorbin, swissspidy, jonsurrell, flixos90, gziolo, westonruter. Fixes #56313. Built from https://develop.svn.wordpress.org/trunk@57269 git-svn-id: http://core.svn.wordpress.org/trunk@56775 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2024-01-11 15:47:14 +01:00
require ABSPATH . WPINC . '/class-wp-script-modules.php';
require ABSPATH . WPINC . '/script-modules.php';
require ABSPATH . WPINC . '/interactivity-api/class-wp-interactivity-api.php';
require ABSPATH . WPINC . '/interactivity-api/class-wp-interactivity-api-directives-processor.php';
require ABSPATH . WPINC . '/interactivity-api/interactivity-api.php';
require ABSPATH . WPINC . '/class-wp-plugin-dependencies.php';
add_action( 'after_setup_theme', array( wp_script_modules(), 'add_hooks' ) );
add_action( 'after_setup_theme', array( wp_interactivity(), 'add_hooks' ) );
/**
* @since 3.3.0
*
* @global WP_Embed $wp_embed WordPress Embed object.
*/
$GLOBALS['wp_embed'] = new WP_Embed();
I18N: Introduce `WP_Textdomain_Registry` to store text domains and their language directory paths. 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
2022-08-11 14:39:12 +02:00
/**
* WordPress Textdomain Registry object.
*
* Used to support just-in-time translations for manually loaded text domains.
*
* @since 6.1.0
*
* @global WP_Textdomain_Registry $wp_textdomain_registry WordPress Textdomain Registry.
*/
$GLOBALS['wp_textdomain_registry'] = new WP_Textdomain_Registry();
$GLOBALS['wp_textdomain_registry']->init();
I18N: Introduce `WP_Textdomain_Registry` to store text domains and their language directory paths. 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
2022-08-11 14:39:12 +02:00
// Load multisite-specific files.
if ( is_multisite() ) {
require ABSPATH . WPINC . '/ms-functions.php';
require ABSPATH . WPINC . '/ms-default-filters.php';
require ABSPATH . WPINC . '/ms-deprecated.php';
}
// Define constants that rely on the API to obtain the default value.
// Define must-use plugin directory constants, which may be overridden in the sunrise.php drop-in.
wp_plugin_directory_constants();
/**
* @since 3.9.0
*
* @global array $wp_plugin_paths
*/
$GLOBALS['wp_plugin_paths'] = array();
// Load must-use plugins.
foreach ( wp_get_mu_plugins() as $mu_plugin ) {
$_wp_plugin_file = $mu_plugin;
include_once $mu_plugin;
$mu_plugin = $_wp_plugin_file; // Avoid stomping of the $mu_plugin variable in a plugin.
/**
* Fires once a single must-use plugin has loaded.
*
* @since 5.1.0
*
* @param string $mu_plugin Full path to the plugin's main file.
*/
do_action( 'mu_plugin_loaded', $mu_plugin );
}
unset( $mu_plugin, $_wp_plugin_file );
// Load network activated plugins.
if ( is_multisite() ) {
foreach ( wp_get_active_network_plugins() as $network_plugin ) {
wp_register_plugin_realpath( $network_plugin );
$_wp_plugin_file = $network_plugin;
include_once $network_plugin;
$network_plugin = $_wp_plugin_file; // Avoid stomping of the $network_plugin variable in a plugin.
/**
* Fires once a single network-activated plugin has loaded.
*
* @since 5.1.0
*
* @param string $network_plugin Full path to the plugin's main file.
*/
do_action( 'network_plugin_loaded', $network_plugin );
}
unset( $network_plugin, $_wp_plugin_file );
}
/**
* Fires once all must-use and network-activated plugins have loaded.
*
* @since 2.8.0
*/
do_action( 'muplugins_loaded' );
if ( is_multisite() ) {
ms_cookie_constants();
}
// Define constants after multisite is loaded.
wp_cookie_constants();
// Define and enforce our SSL constants.
wp_ssl_constants();
// Create common globals.
require ABSPATH . WPINC . '/vars.php';
// Make taxonomies and posts available to plugins and themes.
// @plugin authors: warning: these get registered again on the init hook.
create_initial_taxonomies();
create_initial_post_types();
File Editors: Introduce sandboxed live editing of PHP files with rollbacks for both themes and plugins. * 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
2017-10-04 02:20:45 +02:00
wp_start_scraping_edited_file_errors();
// Register the default theme directory root.
register_theme_directory( get_theme_root() );
if ( ! is_multisite() && wp_is_fatal_error_handler_enabled() ) {
// Handle users requesting a recovery mode link and initiating recovery mode.
wp_recovery_mode()->initialize();
}
// To make get_plugin_data() available in a way that's compatible with plugins also loading this file, see #62244.
require_once ABSPATH . 'wp-admin/includes/plugin.php';
// Load active plugins.
foreach ( wp_get_active_and_valid_plugins() as $plugin ) {
wp_register_plugin_realpath( $plugin );
$_wp_plugin_file = $plugin;
include_once $plugin;
$plugin = $_wp_plugin_file; // Avoid stomping of the $plugin variable in a plugin.
/**
* Fires once a single activated plugin has loaded.
*
* @since 5.1.0
*
* @param string $plugin Full path to the plugin's main file.
*/
do_action( 'plugin_loaded', $plugin );
$plugin_data = get_plugin_data( $plugin, false, false );
$textdomain = $plugin_data['TextDomain'];
if ( $textdomain ) {
if ( $plugin_data['DomainPath'] ) {
$GLOBALS['wp_textdomain_registry']->set_custom_path( $textdomain, dirname( $plugin ) . $plugin_data['DomainPath'] );
} else {
$GLOBALS['wp_textdomain_registry']->set_custom_path( $textdomain, dirname( $plugin ) );
}
}
}
unset( $plugin, $_wp_plugin_file, $plugin_data, $textdomain );
// Load pluggable functions.
require ABSPATH . WPINC . '/pluggable.php';
require ABSPATH . WPINC . '/pluggable-deprecated.php';
// Set internal encoding.
wp_set_internal_encoding();
// Run wp_cache_postload() if object cache is enabled and the function exists.
if ( WP_CACHE && function_exists( 'wp_cache_postload' ) ) {
wp_cache_postload();
}
/**
* Fires once activated plugins have loaded.
*
* Pluggable functions are also available at this point in the loading order.
*
* @since 1.5.0
*/
do_action( 'plugins_loaded' );
// Define constants which affect functionality if not already defined.
wp_functionality_constants();
// Add magic quotes and set up $_REQUEST ( $_GET + $_POST ).
wp_magic_quotes();
/**
* Fires when comment cookies are sanitized.
*
* @since 2.0.11
*/
do_action( 'sanitize_comment_cookies' );
/**
* WordPress Query object
*
* @since 2.0.0
*
* @global WP_Query $wp_the_query WordPress Query object.
*/
$GLOBALS['wp_the_query'] = new WP_Query();
/**
* Holds the reference to {@see $wp_the_query}.
* Use this global for WordPress queries
*
* @since 1.5.0
*
* @global WP_Query $wp_query WordPress Query object.
*/
$GLOBALS['wp_query'] = $GLOBALS['wp_the_query'];
/**
* Holds the WordPress Rewrite object for creating pretty URLs
*
* @since 1.5.0
*
* @global WP_Rewrite $wp_rewrite WordPress rewrite component.
*/
$GLOBALS['wp_rewrite'] = new WP_Rewrite();
/**
* WordPress Object
*
* @since 2.0.0
*
* @global WP $wp Current WordPress environment instance.
*/
$GLOBALS['wp'] = new WP();
/**
* WordPress Widget Factory Object
*
* @since 2.8.0
*
* @global WP_Widget_Factory $wp_widget_factory
*/
$GLOBALS['wp_widget_factory'] = new WP_Widget_Factory();
/**
* WordPress User Roles
*
* @since 2.0.0
*
* @global WP_Roles $wp_roles WordPress role management object.
*/
$GLOBALS['wp_roles'] = new WP_Roles();
/**
* Fires before the theme is loaded.
*
* @since 2.6.0
*/
do_action( 'setup_theme' );
// Define the template related constants and globals.
wp_templating_constants();
wp_set_template_globals();
// Load the default text localization domain.
load_default_textdomain();
$locale = get_locale();
$locale_file = WP_LANG_DIR . "/$locale.php";
if ( ( 0 === validate_file( $locale ) ) && is_readable( $locale_file ) ) {
require $locale_file;
}
unset( $locale_file );
/**
* WordPress Locale object for loading locale domain date and various strings.
*
* @since 2.1.0
*
* @global WP_Locale $wp_locale WordPress date and time locale object.
*/
$GLOBALS['wp_locale'] = new WP_Locale();
/**
* WordPress Locale Switcher object for switching locales.
*
* @since 4.7.0
*
* @global WP_Locale_Switcher $wp_locale_switcher WordPress locale switcher object.
*/
$GLOBALS['wp_locale_switcher'] = new WP_Locale_Switcher();
$GLOBALS['wp_locale_switcher']->init();
// Load the functions for the active theme, for both parent and child theme if applicable.
Bootstrap/Load: Introduce fatal error recovery mechanism allowing users to still log in to their admin dashboard. 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
2019-01-09 21:05:49 +01:00
foreach ( wp_get_active_and_valid_themes() as $theme ) {
$wp_theme = wp_get_theme( basename( $theme ) );
Bootstrap/Load: Introduce fatal error recovery mechanism allowing users to still log in to their admin dashboard. 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
2019-01-09 21:05:49 +01:00
if ( file_exists( $theme . '/functions.php' ) ) {
include $theme . '/functions.php';
}
$wp_theme->load_textdomain();
}
unset( $theme, $wp_theme );
/**
* Fires after the theme is loaded.
*
* @since 3.0.0
*/
do_action( 'after_setup_theme' );
// Create an instance of WP_Site_Health so that Cron events may fire.
if ( ! class_exists( 'WP_Site_Health' ) ) {
require_once ABSPATH . 'wp-admin/includes/class-wp-site-health.php';
}
WP_Site_Health::get_instance();
// Set up current user.
$GLOBALS['wp']->init();
/**
* Fires after WordPress has finished loading but before any headers are sent.
*
* Most of WP is loaded at this stage, and the user is authenticated. WP continues
* to load on the {@see 'init'} hook that follows (e.g. widgets), and many plugins instantiate
* themselves on it for all sorts of reasons (e.g. they need a user, a taxonomy, etc.).
*
* If you wish to plug an action once WP is loaded, use the {@see 'wp_loaded'} hook below.
*
* @since 1.5.0
*/
do_action( 'init' );
// Check site status.
if ( is_multisite() ) {
$file = ms_site_check();
if ( true !== $file ) {
require $file;
die();
}
unset( $file );
}
/**
* This hook is fired once WP, all plugins, and the theme are fully loaded and instantiated.
*
* Ajax requests should use wp-admin/admin-ajax.php. admin-ajax.php can handle requests for
* users not logged in.
*
* @link https://developer.wordpress.org/plugins/javascript/ajax
*
* @since 3.0.0
*/
do_action( 'wp_loaded' );