* `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
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
