Removing Gutenberg Ramp

UPDATE: On January 28, we announced an updated timeline for this deprecation. Due to a core bug, Deprecation has been delayed to February 22, and all outstanding Pull Requests will be merged on February 17.

Since its official release as part of WordPress 5.0 in December of 2018, the Gutenberg project has transformed what it’s like to create content and manage pages and sections.

While the Gutenberg Ramp plugin was initially created to allow WordPress VIP customers to have precise control over their editor experience, WordPress Core includes simple filters which provide this same control and allow for a more streamlined codebase. As a result, we will be removing the Gutenberg Ramp plugin from the mu (must-use) plugins set on February 3, 2021.

What does that mean for me?

The current Gutenberg Ramp experience requires site owners to opt in to use the Block Editor. Using the WordPress Core filters will move the Block Editor to on-by-default, while still allowing customers to easily opt out if they choose.

Starting today, any Administrators on your WordPress VIP site will begin to see a deprecation notice alerting them of the upcoming change. No action is required at this time, but if you’d like to preemptively address the change, see below for specific instructions.

What do I need to do?

You need to test:

While we’ll be proactively creating these Pull Requests in your repos, we highly recommend testing the changes prior to merging, especially when using the use_block_editor_for_post_type filter for a custom implementation.

If you’re already using the Gutenberg Block Editor:

Starting November 23, VIP will create Pull Requests on each environment branch of your GitHub repo. These Pull Requests will be customized depending on your current implementation, to ensure that your application continues to work as expected after the Gutenberg Ramp plugin is deprecated.

For customers who are using the Block Editor site-wide, the Gutenberg Ramp implementation will be replaced with the below snippet:

add_filter( 'use_block_editor_for_post', '__return_true' );

For customers with custom implementations of Gutenberg Ramp (e.g. limited to certain post types), the Pull Request will be configured to meet each specific use case, using a custom function along with the use_block_editor_for_post_type filter:

function maybe_load_gutenberg_for_post_type( $can_edit, $post_type ) {   
          $enable_for_post_types = [ 'post', 'page' ];
    if ( in_array( $post_type, $enable_for_post_types, true ) ) {
                return true;   
          }   

          return $can_edit;
}

add_filter( 'use_block_editor_for_post_type', 'maybe_load_gutenberg_for_post_type', 20, 2 );
If you’re not using the Gutenberg Block Editor:

Starting November 23, VIP will create Pull Requests on the environment branches of your GitHub repo, implementing the below snippet in your client-mu-plugins folder:

add_filter( 'use_block_editor_for_post', '__return_false' );

This filter will allow you to continue opting out of using the Block Editor, once the Gutenberg Ramp plugin is deprecated.

FAQ

Q: What if I don’t have a development team to support this change?

A: The VIP Team will be creating custom Pull Requests for each customer, based on their current implementations, and will also be merging these on customers’ behalf on February 3 where needed. If you have specific questions or concerns about the changes needed for your site, or how to test, please feel free to open a support ticket.

Q: What if we have a planned code freeze?

A: We have planned the below timeline to consider common code freeze periods, such as the upcoming Holidays. If you have specific questions or concerns about the timeframe, please feel free to open a support ticket.

Q: What’s wrong with the Gutenberg Ramp plugin? Why do we have to change?

A: The Gutenberg Ramp plugin has served as a consistent and reliable way for VIP customers to opt in to the Block Editor experience. As we have seen widespread adoption of and success with the Block Editor, we are taking this opportunity to fully endorse a Gutenberg-first experience in the Enterprise WordPress space. The bonus side-effect of this change is helping our customers clean up their code base, while removing some future technical debt.

Timeline

  • November 23, 2020

    Starting today, November 23, the VIP team will create Pull Requests on develop, preprod, and master branches for all customer repos, with the necessary changes for their specific implementation. These Pull Requests will allow you to test on each environment of your application, and merge with confidence that the change has been reviewed by the VIP Team.

  • February 3, 2021

    On February 3, any outstanding Pull Requests will be merged to remove dependencies on the Gutenberg Ramp plugin, and the plugin will be officially deprecated from VIP’s mu-plugins.

Further information

Gutenberg has offered a new approach to matching a team’s existing workflow, and allows editorial teams to work in the context of what their site and pages actually look like. And it has made a flexible, granular reusability of individual elements across projects and even across the community much more directly available.

With Gutenberg, we were able to publish a breaking news story in two minutes versus five minutes in Classic [WordPress]. The main reason for this is the reusable blocks which have been renamed ‘The Game Changer’.

— Joel Davies, Head of Editorial Operations with News UK

If you’d like to learn more about Gutenberg, you can review our documentation or our case study with News UK.

Questions?

If you have testing feedback or questions related to this release, please open a support ticket, and we will be happy to assist.

Updates and recommendations: Facebook and Instagram changing oEmbed to require authentication

Update: As of October 7, the approach recommended below has changed. Please refer to our updated post here for further and up to date information.

For more technical information regarding this further change to our recommended solution, please refer to the following Jetpack source updates:

Facebook has announced that they are deprecating existing oEmbed API endpoints and introducing new authenticated endpoints. This means that, beginning October 24, new posts attempting to use embeds from either Facebook or Instagram will fail to display content correctly. The change will also impact any previously published posts updated in the Classic or Block editor. To mitigate this oEmbed endpoint deprecation for Facebook and Instagram, changes may be required to your WordPress installation.

To make this transition seamless for your team, WordPress VIP recommends you enable Jetpack’s Shortcode Embeds module before October 24.  This post outlines frequently asked questions about Facebook’s update and the steps you can take to prevent any issues.

