In 4.3 the widget controls were fully initialized up front along with the sidebar controls. The sidebar control depended (unnecessarily) on the widget control to ensure that `wp.customize.Widgets.savedWidgetIds` was defined. So after [34563] there could be a situation where the widgets are added/removed from a sidebar before their controls are initialized (if the sidebar section is never expanded), resulting in an error attempting to get a property off of an undefined value. So this change does the right thing and defines `savedWidgetIds` up front.
Also changes the `savedWidgetIds` variable type from an array to an object, to match how it is used as a dictionary lookup.
See #33901.
Built from https://develop.svn.wordpress.org/trunk@34883
git-svn-id: http://core.svn.wordpress.org/trunk@34848 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
After some discussion, it was decided that Multisite vs single site context can just as easily be derived using available functions like `is_network_admin()`, `get_current_screen()`, etc., rendering the second parameter moot. The hook was introduced in [34796].
Fixes#25360.
Built from https://develop.svn.wordpress.org/trunk@34813
git-svn-id: http://core.svn.wordpress.org/trunk@34778 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The current list table is passed as a second parameter, `$this`, and can take the form of either a `WP_Users_List_Table` or `WP_MS_Users_List_Table` instance depending on the context in which the filter was evaluated.
Props juliobox for the initial patch.
Fixes#25360.
Built from https://develop.svn.wordpress.org/trunk@34796
git-svn-id: http://core.svn.wordpress.org/trunk@34761 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Instead of using `Array.toString()` to serialize an array with comma delimiters, explicitly `join` the array using spaces instead. Also ensure that `xfn` is handled properly if it ever gets stored as an array.
Props tyxla, westonruter.
Fixes#34111.
Built from https://develop.svn.wordpress.org/trunk@34788
git-svn-id: http://core.svn.wordpress.org/trunk@34753 1a063a9b-81f0-0310-95a4-ce76da25c4cd
If the `$action` type is 'query_plugins' or 'plugin_information', the API will return an object, thus an object should be passed if replacing it. For 'hot_tags' and 'hot_categories', the same logic applies, but with arrays instead.
See #34035.
Built from https://develop.svn.wordpress.org/trunk@34763
git-svn-id: http://core.svn.wordpress.org/trunk@34728 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`wp_update_plugins()` and `wp_update_themes()` are both hooked into `upgrader_process_complete` with priority 10. But at this stage the caches in `get_plugins()`, `search_theme_directories()`, and `wp_get_themes()` aren't refreshed yet so both functions couldn't fetch any translations for the new plugin/theme.
To reset the caches `wp_clean_themes_cache()` and `wp_clean_plugins_cache()` are now hooked into `upgrader_process_complete` with priority 9.
Fixes#34029.
Built from https://develop.svn.wordpress.org/trunk@34751
git-svn-id: http://core.svn.wordpress.org/trunk@34716 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The main site on a new network is forced by default into using `/blog` as the prefix for its permalink structure. This can be changed easily through the network admin, though the `options-permalink.php` screen is then unusable to make further changes to the structure.
Now, if `/blog/` is not at the beginning of the `permalink_structure` option, we do not force `/blog` as a prefix in the UI.
Fixes#12002.
Built from https://develop.svn.wordpress.org/trunk@34749
git-svn-id: http://core.svn.wordpress.org/trunk@34714 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Also, add a "Edit Comment" legend before the Quick Edit form to pair it with "Reply to Comment" and "Add new Comment" and move the Name, Email, and URL fields after the Comment textarea.
Props joedolson, afercia.
Fixes#33757.
Built from https://develop.svn.wordpress.org/trunk@34743
git-svn-id: http://core.svn.wordpress.org/trunk@34708 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The call to `flock()` is an exclusive advisory lock, which in my testing only PHP respects (apache continues to read it).
Not all filesystems support locking (remote NFS mounts for example) so this offers minimal benefit to those platforms, but offers much better protection against file corruption on systems which do support it.
The call is blocking, so a second process will wait for the first to complete before writing if supported.
See #31767
Built from https://develop.svn.wordpress.org/trunk@34740
git-svn-id: http://core.svn.wordpress.org/trunk@34704 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This fixes issues where SSH2 with chrooted environments runs into a `Unable to locate WordPress Content directory (wp-content).` error.
The workaround is to simply list the contents of the `/./` directory instead of `/`.
Fixes#33919
Built from https://develop.svn.wordpress.org/trunk@34738
git-svn-id: http://core.svn.wordpress.org/trunk@34702 1a063a9b-81f0-0310-95a4-ce76da25c4cd
