`$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
- Adds a complete hash notation for the `WP_Date_Query` arguments array.
- Adds missing documentation for the `date_query_valid_columns` and `get_date_sql` filter hooks.
Props aeg0125 for the incremental patches.
Fixes#25552.
Built from https://develop.svn.wordpress.org/trunk@25860
git-svn-id: http://core.svn.wordpress.org/trunk@25860 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Have wp_get_image_editor() rather than WP_Image_Editor::get_instance(). Having static factory methods would be less confusing if there weren't also static methods tied to individual editor implementations.
* Lazy-load the WP_Image_Editor base class and editor implementations.
* Have WP_Image_Editor_GD::supports_mime_type() actually check which types it supports.
* Deprecate gd_edit_image_support() in favor of wp_image_editor_supports().
props DH-Shredder, scribu, markoheijnen. fixes#22356. see #6821.
git-svn-id: http://core.svn.wordpress.org/trunk@22817 1a063a9b-81f0-0310-95a4-ce76da25c4cd
wp-includes/admin-bar.php:
* Replace get_admin_url() and get_home_url() with admin_url() and home_url() and place them inside a switch/restore. Likewise replace current_user_can_for_blog() with current_user_can(). This avoids doing multiple switch restores.
wp-includes/ms-blogs.php:
* Deprecate the $validate argument to switch_to_blog(). This avoids a not very necessary call to get_blog_details(), possibly saving a few queries.
* Use $_wp_switched and $_wp_switched_stack instead of $switched and $switched_stack to make it less likely these globals will be stomped.
* Use GLOBALS to access blog_id and other globals. I've preferred this style lately since it makes it obvious a global is being used and avoids global blog_id being stomped by a local variable.
* Lose some is_object() checks. wp_get_current_user() always returns an object, for example.
* Call the new WP_Roles::reinit() method.
wp-includes/class-wp-xmlrpc-server.php:
* Replace current_user_can_for_blog() with current_user_can() and move it inside the switch/restore pair. This eliminates a switch/restore.
wp-includes/capabilities.php:
* Use array_keys() instead of $role => $data since $data is unused. I *think* this is a bit faster.
* Introduce WP_Roles::reinit(). This reinitializes WP_Roles and is used after switch_to_blog() has already update the blog ID in the wpdb object. If a global roles array is being used instead of the db, reinit is skipped.
* current_user_can_for_blog() now does a switch/restore. It didn't before meaning it could be reinitializing the user with the wrong role information for the current blog.
wp-includes/ms-settings.php:
* Define $_wp_switched_stack and $_wp_switched. This way switch_to_blog() and restore_current_blog() can rely on it being set.
wp-settings.php:
* Instantiate the WP_Roles global. This was it is always defined during init. To remove the WP_Roles checks from WP_Role and WP_User this would probably have to move before plugins are loaded, which might not be a good thing.
wp-includes/functions.php:
* Update wp_upload_dir() to reference _wp_switched.
git-svn-id: http://core.svn.wordpress.org/trunk@21485 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Getters and Helpers: Introduces a series of methods to allow for easy generation of headers for display, and other theme metadata, including page templates.
* Screenshots: Handles support for multiple screenshots. (see # Additional screenshots must be PNG and start with screenshot-2.png, and be sequential to be counted. see #19816.
* Error Handling: Broken themes have a WP_Error object attached to them.
* Caching: Introduces a wp_cache_themes_persistently filter (also in [20020]) to enable persistent caching of all filesystem and sanitization operations normally handled by WP_Theme (and formerly get_file_data() and get_themes()). Themes are cached individually and across five different cache keys for different data pieces.
* Compatibility: A WP_Theme object is backwards compatible with a theme's array formerly returned by get_themes() and get_theme(), and an stdClass object formerly returned by current_theme_info().
* i18n/L10n: Theme headers are now localizable with proper Text Domain and Domain Path headers, like plugins. (Language packs may remove the requirement for headers.) For page templates, see #6007 (not fixed yet, but will be easy now). For headers, fixes#15858.
* PHP and CSS files: New methods that fetch a list of theme files (for the theme editor) only on demand, rather than only loading them into memory. fixes#11214.
Functions deprecated:
* get_themes(), get_allowed_themes() and get_broken_themes() -- use wp_get_themes()
* get_theme() and current_theme_info() -- use wp_get_theme()
* get_site_allowed_themes() -- use WP_Theme::get_allowed_on_network()
* wpmu_get_blog_allowedthemes() -- use WP_theme::get_allowed_on_site()
see also [20016], [20018], [20019], [20020], [20021], [20022], [20025], [20026], [20027]. also fixes#19244.
see #20103.
git-svn-id: http://svn.automattic.com/wordpress/trunk@20029 1a063a9b-81f0-0310-95a4-ce76da25c4cd
