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
* `wp_version_check()`, `wp_update_plugins()`, and `wp_update_themes()` do not return meaningful responses, and their responses are never handled by core. As such, they shouldn't alternately return `void` or `false`. "Returning" in those functions is just "bailing"
* In the same functions, `version.php` doesn't need to load if `WP_INSTALLING` is defined - the function will immediately bail, the values will never be read, and the globals won't be reset. I have unified the approach in all 3 functions.
* When returning filtered `$locale`, there is no need to set the variable twice.
* In `_maybe_update_core()`, `isset()` can take multiple values to bail before the call to `time()`, if necessary. This is a micro-optimization to prevent PHP from hitting the OS unnecessarily.
See #32444.
Built from https://develop.svn.wordpress.org/trunk@32635
git-svn-id: http://core.svn.wordpress.org/trunk@32605 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This makes it match most cache-clearing functions, including the ones it wraps. Also no need for it to be prefixed as "private."
wp_clean_plugins_cache() doesn't always exist, so as a quick fix, clear the transient we care to clear.
see #30369.
Built from https://develop.svn.wordpress.org/trunk@30856
git-svn-id: http://core.svn.wordpress.org/trunk@30846 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The update screen has a re-install button which could show the wrong language locale after the site language was changed. That's because the update data is cached.
Introduce `_wp_clear_update_cache()` as a helper function to clean up the update cache.
props SergeyBiryukov, ocean90.
fixes#30369.
Built from https://develop.svn.wordpress.org/trunk@30554
git-svn-id: http://core.svn.wordpress.org/trunk@30543 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This is only enabled when new files will not be installed during the update (as indicated by the WordPress.org API), and does not apply to Plugin/Theme/Translation Background Updates.
Additionally, the code to determine if the 'direct' filesystem transport should be used has been tweaked for wider support (where getmyuid() was unavailalbe) which fixes#10424
See #10205, #30245
Built from https://develop.svn.wordpress.org/trunk@30384
git-svn-id: http://core.svn.wordpress.org/trunk@30381 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* `wp-activate.php` and `wp-admin/themes.php` don't need the closing PHP tag
* Switch single quotes for HTML attribute values to double in a few places
* Convert `include_once file.php` syntax to `include_once( 'file.php' )`
* Add access modifiers to methods/members in: `_WP_List_Table_Compat`, `Walker_Nav_Menu_Edit`, `Walker_Nav_Menu_Checklist`, `WP_Screen`, `Walker_Category_Checklist`
* `edit_user()` doesn't need to import the `$wpdb` global
* `wp_list_widgets()` doesn't need to import the `$sidebars_widgets` global
* switch/endswitch syntax is not supported in Hack
* A `<ul>` in `wp-admin/users.php` is unclosed
See #27881.
Built from https://develop.svn.wordpress.org/trunk@28500
git-svn-id: http://core.svn.wordpress.org/trunk@28326 1a063a9b-81f0-0310-95a4-ce76da25c4cd
These commits were accidentally re-synced commits from develop.svn.wordpress.org due to a race condition. Thankfully, the history of this repository matters fairly little. It also happened only for trunk.
git-svn-id: http://core.svn.wordpress.org/trunk@25876 1a063a9b-81f0-0310-95a4-ce76da25c4cd
For example, 3.7.2 install is served a 3.7.3 update, but the current version is 3.8.1.
This commit also allows for core update notification emails to be sent even when we are unable to run an auto update due to filesystem configuration (VCS checkout or file permissions). But, since these emails go through WP_Automatic_Updater, they will not be sent if the updater is outright disabled.
fixes#25654.
Built from https://develop.svn.wordpress.org/trunk@25873
git-svn-id: http://core.svn.wordpress.org/trunk@25873 1a063a9b-81f0-0310-95a4-ce76da25c4cd
New, final filter names:
* auto_update_{$type} (plugin, theme, core, language)
* automatic_updates_is_vcs_checkout
* automatic_updates_disabled
New class name is WP_Automatic_Updater. Method names include update() and should_update().
see #22704.
Built from https://develop.svn.wordpress.org/trunk@25835
git-svn-id: http://core.svn.wordpress.org/trunk@25835 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Scott Taylor
Dominik Schilling
Drew Jaynes
Dion Hulse
John Blackbourn
Andrew Nacin
Boone Gorges
Sergey Biryukov
Gary Pendergast
Ryan Boren