Cancel

Sarah Gooding

Jetpack 7.6 Improves AMP Compatibility, Adds Preview and Upgrade Nudge for Blocks Only Available on Paid Plans

Jetpack 7.6 was released this week with several improvements to the plugin’s AMP compatibility. Automattic was one of the earliest publishing partners on Google’s AMP project, as well as the original author of the official AMP plugin for WordPress. This release makes three more Jetpack features compatible with AMP:

  • Related Posts now display on AMP views.
  • AMP images are now rendered via Jetpack’s image CDN if the module is active.
  • AMP plugin is now capable of styling the Jetpack sharing buttons, without loading any additional CSS.

More AMP compatibility improvements are planned for the 7.7 milestone, including AMP support for the WordAds block.

Version 7.6 also fixes a security vulnerability in the Simple Payments description output. This fix only affects those who have Premium or Professional plans and are using the Simple Payments button to sell products or collect donations.

Jetpack is Beta Testing a Preview and Upgrade Nudge for Blocks Only Available on Paid Plans

Jetpack is testing a new way of marketing its Paid plans inside the block editor. One of the more interesting additions to this release is that the plugin now allows for the insertion and preview of any Jetpack block in the editor, even if the block is only available via a Paid plan. Although it was included as part of the 7.6 release, it look like it’s currently only active for sites that have enabled beta testing.

The first iteration was merged as a generic solution that can be extended for all premium blocks but it currently only applies to the Simple Payments block. Prior to this update, users on the free and personal plans would not see the Simple Payments block in the block inserter. This change adds the Simple Payments block to the list of available blocks and allows users to insert and preview it. The block will not show up on the frontend unless the user upgrades.

Clicking on the upgrade nudge takes the user to the checkout with the plan pre-selected and then drops them back to the editor after they purchase the required plan for using the block. After the initial implementation with the Simple Payments block, the Jetpack team plans to do the same for the Recurring Payments, VideoPress, and WordAds blocks.

It’s easy to see why this controversial addition to the plugin was omitted from the release post. It adds new blocks for features that users cannot access without upgrading. The WordPress.org theme directory has struggled with a similar issue, which Justin Tadlock characterized as “crippleware,” where certain features are locked away behind upsells.

If Jetpack’s implementation catches on and other plugins follow suit, it could cause the block inserter to become a frustrating minefield. Users select from existing blocks, not knowing if the blocks they are inserting require a paid upgrade until the upsell pops into the editor. This is one block editor marketing tactic worth keeping an eye on as Jetpack rolls it out for more of its blocks that are restricted to Paid plans.

Category: ,
Tags:
27

