Previously, personal data exports were stored in `wp-content/uploads/exports`, which is generic enough that it's likely there are existing folders with that name, either created by plugins or manually by administrators. If that folder were reused by Core, then `wp_privacy_delete_old_export_files()` would delete all of the existing files inside it, which is almost certainly not what the site owner wants or expects.
To avoid that, the folder is being renamed to include a specific reference to Core, and a more verbose description of its purpose. With those factored in, it's very unlikely that there will be any conflicts with existing folders.
The `wp_privacy_exports_dir()` and `wp_privacy_exports_url()` functions were introduced to provide a canonical source for the location, and the `wp_privacy_exports_dir` and `wp_privacy_exports_url` filters were introduced to allow plugins to customize it.
Props johnjamesjacoby, allendav.
Fixes#44091.
Built from https://develop.svn.wordpress.org/trunk@43284
git-svn-id: http://core.svn.wordpress.org/trunk@43113 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, when a plugin updated its suggested privacy policy text, an admin notice was shown on all screens in the Administration Panels. That was done in order to make sure that administrators were aware of it, so that they could update their policy if needed. That was a very heavy-handed and intrusive approach, though, which leads to a poor user experience, and notice fatigue.
An alternative approach is to use bubble notifications in the menu, similar to when plugins have updates that need to be installed. That still makes it obvious that something needs the administrator's attention, but is not as distracting as a notice.
The notice will still appear on the Privacy page, though, since it is relevant to that screen, and provides an explanation of why the bubble is appearing.
Props azaozz, xkon, iandunn.
Fixes#43954. See #43953.
Built from https://develop.svn.wordpress.org/trunk@43223
git-svn-id: http://core.svn.wordpress.org/trunk@43052 1a063a9b-81f0-0310-95a4-ce76da25c4cd
r43046 introduced `wp_schedule_delete_old_privacy_export_files()` to schedule the `wp_privacy_delete_old_export_files` cron job, but it did not check to make sure it wasn't running in the context of the install process. When it did run in that context, it created a database error, because the necessary database tables don't exist at that point.
Checking the current context and returning early during the installation phase avoids that issue.
Props helen, timothyblynjacobs, iandunn.
Fixes#43952.
Built from https://develop.svn.wordpress.org/trunk@43162
git-svn-id: http://core.svn.wordpress.org/trunk@42991 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The primary means of protecting the files is the CSPRN appended to the filename, but there is no reason to keep the files after the data subject has downloaded them, so deleting them provides an additional layer of protection. Previously this was done from `wp_privacy_generate_personal_data_export_file()`, but that does not guarantee that it will be run regularly, and on smaller sites that could result in export files being exposed for much longer than necessary.
`wp_privacy_delete_old_export_files()` was moved to a front end file, so that it can be called from `cron.php`.
This introduces the `wp_privacy_export_expiration` filter, which allows plugins to customize how long the exports are kept before being deleted.
`index.html` was added to the `$exclusions` parameter of `list_files()` to make sure that it isn't deleted. If it were, then poorly-configured servers would allow the directory to be traversed, exposing all of the exported files.
Props iandunn, desrosj.
See #43546.
Built from https://develop.svn.wordpress.org/trunk@43046
git-svn-id: http://core.svn.wordpress.org/trunk@42875 1a063a9b-81f0-0310-95a4-ce76da25c4cd
A new global multisite table `wp_blogmeta` is added to the database schema, and a set of `*_site_meta()` API functions are introduced.
The implementation fails gracefully when the new table is not yet available, which may happen especially shortly after the core update, before the network has been upgraded to the new database schema. The presence of the table is detected once and stored as a global setting on the main network.
Core does not yet use site metadata, but there are several use-cases to be implemented or explored in the near future, and it allows plugins to extend sites with arbitrary data, which will come in particularly handy with the upcoming REST API endpoint for sites.
Props spacedmonkey, johnjamesjacoby, jeremyfelt, flixos90.
Fixes#37923.
Built from https://develop.svn.wordpress.org/trunk@42836
git-svn-id: http://core.svn.wordpress.org/trunk@42666 1a063a9b-81f0-0310-95a4-ce76da25c4cd
While intended as a playful error message, `Cheatin’ uh?` can be interpreted as insulting or accusatory in an already stressful situation. This replaces Cheatin’ with more meaningful error messages, depending on the error that occurs.
Props ElectricFeet, EricMeyer, karmatosed, dd32, BandonRandon, melchoyce for language; dmsnell for original patch; peterwilsoncc.
Fixes#38332.
Built from https://develop.svn.wordpress.org/trunk@42648
git-svn-id: http://core.svn.wordpress.org/trunk@42477 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The WPCS `WordPress.WhiteSpace.PrecisionAlignment` rule throws warnings for a bunch of code that will likely cause issues for `wpcbf`. Fixing these manually beforehand gives us better auto-fixed results later.
See #41057.
Built from https://develop.svn.wordpress.org/trunk@42228
git-svn-id: http://core.svn.wordpress.org/trunk@42057 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This pattern occurs a handful of times across the codebase:
`<div class="foo<?php if ( $bar ) { echo ' baz'; } ?>">`
Unfortunately, it doesn't really play nicely with `phpcbf`, so all instances need to be removed in preperation for auto code formatting.
See #41057.
Built from https://develop.svn.wordpress.org/trunk@42217
git-svn-id: http://core.svn.wordpress.org/trunk@42046 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This now treats files containing `./` as valid, and also treats files containing a trailing `../` as valid due to widespread use of this pattern in theme and plugin zip files.
Adds tests.
Props Ipstenu, borgesbruno, DavidAnderson, philipjohn, birgire
Fixes#42016, #36170
Built from https://develop.svn.wordpress.org/trunk@42011
git-svn-id: http://core.svn.wordpress.org/trunk@41845 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When the `WP_Network::$blog_id` property is set manually, for example in the multisite bootstrap process, `get_main_site_id()` should use that value instead of running its own logic. The main logic for the function was therefore moved into the internal `WP_Network::get_main_site_id()` method, which is now being accessed by the function through the magic property handling for `WP_Network::$blog_id` (and its equivalent `WP_Network::$site_id`).
Props spacedmonkey, jeremyfelt.
Fixes#41936.
Built from https://develop.svn.wordpress.org/trunk@41861
git-svn-id: http://core.svn.wordpress.org/trunk@41695 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This allows users who are using the admin area in a language other than the site language to read the notice on the login screen
(which explains that they need to log in again) in their chosen language.
Props Nikschavan, swissspidy
Fixes#40205
Built from https://develop.svn.wordpress.org/trunk@41692
git-svn-id: http://core.svn.wordpress.org/trunk@41526 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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
Built from https://develop.svn.wordpress.org/trunk@41613
git-svn-id: http://core.svn.wordpress.org/trunk@41448 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This function can be used to easily get the main site ID of a given network via the optional `$network_id` parameter, which defaults to the current network. The existing `is_main_site()` now uses the new function internally and now accepts an optional `$network_id` parameter as well.
The main purpose of the new function at this point is to ensure that the `WP_Network::$blog_id` property is always set. Magic getters in the class have been adjusted to auto-fill the property when it is accessed and empty. Furthermore the function encapsulates logic that was previously part of `ms_load_current_site_and_network()` and has been replaced with a call to the function now.
Props spacedmonkey, jeremyfelt, johnjamesjacoby, flixos90.
Fixes#29684.
Built from https://develop.svn.wordpress.org/trunk@41380
git-svn-id: http://core.svn.wordpress.org/trunk@41213 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
This reduces the chances of a site compromise going unnoticed, in the same way that the same notifications for user account email address changes reduces the chances of a user account compromise going unnoticed.
Props MatheusGimenez, johnbillion
Fixes#39117
Built from https://develop.svn.wordpress.org/trunk@41164
git-svn-id: http://core.svn.wordpress.org/trunk@41004 1a063a9b-81f0-0310-95a4-ce76da25c4cd
iandunn
Sergey Biryukov
John Blackbourn
Andrew Ozz
Felix Arntz
Peter Wilson
Drew Jaynes
Dion Hulse
Gary Pendergast
Weston Ruter