The default error handler `wp_handle_upload_error()` expects a reference for the first parameter but `call_user_func()` doesn't pass parameters by reference. The current code didn't produce any issues until now. PHP 7.0.9 (and PHP 7.1) is now stricter and prevents calling the error handler with a warning:
> PHP Warning: Parameter 1 to wp_handle_upload_error() expected to be a reference, value given.
To restore the error handler `_wp_handle_upload()` now uses `call_user_func_array()`.
Merge of [38235] to the 4.6 branch.
Props jbrinley.
Props jorbin for review.
See #37570.
Built from https://develop.svn.wordpress.org/branches/4.6@38236
git-svn-id: http://core.svn.wordpress.org/branches/4.6@38177 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Under certain conditions upgrades on Windows may fail because `wp_tempnam()` gets called in a loop.
This can happen when `wp_tempnam()` is called with `\.maintenance` for the `$filename` parameter. The function strips the extension, in this case `.maintenance`, which results in an empty filename. Because it's empty, `wp_tempnam()` calls itself with `dirname( '\.maintenance' )`. On *nix systems this would be `"/"` which allows `wp_tempnam()` to fall back on `time()`. But on Windows it's `"\"`.
This change adds the backslash to the list of characters which allow `wp_tempnam()` to fall back on `time()`.
See [32322], [31936].
Fixes#33999.
Built from https://develop.svn.wordpress.org/trunk@38151
git-svn-id: http://core.svn.wordpress.org/trunk@38092 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`$context` is a full path to the directory that is tested for being writable. A path shouldn't be a boolean value.
This also updates `WP_Upgrader_Skin::request_filesystem_credentials()` and `Automatic_Upgrader_Skin::request_filesystem_credentials()` and adds missing docs.
Props DrewAPicture, ocean90.
Fixes#37412.
Built from https://develop.svn.wordpress.org/trunk@38138
git-svn-id: http://core.svn.wordpress.org/trunk@38079 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Don't lower memory limit if the current limit is greater than `WP_MAX_MEMORY_LIMIT`.
* Set `WP_MEMORY_LIMIT` and `WP_MAX_MEMORY_LIMIT` to current limit if the `memory_limit` setting can't be changed at runtime.
* Use `wp_convert_hr_to_bytes()` when parsing the value of the `memory_limit` setting because it can be a shorthand or an integer value.
* Introduce `wp_raise_memory_limit( $context )` to raise the PHP memory limit for memory intensive processes. This DRYs up some logic and includes the existing `admin_memory_limit` and `image_memory_limit` filters. The function can also be used for custom contexts, the `{$context}_memory_limit` filter allows to customize the limit.
* Introduce `wp_is_ini_value_changeable( $setting )` to determine whether a PHP ini value is changeable at runtime.
* Remove a `function_exists( 'memory_get_usage' )` check. Since PHP 5.2.1 support for memory limit is always enabled.
Related commits: [38011-38013]
Props jrf, A5hleyRich, swissspidy, ocean90.
Fixes#32075.
Built from https://develop.svn.wordpress.org/trunk@38015
git-svn-id: http://core.svn.wordpress.org/trunk@37956 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Twelve years later, after no fewer than three themes have intentionally implemented popup comments in their functionality, before being abandoned for at least the last six years, we've reached a time where we can put this era behind us. A time when we can remove comment popup functionality from WordPress.
If this breaks the internet, I'll eat my hat.
Fixes#28617
Built from https://develop.svn.wordpress.org/trunk@35848
git-svn-id: http://core.svn.wordpress.org/trunk@35812 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Keeping myhacks support is a small price to pay for not breaking people's sites. Even if it is very very very few sites, breaking sites isn't something that should be encouraged. Even with 10 years of deprecation notices.
https://core.trac.wordpress.org/ticket/33741#comment:18 outlines all the ways that the hack_file and my-hacks options can be setup and thus all the ways that the removal of those options could break sites.
Fixes#33741.
Built from https://develop.svn.wordpress.org/trunk@35688
git-svn-id: http://core.svn.wordpress.org/trunk@35652 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
For the last 10 years, my-hacks has been deprecated and has been throwing a deprecation notice. For the last six years, you haven't been able to enable my-hacks.php in the admin UI. That should be enough time to give developers notice. Plugins and themes seem like they might have staying power.
Fixes#33741
Props bobbingwide
Built from https://develop.svn.wordpress.org/trunk@34291
git-svn-id: http://core.svn.wordpress.org/trunk@34255 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Numerous changes to make the FTP modal experience a good one. These include:
* Update HTML used by both the form here and the form on the standalone screen
* Allow users to cancel FTP install
* Focus locking in the modal
* Focus on modal form on load
* ARIA Attributes
* Style Enhancements
* Add low screen height (such as phone and some tablets) friendly experience for entering credentials
Props ericlewis, afercia
Fixes#31608
Built from https://develop.svn.wordpress.org/trunk@31949
git-svn-id: http://core.svn.wordpress.org/trunk@31928 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This is a restoration of [31749] which was reverted in [31755].
It includes a number of enhancements from the original version. Namely:
* Not doing a credential check in src/wp-includes/script-loader.php
* Add new function `wp_print_request_filesystem_credentials_modal`
* update the version number in the list table when a plugin is updated
UI still needs further work, but this basic version should enable more testing
Props ericlewis, jorbin
See #31528
Built from https://develop.svn.wordpress.org/trunk@31811
git-svn-id: http://core.svn.wordpress.org/trunk@31793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Dominik Schilling
Dion Hulse
Drew Jaynes
Andrea Fercia
Sergey Biryukov
Pascal Birchler
John Blackbourn
Konstantin Kovshenin
Mark Jaquith
Aaron Jorbin
Scott Taylor
Boone Gorges