While web crawlers are able to discover pages from links within the site and from other sites, XML sitemaps supplement this approach by allowing crawlers to quickly and comprehensively identify all URLs included in the sitemap and learn other signals about those URLs using the associated metadata.
See https://make.wordpress.org/core/2020/06/10/merge-announcement-extensible-core-sitemaps/ for more details.
This feature exposes the sitemap index via `/wp-sitemap.xml` and exposes a variety of new filters and hooks for developers to modify the behavior. Users can disable sitemaps completely by turning off search engine visibility in WordPress admin.
This change also introduces a new `esc_xml()` function to escape strings for output in XML, as well as XML support to `wp_kses_normalize_entities()`.
Props Adrian McShane, afragen, adamsilverstein, casiepa, flixos90, garrett-eclipse, joemcgill, kburgoine, kraftbj, milana_cap, pacifika, pbiron, pfefferle, Ruxandra Gradina, swissspidy, szepeviktor, tangrufus, tweetythierry.
Fixes#50117.
See #3670. See #19998.
Built from https://develop.svn.wordpress.org/trunk@48072
git-svn-id: http://core.svn.wordpress.org/trunk@47839 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `register_globals` directive in PHP was deprecated in version 5.3 and removed entirely in 5.4.
Now that WordPress only supports PHP 5.6.20 and newer, the `wp_unregister_GLOBALS()` function can be deprecated.
Props ayeshrajans, desrosj, SergeyBiryukov.
Fixes#49938.
Built from https://develop.svn.wordpress.org/trunk@47612
git-svn-id: http://core.svn.wordpress.org/trunk@47387 1a063a9b-81f0-0310-95a4-ce76da25c4cd
As the WP_Site_Health class is instantiated prior to plugins being required and the `plugins_loaded` hook being fired, it prevents plugins from using the following hooks in the functions called by `maybe_create_scheduled_event()`.
Fixes#49824.
Props peterwilsoncc, whyisjake.
Built from https://develop.svn.wordpress.org/trunk@47568
git-svn-id: http://core.svn.wordpress.org/trunk@47343 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This avoids the performance overhead of the function call every time `dirname( __FILE__ )` was used instead of `__DIR__`.
This commit also includes:
* Removing unnecessary parentheses from `include`/`require` statements. These are language constructs, not function calls.
* Replacing `include` statements for several files with `require_once`, for consistency:
* `wp-admin/admin-header.php`
* `wp-admin/admin-footer.php`
* `wp-includes/version.php`
Props ayeshrajans, desrosj, valentinbora, jrf, joostdevalk, netweb.
Fixes#48082.
Built from https://develop.svn.wordpress.org/trunk@47198
git-svn-id: http://core.svn.wordpress.org/trunk@46998 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Core did not include the navigation block PHP files.
This commit fixes the issue referred, and now the navigation block is executed on the frontend. The block still does not work as expected and throws an error during frontend execution. That problem is going to be fixed on the next WordPress package update.
This commit adds the file as it is on the npm package used.
Props gziolo.
Fixes#49348.
Built from https://develop.svn.wordpress.org/trunk@47176
git-svn-id: http://core.svn.wordpress.org/trunk@46976 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The widget informs administrators of any potential issues that should be addressed to improve the performance or security of their website, and directs them to the Site Health screen for more details.
Props Clorith, hedgefield, guddu1315.
See #47606.
Built from https://develop.svn.wordpress.org/trunk@47063
git-svn-id: http://core.svn.wordpress.org/trunk@46863 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, `wp_favicon_request()` was introduced in [13205] to avoid a performance hit of serving a full 404 page on every favicon request.
While working as intended, that implementation did not provide a way for theme or plugin authors to manage the behavior of favicon requests.
This changeset implements the following logic (only applied if WordPress is installed in the root directory):
* If there is a Site Icon set in Customizer, redirect `/favicon.ico` requests to that icon.
* Otherwise, use the WordPress logo as a default icon.
* If a physical `/favicon.ico` file exists, do nothing, let the server handle the request.
Handling `/favicon.ico` is now more consistent with handling `/robots.txt` requests.
New functions and hooks:
* Introduce `is_favicon()` conditional tag to complement `is_robots()`.
* Introduce `do_favicon` action to complement `do_robots` and use it in template loader.
* Introduce `do_favicon()` function, hooked to the above action by default, to complement `do_robots()`.
* Introduce `do_faviconico` action to complement `do_robotstxt`, for plugins to override the default behavior.
* Mark `wp_favicon_request()` as deprecated in favor of `do_favicon()`.
Props jonoaldersonwp, birgire, joostdevalk, mukesh27, SergeyBiryukov.
Fixes#47398.
Built from https://develop.svn.wordpress.org/trunk@47018
git-svn-id: http://core.svn.wordpress.org/trunk@46818 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This renames the file containing the `WP_Date_Query` class to conform to the coding standards.
This commit also includes:
- A new `date.php` that includes the new file, for anyone that may've been including the file directly.
- Replaces references to the old filename with the new filename.
Fixes#47775. See #47632.
Built from https://develop.svn.wordpress.org/trunk@45678
git-svn-id: http://core.svn.wordpress.org/trunk@45489 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This renames the file containing the `WP_oEmbed` class to conform to the coding standards.
This commit also includes:
- A new `class-oembed.php` that includes the new file, for anyone that may've been including the file directly.
- Replaces references to the old filename with the new filename.
See #47632.
Built from https://develop.svn.wordpress.org/trunk@45663
git-svn-id: http://core.svn.wordpress.org/trunk@45474 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Noteable changes:
- The `magic_quotes_runtime` and `magic_quotes_sybase` settings were removed in PHP 5.4, so no longer need to be set.
- Some functions that use external libraries can generate errors that can't be tested for, so are globally allowed to silence errors.
- Quite a few functions would cause errors if `safe_mode` was set. This setting was removed in PHP 5.4.
- Only a handful of `header()` calls needed corresponding `headers_sent()` checks for unit tests to pass, but more may need to be added as the nightlies builds are tested.
See #46732.
Built from https://develop.svn.wordpress.org/trunk@45611
git-svn-id: http://core.svn.wordpress.org/trunk@45422 1a063a9b-81f0-0310-95a4-ce76da25c4cd
If a fatal error occurs midway through a page load, or in a REST API request, it still needs to be handled internally for the recovery mode, but the custom message may conflict with already rendered output, e.g. by displaying HTML markup in an XML or JSON request.
Props spacedmonkey, flixos90, TimothyBlynJacobs.
Fixes#45989. See #44458.
Built from https://develop.svn.wordpress.org/trunk@45014
git-svn-id: http://core.svn.wordpress.org/trunk@44823 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Using the new fatal handler introduced in [44962], an email is sent to the admin when a fatal error occurs. This email includes a secret link to enter recovery mode. When clicked, the link will be validated and on success a cookie will be placed on the client, enabling recovery mode for that user. This functionality is executed early before plugins and themes are loaded, in order to be unaffected by potential fatal errors these might be causing.
When in recovery mode, broken plugins and themes will be paused for that client, so that they are able to access the admin backend despite of these errors. They are notified about the broken extensions and the errors caused, and can then decide whether they would like to temporarily deactivate the extension or fix the problem and resume the extension.
A link in the admin bar allows the client to exit recovery mode.
Props timothyblynjacobs, afragen, flixos90, nerrad, miss_jwo, schlessera, spacedmonkey, swissspidy.
Fixes#46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44973
git-svn-id: http://core.svn.wordpress.org/trunk@44804 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset introduces a `WP_Fatal_Error_Handler` class that detects fatal errors and displays a more user-friendly message about the site experiencing technical difficulties.
Websites that have custom requirements in that regard can implement their own fatal error handler by adding a `fatal-error-handler.php` drop-in that returns the handler instance to use, which must be based on a class that inherits `WP_Fatal_Error_Handler`. That handler will then be used in place of the default one. Alternatively, the fatal error handler feature can be completely disable through a constant `WP_DISABLE_FATAL_ERROR_HANDLER`.
Websites that would like to modify specifically the error template displayed in the frontend can add a `php-error.php` drop-in that works similarly to the existing `db-error.php` drop-in. For more granular customization, the fatal error handler also includes new filters `wp_should_handle_php_error`, `wp_php_error_message` and `wp_php_error_args`.
Props afragen, bradleyt, flixos90, ocean90, schlessera, SergeyBiryukov, spacedmonkey, timothyblynjacobs.
See #46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44962
git-svn-id: http://core.svn.wordpress.org/trunk@44793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Due to the high number of follow-up tickets and associated security concerns, it was decided to reschedule the fatal error recovery feature for WordPress 5.2, in order to address these issues properly. The feature will continue to be developed, with iterations being merged into trunk early in the 5.2 release cycle.
Fixes#46141. See #44458, #45932, #45940, #46038, #46047, #46068.
Built from https://develop.svn.wordpress.org/trunk@44717
git-svn-id: http://core.svn.wordpress.org/trunk@44548 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `WP_Shutdown_Handler` name plus related function names were premature when originally committed, as there can be multiple shutdown handlers in PHP, and WordPress makes use of that feature. This changeset modifies the name to a more appropriate `WP_Fatal_Error_Handler`, and related to that changes the following names:
* The drop-in to override the handler is now called `fatal-error-handler.php`.
* The internal function `wp_register_premature_shutdown_handler` is now called `wp_register_fatal_error_handler()`.
In addition to these naming changes, a new constant `WP_DISABLE_FATAL_ERROR_HANDLER` is introduced that can be set in `wp-config.php` to entirely disable the fatal error handler. That constant's value is and should be accessed indirectly via a new `wp_is_fatal_error_handler_enabled()` function and is filterable via a new `wp_fatal_error_handler_enabled` hook. Note that disabling the fatal error handler will skip the new functionality entirely, including the potentially used `fatal-error-handler.php` drop-in.
The new set of constant, filter and function provide for an easier-to-use mechanism to disable the fatal error handler altogether, rather than requiring developers to implement a drop-in for purely that purpose.
Props afragen, flixos90, joyously, knutsp, markjaquith, ocean90, schlessera, spacedmonkey.
Fixes#46047. See #44458.
Built from https://develop.svn.wordpress.org/trunk@44674
git-svn-id: http://core.svn.wordpress.org/trunk@44505 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset introduces a `WP_Shutdown_Handler` class that detects fatal errors and which extension (plugin or theme) causes them. Such an error is then recorded, and an error message is displayed. Subsequently, in certain protected areas, for example the admin, the broken extension will be paused, ensuring that the website is still usable in the respective area. The major benefit is that this mechanism allows site owners to still log in to their website, to fix the problem by either disabling the extension or solving the bug and then resuming the extension.
Extensions are only paused in certain designated areas. The frontend for example stays unaffected, as it is impossible to know what pausing the extension would cause to be missing, so it might be preferrable to clearly see that the website is temporarily not accessible instead.
The fatal error recovery is especially important in scope of encouraging the switch to a maintained PHP version, as not necessarily every WordPress extension is compatible with all PHP versions. If problems occur now, non-technical site owners that do not have immediate access to the codebase are not locked out of their site and can at least temporarily solve the problem quickly.
Websites that have custom requirements in that regard can implement their own shutdown handler by adding a `shutdown-handler.php` drop-in that returns the handler instance to use, which must be based on a class that inherits `WP_Shutdown_Handler`. That handler will then be used in place of the default one.
Websites that would like to modify specifically the error template displayed in the frontend can add a `php-error.php` drop-in that works similarly to the existing `db-error.php` drop-in.
Props afragen, bradleyt, flixos90, ocean90, schlessera, SergeyBiryukov, spacedmonkey.
Fixes#44458.
Built from https://develop.svn.wordpress.org/trunk@44524
git-svn-id: http://core.svn.wordpress.org/trunk@44355 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* `plugin_loaded`: Fires once a single activated plugin has loaded.
* `mu_plugin_loaded`: Fires once a single must-use plugin has loaded.
* `network_plugin_loaded`: Fires once a single network-activated plugin has loaded.
Props Rarst, schlessera.
Fixes#41346.
Built from https://develop.svn.wordpress.org/trunk@44344
git-svn-id: http://core.svn.wordpress.org/trunk@44174 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`WP_REST_Block_Renderer_Controller` allows rendering of server-side rendered blocks, whilst `WP_REST_Blocks_Controller` allows retrieving of reusable blocks.
Merges [43805] and [43806] from the 5.0 branch to trunk.
Props desrosj, danielbachhuber, pento, Presskopp, swissspidy.
See #45065, #45098.
Built from https://develop.svn.wordpress.org/trunk@44150
git-svn-id: http://core.svn.wordpress.org/trunk@43980 1a063a9b-81f0-0310-95a4-ce76da25c4cd
- Adds `WP_REST_Autosaves_Controller` which extends `WP_REST_Revisions_Controller`.
- Autosaves endpoint is registered for all post types except attachment because even post types without revisions enabled are expected to autosave.
- Because setting the `DOING_AUTOSAVE` constant pollutes the test suite, autosaves tests are run last. We may want to improve upon this later.
Also, use a truly impossibly high number in User Controller tests. The number `100`, (or `7777` in `trunk`), could be valid in certain test run configurations. The `REST_TESTS_IMPOSSIBLY_HIGH_NUMBER` constant is impossibly high for this very reason.
Finally, Skip Autosaves controller test for multisite. There's a PHP 5.2 edge case where paths calculated differently, possibly caused by differing version of PHPUnit.
Props adamsilverstein, aduth, azaozz, danielbachhuber, rmccue, danielbachhuber.
Merges [43767], [43768], [43769] to trunk.
See #45132, #45131.
Fixes#45128, #43316.
Built from https://develop.svn.wordpress.org/trunk@44126
git-svn-id: http://core.svn.wordpress.org/trunk@43956 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `WP_Block_Parser` class, and the accompanying `parse_blocks()` helper function, can be used to parse an array of blocks out of a content string.
`WP_Block_Parser` is copied from the `@wordpress/block-serialization-default-parser` package. To ensure it stays in sync with the JavaScript parser, changes should be implemented in the package first, then the package version should be upgraded to include the changes.
Props pento.
Merges [43751] to trunk.
See #45109.
Built from https://develop.svn.wordpress.org/trunk@44116
git-svn-id: http://core.svn.wordpress.org/trunk@43946 1a063a9b-81f0-0310-95a4-ce76da25c4cd
These are the foundational classes allowing blocks to be registered and used throughout WordPress.
This commit also includes the `has_block()` and `has_blocks()` functions, which are required for unit testing these classes.
Merges [43742] from the 5.0 branch to trunk.
Props adamsilverstein, danielbachhuber, desrosj.
Fixes#45097.
See #45109.
Built from https://develop.svn.wordpress.org/trunk@44108
git-svn-id: http://core.svn.wordpress.org/trunk@43938 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introduces a `WP_REST_Search_Controller` class which registers a `/wp/v2/search` endpoint. Search types are handled by extending `WP_REST_Search_Handler`. The default search type is `WP_REST_Post_Search_Handler` but can be filtered by plugins or a theme.
Merges [43739,43741] from the 5.0 branch to trunk.
Props danielbachhuber, flixos90, pento, rmccue, joehoyle.
Fixes#39965.
Built from https://develop.svn.wordpress.org/trunk@44107
git-svn-id: http://core.svn.wordpress.org/trunk@43937 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In order to correctly render parts of its UI, the new editor needs to be aware of the active theme's post-formats and post-thumbnails support. This data is exposed by querying for the active theme on a new /wp/v2/themes endpoint for sufficiently privileged users.
Merges [43734], [43735] to trunk.
props desrosj.
Fixes#45016.
Built from https://develop.svn.wordpress.org/trunk@43985
git-svn-id: http://core.svn.wordpress.org/trunk@43817 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Edits to active plugins which cause PHP fatal errors will no longer auto-deactivate the plugin. Supersedes #39766.
* Introduce sandboxed PHP file edits for active themes, preventing accidental whitescreening of a user's site when introducing a fatal error.
* After writing a change to a PHP file for an active theme or plugin, perform loopback requests on the file editor admin screens and the homepage to check for fatal errors. If a fatal error is encountered, roll back the edited file and display the error to the user to fix and try again.
* Introduce a secure way to scrape PHP fatal errors from a site via `wp_start_scraping_edited_file_errors()` and `wp_finalize_scraping_edited_file_errors()`.
* Moves file modifications from `theme-editor.php` and `plugin-editor.php` to common `wp_edit_theme_plugin_file()` function.
* Refactor themes and plugin editors to submit file changes via Ajax instead of doing full page refreshes when JS is available.
* Use `get` method for theme/plugin dropdowns.
* Improve styling of plugin editors, including width of plugin/theme dropdowns.
* Improve notices API for theme/plugin editor JS component.
* Strip common base directory from plugin file list. See #24048.
* Factor out functions to list editable file types in `wp_get_theme_file_editable_extensions()` and `wp_get_plugin_file_editable_extensions()`.
* Scroll to line in editor that has linting error when attempting to save. See #41886.
* Add checkbox to dismiss lint errors to proceed with saving. See #41887.
* Only style the Update File button as disabled instead of actually disabling it for accessibility reasons.
* Ensure that value from CodeMirror is used instead of `textarea` when CodeMirror is present.
* Add "Are you sure?" check when leaving editor when there are unsaved changes.
Supersedes [41560].
See #39766, #24048, #41886.
Props westonruter, Clorith, melchoyce, johnbillion, jjj, jdgrimes, azaozz.
Fixes#21622, #41887.
Built from https://develop.svn.wordpress.org/trunk@41721
git-svn-id: http://core.svn.wordpress.org/trunk@41555 1a063a9b-81f0-0310-95a4-ce76da25c4cd
"Install" is not a noun, and while it might be acceptable to use the verb as a noun, it is not correct. Using the correct
noun, "installation", increases clarity, especially for non-native English speakers.
This change fixes the usage in user-facing text and in developer documentation.
Fixes#41620
Built from https://develop.svn.wordpress.org/trunk@41289
git-svn-id: http://core.svn.wordpress.org/trunk@41129 1a063a9b-81f0-0310-95a4-ce76da25c4cd
With the introduction of user-specific languages in [38705] it's necessary to be able to switch translations on the fly. For example emails should be sent in the language of the recipient and not the one of the current user.
This introduces a new `WP_Locale_Switcher` class which is used for switching locales and translations. It holds the stack of locales whenever `switch_to_locale( $locale )` is called. With `restore_previous_locale()` you can restore the previous locale. `restore_current_locale()` empties the stack and sets the locale back to the initial value.
`switch_to_locale()` is added to most of core's email functions, either with the value of `get_locale()` (site language) or `get_user_locale()` (user language with fallback to site language).
Props yoavf, tfrommen, swissspidy, pbearne, ocean90.
See #29783.
Fixes#26511.
Built from https://develop.svn.wordpress.org/trunk@38961
git-svn-id: http://core.svn.wordpress.org/trunk@38904 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In addition to `wp_list_filter()` for filtering a list of objects, and `wp_list_pluck()` for plucking a certain field out of each object in a list, this new function can be used for sorting a list of objects by specific fields. These functions are now all contained within the new `WP_List_Util()` class and `wp_list_sort()` is used in various parts of core for sorting lists.
This was previously committed in [38859] but got reverted in [38862] and [38863]. To fix the previous issues, `wp_list_sort()` supports now an additional argument to preserve array keys via `uasort()`.
Props flixos90, DrewAPicture, jorbin.
Fixes#37128.
Built from https://develop.svn.wordpress.org/trunk@38928
git-svn-id: http://core.svn.wordpress.org/trunk@38871 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously we ensured that the entry points to WordPress were parsable by PHP4 in order to display a friendly not-supported-php error message.
However, for the last two years the main entry points have not actually parsed, and we've only added extra parse errors since it last worked in 3.9, so it's time we just remove this 'feature'.
The PHP version checks are still there for PHP 5.0/5.1, and so it's inplace when we eventually drop PHP 5.2 support.
See #29489.
Built from https://develop.svn.wordpress.org/trunk@38899
git-svn-id: http://core.svn.wordpress.org/trunk@38842 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In addition to `wp_list_filter()` for filtering a list of objects, and `wp_list_pluck()` for plucking a certain field out of each object in a list, this new function can be used for sorting a list of objects by specific fields. These functions are now all contained within the new `WP_List_Util()` class and `wp_list_sort()` is used in various parts of core for sorting lists.
Props flixos90, DrewAPicture, jorbin.
Fixes#37128.
Built from https://develop.svn.wordpress.org/trunk@38859
git-svn-id: http://core.svn.wordpress.org/trunk@38802 1a063a9b-81f0-0310-95a4-ce76da25c4cd
REST API endpoints for your WordPress content. These endpoints provide machine-readable external access to your WordPress site with a clear, standards-driven interface, allowing new and innovative apps for interacting with your site. These endpoints support all of the following:
- Posts: Read and write access to all post data, for all types of post-based data, including pages and media.
- Comments: Read and write access to all comment data. This includes pingbacks and trackbacks.
- Terms: Read and write access to all term data.
- Users: Read and write access to all user data. This includes public access to some data for post authors.
- Meta: Read and write access to metadata for posts, comments, terms, and users, on an opt-in basis from plugins.
- Settings: Read and write access to settings, on an opt-in basis from plugins and core. This enables API management of key site content values that are technically stored in options, such as site title and byline.
Love your REST API, WordPress! The infrastructure says, "Let's do lunch!" but the content API endpoints say, "You're paying!"
Props rmccue, rachelbaker, danielbachhuber, joehoyle, adamsilverstein, afurculita, ahmadawais, airesvsg, alisspers, antisilent, apokalyptik, artoliukkonen, attitude, boonebgorges, bradyvercher, brianhogg, caseypatrickdriscoll, chopinbach, chredd, christianesperar, chrisvanpatten, claudiolabarbera, claudiosmweb, cmmarslender, codebykat, coderkevin, codfish, codonnell822, daggerhart, danielpunkass, davidbhayes, delphinus, desrosj, dimadin, dotancohen, DrewAPicture, Dudo1985, duncanjbrown, eherman24, eivhyl, eliorivero, elyobo, en-alis, ericandrewlewis, ericpedia, evansobkowicz, fjarrett, frozzare, georgestephanis, greatislander, guavaworks, hideokamoto, hkdobrev, hubdotcom, hurtige, iandunn, ircrash, ironpaperweight, iseulde, Japh, jaredcobb, JDGrimes, jdolan, jdoubleu, jeremyfelt, jimt, jjeaton, jmusal, jnylen0, johanmynhardt, johnbillion, jonathanbardo, jorbin, joshkadis, JPry, jshreve, jtsternberg, JustinSainton, kacperszurek, kadamwhite, kalenjohnson, kellbot, kjbenk, kokarn, krogsgard, kuchenundkakao, kuldipem, kwight, lgedeon, lukepettway, mantismamita, markoheijnen, matrixik, mattheu, mauteri, maxcutler, mayukojpn, michael-arestad, miyauchi, mjbanks, modemlooper, mrbobbybryant, NateWr, nathanrice, netweb, NikV, nullvariable, oskosk, oso96_2000, oxymoron, pcfreak30, pento, peterwilsoncc, Pezzab, phh, pippinsplugins, pjgalbraith, pkevan, pollyplummer, pushred, quasel, QWp6t, schlessera, schrapel, Shelob9, shprink, simonlampen, Soean, solal, tapsboy, tfrommen, tharsheblows, thenbrent, tierra, tlovett1, tnegri, tobych, Toddses, toro_unit, traversal, vanillalounge, vishalkakadiya, wanecek, web2style, webbgaraget, websupporter, westonruter, whyisjake, wonderboymusic, wpsmith, xknown, zyphonic.
Fixes#38373.
Built from https://develop.svn.wordpress.org/trunk@38832
git-svn-id: http://core.svn.wordpress.org/trunk@38775 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changes the global `$wp_taxonomies` to an array of `WP_Taxonomy ` objects. `WP_Taxonomy ` includes methods to handle rewrite rules and hooks.
Each taxonomy argument becomes a property of `WP_Taxonomy`. Introducing such a class makes further improvements in the future much more feasible.
Props boonebgorges for review.
Fixes#36224. See #36217.
Built from https://develop.svn.wordpress.org/trunk@38747
git-svn-id: http://core.svn.wordpress.org/trunk@38690 1a063a9b-81f0-0310-95a4-ce76da25c4cd
After [38364], the inclusion of `class-wp-locale.php` was changed from a `require_once()` to a `require()`. This caused problems for anything that called `load_text_domain_early()` prior to the `require()` but didn't bail, as it was now being `require()`-ed a second time.
With the use of `require_once()`, it doesn't really matter where it's loaded, so it has been moved next to the related `l10n.php` load.
See #37827.
Built from https://develop.svn.wordpress.org/trunk@38496
git-svn-id: http://core.svn.wordpress.org/trunk@38437 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* `wp-admin` and `wp-includes` are scanned for classes to autoload
* Several 3rd-party and Ryan McCue-shaped libraries are excluded when the classmap is generated, see `composer.json`: `autoload.exclude-from-classmap`
* `wp-vendor/autoload_52.php` is included at the top of `wp-settings.php` - no changes need to be made to unit tests to include the autoloader
* An avalanche of `require()` and `require_once()` calls that loaded class files have been removed from the codebase.
The following files have been added to `svn:ignore` - they are not 5.2-compatible and fail during pre-commit:
* src/wp-vendor/autoload.php
* src/wp-vendor/composer/autoload_real.php
* src/wp-vendor/composer/autoload_static.php
* src/wp-vendor/composer/ClassLoader.php
We favor these files instead:
* src/wp-vendor/autoload_52.php
* src/wp-vendor/composer/autoload_real_52.php
* src/wp-vendor/composer/ClassLoader52.php
When new PHP classes are added to the codebase, simply run `composer install` or `composer update` from the project root to update the autoloader.
The future is now.
See #36335.
Built from https://develop.svn.wordpress.org/trunk@38399
git-svn-id: http://core.svn.wordpress.org/trunk@38340 1a063a9b-81f0-0310-95a4-ce76da25c4cd
First added in [37588] and later modified in [38224], the idea was to ensure that filters/actions added before `advance-cache.php` would not disappear if `advance-cache.php` overloaded the filters/actions with code such as `$wp_filter = array()`. This is an edge case and one that there is no documented case of existing.
This restores the behavior from WordPress 4.5 and before. It is strongly encouraged that developers using `advance-cache.php` to use the Plugins API that is available before the loading of `advance-cache.php` rather than directly interacting with any of the globals.
Props azaozz, jorbin, dd32 for review, pento for review, westi for investigation, ipstenu for research.
See #36819.
Built from https://develop.svn.wordpress.org/trunk@38251
git-svn-id: http://core.svn.wordpress.org/trunk@38192 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[37588] added methods to backup the plugin globals, for ensuring that advanced cache drop-ins don't overwrite hooks that've been added earlier in the load process.
The method for restoring the plugin globals wasn't compatible with the implementation of `WP_Hook` in #17817. `WP_Hook` implements `ArrayAccess`, so `_restore_plugin_globals()` was treating it as an array, and inadvertantly overwriting the `WP_Hook` object with a plain array.
To avoid having to re-write this code as part of #17817, we now use `add_filter()` to restore any hooks that were added by cache drop-ins, which `WP_Hook` correctly supports.
Props pento, jorbin.
See #36819.
Built from https://develop.svn.wordpress.org/trunk@38223
git-svn-id: http://core.svn.wordpress.org/trunk@38164 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Provides a consistent way to query `$wpdb->site` for `WP_Network` objects based on domain, path, network ID, and (main) site ID.
Introduces and uses update_network_cache() and _prime_network_caches() to maintain a cached list of WP_Network objects for use in multiple queries.
Props flixos90.
See #32504.
Built from https://develop.svn.wordpress.org/trunk@37894
git-svn-id: http://core.svn.wordpress.org/trunk@37835 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changes the global `$wp_post_types` to an array of `WP_Post_Type` objects. `WP_Post_Type` includes methods to handle post type supports, rewrite rules, meta boxes, hooks, and taxonomies.
Each post type argument becomes a property of `WP_Post_Type`.
Props swissspidy, flixos90.
Fixes#36217.
Built from https://develop.svn.wordpress.org/trunk@37890
git-svn-id: http://core.svn.wordpress.org/trunk@37831 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Non web interfaces with WordPress (such as wp-cli) need to be able to bypass certain checks in the bootstrap process. This introduces three new filters to allow for those checks to be skipped.
1. Provides a way of forcefully bypassing wp_maintenance().
2. Provides a way of forcefully bypassing wp_debug_mode(). See https://github.com/wp-cli/wp-cli/issues/177
3. Provide a way of forcefully skipping loading wp-content/advance-cache.php. See https://github.com/wp-cli/wp-cli/pull/164
These filters should not be used by plugins (in fact, they run before plugins are loaded, so they can't be used by plugins). In general, they should only be used in non-web interactions with WordPress.
See #34936.
Props jorbin, DrewAPicture.
Built from https://develop.svn.wordpress.org/trunk@37626
git-svn-id: http://core.svn.wordpress.org/trunk@37594 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In order to allow non-web initializations of WordPress (such as through wp-cli) to modify things like the check for maintenance mode, plugins.php and the associated functions must be available much earlier. The use of these functions earlier than the loading of plugins is not recommended in most use cases.
Fixes#36819. See #34936.
Props jorbin, danielbachhuber for documentation.
Built from https://develop.svn.wordpress.org/trunk@37588
git-svn-id: http://core.svn.wordpress.org/trunk@37556 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`WP_Term_Query` is modeled on existing query classes, such as those used
for comments and users. It provides a more consistent structure for generating
term queries, and should make it easier to add new functionality in the future.
Props flixos90, boonebgorges.
See #35381.
Built from https://develop.svn.wordpress.org/trunk@37572
git-svn-id: http://core.svn.wordpress.org/trunk@37540 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Provides a consistent way to query `$wpdb->blogs` for `WP_Site` objects based on domain, path, site ID, network ID, and more.
Introduces and uses `update_site_cache()` and `_prime_site_caches()` to maintain a cached list of `WP_Site` objects for use in multiple queries.
Props spacedmonkey, flixos90, DrewAPicture, jeremyfelt, ocean90.
See #35791.
Built from https://develop.svn.wordpress.org/trunk@37477
git-svn-id: http://core.svn.wordpress.org/trunk@37445 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Comment and term meta lazyloading for `WP_Query` loops, introduced in 4.4,
depended on filter callback methods belonging to `WP_Query` objects. This meant
storing `WP_Query` objects in the `$wp_filter` global (via `add_filter()`),
requiring that PHP retain the objects in memory, even when the local variables
would typically be expunged during normal garbage collection. In cases where a
large number of `WP_Query` objects were instantiated on a single pageload,
and/or where the contents of the `WP_Query` objects were quite large, serious
performance issues could result.
We skirt this problem by moving metadata lazyloading out of `WP_Query`. The
new `WP_Metadata_Lazyloader` class acts as a lazyload queue. Query instances
register items whose metadata should be lazyloaded - such as post terms, or
comments - and a `WP_Metadata_Lazyloader` method will intercept comment and
term meta requests to perform the cache priming. Since `WP_Metadata_Lazyloader`
instances are far smaller than `WP_Query` (containing only object IDs), and
clean up after themselves far better than the previous `WP_Query` methods (bp
only running their callbacks a single time for a given set of queued objects),
the resource use is decreased dramatically.
See [36525] for an earlier step in this direction.
Props lpawlik, stevegrunwell, boonebgorges.
Fixes#35816.
Built from https://develop.svn.wordpress.org/trunk@36566
git-svn-id: http://core.svn.wordpress.org/trunk@36533 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`$blog_id` is used in both single and multisite configurations as a global variable, though has never been explicitly marked as such in the global scope. This can cause confusion depending on how core is loaded.
Fixes#34217.
Built from https://develop.svn.wordpress.org/trunk@34961
git-svn-id: http://core.svn.wordpress.org/trunk@34926 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Baby API was born at 2.8KLOC on October 8th at 2:30 UTC. API has lots
of growing to do, so wish it the best of luck.
Thanks to everyone who helped along the way:
Props rmccue, rachelbaker, danielbachhuber, joehoyle, drewapicture,
adamsilverstein, netweb, tlovett1, shelob9, kadamwhite, pento,
westonruter, nikv, tobych, redsweater, alecuf, pollyplummer, hurtige,
bpetty, oso96_2000, ericlewis, wonderboymusic, joshkadis, mordauk,
jdgrimes, johnbillion, jeremyfelt, thiago-negri, jdolan, pkevan,
iseulde, thenbrent, maxcutler, kwight, markoheijnen, phh, natewr,
jjeaton, shprink, mattheu, quasel, jmusal, codebykat, hubdotcom,
tapsboy, QWp6t, pushred, jaredcobb, justinsainton, japh, matrixik,
jorbin, frozzare, codfish, michael-arestad, kellbot, ironpaperweight,
simonlampen, alisspers, eliorivero, davidbhayes, JohnDittmar, dimadin,
traversal, cmmarslender, Toddses, kokarn, welcher, and ericpedia.
Fixes#33982.
Built from https://develop.svn.wordpress.org/trunk@34928
git-svn-id: http://core.svn.wordpress.org/trunk@34893 1a063a9b-81f0-0310-95a4-ce76da25c4cd
For the past 6 years, WordPress has operated as an oEmbed consumer, allowing users to easily embed content from other sites. By adding oEmbed provider support, this allows any oEmbed consumer to embed posts from WordPress sites.
In addition to creating an oEmbed provider, WordPress' oEmbed consumer code has been enhanced to work with any site that provides oEmbed data (as long as it matches some strict security rules), and provides a preview from within the post editor.
For security, embeds appear within a sandboxed iframe - the iframe content is a template that can be styled or replaced entirely by the theme on the provider site.
Props swissspidy, pento, melchoyce, netweb, pfefferle, johnbillion, extendwings, davidbinda, danielbachhuber, SergeyBiryukov, afercia
Fixes#32522.
Built from https://develop.svn.wordpress.org/trunk@34903
git-svn-id: http://core.svn.wordpress.org/trunk@34868 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `WP_INSTALLING` constant is a flag that WordPress sets in a number of
places, telling the system that options should be fetched directly from the
database instead of from the cache, that WP should not ping wordpress.org for
updates, that the normal "not installed" checks should be bypassed, and so on.
A constant is generally necessary for this purpose, because the flag is
typically set before the WP bootstrap, meaning that WP functions are not yet
available. However, it is possible - notably, during `wpmu_create_blog()` -
for the "installing" flag to be set after WP has already loaded. In these
cases, `WP_INSTALLING` would be set for the remainder of the process, since
there's no way to change a constant once it's defined. This, in turn, polluted
later function calls that ought to have been outside the scope of site
creation, particularly the non-caching of option data. The problem was
particularly evident in the case of the automated tests, where `WP_INSTALLING`
was set the first time a site was created, and remained set for the rest of the
suite.
The new `wp_installing()` function allows developers to fetch the current
installation status (when called without any arguments) or to set the
installation status (when called with a boolean `true` or `false`). Use of
the `WP_INSTALLING` constant is still supported; `wp_installing()` will default
to `true` if the constant is defined during the bootstrap.
Props boonebgorges, jeremyfelt.
See #31130.
Built from https://develop.svn.wordpress.org/trunk@34828
git-svn-id: http://core.svn.wordpress.org/trunk@34793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
