This change fixes oEmbed host script enqueueing on front-end when using block themes.
It deprecates `wp_oembed_add_host_js` in favor of `wp_maybe_enqueue_oembed_host_js`. The action is still triggered in `default-filters.php` to ensure backward compatibility for websites that are removing the action. There is now a `has_action()` check in `wp_maybe_enqueue_oembed_host_js()` to see if `wp_oembed_add_host_js()` has not been unhooked from running at the `wp_head` action.
Follow-up to [52132], [52151], [52153], [52325].
Props swissspidy, westonruter, flixos90, kafleg.
Fixes#44632.
Built from https://develop.svn.wordpress.org/trunk@52437
git-svn-id: http://core.svn.wordpress.org/trunk@52029 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Update packages to include these bug fixes from Gutenberg:
- Image block: Set image display to grid when no alignment sent to properly align caption on resize
- Update and align template descriptions
- Site Editor - prevent loading state from showing the admin menu.
- Add client side routing for Site Editor
- Navigation: Add clearance for appender in submenus.
- Fix CSS Custom Properties for presets in the site editor
- Add/navigation blocks post processing after migration from menu items
- Allow selector ordering to ensure theme.json root selector margin takes precedence
- Do not remove theme presets if defaults are hidden
- Format library: fix unsetting highlight color
- FSE: Fix template resolution to give precedence to child theme PHP templates over parent theme block templates with equal specificity
- ColorPalette: Improving accessibility and visibility
- Update: Make the color popover on the gradient picker appear as expected
- Site Editor: Display a notice if export fails
- Fix docs and function naming for gallery block registration in PHP
- Switch to addEventListener for load event in the navigation block view script
- Fix mistake in _remove_theme_attribute_in_block_template_content
- Better synchronisation between Gutenberg and Core code
- Move the block page templates hook into compat/5.9 folder
- Moves to the template loader hooks and functions into lib/compat folder
- Refactor the gutenberg_is_fse_theme function to use wp_is_block_theme
- Site Editor: Update support doc URL in Welcome Guide
- Global Styles: Add Welcome Guide toggle
- Hide remove control point when removing would break gradient control
- Don't request the deprecated navigation areas endpoint outside of the Gutenberg plugin
- Image: Fix resizer controls being hidden in Safari when switching between alignments
- Remove Navigation Menus from WP Admin sidebar
- Site Editor: Hide the block appender in the Template Part editor
- Site Editor: Use server definition for the Template Areas
- Synchronize wp_is_block_theme and block-templates block support with Core
- E2E: Retry login again after a bad nonce request to prevent intermittent test failures
- Fix theme requirement validation with WP 5.8
- Fix WP 5.9 check for conditionally running code
- Fix post comment form input width
- Border Style Control: Update styling for consistency with border width control
- Fix form-submit styles by adding button classes to the submit-button in post-comments block
- Site Editor: Fix edit template part link in header dropdown
- Move duotone palette to the bottom of global styles gradients
- Fix how appearanceTools works
- Move WP 5.9 wp-admin menus compatibility code to lib/compat folder
- Revert "Site Editor: Set the <title> on the list page to be same as the CPT name"
- Site Editor: Document Actions: add SR text to heading 1
- Do not register global styles CPT in WordPress 5.9
- Global Styles: Move the 'Edit colors' button to a standard menu item
- Fix styles for previews and patterns
- Site Editor: Fix failing E2E test
- Templates: Search for old template names in the parent theme too
- Remove 4 instances of 'gutenberg' text domain from WordPress core
- Fix content loss when ungrouping template parts or reusable blocks
- Simplify the RESET_BLOCK action to fix template part focus mode content loss
- [Global Styles]: Make Blocks section more distinguishable
- Only use block markup for comment form button when using a block theme
- Navigation: Fix vertical alignment of page list in modal.
- Fix: ToggleGroupControl active state
- Remove gutenberg_ prefix from @wordpress/block-library
Props ocean90, oandregal, hellofromtonya, youknowriad.
See #54487.
Built from https://develop.svn.wordpress.org/trunk@52364
git-svn-id: http://core.svn.wordpress.org/trunk@51956 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The template resolution system makes a request like `/?page_id=1234&_wp-find-template=true`, depending on `WP_Query` to resolve a page or post using the page_id or p (post_id) in the query string. With new posts/pages, a placeholder post with the status auto-draft is created. But by default `WP_Query` will not resolve these posts, unless the query is specifically set to look for them.
This commit handles the query string to properly resolve a page or post. It adds 2 private callbacks for the processing.
Props poena, noisysocks, bernhard-reiter, costdev, hellofromTonya.
Fixes#54553.
Built from https://develop.svn.wordpress.org/trunk@52316
git-svn-id: http://core.svn.wordpress.org/trunk@51908 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Navigation area were merged as part of full site editing and the new navigation block. This functionality is experimental and not currently used in WordPress core, so should be removed.
Props noisysocks, spacedmonkey, get_dave, zieladam.
Fixes#54506.
Built from https://develop.svn.wordpress.org/trunk@52272
git-svn-id: http://core.svn.wordpress.org/trunk@51864 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Copies Navigation Area infrastrucutre from lib/navigation.php in Gutenberg. This
allows a Navigation block to be associated with a particular area which persists
when switching theme.
Props antonvlasenko, mamaduka, spacedmonkey.
See #54337.
Built from https://develop.svn.wordpress.org/trunk@52145
git-svn-id: http://core.svn.wordpress.org/trunk@51737 1a063a9b-81f0-0310-95a4-ce76da25c4cd
- First pass at adding the site editor from the Gutenberg plugin to
wp-admin/site-editor.php.
- Adds miscellaneous PHP changes from Gutenberg 10.1 - 11.9.
Follows [52042].
See #54337.
Props youknowriad, aristath, hellofromtonya, gziolo.
Built from https://develop.svn.wordpress.org/trunk@52069
git-svn-id: http://core.svn.wordpress.org/trunk@51661 1a063a9b-81f0-0310-95a4-ce76da25c4cd
It is common that plugins erroneously have `wp-editor` or `wp-edit-post` as a
dependency in a script that is loaded in the new widgets editor. This is a smell
since both `@wordpress/editor` and `@wordpress/edit-post` assume the existence
of a global "post" object which the widgets editor does not have.
[51387] fixes the user-facing errors typically caused by this mistake, but we
can go a step further and warn developers about this by calling
`_doing_it_wrong()` when we detect that the `wp-editor` script or `wp-edit-post`
style is enqueued alongside `wp-edit-widgets` or `wp-customize-widgets`.
See #53437.
Fixes#53569.
Props zieladam, spacedmonkey, TimothyBlynJacobs, andraganescu, dlh.
Built from https://develop.svn.wordpress.org/trunk@51388
git-svn-id: http://core.svn.wordpress.org/trunk@50999 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This fixes the logic in `wp_enqueue_global_styles()` to ensure that global styles are loaded in the footer when a site opts-in to loading Core block assets individually.
This fixes a bug where styles defined in `themes.json` are not respected.
Props walbo, nosolosw, mcsf, aristath, desrosj.
Fixes#53494.
Built from https://develop.svn.wordpress.org/trunk@51309
git-svn-id: http://core.svn.wordpress.org/trunk@50918 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This better aligns with developer expectations, as `add_theme_support()` and `remove_theme_support()` are meant to be called within functions attached to the `after_setup_theme` hook.
This also adds the `widgets-block-editor` feature to the docblock for `add_theme_support()`.
Props kevin940726, caseymilne, jamesros161, noisysocks, Mamaduka, audrasjb, zieladam, hellofromTonya, desrosj.
Fixes#53424.
Built from https://develop.svn.wordpress.org/trunk@51214
git-svn-id: http://core.svn.wordpress.org/trunk@50823 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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
