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
`class-http.php` requires functions from `http.php`, so loading it by itself wouldn't have worked.
Creates:
`class-wp-http-cookie.php`
`class-wp-http-curl.php`
`class-wp-http-encoding.php`
`class-wp-http-proxy.php`
`class-wp-http-streams.php`
`http-functions.php`
`WP_Http` remains in `class-http.php`.
`http.php` contains only top-level code. Class files only contain classes. Functions file only contains functions.
See #33413.
Built from https://develop.svn.wordpress.org/trunk@33748
git-svn-id: http://core.svn.wordpress.org/trunk@33716 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Sessions are stored in usermeta via WP_User_Meta_Session_Tokens, which extends the abstract WP_Session_Tokens class. Extending WP_Session_Tokens can allow for alternative storage, such as a separate table or Redis.
Introduces some simple APIs for session listing and destruction, such as wp_get_active_sessions() and wp_destroy_all_sessions().
This invalidates all existing authentication cookies, as a new segment (the session token) has been added to them.
props duck_, nacin, mdawaffe.
see #20276.
Built from https://develop.svn.wordpress.org/trunk@29221
git-svn-id: http://core.svn.wordpress.org/trunk@29005 1a063a9b-81f0-0310-95a4-ce76da25c4cd