Background

From Facebook’s announcement post

Changes to tokenless access for User Picture and FB/IG OEmbed endpoints: By October 24, 2020, developers must leverage a user, app, or client token when querying Graph API for user profile pictures via UID, FB OEmbeds and IG OEmbeds. Developers should provide a user or app token when querying for profile pictures via a UID or ASID, though client tokens are supported as well. Please visit our changelog for User PictureFacebook OEmbed, and Instagram OEmbed for details on how to start calling these Graph API endpoints today. 

For more context, please see our previous Lobby post here. You can find Facebook’s latest developer documentation for Facebook oEmbeds here and Instagram oEmbeds here. For more information on the changes to the core WordPress project’s response to this change, please refer to the make.wordpress.org post and related discussion.  

Steps to enable Jetpack’s Shortcode Embeds Module

How do I enable Jetpack’s Shortcode Embeds module? 

We recommend enabling the Shortcode Embeds Module programmatically like this:

add_filter( 'jetpack_active_modules', 'x_enable_jetpack_shortcode_module', 9999 );

function x_enable_jetpack_shortcode_module( $modules ) {
    if ( ! in_array( 'shortcodes', $modules, true ) ) {
        $modules[] = 'shortcodes';
    }
    return $modules;
}

FAQ

How will this affect content publishing and editing on my site after October 24?

For legacy/previously-published content: By default, WordPress caches oEmbed contents in post metadata. These embeds will continue to display in previously-published content.

For new posts: In both the Classic Editor and the Block Editor, new posts attempting to use embeds from either Facebook or Instagram will fail to embed the proper content starting on October 24th. They will display either a plain shortcode or the URL of the attempted embed, depending on the embed method.

What solution does WordPress VIP recommend?

Prior to the October 24th deadline, Jetpack 9.0 will add support for Facebook and Instagram embeds separate from the removed WordPress core support. To receive this updated embed support, your site will need to have the Jetpack Shortcode Embeds module enabled.

How does Jetpack’s solution to this new oEmbed requirement function?

Jetpack’s Shortcode Embeds module takes the embed requests to Facebook and Instagram and proxies them through the Jetpack service. For Facebook embed requests, the Jetpack module utilizes the Facebook JavaScript SDK, which is not affected by the upcoming changes to embeds. For Instagram embed requests, Jetpack will “proxy” an API token owned by Automattic, which alters the request so it is no longer “tokenless.”

Can I use my own Instagram Developer API Token, instead of Automattic’s token, for these requests?

To set the constant, add this to your vip-config/vip-config.php file:

define( 'JETPACK_INSTAGRAM_EMBED_TOKEN', 'YOUR_TOKEN' );

Alternatively, you can set your API Token using this filter:

add_filter( 'jetpack_instagram_embed_token', 'x_set_jetpack_instagram_embed_token' );

function x_set_jetpack_instagram_embed_token() {
    return 'YOUR_TOKEN';
}
Where can I see the changes that have been made to Jetpack to accommodate this fix?

The primary work on the Jetpack plugin to support working Facebook and Instagram embeds can be found in the following Github pull requests to the public repository:

Are there alternative solutions WordPress VIP recommends to prevent these embeds from breaking?

The WordPress VIP team has evaluated third-party solutions for mitigating these changes to the Facebook API. At this time, we recommend the Jetpack Shortcode Embeds module as the best option to mitigate these changes.

If you know of or are working on a solution you believe would be of benefit to other WordPress VIP customers, please reach out to us and we would be happy to review it for recommendation.

What should I do if I have further questions regarding this change?

If you have any questions regarding the changes to the Facebook oEmbed implementation, or regarding the Jetpack implementation described above, please file a support ticket and our support staff will be happy to assist you.

Facebook + Instagram removing oEmbed Support

Facebook has announced that they are removing support for oEmbed requests. From their announcement post:

Changes to tokenless access for User Picture and FB/IG OEmbed endpoints: By October 24, 2020, developers must leverage a user, app, or client token when querying Graph API for user profile pictures via UID, FB OEmbeds and IG OEmbeds. Developers should provide a user or app token when querying for profile pictures via a UID or ASID, though client tokens are supported as well. Please visit our changelog for User Picture, Facebook OEmbed, and Instagram OEmbed for details on how to start calling these Graph API endpoints today.

How does this affect my site on WordPress VIP?

Writers and editors for your site may have been embedding Facebook statuses and Instagram posts into your content using oEmbed-compatible URLs. When WordPress detects these, it requests the embed to display from Facebook’s services using the oEmbed format.

Currently, Facebook does not require any authentication to supply these embeds and place them within your post content. Starting on October 24th, this policy is changing, and an identifying token from the Facebook Developer program will be required for the embed to display. For more of an overview of oEmbeds you can visit the WordPress.org support article here or the general oEmbed documentation here.

Since these endpoints will no longer be open, WordPress Core is planning on removing support. If you rely on Facebook or Instagram oEmbeds, after October 24th, by default the URLs will be returned as a string inside of the post. 

What are the next steps from WordPress VIP?

We are aware that customers will face content-breaking changes with this change to embeds. We will publish recommended solutions on or before September 28th to help you ensure Facebook and Instagram embeds continue to function after the October 24th deadline.  You may be required to use a Facebook Developer token to implement this solution, and any solution is likely to require a small change to your site’s code. If you are unsure how to implement these changes, or have any additional questions regarding this change, please open a support ticket and we’ll be happy to assist.