Add RRM inline CTA button blocks

[nfmohit]

Feature Description

As part of RRM Phase 2, the WordPress post editor will offer one of the two following blocks:

1. “Contribute with Google”; This will only be registered if the publication’s payment option is contributions, obtainable using the new paymentOption module setting. The block should render the following:
   <button swg-standard-button="contribution"></button>
2. “Subscribe with Google”; This will only be registered if the publication’s payment option is subscriptions, obtainable using the new paymentOption module setting. The block should render the following:
   <button swg-standard-button="subscription"></button>

The blocks should be “dynamic”. Learn more about dynamic blocks here. A Modules\Reader_Revenue_Manager\Blocks\Inline_Buttons class should be created to register the above dynamic WordPress editor blocks offering the user to place inline contribute/subscribe buttons within their content and create a new block category that would nest blocks from the Site Kit plugin.

The new googlesitekit-reader-revenue-manager-post-editor.js JavaScript entry point will include the JavaScript block definitions.

• See relevant section in the design doc.

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• If the rrmModuleV2 feature flag is enabled, two new dynamic blocks should be added to the WordPress block editor with render content as follows:
  1. "Contribute with Google": <button swg-standard-button="contribution"></button>
  2. "Subscribe with Google": <button swg-standard-button="subscription"></button>
• The blocks should render the above content only if the following conditions are met, otherwise, they should not render anything:
  • The connected publication has a payment option of either contributions (for the "Contribute with Google" block) or subscriptions (for the "Subscribe with Google" block).
  • The post where the blocks are added includes the Reader Revenue Manager snippet, which can be determined using the logic defined in #9973.
• The editor preview of the blocks should be composed according to the following:
  • If the above conditions are met and the CTA is actually rendered to the front end, the editor should simply display a preview of the CTA (see the screenshot in the feature description or the actual CTA in the front end for styling reference).
  • If the above conditions are not met and the content is not rendered to the front end, the editor should display the preview of the CTA but with a grayscale lower-opacity effect to indicate that it is disabled.
    • When the block is selected, its block sidebar (inspector controls) should render an undismissible warning notice explaining why the block content will not be rendered, according to the following:
      • If the connected publication does not have a payment option of either contributions or subscriptions:
        • For the "Contribute with Google" block:
          • If the current user has access to the Reader Revenue Manager module: "You need to set up a contributions request in Reader Revenue Manager to use this block. Go to Reader Revenue Manager". The "Go to Reader Revenue Manager" part should be a link that navigates the user to the publication's Reader Revenue Manager page in Publisher Center, i.e. https://publishercenter.google.com/reader-revenue-manager?publication={ PUBLICATION_ID }.
          • If the current user does not have access to the Reader Revenue Manager module: "You need to set up a contributions request in Reader Revenue Manager to use this block. Contact your administrator".
        • For the "Subscribe with Google" block:
          • If the current user has access to the Reader Revenue Manager module: "You need to set up a paywall in Reader Revenue Manager to use this block. Go to Reader Revenue Manager". The "Go to Reader Revenue Manager" part should be a link that navigates the user to the publication's Reader Revenue Manager page in Publisher Center, i.e. https://publishercenter.google.com/reader-revenue-manager?publication={ PUBLICATION_ID }.
          • If the current user does not have access to the Reader Revenue Manager module: "You need to set up a paywall in Reader Revenue Manager to use this block. Contact your administrator".
      • If the post where the blocks are added does not include the Reader Revenue Manager snippet:
        • If the current user has access to the Reader Revenue Manager module: "This post does not include the Reader Revenue Manager snippet. Configure the snippet for this post in the post settings sidebar.".
        • If the current user does not have access to the Reader Revenue Manager module: "This post does not include the Reader Revenue Manager snippet. Contact your administrator".

Implementation Brief

• Review and refine the PoC, which creates ground for adding RRM Gutenberg blocks and implements the "Contribute with Google" block.
• Repeat the same (and consolidate commonalities) for the "Subscribe with Google" block.
  • Compose a new "Subscribe with Google" block in blocks/reader-revenue-manager/subscribe-with-google.
    • Create block.json similar to the one in the Contribute with Google block and adapt details accordingly. For the description, use Allow users to subscribe using Reader Revenue Manager to access content behind a paywall..
    • Create Edit.js similar to the one in the Contribute with Google block and adapt details accordingly. Instead of checking for the contributions payment option, check for subscriptions instead.
    • Register the block in index.js, similar to the one in the Contribute with Google block.
  • In includes/Modules/Reader_Revenue_Manager/Blocks, create Subscribe_With_Google.php based on Contribute_With_Google.php and adapt details accordingly. In the rendered button, set the value of the swg-standard-attribute to subscription.
  • In includes/Modules/Reader_Revenue_Manager.php:
    • In the register method, instantiate the Subscribe_With_Google class and call its register method, similar to how it is done for Contribute_With_Google.
    • In the setup_assets method, enqueue the block's distributable index.js file, similar to how it is done for the Contribute with Google block.

Test Coverage

• Add test coverage for the block's dynamically rendered content.
• Add test coverage, if feasible, for the block's editor preview content.

QA Brief

Changelog entry

[ivonac4]

@aaemnnosttv Nahid told me you've talked about this, but would still like your final green flag on it. Could you take a look today, as we need to move RRM tickets forward?

[aaemnnosttv]

Thanks @nfmohit – this LGTM 👍 We may tweak the language during review but nothing blocking here.

AC ✅

[nfmohit]

@aaemnnosttv Just a heads-up that I've removed the fallback content/notice for the block in case the module is not connected. This follows the approach that the Sign in with Google block took and thus simplifies the block further, as the module's register method is not invoked unless the module is at least "active". The only drawback is that the block would appear corrupted if RRM is not connected.

[techanvil]

Hey @nfmohit, the linked PoC is looking good - I have just added a couple of comments to it for your consideration: here and here.

With regard to the IB, it's really leaving things quite open to interpretation at execution time with quite a large draft PR and not a huge amount of guidance in the IB.

I would suggest providing a bit of high level direction in the IB about how we'll adapt the PR to add support for the "Subscribe with Google" block. It doesn't have to go into too much detail, but it would be good to provide an outline, this will show that we've thought about it, provide the executing engineer with a bit of direction, and help to substantiate the estimate.

It would also be good to call out anything from the PoC that might not be entirely clear to whoever picks this up, although if you don't see anything that's worth highlighting that's fine.

[nfmohit]

Hi @techanvil!

the linked PoC is looking good - I have just added a couple of comments to it for your consideration: here and here.

I've responded to your comments, thank you!

I would suggest providing a bit of high level direction in the IB about how we'll adapt the PR to add support for the "Subscribe with Google" block. It doesn't have to go into too much detail, but it would be good to provide an outline, this will show that we've thought about it, provide the executing engineer with a bit of direction, and help to substantiate the estimate.

It would also be good to call out anything from the PoC that might not be entirely clear to whoever picks this up, although if you don't see anything that's worth highlighting that's fine.

I've expanded the IB a little further hoping to provide a general direction for the implementation. Please let me know if it looks good, thanks so much!

[techanvil]

Thanks @nfmohit! That's great, the IB LGTM. I'm just sending this back your way to address the last point of discussion in the PoC PR.

[nfmohit]

I've addressed the last point, thanks so much Tom!

[techanvil]

Thanks @nfmohit! Sending back to you for one last tweak to the PoC as discussed on Slack, this will then be good to go.

[nfmohit]

Thank you @techanvil! I've updated the PoC PR as suggested.

[techanvil]

Thanks @nfmohit! That's great, and this IB is LGTM.

IB ✅