27 responses to “Jetpack 7.6 Improves AMP Compatibility, Adds Preview and Upgrade Nudge for Blocks Only Available on Paid Plans”

  1. It’s easy to see why this controversial addition to the plugin was omitted from the release post.

    To clarify, we did not include this new feature in the release post because it is still a work in progress. As you mentioned in the post, the feature isn’t fully ready yet; it’s not available for all blocks just yet, and still in Beta.

    Once we start rolling out this feature for everyone, we will mention it in the release post :)

    Create forum topic from comment

  2. It adds new blocks for features that users cannot access without upgrading. The WordPress.org theme directory has struggled with a similar issue, which Justin Tadlock characterized as “crippleware,” where certain features are locked away behind upsells.

    Users select from existing blocks, not knowing if the blocks they are inserting require a paid upgrade until the upsell pops into the editor.

    On the other hand, this allows site owners to discover blocks that are already available on their site. Jetpack’s Simple Payments isn’t new, it’s been part of Jetpack since November 2018. Yet some site owners may not know about it, and may be looking for just that feature for their site.

    I believe such an initiative goes hand in hand with Core’s Block directory project:
    – Block Directory in WP-Admin Concepts
    – Block Directory updates

    This project, just like Jetpack’s work on block notices, brings us closer to a place where you can manage your site from the editor, without having to leave the editor. It improves block discovery and gives you access to new blocks without having to google around or search for new plugins in Plugins > Add New whenever you need a new block.

    If Jetpack’s implementation catches on and other plugins follow suit, it could cause the block inserter to become a frustrating minefield.

    I believe this is also something that will be addressed by the block directory project. WordPress already includes a block manager, and it will be further improved with the Block Directory project so it becomes easier for one to filter out the blocks they don’t want to see in their editor. Check the post I linked to above to find out more (and check the comments as well, where folks have already chimed in with some suggestions for the block manager interface).

    Create forum topic from comment

    • It improves block discovery

      It improves discovery of paid services.

      Does it improve discovery of blocks users actually want or does it provide an obstacle to it?

      If a user is searching for blocks with specific functionality, then clicks on them only to find out repeatedly that the functionality is locked behind a paywall, that’s a frustrating experience – particularity if others start following Automattic’s increasingly aggressive marketing push.

      Create forum topic from comment

      • Does it improve discovery of blocks users actually want or does it provide an obstacle to it?

        That’s a good question, and one that we are trying to answer with our tests, and with feedback like yours!

        If I search for “PayPal” or “sell” in the block picker, I’d consider it a win to get a result; it brings me one step closer to my goal. I can then preview the block, and proceed with my purchase only if that’s really the block I am looking for. If not I’ll keep looking.

        I personally like the idea of doing that research inside the editor, so I don’t have to completely abandon my editing flow just because I am looking for something that isn’t available on my site just yet. I also feel like seeing the block in the editor gives me a better idea of what its options are, and allows me to quickly see if the block is really what I need, or if I should look for something else.

        I can’t count the number of times I spent hours trying out plugin after plugin to find a feature I was interested in. Often a plugin’s readme doesn’t give you enough information and you need to see the feature in action to really know if that’s what you need.

        This is part of why I am excited about the upcoming Block Directory project.

        That said, I know that not everyone shares my opinion. @Patrick B put that quite nicely in his comment below:

        It’s an editor, it should be dedicated to that task.

        I guess it boils down to how we define “editing” on a WordPress site today. I think the Block editor kind of allows us to redefine what the editing experience means for WordPress today. It offers us some opportunities, and some challenges. I don’t know where editing should stop, what should be in the editor and what shouldn’t be in there. Overall, I think experiments made in plugins like Jetpack and core projects like the Block Directory project will help us figure this out in the next few months.

        Create forum topic from comment

      • “If I search for “PayPal” or “sell” in the block picker, I’d consider it a win to get a result; “

        Take the example of a user who wants a PayPal block that’s free to use.

        They search for one in the editor, then click on it only to find out that it requires payment.

        Repeat that process multiple times when others follow Automattic’s example, and it’s not a good user experience.

        If the editor is going to be used by companies to push premium blocks like in an app store, then there should be a way for users to filter free and paid blocks when searching for them.

        Create forum topic from comment

      • If the editor is going to be used by companies to push premium blocks like in an app store, then there should be a way for users to filter free and paid blocks when searching for them.

        I definitely agree. The current block picker could be improved, and we know it will be. The Block directory project will bring in big changes for once, but the picker is already continuously improving, as we can see by browsing the Gutenberg repository and looking at the “Inserter” component label.

        Ideally you’d be able to filter your search using multiple factors. Free/paid is one of them, but I could also imagine ratings, number of active installs, or whether the block is translated in your language or not. I’ll personally be keeping a close eye on the Block Directory project to see where this goes.

        Create forum topic from comment

  3. If Jetpack’s implementation catches on and other plugins follow suit, it could cause the block inserter to become a frustrating minefield.

    Coming back to this, I am hoping that 2 things may help here:

    1. The current WordPress.org Plugin Guidelines have specific rules in place to avoid random features being blocked behind a paywall. Software as a Service is permitted, but Trialware is not. As a result, if a block is not available in a plugin you’ve installed from the WordPress.org plugin directory, there is a reason for it.

    2. Jetpack’s implementation is still, as I mentioned earlier, a work in progress. It’s in a Beta phase. We’re collecting feedback and will keep iterating before the feature becomes available to all site owners.

    We’ve already experimented with different ideas to make things clearer in the block picker as well (here are 2 examples). We’ll keep experimenting.

    If anyone has feedback on the current implementation, or wants to help with testing, do not hesitate to join our Beta group and/or contact us with your remarks and ideas. Thank you!

    Create forum topic from comment

  4. https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/#5-trialware-is-not-permitted

    Plugins may not contain functionality that is restricted or locked, only to be made available by payment or upgrade.

    🤦‍♂️

    It is why I had to take off one of my plugins from WordPress.org’s repo.

    Automattic, you’re encouraging behavior all but the greedy are against. Stop it. Go back to your roots; it’s why we supported you.

    Create forum topic from comment

    • You’re right, trialware is not permitted in the WordPress.org plugin directory. Software as a Service, however, is:
      https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/#6-software-as-a-service-is-permitted

      Jetpack currently ships with 4 paid blocks. All 4 of them rely on a third-party service that lives on WordPress.com. Don’t hesitate to check them out to learn more about them:

      – Recurring Payments Block
      – Simple Payments Block
      – Video Block
      – Ad Block

      Create forum topic from comment

      • Thank you, Jeremy, for being on top of this.

        I believe that you should highlight in the blocks that the wp.com servers are required to make them of any use. For sanity, you hide the blocks when such a connection isn’t available. To help ease with integration, the user may already fill in the details, etcetera.

        As of now, from the images, it shows there’s an incentive to make the editor a marketplace. It is why it’s received so negatively.

        We still have bad tastes in our mouths from the imposed Gutenberg release last December, let us water that down first (by fixing the code editor, tyvm) before adding more to that.

        Create forum topic from comment

      • You’re right, trialware is not permitted in the WordPress.org plugin directory. Software as a Service, however, is […]

        How is this not trialware? You’re able to use the block and try it out, but you can’t actually do anything with it unless you pay for a Jetpack plan. That is literally trialware.

        Create forum topic from comment

      • I believe that you should highlight in the blocks that the wp.com servers are required to make them of any use.

        Yes, that came up on Twitter yesterday as well. It’s clear we need to do a better job of explaining why a block may not be fully available, so site owners can make informed decisions based on that. I’ve taken note of that, and we’ll see how we can best do that.

        Thanks for the feedback!

        Create forum topic from comment

      • How is this not trialware? You’re able to use the block and try it out, but you can’t actually do anything with it unless you pay for a Jetpack plan.

        You can’t use the block without a connection to the WordPress.com API. It relies on that service to work. I described this into more details in another comment here.

        Create forum topic from comment

  5. The trialware rule needs be rewritten.

    It encourages behavior like this where some piece of functionality that could be accomplished locally is instead put in a “service” that a user needs to sign up for separately.

    It also encourages the glut of admin upgrade notices everyone complains about since that is just about the only way to promote the paid version of a free plugin.

    The UI here is actually a really big improvement over yet another upgrade notice in the admin screen. Unfortunately it’s only available to people who use the saas loophole Automattic is using here (and even then I wonder if it would be allowed for a different developer)

    The trialware rule should be applied to true trialware only, not to otherwise useful free software that only wants to improve it’s upgrade promotion UI with contexual notices like the example here.

    You would see a LOT less annoying admin messages as a result if this were allowed for everyone.

    Create forum topic from comment

    • behavior like this where some piece of functionality that could be accomplished locally is instead put in a “service” that a user needs to sign up for separately.

      Are you referring to the Simple Payments feature in Jetpack? I’ve received some good feedback about this on Twitter earlier today; we definitely need to improve Jetpack’s documentation about this feature to better explain how it works, and why it relies on a third-party service (WordPress.com). That’s on our to-do list!

      In short, the WordPress.com API is used for a few things:

      1. Interface with the PayPal API to process the payments made through the blocks
      2. Send notifications emails and summaries about the different purchases on your site.
      3. Store PCI-compliant tokens and API keys.

      You could certainly build a “local” PayPal block that contacts PayPal directly (maybe one exists already!), but you wouldn’t benefit from features 2 and 3 on my list above. That would be a different product.

      This is why the Simple Payments feature relies on a third-party service.

      If you have more questions about the feature, don’t hesitate to reach out!

      Create forum topic from comment

    • It encourages behavior like this where some piece of functionality that could be accomplished locally is instead put in a “service” that a user needs to sign up for separately.

      Fake services are not permitted. Says so right there in the guidelines.

      “The service itself must provide functionality of substance and be clearly documented in the readme file submitted with the plugin, preferably with a link to the service’s Terms of Use.

      Services and functionality not allowed include:

      – A service that exists for the sole purpose of validating licenses or keys while all functional aspects of the plugin are included locally is not permitted.
      – Creation of a service by moving arbitrary code out of the plugin so that the service may falsely appear to provide supplemented functionality is prohibited.
      – Storefronts that are not services. A plugin that acts only as a front-end for products to be purchased from external systems will not be accepted.”

      We did think ahead on this one, about 8 years back or so.

      Create forum topic from comment

      • Thanks for the reply Otto. I didn’t mean to imply that Automattic is using a fake service. Just that their functionality *could* be included inside the distributed plugin instead. Maybe there are benefits to doing payment integration and sending emails and storing api keys as a service but lots of other plugins accomplish these tasks inside the plugin itself.

        My main point was that there’s an incentive to put block functionality in a service if doing so lets the developer then use more effective upgrade UI that would otherwise not be allowed by the guidelines “crippleware”
        policy.

        Create forum topic from comment

  6. The last thing users want or need is ads on the WP editor screen. Calling it anything else is at best “marketing spin.”

    It appears that the goal of the JetPack team is to insert their ads in every nook and cranny. Let’s help them out:

    – On the login screen put an ad for brute force attack protection

    – On the Settings discussion screen put an ad for Akismet

    – In the media library put in ads for file and image hosting

    – On the edit screen put an add for social media posting on the Publish button

    This is clearly functionality locked behind payment otherwise it would work without payment. The fact that the blocks are unlocked via a web service doesn’t change that. If people want to subscribe to JetPack, fine, but we shouldn’t allow non-functioning blocks in the editor.

    Create forum topic from comment

  8. This sort of interaction should stay out of the block editor. The new editor already adds new levels of complexity into creating and formatting content on a page. Adding sales and research decisions into it doesn’t help.

    It’s an editor, it should be dedicated to that task.

    Create forum topic from comment

    • It’s an interesting point of view. I don’t know if that’s where we’re headed with the block editor today. Projects currently in the works like the Block Directory Project would seem to indicate otherwise.

      We were discussing something similar a few comments above, and your comment offers an interesting counterpoint. 👍

      In any case, I think that Block directory project could really benefit from your remarks!

      On Jetpack’s end, we’ll see about implementing a way of short-circuiting that behaviour to address your feedback. I’ve taken note of this! 👍

      Create forum topic from comment

  10. > It adds new blocks for features that users cannot access without upgrading. The WordPress.org theme directory has struggled with a similar issue, which Justin Tadlock characterized as “crippleware,” where certain features are locked away behind upsells.

    I don’t think this is a fair comparison of what I was saying about crippleware themes and this feature in Jetpack.

    I have no problem whatsoever with upselling. I wouldn’t classify this particular Jetpack feature being behind a paywall as crippleware. Jetpack is a fully-featured plugin where the majority of its features are not locked.

    The crippleware issue I was talking about in regards to the theme directory has more to do with themes being little more than bare-bones designs with literally every useful feature hidden behind the paywall.

    There is a huge distinction between having a value-add in the form of a paid add-on/upgrade and simply making a basic enough product to get into the theme directory just to market your pro version.

    Create forum topic from comment

  11. This is poor UX and has nothing to do with the WordPress way. It shouldn’t be allowed in WordPress.org. And it’s only allowed because it’s Jetpack and Automattic. Info on payed blocks should be reserved to the plugin’s settings page, the WordPress.org readme text and the plugin’s own page, not in the editor.

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.