Updated Release Process for VIP MU Plugins

We are excited to announce that we will be offering more transparency, predictability, and testability of the platform codebase. Below is the summary of the changes:

• Production and staging releases for the VIP Platform Must Use Plugins only happen on Tuesdays. You are able to run the staging branch of the MU Plugins in non-production environments, allowing you to test your applications against our platform code ahead of the production release.
• Beginning Nov 29, 2022 we will switch every “develop” environment to use the staging branch of MU plugins. 

Improved visibility and predictability for VIP MU plugins releases

VIP MU plugins is a codebase that integrates your WordPress applications in the WordPress VIP Platform, and it provides key scaling, security, and management functionality. 

To give you a greater ability to assess updates to our platform against your unique application code and ensure they will not have an impact on your business, we are changing the way updates are deployed across production and non-production environments.

Over the years we’ve been providing increasing levels of visibility into what is being implemented and when it will be deployed. In 2021, we introduced the VIP Changelog, a stream of all public changes released on the Platform. We also designated Tuesdays for all VIP MU plugin releases.

Every Tuesday, the previous week’s staging release is promoted to production, and a new staging release is made. 

Undisclosed security mitigations, critical hotfixes, Jetpack updates, and core releases are not subject to the MU plugins release schedule.

Staging releases on non-production environments

The updates we make to VIP MU plugins undergo rigorous internal testing before they are merged to the Staging branch and made available for customers. 

Every feature branch must pass 42 checks before it can be merged. We run core tests, MU plugins tests across every deployed WordPress version, linters, code coverage reports, end-to-end tests, and other benchmarks to keep track of code quality.

Though great effort is made by VIP to provide stable releases every week, it’s important for customers to be able to validate compatibility of the application and the platform codebases. That’s why on November 29, 2022, at least one `develop` (non-production) environment per application will be configured to use the staging branch of VIP MU plugins.

We recognize that everyone’s needs and workflows are different, and running non-production code may not be pertinent, so we made it easy to opt-in/opt-out any environment using the Software Management feature in the VIP Dashboard or using VIP-CLI.

# vip @<ID>.<ENV> config software update muplugins <staging|production>

Questions?

If you have any questions related to this update, please open a support ticket and we will be happy to assist.

New Feature: User Settings in the VIP Dashboard

We have added a User Settings page to the VIP Dashboard.

Currently, this page provides a read-only view into information about your user account including all roles & permissions you have via the VIP Dashboard.

In the near future, we’ll be adding support for editing your information as well as ability to manage notification preferences, auth tokens, and more.

You can learn more about the User Settings page in our documentation.

We’d love to know what you think; please get in touch!

Parse.ly WordPress Plugin 2.5 Release

Fresh on the heels of last month’s 2.4.1 release, we’re now pleased to announce the 2.5.0 release of the wp-parsely plugin.

Parse.ly gives creators, marketers and developers the tools to understand content performance, prove content value, and deliver tailored content experiences that drive meaningful results.

We encourage everyone using the plugin to update to the latest version.

If you have any questions about how WPVIP + Parse.ly can help you deliver meaningful customer experiences, please get in touch.

What is being added or changed?

Added

• Refreshed contributor documentation into a new CONTRIBUTING.md file.
• Introduce a build step for front-end and admin page JavaScript assets which leverages the @wordpress/scripts package. Scripts are now separately enqueued and browser-cacheable.
• Allow for select HTML tags and attributes in the Recommended Content widget title.
• Add a “No boost” option for scores in the widget.
• Add filter wp_parsely_post_type to override the type of content Parse.ly attributes to an article.
• Add support for custom post status slugs via the wp_parsely_trackable_statuses filter (to allow for those other than publish to be tracked).
• Make $post_id available to the wp_parsely_permalink filter.

Changed

• Refactor printed markup into template “views.”
• Refactor plugin entry file to perform minimal initialization and separately load the Parsely class file.
• Improve the README file (which populates the copy in the plugin repository page).
• Expand test coverage (PHP and JavaScript).
• Expanded string localization and consolidate into a single text domain.
• Adjust HTML heading levels for improved usability and accessibility.
• Improve accessibility of radio inputs on the admin page.
• Improve the widget user interface to make it more consistent with core styles.
• Better load Widget CSS and use plugin version for cache busting.
• Replace widget form and hide front-end output when API values are missing.
• Prevent printing of admin page CSS outside the specific admin page for this plugin.
• Switch to XHRs for /profile calls (instead of using JSONP).
• Remove jQuery dependency from the API and Admin scripts.
• Stop using protocol-relative URL for the tracking script.
• Register the package at Packagist for easier install via Composer.

