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.
git-svn-id: https://develop.svn.wordpress.org/trunk@43223 602fd350-edb4-49c9-b593-d223f7449a82
- Separate the guide text form the suggested policy text.
- Add table of content for easier navigation.
- Move the content to tools.php (prevents the settings menu of being open).
- Add a link to the guide from the Privacy settings screen.
Props melchoyce, azaozz.
See #43980.
git-svn-id: https://develop.svn.wordpress.org/trunk@43203 602fd350-edb4-49c9-b593-d223f7449a82
- Insert both the text and tutorial in new policy pages and highlight is brightly in the editor.
- Show only the suggested text in the policy postbox.
Props melchoyce, azaozz.
See #43473.
git-svn-id: https://develop.svn.wordpress.org/trunk@43146 602fd350-edb4-49c9-b593-d223f7449a82
This allows referrer-restricted content from third parties (such as images and fonts) to continue working in the admin area.
Props aranwer104, qcmiao
Fixes#43285
git-svn-id: https://develop.svn.wordpress.org/trunk@42830 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
Fixes a bug where files couldn't be accessed in multisite installs.
Props flixos90, westonruter.
Fixes#42420.
git-svn-id: https://develop.svn.wordpress.org/trunk@42115 602fd350-edb4-49c9-b593-d223f7449a82
This sets a referrer policy of `same-origin` which adds hardening by preventing a referrer being sent from the admin area or login screens to other origins. This helps prevent unwanted exposure of potentially sensitive information that may be contained within URLs.
This change introduces a new filter, `admin_referrer_policy`, for filtering the referrer policy header value. The header can be disabled if necessary by removing the `wp_admin_headers` action from the `admin_init` and `login_init` hooks.
Props joostdevalk
Fixes#42036
git-svn-id: https://develop.svn.wordpress.org/trunk@41741 602fd350-edb4-49c9-b593-d223f7449a82
This adds this previously Multisite-only functionality to single site installations too. This change prevents accidental or erroneous email address changes from potentially locking users out of their site.
Props MatheusGimenez, johnbillion
Fixes#39118
git-svn-id: https://develop.svn.wordpress.org/trunk@41254 602fd350-edb4-49c9-b593-d223f7449a82
Replaces unsecure links in documentation and translator comments with their secure versions.
Props johnpgreen, netweb
Fixes#36993
git-svn-id: https://develop.svn.wordpress.org/trunk@37674 602fd350-edb4-49c9-b593-d223f7449a82
Applying these specially-crafted `@see` tags allows the Code Reference parser to recognize and link these elements as actions and filters.
See #36921.
git-svn-id: https://develop.svn.wordpress.org/trunk@37537 602fd350-edb4-49c9-b593-d223f7449a82
Having a view mode switcher nestled within table navigation makes no sense, especially now that it's a sticky user option. While less convenient for frequent switching, there is no evidence as of yet that there is a large userbase of frequent view mode switchers.
Introduces a filter for `view_mode_post_types`, which by default is all hierarchical post types with edit UI on.
props Oxymoron.
fixes#22222.
git-svn-id: https://develop.svn.wordpress.org/trunk@35357 602fd350-edb4-49c9-b593-d223f7449a82
This change also makes it bail early (without writing) if the markers content is the same as the existing, and uses `ftell()` rather than `$bytes` for the location to truncate the file to - based on the file pointer being at the end of the written stream.
Props willmot tigertech kevinatelement
See #31767
git-svn-id: https://develop.svn.wordpress.org/trunk@35267 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
The call to `flock()` is an exclusive advisory lock, which in my testing only PHP respects (apache continues to read it).
Not all filesystems support locking (remote NFS mounts for example) so this offers minimal benefit to those platforms, but offers much better protection against file corruption on systems which do support it.
The call is blocking, so a second process will wait for the first to complete before writing if supported.
See #31767
git-svn-id: https://develop.svn.wordpress.org/trunk@34740 602fd350-edb4-49c9-b593-d223f7449a82
Previously, rewrite rules could be flushed and regenerated in the context of another site. Deleting the rules when in a switched state allows for them to be generated properly on the next page view.
Fixes#33816.
git-svn-id: https://develop.svn.wordpress.org/trunk@34672 602fd350-edb4-49c9-b593-d223f7449a82
