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
When a setting is invalid, not only will it be blocked from being saved but all other settings will be blocked as well. This ensures that Customizer saves aren't partial but are more transactional. User will be displayed the error in a notification so that they can fix and re-attempt saving.
PHP changes:
* Introduces `WP_Customize_Setting::validate()`, `WP_Customize_Setting::$validate_callback`, and the `customize_validate_{$setting_id}` filter.
* Introduces `WP_Customize_Manager::validate_setting_values()` to do validation (and sanitization) for the setting values supplied, returning a list of `WP_Error` instances for invalid settings.
* Attempting to save settings that are invalid will result in the save being blocked entirely, with the errors being sent in the `customize_save_response`. Modifies `WP_Customize_Manager::save()` to check all settings for validity issues prior to calling their `save` methods.
* Introduces `WP_Customize_Setting::json()` for parity with the other Customizer classes. This includes exporting of the `type`.
* Modifies `WP_Customize_Manager::post_value()` to apply `validate` after `sanitize`, and if validation fails, to return the `$default`.
* Introduces `customize_save_validation_before` action which fires right before the validation checks are made prior to saving.
JS changes:
* Introduces `wp.customize.Notification` in JS which to represent `WP_Error` instances returned from the server when setting validation fails.
* Introduces `wp.customize.Setting.prototype.notifications`.
* Introduces `wp.customize.Control.prototype.notifications`, which are synced with a control's settings' notifications.
* Introduces `wp.customize.Control.prototype.renderNotifications()` to re-render a control's notifications in its notification area. This is called automatically when the notifications collection changes.
* Introduces `wp.customize.settingConstructor`, allowing custom setting types to be used in the same way that custom controls, panels, and sections can be made.
* Injects a notification area into existing controls which is populated in response to the control's `notifications` collection changing. A custom control can customize the placement of the notification area by overriding the new `getNotificationsContainerElement` method.
* When a save fails due to setting invalidity, the invalidity errors will be added to the settings to then populate in the controls' notification areas, and the first such invalid control will be focused.
Props westonruter, celloexpressions, mrahmadawais.
See #35210.
See #30937.
Fixes#34893.
Built from https://develop.svn.wordpress.org/trunk@37476
git-svn-id: http://core.svn.wordpress.org/trunk@37444 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introduce `ms_load_current_site_and_network`. This is used by core during the multisite bootstrap process to populate the `$current_site` and `$current_blog` globals based on a requested domain and path.
Return values from this function inform `ms-settings.php` as to whether a page view should continue, `ms_not_installed()` should fire, or a redirect to a new location should occur.
This was previously a procedural block in `ms-settings.php`. Wrapping this code and providing specific return values allows us to write tests that do not rely on the manual and repeated inclusion of `ms-settings.php`.
This should not be used by plugins or themes. Please.
See #34941.
Built from https://develop.svn.wordpress.org/trunk@37475
git-svn-id: http://core.svn.wordpress.org/trunk@37443 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Given a site ID or site object, `get_site()` retrieves site data in the same vein as `get_post()` or `get_comment()`. This will allow for clean retrieval of sites from a primed cache when `WP_Site_Query` is implemented.
Adds a `WP_Site::to_array()` method to support multiple return types within `get_site()`.
Props spacedmonkey.
See #35791.
Built from https://develop.svn.wordpress.org/trunk@37468
git-svn-id: http://core.svn.wordpress.org/trunk@37436 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introduce the `network_edit_site_nav` function, which DRYs up the code used to display a common set of links at the top of "Edit Site" views.
Introduce the `network_edit_site_nav_links` filter, which allows plugins to modify the list of links displayed at the top of Edit Site views as a "tabbed" interface.
Props johnjamesjacoby, c3mdigital, Bueltge.
Fixes#15800.
Built from https://develop.svn.wordpress.org/trunk@37466
git-svn-id: http://core.svn.wordpress.org/trunk@37434 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Clicking on the Edit Menu button focuses on the corresponding nav menu section. Upon collapsing the nav menu section, the focus is returned to the Custom Menu widget instead of taking the user to the menus root panel. In this way, the back button behavior is modified once to serve as breadcrumb/history navigation. The Edit Menu button with the breadcrumb back button behavior greatly reduce the number of UI interactions needed to edit a menu referenced in a Custom Menu widget.
Props celloexpressions, westonruter.
Fixes#32683.
Built from https://develop.svn.wordpress.org/trunk@37437
git-svn-id: http://core.svn.wordpress.org/trunk@37403 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `medium_large_size_w` and `medium_large_size_h` options were added to the
$whitelist_options['media'] in options.php in [35479], which causes both options
to be set to `0` when the media settings are changed. When this occurs, the
medium_large image size will no longer be created when an image is uploaded.
Since these options aren't meant to be updated via the settings UI, they can be
safely removed from the whitelist.
Fixes#36531.
Built from https://develop.svn.wordpress.org/trunk@37435
git-svn-id: http://core.svn.wordpress.org/trunk@37401 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Also use 'back-compat' in some inline comments where backward compatibility is the subject and shorthand feels more natural.
Note: 'backwards compatibility/compatibile' can also be considered correct, though it's primary seen in regular use in British English.
Props ocean90.
Fixes#36835.
Built from https://develop.svn.wordpress.org/trunk@37431
git-svn-id: http://core.svn.wordpress.org/trunk@37397 1a063a9b-81f0-0310-95a4-ce76da25c4cd
WordPress erroneously follows browser-style behaviour with 3xx redirects, where a POST to 302 becomes a GET. Requests instead follows the specification and keeps the same method. Requests also exposes a hook to allow changing the behaviour.
[37428] used the wrong method of adding this hook, now corrected.
See #33055.
Built from https://develop.svn.wordpress.org/trunk@37429
git-svn-id: http://core.svn.wordpress.org/trunk@37395 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This removes the `die()` call from `WP_Widget::widget()` and converts it to an abstract method.
`WP_Widgets` (later renamed to `WP_Widget`) was introduced in [10764] where the minimum PHP requirement was 4.3, thus no `abstract` was available.
Props johnbillion.
Fixes#35981.
Built from https://develop.svn.wordpress.org/trunk@37425
git-svn-id: http://core.svn.wordpress.org/trunk@37391 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When no `$meta` arguments are passed to `wpmu_create_blog()`, `public` is set to `0` in the database for new sites. This is fine, but also does not match the default implied when most sites are created via `site-new.php`.
The only current use of the `$meta` argument in the tests is to (re)mark `public` as `0`. All existing tests pass with this change. Tests for `WP_Site_Query` can now rely on better default expectations.
See #36566.
Built from https://develop.svn.wordpress.org/trunk@37418
git-svn-id: http://core.svn.wordpress.org/trunk@37384 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`load_theme_textdomain()`, `load_plugin_textdomain()` and `load_muplugin_textdomain()` now try to load the .mo file from the `wp-content/languages` directory first. After the introduction of language packs, translation files are more likely to be located there.
Props swissspidy, sebastian.pisula.
Fixes#34213.
Built from https://develop.svn.wordpress.org/trunk@37414
git-svn-id: http://core.svn.wordpress.org/trunk@37380 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Rejoice, for your admins will feel more native to your surrounding computing environment and likely load faster, especially when offline, as they no longer have to talk to The Google Overlord.
At the time of introduction in 3.8, there were not good system fonts common to all platforms at the time. In the years since, Windows, Android, OS X, iOS, Firefox OS, and various flavors of Linux have all gotten their own (good) system UI fonts.
There will definitely be visual bugs, mainly around alignment and spacing; these should be documented and reported on the ticket and fixed more atomically so that our current and future selves have a better understanding of what happened and why.
The style remains registered, as it is almost certainly in use by themes and plugins.
props mattmiklic.
see #36753.
Built from https://develop.svn.wordpress.org/trunk@37361
git-svn-id: http://core.svn.wordpress.org/trunk@37327 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The test, introduced in [32207], used the incorrect syntax for 'meta_query' -
one fewer level of array-nesting than what `WP_Meta_Query` requires. This
slip uncovered a bug introduced into `WP_User_Query` in [30094], whereby
an incorrectly formatted 'meta_query' parameter would be properly parsed by
`WP_User_Query` when passed alongside `who=authors`.
We need to fix the inconsistent syntax in order to resolve#36724.
See #36724, #32019, #23849, #27026.
Built from https://develop.svn.wordpress.org/trunk@37359
git-svn-id: http://core.svn.wordpress.org/trunk@37325 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The rewrite rule matching code in WP::parse_request() used an unclear variable `$request` to represent the requested path (e.g. "2016/05/03") as well as a deceptively named variable `$request_uri`, which actually represents the requested file when an install used PATHINFO links.
Those variables are replaced with `$requested_path` and `$requested_file` respectively for clarity.
Fixes#36674.
Built from https://develop.svn.wordpress.org/trunk@37356
git-svn-id: http://core.svn.wordpress.org/trunk@37322 1a063a9b-81f0-0310-95a4-ce76da25c4cd