Fixed

• Fix the “requires a recrawl” notices to limit to specific admin page settings.
• Fix inconsistent ports in canonical URLs.

Deprecated

• Deprecate filter after_set_parsely_page — use new name wp_parsely_metadata instead.
• Deprecate filter parsely_filter_insert_javascript — use new name wp_parsely_load_js_tracker instead.

Questions?

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

Parse.ly WordPress Plugin 2.4 Release

Since we announced Parse.ly joining forces with WPVIP, we’ve been working on improving the WordPress integration. The first collaborative release of the Parse.ly plugin is here!

Parse.ly gives creators, marketers and developers the tools to understand content performance, prove content value, and deliver tailored content experiences that drive meaningful results.

We encourage all of our customers using the plugin to update to the latest version, particularly if it’s being managed in code.

If you have any questions about how WPVIP + Parse.ly can help you deliver meaningful customer experiences, please get in touch.

We’ve got lots of planned enhancements coming soon!

What is being added or changed?

Changed

• Improve WordPress.org assets (screenshots, icons, readme).

Fixed

• Fix metadata for home pages, including pages of older posts.
• Fix metadata for category archives.

Removed

• Remove Parse.ly metadata from search result pages.

For more detailed information, please check out the changelog.

Questions?

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

Updated Timeline – Removing Gutenberg Ramp

As shared in our November 2020 announcement, VIP is actively working to deprecate the Gutenberg Ramp plugin. To facilitate this, we have proactively opened Pull Requests against individual customer repos and branches for each environment, which replaces the Gutenberg Ramp functionality with simplified WordPress Core filters. 

During testing of these Pull Requests, we have identified a bug in the Core filter (details below). While we are actively working to mitigate this issue, both on the VIP platform, and within Core, we are delaying the deprecation from February 3 to February 22, 2021. This includes delaying the previously planned merging of outstanding Pull Requests to February 17.

Identified Issue Affecting Certain Post Types

We have identified an issue affecting any post types that do not support the Block Editor, such as attachments, and certain custom post types. The current Core Filter, use_block_editor_for_post, will attempt to use the Block Editor for all post types, and does not check for Block Editor support. This results in an error on the WordPress Dashboard when attempting to edit these posts. This issue does not affect front-end display.

Solutions in Progress

We have reported the bug within WordPress Core and have provided a patch to implement a check for Block Editor support. 

As an immediate fix, we are implementing the following patch to vip-go-mu-plugins:

add_filter('use_block_editor_for_post', function( $can_edit, $post ) { if ( ! post_type_supports( $post->post_type, 'editor' ) ) { return false; } return $can_edit; }, 999, 2 );

What if I’ve already merged the Pull Requests?

For those customers who have proactively tested and merged the Pull Requests, no additional action is needed. The above immediate fix will mitigate any potential conflicts.

What If I haven’t merged the Pull Requests?

For those who have not yet acted on the Pull Requests, we will be opening follow-up tickets via Zendesk both as a reminder, and to help answer any question you may have about this deprecation. We do still ask that you test and action these changes according to your development workflows. This is required in order to maintain current functionality when Gutenberg Ramp has been removed.

According to our updated timeline, all outstanding Pull Requests will be merged on February 17, 2021. Deprecation will follow on February 22, 2021.

---

Thank you so much to those who have had the opportunity to test and action the changes, and helped to identify this bug. As always, if you have any questions or concerns please feel free to open a support ticket.

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.

Update: Facebook and Instagram oEmbed authentication change recommendations

On September 28, we published a list of recommendations for mitigating the deprecation of Facebook’s support for unauthenticated oEmbed requests.

Since that time, the solution we recommended has changed.

Due to this upcoming change, Jetpack will not require activation of the shortcodes embed module to update this compatibility. The update to Facebook and Instagram oEmbed endpoints is now included by default for all Jetpack-enabled sites.

These changes are part of the upcoming Jetpack 9.0 release. If you are using our recently-released Jetpack version selection, you must set your preferred Jetpack version to 9.0 or greater to receive these changes to embeds. For more information on setting your preferred Jetpack version, please see our Lobby post here.

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

