This change adds a throttle mechanism to plugin and theme auto-update failure emails using similar logic to the email sent for a Core auto-update.
The first time a plugin or theme auto-update fails, the package and `new_version` will be tracked in the `auto_plugin_theme_update_emails` option. An email for this specific update attempt will not be resent.
However, if this update fails again and non-repeat failures or successful updates are also present, then the failure information will be included in that email (an email needs to be sent for the new events regardless).
Props johnbillion, arpitgshah, desrosj, audrasjb, pbiron, earnjam.
Fixes#50448.
git-svn-id: https://develop.svn.wordpress.org/trunk@48397 602fd350-edb4-49c9-b593-d223f7449a82
“The WordPress open source community cares about diversity. We strive to maintain a welcoming environment where everyone can feel included.”
With this commit, all occurrences of “whitelist” and “blacklist” (with the single exception of the `$new_whitelist_options` global variable) are removed. A new ticket has been opened to explore renaming the `$new_whitelist_options` variable (#50434).
Changing to more specific names or rewording sentences containing these terms not only makes the code more inclusive, but also helps provide clarity. These terms are often ambiguous. What is being blocked or allowed is not always immediately clear. This can make it more difficult for non-native English speakers to read through the codebase.
Words matter. If one contributor feels more welcome because these terms are removed, this was worth the effort.
Props strangerstudios, jorbin, desrosj, joemcgill, timothyblynjacobs, ocean90, ayeshrajans, davidbaumwald, earnjam.
See #48900, #50434.
Fixes#50413.
git-svn-id: https://develop.svn.wordpress.org/trunk@48121 602fd350-edb4-49c9-b593-d223f7449a82
This is the first step to bring support for custom comment types into WordPress.
Add a scheduled upgrade routine to update the type value for existing comments, in batches of 100 at a time.
Props imath, aaroncampbell, jeremyfelt, dshanske.
Fixes#49236.
git-svn-id: https://develop.svn.wordpress.org/trunk@47597 602fd350-edb4-49c9-b593-d223f7449a82
* `erase_others_personal_data`
* `export_others_personal_data`
* `manage_privacy_options`
Previously mapped to `manage_options` or `manage_network` (on Multisite), these are now added to the Administrator role separately.
Additionally, `manage_privacy_options` is added to the Editor role.
Props garrett-eclipse, xkon, pbiron, desrosj, johnbillion, flixos90, juliobox, lakenh, Ov3rfly, ianatkins.
Fixes#44176.
git-svn-id: https://develop.svn.wordpress.org/trunk@47269 602fd350-edb4-49c9-b593-d223f7449a82
Previously, `wp_favicon_request()` was introduced in [13205] to avoid a performance hit of serving a full 404 page on every favicon request.
While working as intended, that implementation did not provide a way for theme or plugin authors to manage the behavior of favicon requests.
This changeset implements the following logic (only applied if WordPress is installed in the root directory):
* If there is a Site Icon set in Customizer, redirect `/favicon.ico` requests to that icon.
* Otherwise, use the WordPress logo as a default icon.
* If a physical `/favicon.ico` file exists, do nothing, let the server handle the request.
Handling `/favicon.ico` is now more consistent with handling `/robots.txt` requests.
New functions and hooks:
* Introduce `is_favicon()` conditional tag to complement `is_robots()`.
* Introduce `do_favicon` action to complement `do_robots` and use it in template loader.
* Introduce `do_favicon()` function, hooked to the above action by default, to complement `do_robots()`.
* Introduce `do_faviconico` action to complement `do_robotstxt`, for plugins to override the default behavior.
* Mark `wp_favicon_request()` as deprecated in favor of `do_favicon()`.
Props jonoaldersonwp, birgire, joostdevalk, mukesh27, SergeyBiryukov.
Fixes#47398.
git-svn-id: https://develop.svn.wordpress.org/trunk@47018 602fd350-edb4-49c9-b593-d223f7449a82
Most sites will be unaffected by this change, but those with a large number of rows in `wp_options`, only a small number of which have `autoload` set, will see a significant performance improvement.
Sites with a large number of rows in `wp_options`, with many of them having `autoload` set will unfortunately see a performance penalty on top of the already very slow queries they're running, but this should be the minority of cases.
Props DanBUK.
Fixes#24044.
git-svn-id: https://develop.svn.wordpress.org/trunk@45805 602fd350-edb4-49c9-b593-d223f7449a82
