Adds new hooks (rest_save_sidebar, rest_delete_widget, rest_after_save_widget)
to the widgets REST API and uses them to delete the fresh_site option when
updating widgets via the REST API. This ensures that starter content isn't
loaded in the Customizer after a user makes changes.
Fixes#53317.
Props kevin940726, garrett-eclipse, andraganescu, hellofromtonya.
Built from https://develop.svn.wordpress.org/trunk@51068
git-svn-id: http://core.svn.wordpress.org/trunk@50677 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adds a new 'widget_block_content' filter to the widget block and hooks
`run_shortcode`, `autoembed`, `do_blocks`, and `do_shortcode` into it by
default. This is simlar to `widget_text_content.`
Fixes#51566.
Props talldanwp.
Built from https://develop.svn.wordpress.org/trunk@51058
git-svn-id: http://core.svn.wordpress.org/trunk@50667 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Add an endpoint for fetching block patterns from WordPress.org, and load the block patterns from this new API. Remove the block patterns that have already been moved to WordPress.org/patterns.
Props ryelle, iandunn, youknowriad, timothyblynjacobs.
Fixes#53246.
Built from https://develop.svn.wordpress.org/trunk@51021
git-svn-id: http://core.svn.wordpress.org/trunk@50630 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In `wp_get_document_title(), the returned value is currently passed directly through `wptexturize()`, `convert_chars()`, and `capital_P_dangit()`, and is done so after the `document_title_parts` filter is run.
This makes it impossible to fully control the output of `wp_get_document_title()` and is inconsistent with how other similar text is processed with these functions.
This commit introduces the `document_title` filter, which is run immediately before returning the results of the `wp_get_document_title()` function and moves the three formatting functions mentioned above to the new filter hook. This allows developers to further modify the title after being prepared by WordPress, or to modify the functions hooked to this filter as they wish.
Props dragunoff, jeremyfelt, paaggeli, audrasjb.
Fixes#51643.
Built from https://develop.svn.wordpress.org/trunk@51019
git-svn-id: http://core.svn.wordpress.org/trunk@50628 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adds styles for individual core blocks to make it possible to render only styles for those blocks that are rendered on the page (frontend). This is optinal functionality for start that can be controlled with the new `separate_core_block_assets` filter.
In addition to that, styles can be inlined when `path` is passed when registering an individual styles. This functionality can be changed with the new `styles_inline_size_limit` filter. The maximum size of inlined styles in bytes defaults to 20 000.
Props aristath, aduth, westonruter, mcsf.
Fixes#50328, #52620.
Built from https://develop.svn.wordpress.org/trunk@50836
git-svn-id: http://core.svn.wordpress.org/trunk@50445 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Ensures that `wp-format-library` assets are always loaded for the block editor. Otherwise, they have to be loaded individually for every screen that needs it. It's similar to how `wp-block-directory` assets are handled.
Props ellatrix.
See #52920.
Built from https://develop.svn.wordpress.org/trunk@50620
git-svn-id: http://core.svn.wordpress.org/trunk@50233 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Switching a WordPress site from HTTP to HTTPS has historically been a tedious task. While on the surface the Site Address and WordPress Address have to be updated, existing content still remains using HTTP URLs where hard-coded in the database. Furthermore, updating _two_ URLs to migrate to HTTPS is still a fairly unintuitive step which is not clearly explained.
This changeset simplifies migration from HTTP to HTTPS and, where possible, makes it a one-click interaction.
* Automatically replace insecure versions of the Site Address (`home_url()`) with its HTTPS counterpart on the fly if the site has been migrated from HTTP to HTTPS. This is accomplished by introducing a `https_migration_required` option and enabling it when the `home_url()` is accordingly changed.
* A new `wp_replace_insecure_home_url()` function is hooked into various pieces of content to replace URLs accordingly.
* The migration only kicks in when the Site Address (`home_url()`) and WordPress Address (`site_url()`) match, which is the widely common case. Configurations where these differ are often maintained by more advanced users, where this migration routine would be less essential - something to potentially iterate on in the future though.
* The migration does not actually update content in the database. More savvy users that prefer to do that can prevent the migration logic from running by either deleting the `https_migration_required` option or using the new `wp_should_replace_insecure_home_url` filter.
* For fresh sites that do not have any content yet at the point of changing the URLs to HTTPS, the migration will also be skipped since it would not be relevant.
* Expose a primary action in the Site Health recommendation, if HTTPS is already supported by the environment, built on top of the HTTPS detection mechanism from [49904]. When clicked, the default behavior is to update `home_url()` and `site_url()` in one go to their HTTPS counterpart.
* A new `wp_update_urls_to_https()` function takes care of the update routine.
* A new `update_https` meta capability is introduced to control access.
* If the site's URLs are controlled by constants, this update is not automatically possible, so in these scenarios the user is informed about that in the HTTPS status check in Site Health.
* Allow hosting providers to modify the URLs linked to in the HTTPS status check in Site Health, similar to how that is possible for the URLs around updating the PHP version.
* A `WP_UPDATE_HTTPS_URL` environment variable or `wp_update_https_url` filter can be used to provide a custom URL with guidance about updating the site to use HTTPS.
* A `WP_DIRECT_UPDATE_HTTPS_URL` environment variable or `wp_direct_update_https_url` filter can be used to provide a custom URL for the primary CTA to update the site to use HTTPS.
Props flixos90, timothyblynjacobs.
Fixes#51437.
Built from https://develop.svn.wordpress.org/trunk@50131
git-svn-id: http://core.svn.wordpress.org/trunk@49810 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The opt-in form is shown after the comment is submitted and held for moderation.
Sorry this took five years.
Props jeffr0, swissspidy, mrahmadawais, wonderboymusic, jdgrimes, obenland, Monika, imath, garrett-eclipse, johnbillion
Fixes#33717
Built from https://develop.svn.wordpress.org/trunk@50109
git-svn-id: http://core.svn.wordpress.org/trunk@49788 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset introduces a `wp_robots_max_image_preview_large()` function which is hooked into the `wp_robots` filter to include the `max-image-preview:large` directive for all sites which are configured to be indexed by search engines. The directive allows search engines to display large image previews for the site in search results.
Props adamsilverstein, Clorith, flixos90, helen, joostdevalk, tweetythierry, westonruter.
Fixes#51511.
Built from https://develop.svn.wordpress.org/trunk@50078
git-svn-id: http://core.svn.wordpress.org/trunk@49778 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This introduces a new endpoint, `wp/v2/users/me/application-passwords/introspect`, that will return details about the App Password being used to authenticate the current request. This allows for an application to disambiguate between multiple installations of their application which would all share the same `app_id`.
Props xkon, peterwilsoncc, TimothyBlynJacobs.
Fixes#52275.
Built from https://develop.svn.wordpress.org/trunk@50065
git-svn-id: http://core.svn.wordpress.org/trunk@49766 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset introduces a filter-based Robots API, providing central control over the `robots` meta tag.
* Introduces `wp_robots()` function which should be called anywhere a `robots` meta tag should be included.
* Introduces `wp_robots` filter which allows adding or modifying directives for the `robots` meta tag. The `wp_robots()` function is entirely filter-based, i.e. if no filter is added to `wp_robots`, no directives will be present, and therefore the entire `robots` meta tag will be omitted.
* Introduces the following `wp_robots` filter functions which replace similar existing functions that were manually rendering a `robots` meta tag:
* `wp_robots_noindex()` replaces `noindex()`, which has been deprecated.
* `wp_robots_no_robots()` replaces `wp_no_robots()`, which has been deprecated.
* `wp_robots_sensitive_page()` replaces `wp_sensitive_page_meta()`, which has been deprecated. Its rendering of the `referrer` meta tag has been moved to another new function `wp_strict_cross_origin_referrer()`.
Migration to the new functions is straightforward. For example, a call to `add_action( 'wp_head', 'wp_no_robots' )` should be replaced with `add_filter( 'wp_robots', 'wp_robots_no_robots' )`.
Plugins and themes that render their own `robots` meta tags are encouraged to switch to rely on the `wp_robots` filter in order to use the central management layer now provided by WordPress core.
Props adamsilverstein, flixos90, timothyblynjacobs, westonruter.
See #51511.
Built from https://develop.svn.wordpress.org/trunk@49992
git-svn-id: http://core.svn.wordpress.org/trunk@49693 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset modifies the Site Health panel for HTTPS to provide more accurate recommendations based on whether the environment is already set up for HTTPS.
* Introduces `wp_is_using_https()` to check whether the site is configured to use HTTPS (via its Site Address and WordPress Address).
* Introduces `wp_is_https_supported()` to check whether the environment supports HTTPS. This relies on a cron job which periodically checks support using a loopback request.
Props Clorith, flixos90, miinasikk, westonruter.
Fixes#47577.
Built from https://develop.svn.wordpress.org/trunk@49904
git-svn-id: http://core.svn.wordpress.org/trunk@49603 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This includes the packages that match the Gutenberg 9.2 Release.
It is going to be the last block-editor features update for WordPress 5.6.
It also updates the block-supports code base to the latest APIs.
Props isabel_brison, noisysocks, desrosj.
Fixes#51570.
Built from https://develop.svn.wordpress.org/trunk@49226
git-svn-id: http://core.svn.wordpress.org/trunk@48988 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* `do_all_pingbacks()`
* `do_all_enclosures()`
* `do_all_trackbacks()`
This allows for the specific removal/replacement of one of more services.
Props dshanske, garrett-eclipse, Mista-Flo, azaozz, hellofromTonya.
Fixes#36576.
Built from https://develop.svn.wordpress.org/trunk@49211
git-svn-id: http://core.svn.wordpress.org/trunk@48973 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In WordPress 4.4 the REST API was first introduced. A few releases later in WordPress 4.7, the Content API endpoints were added, paving the way for Gutenberg and countless in-site experiences. In the intervening years, numerous plugins have built on top of the REST API. Many developers shared a common frustration, the lack of external authentication to the REST API.
This commit introduces Application Passwords to allow users to connect to external applications to their WordPress website. Users can generate individual passwords for each application, allowing for easy revocation and activity monitoring. An authorization flow is introduced to make the connection flow simple for users and application developers.
Application Passwords uses Basic Authentication, and by default is only available over an SSL connection.
Props georgestephanis, kasparsd, timothyblynjacobs, afercia, akkspro, andraganescu, arippberger, aristath, austyfrosty, ayesh, batmoo, bradyvercher, brianhenryie, helen, ipstenu, jeffmatson, jeffpaul, joostdevalk, joshlevinson, kadamwhite, kjbenk, koke, michael-arestad, Otto42, pekz0r, salzano, spacedmonkey, valendesigns.
Fixes#42790.
Built from https://develop.svn.wordpress.org/trunk@49109
git-svn-id: http://core.svn.wordpress.org/trunk@48871 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Currently themes can declare support for a given feature by using add_theme_support(). This commit adds a register_theme_feature() API that allows plugins and WordPress Core to declare a list of available features that themes can support.
The REST API uses this to expose a theme's supported features if the feature has been registered with "show_in_rest" set to true.
Props kadamwhite, spacedmonkey, williampatton, desrosj, TimothyBlynJacobs.
Fixes#49406.
Built from https://develop.svn.wordpress.org/trunk@48171
git-svn-id: http://core.svn.wordpress.org/trunk@47940 1a063a9b-81f0-0310-95a4-ce76da25c4cd
“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.
Built from https://develop.svn.wordpress.org/trunk@48121
git-svn-id: http://core.svn.wordpress.org/trunk@47890 1a063a9b-81f0-0310-95a4-ce76da25c4cd
While web crawlers are able to discover pages from links within the site and from other sites, XML sitemaps supplement this approach by allowing crawlers to quickly and comprehensively identify all URLs included in the sitemap and learn other signals about those URLs using the associated metadata.
See https://make.wordpress.org/core/2020/06/10/merge-announcement-extensible-core-sitemaps/ for more details.
This feature exposes the sitemap index via `/wp-sitemap.xml` and exposes a variety of new filters and hooks for developers to modify the behavior. Users can disable sitemaps completely by turning off search engine visibility in WordPress admin.
This change also introduces a new `esc_xml()` function to escape strings for output in XML, as well as XML support to `wp_kses_normalize_entities()`.
Props Adrian McShane, afragen, adamsilverstein, casiepa, flixos90, garrett-eclipse, joemcgill, kburgoine, kraftbj, milana_cap, pacifika, pbiron, pfefferle, Ruxandra Gradina, swissspidy, szepeviktor, tangrufus, tweetythierry.
Fixes#50117.
See #3670. See #19998.
Built from https://develop.svn.wordpress.org/trunk@48072
git-svn-id: http://core.svn.wordpress.org/trunk@47839 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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.
Built from https://develop.svn.wordpress.org/trunk@47597
git-svn-id: http://core.svn.wordpress.org/trunk@47372 1a063a9b-81f0-0310-95a4-ce76da25c4cd
For accessibility, the visual appearance and source order should match. Moving the toolbar to load in the new hook `wp_body_open` (5.2) fixes a long-standing source order problem.
Props jankimoradiya, afercia, SergeyBiryukov, audrasjb, ocean90, xkon, dinhtungdu.
Fixes#47053.
Built from https://develop.svn.wordpress.org/trunk@47221
git-svn-id: http://core.svn.wordpress.org/trunk@47021 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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.
Built from https://develop.svn.wordpress.org/trunk@47018
git-svn-id: http://core.svn.wordpress.org/trunk@46818 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Convert `date_i18n()` into a wrapper for `wp_date()`.
`wp_date()` is intended as a replacement for `date_i18n()` without legacy quirks in it. It accepts a true Unix timestamp (not summed with timezone offset) and an arbitrary timezone.
Props Rarst, mboynes, MikeHansenMe, rmccue, nacin.
Fixes#28636.
Built from https://develop.svn.wordpress.org/trunk@45901
git-svn-id: http://core.svn.wordpress.org/trunk@45712 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introduces the faux primitive capability `view_site_health_checks` available to single site admins and multisite super-admin to view the site health page within the admin.
The capability is mapped to the `install_plugins` capability without being dependent on the file system being writable. This fixes a bug where the feature couldn't be used by sites unable to write to the file system or managed through version control.
The capability is granted on the `user_has_cap` filter.
Props birgire, Clorith, palmiak, peterwilsoncc, spacedmonkey.
Fixes#46957.
Built from https://develop.svn.wordpress.org/trunk@45507
git-svn-id: http://core.svn.wordpress.org/trunk@45318 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Using the new fatal handler introduced in [44962], an email is sent to the admin when a fatal error occurs. This email includes a secret link to enter recovery mode. When clicked, the link will be validated and on success a cookie will be placed on the client, enabling recovery mode for that user. This functionality is executed early before plugins and themes are loaded, in order to be unaffected by potential fatal errors these might be causing.
When in recovery mode, broken plugins and themes will be paused for that client, so that they are able to access the admin backend despite of these errors. They are notified about the broken extensions and the errors caused, and can then decide whether they would like to temporarily deactivate the extension or fix the problem and resume the extension.
A link in the admin bar allows the client to exit recovery mode.
Props timothyblynjacobs, afragen, flixos90, nerrad, miss_jwo, schlessera, spacedmonkey, swissspidy.
Fixes#46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44973
git-svn-id: http://core.svn.wordpress.org/trunk@44804 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Screen reader users rely on the iframe title attribute to describe the contents of iframes. A meaningful title attribute allows to quickly identify the iframe content, so users can determine which iframe to enter and explore in detail or skip if desired.
Note: this is the only case where a title attribute is required for compliance with the W3C Web Content Accessibility Guidelines (WCAG).
- checks for oEmbed response of type `video` or `rich`
- checks if they use an iframe
- fetches the title (if any) from the oEmbed response
- adds the title to the embed iframe
Props bamadesigner, TomHarrigan, swissspidy, jrf, afercia.
Fixes#40245.
Built from https://develop.svn.wordpress.org/trunk@44942
git-svn-id: http://core.svn.wordpress.org/trunk@44773 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset introduces `$post` parameters to `get_the_content()` and
`wp_trim_excerpt()`. When a `$post` object is passed to one of these functions,
the functions will operate on the data from that object, rather than from the
post globals (`$authordata`, `$page`, etc). This ensures that the functions work
in a predictable manner when used outside of the regular post loop.
The global-mismatch problem is surfaced in cases where `get_the_excerpt()` is
called outside of the post loop, on posts that don't have a defined excerpt. In
these cases, the post globals - used to generate a fallback excerpt - may refer
to the incorrect object, resulting in PHP notices or other unpredictable
behavior. See #36934 for a related issue.
Props spacedmonkey, kraftbj, Shital Patel.
Fixes#42814.
Built from https://develop.svn.wordpress.org/trunk@44941
git-svn-id: http://core.svn.wordpress.org/trunk@44772 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The pre-save filters added to links in [43732] could invalidate JSON data when saving Customizer change-sets.
This removes the filters when saving and publishing change-sets.
Props peterwilsoncc, nikeo for testing.
See #45292.
Built from https://develop.svn.wordpress.org/trunk@44714
git-svn-id: http://core.svn.wordpress.org/trunk@44545 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Blocks are able to register styles that used in the editor and the frontend, or only in the editor. These functions ensure the correct styles are loaded in the correct place.
Props pento.
Merges [43812] to trunk.
See #45065.
Built from https://develop.svn.wordpress.org/trunk@44157
git-svn-id: http://core.svn.wordpress.org/trunk@43987 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adjusts the packages registration after [43723]:
Combine the different registration functions into one `wp_default_packages` function. To reach this goal move the prefix logic into a function so it can be called from different locations. Use a static variable there to prevent duplicate inclusion of `version.php`.
Call this function from the `wp_default_scripts` action by registering it as a default filter.
Combine some of the logic in `_WP_Editors::print_tinymce_scripts` into `wp_register_tinymce_scripts`. The logic to force an uncompressed TinyMCE script file stays in `_WP_Editors::force_uncompressed_tinymce` because that logic is very specific to the classic editor.
The script handle `wp-tinymce` is now a dependency of the editor script handle. In combination with the previous item, this makes the classic editor work.
Adjust the syntax of the script paths to be more consistent with other WordPress code.
Always use "production" mode for the media files to prevent people from inadvertently committing development files.
Props pento, omarreiss, atimmer.
Merges [43738] into trunk.
Fixes#45065.
Built from https://develop.svn.wordpress.org/trunk@44115
git-svn-id: http://core.svn.wordpress.org/trunk@43945 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Object type-specific actions that should happen before or after modification of metadata have so far been part of the respective wrapper functions. By using action and filter hooks, this changeset ensures they are always executed, even when calling the lower-level Meta API functions directly, which the REST API does as a prime example.
Merges [43729] to trunk.
Props flixos90, spacedmonkey.
Fixes#44467.
Built from https://develop.svn.wordpress.org/trunk@43982
git-svn-id: http://core.svn.wordpress.org/trunk@43814 1a063a9b-81f0-0310-95a4-ce76da25c4cd
WPCS 1.0.0 includes a bunch of new auto-fixers, which drops the number of coding standards issues across WordPress significantly. Prior to running the auto-fixers, there were 15,312 issues detected. With this commit, we now drop to 4,769 issues.
This change includes three notable additions:
- Multiline function calls must now put each parameter on a new line.
- Auto-formatting files is now part of the `grunt precommit` script.
- Auto-fixable coding standards issues will now cause Travis failures.
Fixes#44600.
Built from https://develop.svn.wordpress.org/trunk@43571
git-svn-id: http://core.svn.wordpress.org/trunk@43400 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
Previously the admin didn't have any way to know if a pending request was ready to be processed, aside from manually checking the Export/Erase pages. Sending them an email is a much more convenient option.
Props garrett-eclipse, desrosj, iandunn.
See #43967.
Built from https://develop.svn.wordpress.org/trunk@43211
git-svn-id: http://core.svn.wordpress.org/trunk@43040 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
When a post slug is changed, we store a copy of the old slug, so that we can redirect visitors visiting the old URL to the new URL.
In the same way, this stores a copy of the old date, when the post date changes, so we can redirect visitors to the new URL.
Props nickmomrik.
Fixes#15397 for trunk.
Built from https://develop.svn.wordpress.org/trunk@42401
git-svn-id: http://core.svn.wordpress.org/trunk@42230 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Reverting this for 4.9. It will be added back in a future version of WordPress. This doesn't mean that you shouldn't be trying Gutenberg, just that it isn't ready for a call out to a larger audience. But if you are the type to read commit messages, https://github.com/WordPress/gutenberg could use your pull requests and comments on issues.
Reverts [41931] [41900] [41896] [41895]
See #41316
Built from https://develop.svn.wordpress.org/trunk@41978
git-svn-id: http://core.svn.wordpress.org/trunk@41812 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
* Used now in core to facilitate displaying inserted media. See #40854.
* The `[embed]` shortcode is not supported because there is no post context for caching oEmbed responses. This depends on #34115.
* Add `do_shortcode()` to the `widget_text_content` filter in the same way it is added for `the_content` at priority 11, with `shortcode_unautop()` called at priority 10 after `wpautop()`.
* For Text widget in legacy mode, manually apply `do_shortcode()` (and `shortcode_unautop()` if auto-paragraph checked) if the core-added `widget_text_content` filter remains, unless a plugin added `do_shortcode()` to `widget_text` to prevent applying shortcodes twice.
* Ensure that global `$post` is `null` while filters apply in the Text widget so shortcode handlers won't run with unexpected contexts.
Props westonruter, nacin, aaroncampbell.
See #40854, #34115.
Fixes#10457.
Built from https://develop.svn.wordpress.org/trunk@41361
git-svn-id: http://core.svn.wordpress.org/trunk@41194 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The new meta capabilities are called `install_languages` and `update_languages`. Prior to this change, there were no proper capability checks applied. Instead only the filesystem and related constants were checked, and for actual permissions a rather vague fallback was used where a user needed to have at least one of the other updating capabilities. In addition to being generally more verbose, the new capabilities make it possible for example to allow a user to update languages, but nothing else. By default they fall back to the original way of how they were handled.
Props johnbillion, flixos90.
Fixes#39677.
Built from https://develop.svn.wordpress.org/trunk@41268
git-svn-id: http://core.svn.wordpress.org/trunk@41108 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This will send nav menu locations through three levels of mapping:
1. If both themes have only one location, that gets mapped.
2. If both themes have locations with the same slug, they get mapped.
3. Locations that (even partially) match slugs from a similar kind of menu location will get mapped.
Menu locations are mapped for Live Previews in the Customizer and during theme switches.
Props westonruter, obenland, welcher, melchoyce.
Fixes#39692.
Built from https://develop.svn.wordpress.org/trunk@41237
git-svn-id: http://core.svn.wordpress.org/trunk@41077 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Ensures that users who copy HTML from the Text widget in legacy mode over to the Custom HTML widget will continue to get all of the same filters applied, including tag balancing and shortcodes, if a plugin added support. Plugins still have the `widget_text_content` and `widget_custom_html_content` filters they can use to target the specific widget types.
Amends [40893].
See #40951.
Fixes#40907 for trunk.
Built from https://develop.svn.wordpress.org/trunk@41086
git-svn-id: http://core.svn.wordpress.org/trunk@40926 1a063a9b-81f0-0310-95a4-ce76da25c4cd
A theme can opt-in for tailored starter content to apply to the customizer when previewing the theme on a fresh install, when `fresh_site` is at its initial `1` value. Starter content is staged in the customizer and does not go live unless the changes are published. Initial starter content is added to Twenty Seventeen.
* The `fresh_site` flag is cleared when a published post or page is saved, when widgets are modified, or when the customizer state is saved.
* Starter content is registered via `starter-content` theme support, where the argument is an array containing `widgets`, `posts`, `nav_menus`, `options`, and `theme_mods`. Posts/pages in starter content are created with the `auto-draft` status, re-using the page/post stubs feature added to nav menus and the static front page controls.
* A `get_theme_starter_content` filter allows for plugins to extend a theme's starter content.
* Starter content in themes can/should re-use existing starter content items in core by using named placeholders.
* Import theme starter content into customized state when fresh site.
* Prevent original_title differences from causing refreshes if title is present.
* Ensure nav menu item url is set according to object when previewing.
* Make sure initial saved state is false if there are dirty settings without an existing changeset.
* Ensure dirty settings are cleaned upon changeset publishing.
Props helen, westonruter, ocean90.
Fixes#38114, #38533.
Built from https://develop.svn.wordpress.org/trunk@38991
git-svn-id: http://core.svn.wordpress.org/trunk@38934 1a063a9b-81f0-0310-95a4-ce76da25c4cd
With the introduction of user-specific languages in [38705] it's necessary to be able to switch translations on the fly. For example emails should be sent in the language of the recipient and not the one of the current user.
This introduces a new `WP_Locale_Switcher` class which is used for switching locales and translations. It holds the stack of locales whenever `switch_to_locale( $locale )` is called. With `restore_previous_locale()` you can restore the previous locale. `restore_current_locale()` empties the stack and sets the locale back to the initial value.
`switch_to_locale()` is added to most of core's email functions, either with the value of `get_locale()` (site language) or `get_user_locale()` (user language with fallback to site language).
Props yoavf, tfrommen, swissspidy, pbearne, ocean90.
See #29783.
Fixes#26511.
Built from https://develop.svn.wordpress.org/trunk@38961
git-svn-id: http://core.svn.wordpress.org/trunk@38904 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Fixes bug where an invalid Last-Modified value would be returned in feed requests for sites that had 0 items to return. Comment or post feeds will now return the current timestamp as the Last-Modified header value. Example: a request for the comments feed for a site without any comments.
Replaced use of the local static variable `$cache_lastcommentmodified` to store the modified date in `get_lastcommentmodified()` with the Object Cache API. The `get_lastcommentmodified()` function returns early if there is a cached value and returns `false` if there where no comments found. Introduced `_clear_modified_cache_on_transition_comment_status()` to flush the `lastcommentmodified` cache key when a comment enters or leaves approval status. In `get_lastpostmodified()` return early if there is a cached value and return `false` if there are no posts found.
Props swissspidy, rachelbaker, dllh, leobaiano.
Fixes#38027.
Built from https://develop.svn.wordpress.org/trunk@38925
git-svn-id: http://core.svn.wordpress.org/trunk@38868 1a063a9b-81f0-0310-95a4-ce76da25c4cd
REST API endpoints for your WordPress content. These endpoints provide machine-readable external access to your WordPress site with a clear, standards-driven interface, allowing new and innovative apps for interacting with your site. These endpoints support all of the following:
- Posts: Read and write access to all post data, for all types of post-based data, including pages and media.
- Comments: Read and write access to all comment data. This includes pingbacks and trackbacks.
- Terms: Read and write access to all term data.
- Users: Read and write access to all user data. This includes public access to some data for post authors.
- Meta: Read and write access to metadata for posts, comments, terms, and users, on an opt-in basis from plugins.
- Settings: Read and write access to settings, on an opt-in basis from plugins and core. This enables API management of key site content values that are technically stored in options, such as site title and byline.
Love your REST API, WordPress! The infrastructure says, "Let's do lunch!" but the content API endpoints say, "You're paying!"
Props rmccue, rachelbaker, danielbachhuber, joehoyle, adamsilverstein, afurculita, ahmadawais, airesvsg, alisspers, antisilent, apokalyptik, artoliukkonen, attitude, boonebgorges, bradyvercher, brianhogg, caseypatrickdriscoll, chopinbach, chredd, christianesperar, chrisvanpatten, claudiolabarbera, claudiosmweb, cmmarslender, codebykat, coderkevin, codfish, codonnell822, daggerhart, danielpunkass, davidbhayes, delphinus, desrosj, dimadin, dotancohen, DrewAPicture, Dudo1985, duncanjbrown, eherman24, eivhyl, eliorivero, elyobo, en-alis, ericandrewlewis, ericpedia, evansobkowicz, fjarrett, frozzare, georgestephanis, greatislander, guavaworks, hideokamoto, hkdobrev, hubdotcom, hurtige, iandunn, ircrash, ironpaperweight, iseulde, Japh, jaredcobb, JDGrimes, jdolan, jdoubleu, jeremyfelt, jimt, jjeaton, jmusal, jnylen0, johanmynhardt, johnbillion, jonathanbardo, jorbin, joshkadis, JPry, jshreve, jtsternberg, JustinSainton, kacperszurek, kadamwhite, kalenjohnson, kellbot, kjbenk, kokarn, krogsgard, kuchenundkakao, kuldipem, kwight, lgedeon, lukepettway, mantismamita, markoheijnen, matrixik, mattheu, mauteri, maxcutler, mayukojpn, michael-arestad, miyauchi, mjbanks, modemlooper, mrbobbybryant, NateWr, nathanrice, netweb, NikV, nullvariable, oskosk, oso96_2000, oxymoron, pcfreak30, pento, peterwilsoncc, Pezzab, phh, pippinsplugins, pjgalbraith, pkevan, pollyplummer, pushred, quasel, QWp6t, schlessera, schrapel, Shelob9, shprink, simonlampen, Soean, solal, tapsboy, tfrommen, tharsheblows, thenbrent, tierra, tlovett1, tnegri, tobych, Toddses, toro_unit, traversal, vanillalounge, vishalkakadiya, wanecek, web2style, webbgaraget, websupporter, westonruter, whyisjake, wonderboymusic, wpsmith, xknown, zyphonic.
Fixes#38373.
Built from https://develop.svn.wordpress.org/trunk@38832
git-svn-id: http://core.svn.wordpress.org/trunk@38775 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Custom CSS is associated with a given theme and is displayed in an inline `style` element at the `wp_head` hook after the `wp_print_styles` is called so that it overrides any enqueued stylesheets.
* A `wp_get_custom_css()` function is used for accessing the CSS associated with the current theme (or another theme) and a `wp_get_custom_css` filter for manipulating it.
* CSS is managed in customizer via a new "Additional CSS" section with a single `textarea` control.
* `WP_Customize_Section::$description_hidden` is introduced for hiding extended descriptions in customizer sections behind a help toggle as done with panels.
* CSS is stored in a `custom_css` post type with the theme (stylesheet) slug as the `post_name`.
* `WP_Customize_Custom_CSS_Setting` is introduced to handle validation of CSS, previewing, and persisting the CSS to the `custom_css` post type.
* The `custom_css` setting is tied to a new `unfiltered_css` capability which maps to `unfiltered_html` by default.
* Escaping the message in the notification template is removed to allow markup (`code` tags) to be rendered.
See https://make.wordpress.org/core/2016/10/11/feature-proposal-better-theme-customizations-via-custom-css-with-live-previews/
Props johnregan3, celloexpressions, folletto, westonruter.
Fixes#35395.
Built from https://develop.svn.wordpress.org/trunk@38829
git-svn-id: http://core.svn.wordpress.org/trunk@38772 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Since 4.4, comment submission has been mostly abstracted into a function,
rather than being processed inline in wp-comments-post.php. This change
made it easier to write automated tests against the bulk of the comment
submission process. `wp_allow_comment()` remained untestable, however:
when a comment failed one of its checks (flooding, duplicates, etc),
`die()` or `wp_die()` would be called directly. This shortcoming posed
problems for any application attempting to use WP's comment verification
functions in an abstract way - from PHPUnit to the REST API.
The current changeset introduces a new parameter, `$avoid_die`, to the
`wp_new_comment()` stack. When set to `true`, `wp_new_comment()` and
`wp_allow_comment()` will return `WP_Error` objects when a comment check
fails. When set to `false` - the default, for backward compatibility -
a failed check will result in a `die()` or `wp_die()`, as appropriate.
Prior to this changeset, default comment flood checks took place in the
function `check_comment_flood_db()`, which was hooked to the
'check_comment_flood' action. This design allowed the default comment
flood routine to be bypassed or replaced using `remove_action()`.
In order to maintain backward compatibility with this usage, while
simultaneously converting the comment flood logic into something that
returns a value rather than calling `die()` directly,
`check_comment_flood_db()` has been changed into a wrapper function for
a call to `add_filter()`; this, in turn, adds the *actual* comment flood
check to a new filter, 'wp_is_comment_flood'. Note that direct calls
to `check_comment_flood_db()` will no longer do anything in isolation.
Props websupporter, rachelbaker.
Fixes#36901.
Built from https://develop.svn.wordpress.org/trunk@38778
git-svn-id: http://core.svn.wordpress.org/trunk@38721 1a063a9b-81f0-0310-95a4-ce76da25c4cd