• https://github.com/Automattic/jetpack/pull/17192
• https://github.com/Automattic/jetpack/pull/17301

Our previous update regarding this change can be found here and has been edited to match this latest change to our recommendation.

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.

Notice: WordPress 5.5 jQuery Compatibility Issues

Yesterday, we released a platform-wide upgrade to WordPress 5.5. Since then, we’ve noticed that some customers experiencing incompatibility issues with custom JavaScript code. This post is to help those customers understand the upgrade and how to resolve issues that may have come up.

If you are seeing new issues such as broken widgets or buttons in your editor, unresponsive buttons like “Publish,” broken page functionality that relies on JavaScript, or new errors in your browser console, these issues may be related to the platform upgrade.

The quick fix

We recommend installing and activating the jQuery Migrate Helper plugin to see if that resolves the issue first. This immediate fix has helped most customers facing issues after the WordPress 5.5 upgrade.

Enable jQuery Migrate Helper

Why are these issues happening?

jQuery is a popular JavaScript library in use on many websites, and included in part of WordPress core.

The WordPress Core team is in the process of upgrading the version of jQuery (1.12) that is bundled with WordPress to the latest release (3.x). Upgrading jQuery brings many security and performance-related improvements. However, it can also introduce breaking changes for customers using older versions. To allow for a safe and smooth transition, the Core team has planned to manage the upgrade over several core releases.

The removal of jQuery migrate 1.x in the WordPress 5.5 release is the first step in this process. Customers that have custom code or plugins that rely on jQuery features that were removed or deprecated prior to jQuery v1 may run into issues like JavaScript errors.

The current schedule for updating the versions of jQuery in WordPress core is laid out in this WordPress Core development note. Following the recommendations of the jQuery team, this update will happen in the following stages:

1. Remove jQuery Migrate 1.x. This was released on August 11th, 2020 with WordPress 5.5.
2. Update to the latest version of jQuery and add the latest jQuery Migrate.
   1. This is tentatively planned for WordPress 5.6, depending on test results. (December 2020)
   2. Updating to the latest jQuery UI, version 1.12.1, is also planned for 5.6. (December 2020)
3. Remove jQuery Migrate. This is tentatively planned for WordPress 5.7 or later, depending on testing. (Spring 2021)

How do I fix this problem?

For an immediate fix: we encourage you to install the jQuery Migrate Helper plugin. This is a short-term fix intended to give your team time to resolve compatibility issues.

For a longer-term fix: we suggest removing this plugin on your development environments, and resolving JavaScript errors there. Once you have your fixes, you can push them to your production environment and deactivate the helper plugin.

To test these changes, there is a plugin that can simulate the changes to different versions of jQuery bundled in code. We encourage you to test the updates well in advance of the pending changes coming in WordPress 5.6, currently scheduled for the end of the year.

How can I prevent compatibility issues from happening in the future?

As part of our managed WordPress service, we are committed to testing and deploying the latest version of WordPress on schedule to keep your site stable, performant, and secure.

Our automated testing catches some issues, however many of the issues with jQuery upgrades happen at the customized application layer. For instance, if you are using plugins that have JavaScript-based customization of your wp-admin screens, you might see breakdown in custom functionality. 

For this reason, we encourage everyone to:

• Subscribe to email updates from this Lobby, which includes calls for testing for WordPress upgrades.
• Upgrade your non-production environments to test WordPress release candidates on your environments; you can open a support ticket to request an upgrade.

We will continue to improve our communications to better prepare you for Core releases. If you have suggestions about how you’d like us to contact you, please let us know.

Please don’t hesitate to reach out to the VIP team and open a support ticket, if you need further assistance.

 

New Release: AMP 1.4.2 on WordPress.com

Following a successful call for testing period and the completion of a series of automated tests, we have deployed AMP 1.4.2 across VIP sites on WordPress.com.

(Note: this update does not apply to sites on the VIP Go platform.)

The AMP plugin has been updated from v0.6.2 to v1.4.2. The 1.4.2 release includes tons of bug fixes and other improvements we think you will enjoy. For a complete list of what has changed, head on over to the GitHub changelog and browse through the release history.

If you have questions or run into issues, please open a support ticket with details and we will be glad to assist.