This tag has been used in the past, but should no longer be used. Just using the `static` keyword in code is enough for PhpDocumentor on PHP5+ to recognize static variables and methods, and PhpDocumentor will mark them as static.
Props birgire.
See #42803.
Built from https://develop.svn.wordpress.org/trunk@42745
git-svn-id: http://core.svn.wordpress.org/trunk@42575 1a063a9b-81f0-0310-95a4-ce76da25c4cd
"Install" is not a noun, and while it might be acceptable to use the verb as a noun, it is not correct. Using the correct
noun, "installation", increases clarity, especially for non-native English speakers.
This change fixes the usage in user-facing text and in developer documentation.
Fixes#41620
Built from https://develop.svn.wordpress.org/trunk@41289
git-svn-id: http://core.svn.wordpress.org/trunk@41129 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Prior to about 2013, many class methods lacked even access modifiers which made the `@access` notations that much more useful. Now that we've gotten to a point where the codebase is more mature from a maintenance perspective and we can finally remove these notations. Notable exceptions to this change include standalone functions notated as private as well as some classes still considered to represent "private" APIs.
See #41452.
Built from https://develop.svn.wordpress.org/trunk@41161
git-svn-id: http://core.svn.wordpress.org/trunk@41001 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* `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
An upgrader class is used in conjunction with an upgrader skin class. A skin class handles the logging for an upgrade and informs a user about the progress and failures.
The current Ajax install/update handlers are using the `Automatic_Upgrader_Skin` class because during an Ajax request no output is intended. The difference between Ajax updates and automatic updates is that you will see the full log (usually by email) while Ajax updates focus only on success or failure. For that `Automatic_Upgrader_Skin` has one disadvantage: It doesn't provide a way to retrieve failure messages which were passed through `WP_Upgrader_Skin::error()` by the upgrader.
To solve this issue a new skin `WP_Ajax_Upgrader_Skin` has been introduced. The skin extends `Automatic_Upgrader_Skin` and overrides the `error()` and `feedback()` methods to intercept all errors, which can be a `WP_Error` object or a string.
This updates all four Ajax handler for installing/updating themes/plugins to use the new skin. They now also check the skin for any intercepted errors and pass them on to the user.
Props flixos90, obenland, ocean90.
Props DrewAPicture, pento for review.
Fixes#37531.
Built from https://develop.svn.wordpress.org/trunk@38199
git-svn-id: http://core.svn.wordpress.org/trunk@38140 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Gone are the days of isolation and feelings of "meh", brought on by The Bleak Screen of Sadness. For a shiny knight has arrived to usher our plugins and themes along their arduous journey of installation, updates, and the inevitable fate of ultimate deletion.
Props swissspidy, adamsilverstein, mapk, afragen, ocean90, ryelle, j-falk, michael-arestad, melchoyce, DrewAPicture, AdamSoucie, ethitter, pento, dd32, kraftbj, Ipstenu, jorbin, afercia, stephdau, paulwilde, jipmoors, khag7, svovaf, jipmoors, obenland.
Fixes#22029, #25828, #31002, #31529, #31530, #31773, #33637, #35032.
Built from https://develop.svn.wordpress.org/trunk@37714
git-svn-id: http://core.svn.wordpress.org/trunk@37680 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Known functions, classes, and methods are now auto-linked in Code Reference pages following #meta1483.
Note: Hook references are still linked via inline `@see` tags due to the unlikelihood of reliably matching for known hooks based on a RegEx pattern.
See #32246.
Built from https://develop.svn.wordpress.org/trunk@37342
git-svn-id: http://core.svn.wordpress.org/trunk@37308 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.
This is a follow-up to [34751].
See #34029.
Fixes#36383.
Built from https://develop.svn.wordpress.org/trunk@37272
git-svn-id: http://core.svn.wordpress.org/trunk@37238 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `_network_option()` parameter order will be changing to accept `$network_id` first. The `_site_option()` functions will remain in use throughout core as our way of retrieving a network option for the current network.
See #28290.
Built from https://develop.svn.wordpress.org/trunk@34912
git-svn-id: http://core.svn.wordpress.org/trunk@34877 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_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
Standardizes summaries and tags for the following classes:
* `WP_Upgrader`
* `Plugin_Upgrader`
* `Theme_Upgrader`
* `Language_Pack_Upgrader`
* `Core_Upgrader`
* `File_Upload_Upgrader`
* `WP_Automatic_Updater`
See #32246.
Built from https://develop.svn.wordpress.org/trunk@34499
git-svn-id: http://core.svn.wordpress.org/trunk@34463 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This will avoid partially deleting an item during update which has inconsistent permissions.
This change only affects those using the direct & ssh transports as FTP's is_writable() currently always returns `true`.
Fixes#30921
Built from https://develop.svn.wordpress.org/trunk@32854
git-svn-id: http://core.svn.wordpress.org/trunk@32825 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`admin-filters.php`
`ms-admin-filters.php`
There are random actions and filters littered among files like `misc.php`. These files contain functions that won't work outside of admin context and are typically only loaded in files that have already loaded the admin bootstrap.
See #32529.
Built from https://develop.svn.wordpress.org/trunk@32653
git-svn-id: http://core.svn.wordpress.org/trunk@32623 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
