WPCS 1.0.0 includes a bunch of new auto-fixers, which drops the number of coding standards issues across WordPress significantly. Prior to running the auto-fixers, there were 15,312 issues detected. With this commit, we now drop to 4,769 issues.
This change includes three notable additions:
- Multiline function calls must now put each parameter on a new line.
- Auto-formatting files is now part of the `grunt precommit` script.
- Auto-fixable coding standards issues will now cause Travis failures.
Fixes#44600.
git-svn-id: https://develop.svn.wordpress.org/trunk@43571 602fd350-edb4-49c9-b593-d223f7449a82
Add missing translator comments in `WP_Theme_Install_List_Table` and `wp_notify_postauthor()`.
Add missing commas in some translator comments.
Fixes#43523.
git-svn-id: https://develop.svn.wordpress.org/trunk@42827 602fd350-edb4-49c9-b593-d223f7449a82
This code branch is responsible for running all autoupdates, including plugins and themes - which should run regardless of if there's a core autoupdate available.
This revert does not revert the `$timeout` changes, as these should still use cached data if it's available.
Ideally this should be decoupled from the core update check to allow background updates to operate even when the core update check is disabled or running more often than twice daily.
See #43103.
git-svn-id: https://develop.svn.wordpress.org/trunk@42653 602fd350-edb4-49c9-b593-d223f7449a82
This change reduces the number of API calls which WordPress makes to api.wordpress.org during release windows.
Previously the background updates would run upon every core update transient refresh, however now they'll only run if there's an update available.
The change also increases the cache period for plugin & theme checks when running via the cron, from never-cache to 2 hours, which should hopefully reduce the number of needless API calls.
Fixes#43103 for trunk.
git-svn-id: https://develop.svn.wordpress.org/trunk@42584 602fd350-edb4-49c9-b593-d223f7449a82
WordPress' code just... wasn't.
This is now dealt with.
Props jrf, pento, netweb, GaryJ, jdgrimes, westonruter, Greg Sherwood from PHPCS, and everyone who's ever contributed to WPCS and PHPCS.
Fixes#41057.
git-svn-id: https://develop.svn.wordpress.org/trunk@42343 602fd350-edb4-49c9-b593-d223f7449a82
This filter allows the data being sent for core update checks to be controlled for privacy concerns.
Props toscho, MattyRob, swissspidy, pento.
Fixes#16778.
git-svn-id: https://develop.svn.wordpress.org/trunk@41962 602fd350-edb4-49c9-b593-d223f7449a82
Calling the `count_users()` function is expensive, regardless of the counting strategy that's used, and it gets
slower the more users there are on a site. In order to speed up the Users screen in the admin area, calling
`count_users()` can be avoided entirely while still displaying the total count for users.
This introduces some new functions:
* `wp_is_large_user_count()`
* `wp_get_active_user_count()`
* `wp_update_active_user_count()`
A corresponding `wp_is_large_user_count` filter is also introduced.
Props tharsheblows, johnbillion
Fixes#38741
git-svn-id: https://develop.svn.wordpress.org/trunk@41613 602fd350-edb4-49c9-b593-d223f7449a82
This also standardises the `User-Agent` used when communicating with WordPress.org, allowing for more consistent version detection.
Fixes#42004.
git-svn-id: https://develop.svn.wordpress.org/trunk@41605 602fd350-edb4-49c9-b593-d223f7449a82
This fixes the paths in `wp-vendor/` that were including `src`. I want to drop this in so we can find out what else will break.
See #36335.
git-svn-id: https://develop.svn.wordpress.org/trunk@38411 602fd350-edb4-49c9-b593-d223f7449a82
The generated classmaps reference `/src/` files and operates in the assumption that the base directory is one level above `wp-settings.php`, which it isn't after our build processes are run.
See #36335
git-svn-id: https://develop.svn.wordpress.org/trunk@38402 602fd350-edb4-49c9-b593-d223f7449a82
* `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.
git-svn-id: https://develop.svn.wordpress.org/trunk@38399 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@34828 602fd350-edb4-49c9-b593-d223f7449a82
* `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.
git-svn-id: https://develop.svn.wordpress.org/trunk@32635 602fd350-edb4-49c9-b593-d223f7449a82
`default-filters.php` is loaded before the `$current_site` global is set, so `is_main_site()` cannot be used there.
fixes#30947.
git-svn-id: https://develop.svn.wordpress.org/trunk@31708 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@30856 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@30554 602fd350-edb4-49c9-b593-d223f7449a82
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
git-svn-id: https://develop.svn.wordpress.org/trunk@30384 602fd350-edb4-49c9-b593-d223f7449a82
Installed plugins that are up to date are now returned in the update-check API response.
props tellyworth.
see #17902.
git-svn-id: https://develop.svn.wordpress.org/trunk@29226 602fd350-edb4-49c9-b593-d223f7449a82
* `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.
git-svn-id: https://develop.svn.wordpress.org/trunk@28500 602fd350-edb4-49c9-b593-d223f7449a82
