27 Comments

  1. Jeremy

    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 :)

    Report

    • Joseph Dickson

      Please show some restraint. I occasionally use Jetpack for a one off microsite gallery a paid plan would be overkill.

      Report

      • Jeremy

        👍 You’re welcome to keep using Jetpack’s free version and its Tiled Gallery block for example. It’s not going anywhere, and you don’t have to purchase a plan to use that block (or many of the other blocks offered by Jetpack).

        Your experience with the Tiled Gallery block in the editor won’t change one bit.

        Report

  2. Jeremy

    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).

    Report

    • Gary

      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.

      Report

      • Jeremy

        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.

        Report

      • Gary

        “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.

        Report

      • Jeremy

        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.

        Report

  3. Jeremy

    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!

    Report

  4. Sybre Waaijer

    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.

    Report

    • Jeremy

      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

      Report

      • Sybre Waaijer

        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.

        Report

      • Daniel James

        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.

        Report

      • Jeremy

        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!

        Report

      • Jeremy

        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.

        Report

  5. Bradley Kirby

    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.

    Report

    • Jeremy

      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!

      Report

    • Otto

      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.

      Report

      • Bradley Kirby

        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.

        Report

  6. David McCan

    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.

    Report

  7. Morten Rand-Hendriksen

    Act only according to that maxim whereby you can at the same time will that it should become a universal law.

    – Immanuel Kant

    Report

  8. Patrick B

    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.

    Report

    • Jeremy

      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! 👍

      Report

  9. Jon Brown

    I want to ❤️ .com and JetPack, but 💩.

    This is a storefront.

    Report

    • Jon Brown

      …and this is including non-functional code locked behind a paywall.

      Every other plugin that has tried to do this has been told “no” you have to download and install a separate “pro” plugin to deliver that code.

      Report

  10. Justin Tadlock

    > 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.

    Report

  11. Álvaro

    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.

    Report

Comments are closed.

%d bloggers like this: