PayPal Payment Buttons: put the API-managed buttons behind a feature flag - #51982
PayPal Payment Buttons: put the API-managed buttons behind a feature flag#51982millerf wants to merge 6 commits into
Conversation
|
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 Follow this PR Review Process:
If you have questions about anything, reach out in #jetpack-developers for guidance! Jetpack plugin: The Jetpack plugin has different release cadences depending on the platform:
If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. Paypal Payment buttons plugin: No scheduled milestone found for this plugin. If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. |
…flag Register `paypal-payments-api-managed-buttons` (off by default) in the package and read it from both bootstraps. While it is off the REST routes, the Payment Links admin page, the email sender, and the sharing hook stay unregistered, and the block editor shows the paste-code editor restored from trunk. A button created through the API keeps rendering on the frontend and shows as a read-only preview in the editor. Also restores trunk's WordPress.com plan gate on the block (`plan_check` and the `value_bundle` upsell fallback), which the V2 port had dropped. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
… is off in the changelog The standalone plugin's e2e suite drives the V2 editor, so it gets an e2e helper plugin that forces the flag on, mounted like Boost's helpers and activated by the suite's env scripts. The V2 changelog entries now say the feature sits behind a flag that is not yet enabled. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…ndant Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
e20d86a to
f9eaa51
Compare
…, flipped button default * Fixed the editor loading the PayPal block bundle twice on every editor screen * Fixed the onboarding endpoint registering on every site while the feature is off * Reverted a buttonType default flip that re-rendered already-published buttons * Fixed the block stylesheet loading on every classic-theme page * Fixed a warning style leaking onto every warned block in the editor * Changed the Payment Links admin page to load nothing while the feature is off * Changed the package to stop shipping 49 KB of internal docs
Two stubs claimed the handle on init, ahead of Script_Data registering the real file on wp_loaded. The editor bundle imports isWpcomPlatformSite, which only the real module exports, so the block failed to render with the flag off.
Fixes PAYPAL-180
Proposed changes
Puts the API-managed PayPal Payment Buttons (V2) behind a
jetpack-feature-flagsflag,paypal-payments-api-managed-buttons, off by default, so the V2 work can merge without shipping.PayPal_Payment_Buttons::is_api_managed_enabled()andadd_editor_feature_flags(). While the flag is off, thewpcom/v2/paypal/*REST routes, the Payment Links admin page, the email sender AJAX action, and the sharing hook are not registered. Rendering is deliberately not gated, so a button created while the flag was on keeps working after it is turned off.edit.jsxis now a thin switch. The V2 editor moved toedit-api-managed.jsx; trunk's paste-code editor is restored asedit-paste-code.jsx(with its styles) and is what the block shows while the flag is off. The two are separate components so the V2 connection hooks, which call routes that only exist while the flag is on, never run on the paste-code path. An API-managed block seen with the flag off shows a read-only preview with a notice.jetpack_block_editor_feature_flags, so JS reads it withhasFeatureFlag(). Also restores trunk's WordPress.com plan gate (plan_check => trueand thevalue_bundleupsell fallback), which the V2 port had dropped; that gate is current pricing policy (DOTCOM-15310, Gate PayPal payment buttons block behind conditional features #46536) and this PR should not lift it.feature_flagsto the editor state it already localizes.DEVELOPMENT.md.Related product discussion/links
fix/paypal-admin-delete-orphans), which sits on Add/paypal payment buttons v2 #51656.Does this pull request change what data or activity we track or use?
No.
Testing instructions
Flag off (default)
plugins/jetpackorplugins/paypal-payment-buttonsto a test site.wp eval 'var_dump( array_keys( \Automattic\Jetpack\Feature_Flags\Feature_Flags::all() ) );'listspaypal-payments-api-managed-buttons.curl -s <site>/wp-json/wpcom/v2/paypal/connectionreturnsrest_no_route, and there is no Payment Links entry under the Jetpack (or Settings) menu.Flag on
wp companion feature-flag enable paypal-payments-api-managed-buttons. Elsewhere, dropadd_filter( 'jetpack_feature_flag_enabled_paypal-payments-api-managed-buttons', '__return_true' );into an mu-plugin.Automated
jp test php packages/paypal-paymentsandjp test js packages/paypal-paymentscover both branches of the flag.