Skip to content

Donations Block: admin defaults (frequency/amounts/toggles) - #48464

Closed
angelablake wants to merge 39 commits into
update/donations-block-style-optionsfrom
update/donations-frequency-amount-defaults
Closed

angelablake wants to merge 39 commits into
update/donations-block-style-optionsfrom
update/donations-frequency-amount-defaults

Conversation

@angelablake

@angelablake angelablake commented May 1, 2026 •

Copy link
Copy Markdown
Contributor

Stacked on top of #48415. Reviews can wait until that lands; this PR can be tested on Jetpack Beta in parallel.

Proposed changes

Adds admin-configurable frequency visibility controls and donation defaults to the Donations Form block.

Frequency visibility toggles

  • New "Show one-time donations" toggle in the Settings panel, joining the existing monthly and annual toggles, so authors can hide any combination of intervals.
  • Last-enabled guard: the final visible toggle is disabled and shows help text ("At least one frequency must be enabled."), preventing an empty/broken form.
  • Auto-shift: hiding the interval that is currently set as the default silently shifts defaultInterval to the next visible interval in the same setAttributes call — no stale or invisible default can persist.
  • Side-effect bug fix: previously, hiding One-Time while keeping Monthly broke the frontend — view.js was hardcoded to this.interval = 'one-time'. The fix reads the initial interval from data-default-interval on the wrapper instead.

Frequency and amount defaults

  • New "Defaults" sub-section in the Settings panel with a Frequency selector (filtered to currently-shown intervals) and per-frequency default amount selects (None + the three configured dollar values).
  • Default amount is stored by index, not value, so it survives admin edits to the amount values (e.g. changing $15 → $20 keeps the same slot pre-selected).
  • Suggested custom amount: a number input for the placeholder value shown in the custom amount tile; currency-aware minimum enforced.
  • On load and on each tab switch, the configured default amount tile is highlighted and the Donate button is pre-enabled. Clears and resets correctly when switching tabs.
  • Currency change resets customAmountPlaceholder along with the existing per-interval amount reset.

Related product discussion/links

  • Part of the same internal RSM project as #48415.

Does this pull request change what data or activity we track or use?

No tracking or data changes.

Testing instructions

Frequency toggles

  1. Add a Donations Form block. In the Settings panel, toggle "Show one-time donations" off.
    • The One-Time tab should disappear in the editor; the active tab should fall back to Monthly (or Yearly if Monthly is also off).
    • Save and view on the frontend — the One-Time tab should be gone.
  2. Toggle off Monthly as well — only Annual remains. Confirm all three toggle buttons show the last-enabled help text and are disabled, preventing an empty form.
  3. Toggle One-Time back on — the tab reappears and the block is functional again.
  4. Open a legacy Donations block (created before this branch, where oneTimeDonation.show was never set) — the One-Time toggle should show as on and the block should behave normally.

Defaults section [screenshot]
5. Expand the Settings panel and locate the Defaults sub-section below the Show/hide toggles.

  • Set Frequency to Monthly and Monthly default amount to the $15 slot.
  • Save and view on the frontend — the Monthly tab should be active on load, with the $15 tile pre-selected and the Donate button enabled without any user interaction. [demo]
  1. Set a suggested custom amount (e.g. 50) — the custom amount tile placeholder on the frontend should reflect this value.
  2. Change currency — the suggested custom amount should reset.
  3. Hide the frequency that is set as the default — the default should automatically shift to the next visible interval without requiring a separate action.

Angela Blake and others added 29 commits April 30, 2026 10:12
- Wrap the frontend Donate button in `wp-block-button` and add the
  `wp-element-button` class on both editor preview and frontend so
  block themes can style it via theme.json `styles.elements.button`.
- Drop hardcoded `font-size: 16px` on tab labels and amount tiles so
  theme typography flows through.
- Use `transparent` background and `inherit` text color on inactive
  tabs and amount tiles. Active state and structural borders remain
  hardcoded for now; making those theme-driven via CSS custom
  properties is blocked on the build's `postcss-custom-properties`
  config (`preserve: false` inlines fallbacks at build time). A
  follow-up that adds Gutenberg `supports.color/typography/spacing`
  is the standard mechanism and is unaffected by that constraint.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Standard Gutenberg supports (color, typography, spacing,
__experimentalBorder including color/radius/style/width) so users
get the usual style-tab panels for the block as a whole. The default
container border moves up to the block wrapper; users can override
its color, width, style, and radius from the inspector.

Custom inspector controls (under the Styles tab) for per-state colors
that block supports cannot reach: active tab background and text,
inactive tab background and text, and selected amount background and
text. These are stored as block attributes and rendered as a per-
instance scoped <style> element with rules keyed off a unique class
on the wrapper. This pattern is needed because the plugin's postcss
config inlines var() fallbacks at build time, so theme.json presets
cannot flow through the SCSS — the runtime <style> sidesteps the
build entirely.

PHP render sanitizes user-supplied color values before injecting them
into the <style> element to prevent breakout of the CSS context.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Replace isset(X) ? X : '' with X ?? '' to satisfy phan's
PhanPluginDuplicateConditionalNullCoalescing.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…unded corners

* Replace `Blocks::classes()` with `get_block_wrapper_attributes()` in
  the PHP render. The Jetpack helper only emits class names; the WP
  core function emits classes plus the inline `style="..."` for
  user-set color/border/typography supports, so user-set border
  styles now actually appear on the frontend (they were already
  visible in the editor via `useBlockProps()`).
* Add `overflow: hidden` on the block wrapper so children (tabs)
  are clipped to any user-set `border-radius`. Without it, the tab
  corners poke past the rounded outer corners.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Add `<ContrastChecker>` inside each per-state color panel (active
  tab, inactive tab, selected amount) so the inspector warns when a
  user pairs low-contrast foreground/background colors. Same a11y
  affordance core blocks use.
* Add PHPUnit coverage for `sanitize_color_for_css` (hex / rgb / hsl
  / var / named colors pass through; dangerous chars / over-long /
  non-string inputs are rejected) and `build_custom_styles` (empty
  when no overrides, scoped rules per state, unsafe values dropped).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds a "Tab dimensions" panel under the Styles tab with `FontSizePicker`
and `BoxControl` from `@wordpress/components`/`block-editor`, wired to
new `tabFontSize` and `tabPadding` block attributes. Standard Gutenberg
typography/spacing UIs apply only to whole blocks, so per-element
controls go through the same per-instance scoped `<style>` builder used
by the per-state colors.

Also rename `sanitize_color_for_css` to `sanitize_css_value` since it's
now used for non-color values too. The implementation didn't change.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds a "Donate button" panel under the Styles tab with:

* `FontSizePicker` and `BoxControl` for per-instance font-size and
  padding on the donate button. Same pattern as the existing tab
  dimensions controls — values are stored as block attributes and
  rendered via the per-instance scoped <style> element.
* A `ToggleGroupControl` with four options (Left, Center, Right,
  Full width). Left/center/right emit `text-align` on the donate
  button wrapper; full width forces both wrapper and button to
  block-level 100% with `box-sizing: border-box` so padding doesn't
  overflow.

Block-level button color is already covered by `supports.color.button`
enabled previously; this PR fills in the dimensions/alignment gaps
that block supports cannot reach for sub-elements.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Registers a Gutenberg block style variation: users pick "Default" or
"Buttons" from the Styles tab's variations card row. The "Buttons"
variant renders the frequency selectors (One-time / Monthly / Yearly)
as a row of pill-shaped buttons with gaps, instead of the default
edge-to-edge tabs separated by dividers.

CSS-only — variations apply via the `is-style-{slug}` class Gutenberg
adds to the wrapper. User-set per-state colors and tab dimensions
compose on top because they target the same elements at equal-or-
higher specificity in the per-instance scoped <style>.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…g; center full-width button text

Two fine-tuning fixes from JN testing:

* In the Buttons style variation, the nav container had a fixed
  `padding: 16px 16px 0` above the pill row, independent of any
  user-set tab dimensions. Setting tab padding-top/bottom only
  affected the pill interiors; the visible row height felt
  uncoupled from the control. The per-instance <style> now also
  emits matching `padding-top` / `padding-bottom` on the nav,
  scoped to `.is-style-buttons`, so the row scales with the pill
  interior padding the user set.
* Full-width donate button: switching the button to `display: block`
  with `width: 100%` reset its text alignment to the default
  start-of-line, leaving the label visually left-aligned in a
  full-width pill. Add `text-align: center` to the full-width
  button rule.

Tests updated: full-width assertion now covers `text-align: center`,
and two new cases cover the buttons-style nav padding mirror and
absence of the rule when no padding is set.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Reorganize the Styles tab so all tab-related controls live in a single
"Tabs" panel:

* New `tabsAppearance` attribute (enum tabs|buttons, default tabs)
  replaces the block.json `styles` variation registration. The
  appearance toggle now lives inside the "Tabs" panel rather than the
  auto-rendered block-style card row at the top of the inspector.
  The `is-style-buttons` class is applied manually via useBlockProps
  in the editor and via the wrapper class string in PHP, so existing
  CSS keys off the same selector.
* New `tabBorderColor` attribute. The per-instance <style> emits a
  `border-color` rule on `.donations__nav` and `.donations__nav-item`
  so it covers the default-style divider lines AND the buttons-style
  pill borders with one declaration.
* The "Tab dimensions" panel is removed; FontSizePicker and BoxControl
  move into the consolidated "Tabs" panel beside the colors and
  appearance toggle. The five color pickers use
  `__experimentalColorGradientControl` so colors and non-color controls
  coexist cleanly in one PanelBody.
* Setter callbacks are memoized in `useMemo` to keep stable references
  for JSX props (react/jsx-no-bind), and `handleModalClose` in edit.js
  is wrapped in `useCallback` for the same reason.

The "Selected amount" and "Donate button" panels are unchanged.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Revert the per-instance rule that mirrored user-set tab padding-top/
bottom onto the buttons-style nav container. Tab Padding should only
control the pill interior padding (between pill border and text).
The space between the form border and the top of the pill row is set
by the SCSS default (`padding: 16px 16px 0` / `24px 24px 0`) and stays
fixed regardless of user input.

Test renamed and inverted: confirms the buttons-style nav rule is NOT
emitted when only tab padding is set.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Replace the "Selected amount" PanelColorSettings with a consolidated
"Amounts" PanelBody containing all amount-tile styling:

* Selected amount background and text (with ContrastChecker)
* Font size (applies to all tiles, preset + custom)
* Border via BorderBoxControl: color + width + style with link/unlink
  for individual sides — same component WP core's block-level border
  supports renders.
* Border radius via __experimentalBorderRadiusControl: uniform or
  per-corner.

Storage matches the standard Gutenberg shape:
* `amountBorder` (object): uniform `{color, style, width}` or split
  `{top: {...}, right: ..., bottom: ..., left: ...}`.
* `amountBorderRadius` (string or object): "8px" uniform or
  `{topLeft, topRight, bottomRight, bottomLeft}`.

CSS emission (in `build_custom_styles` JS + PHP) handles both shapes
via two new helpers (build_border_decls, build_radius_decls in PHP;
borderDecls, radiusDecls in JS), expanding split values into per-side
or per-corner declarations.

Tests cover uniform border, split border, and per-corner radius shapes.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Switch the five tab color pickers from inline ColorGradientControl
back to PanelColorSettings (rendered without its own title via
showTitle={false}, nested inside the existing "Tabs" PanelBody).

This restores the compact swatch+label rows the standard Color
panel uses for "Background", "Text", etc. — clicking each row opens
a popover with the picker, instead of every picker rendering inline
and stretching the panel.

The five rows are: Active tab background, Active tab text, Inactive
tab background, Inactive tab text, Tab border. Adjacent labels share
a prefix so the active/inactive groupings read clearly. The two
ContrastCheckers stay as children of PanelColorSettings.

(Doesn't address the auto-rendered Dimensions and Border panels'
default-collapsed state — those are core-supports panels and out of
direct block control. The three custom panels (Tabs / Amounts /
Donate button) already use initialOpen={false}.)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Same change as the previous commit applied to the Amounts panel: the
two selected-amount color pickers (background + text) move from inline
ColorGradientControl into a PanelColorSettings (showTitle={false}) so
they render as compact swatch+label rows that open a popover on click,
matching the standard Color panel UX.

The ContrastChecker stays as a child of PanelColorSettings; the
FontSizePicker, BorderBoxControl, and BorderRadiusControl below are
unchanged. The unused ColorGradientControl import is dropped.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Remove `supports.spacing` (padding / margin / blockGap) from the
block.json supports declaration. The auto-rendered Dimensions panel
disappears from the Styles tab.

Block-level padding/margin/gap aren't load-bearing for the donation
form's internal layout — users have higher-leverage controls (tab
padding, button padding, alignment) for the things they typically
want to adjust. Trimming this panel reduces clutter.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two style-panel polish changes:

1. Combine related color pickers into compound rows (one row, multiple
   swatches), modeled after the standard Color panel's "Button" row:
   - Active tab → background + text in one row
   - Inactive tab → background + text in one row
   - Selected amount → background + text in one row
   - Tab border still single-swatch (now using the same component for a
     consistent look)

   New `CompoundColorRow` component built on `Dropdown` + `ColorIndicator`
   + `ColorGradientControl`. Render functions are wrapped in useCallback
   to keep stable refs (react/jsx-no-bind).

2. Add a `jp-donations-style-panel` className to all three custom panels
   (Tabs, Amounts, Donate button) and apply `margin-block-start: 24px`
   to every top-level child after the panel title in editor.scss. Fixes
   the cramped layout where, e.g., the BorderBoxControl's "Border" label
   sat directly under the FontSizePicker. Default control margins differ
   across components, so a wrapper rule normalizes the gap.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…lor rows

Restructure the compound color rows so they look identical to the
auto-rendered "Color (Block support panel)" rows from supports.color:

* Each row is now a `__experimentalToolsPanelItem` with the
  `block-editor-tools-panel-color-gradient-settings__item` class — the
  borders, rounded corners, and per-row reset (kebab menu) come from
  core's existing CSS for that class, no duplicated styles in our
  stylesheet.
* The labeled-indicators toggle uses `__experimentalZStack` with
  `offset={-8}` to overlap the swatches by 8px, matching exactly how
  core's "Button" row stacks its text + background indicators.
* Each panel's compound rows are wrapped in a `__experimentalToolsPanel`
  (with the `color-block-support-panel` class) plus a `resetAll`
  callback. Required for ToolsPanelItem to register properly.

Same component (`CompoundColorRow`) renders both single-swatch (Tab
border) and multi-swatch (Active tab, Inactive tab, Selected amount)
rows.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Mirror the wrapping that core's ColorToolsPanel uses around its
ToolsPanel content — the missing piece was the grid layout that
`hasInnerWrapper={true}` activates plus the
`color-block-support-panel__inner-wrapper` div around children.

Both the Tabs and Amounts color sections now use the same
ToolsPanel props as core (`hasInnerWrapper`, `headingLevel={3}`,
the experimental first/last visible-item classes) and wrap their
CompoundColorRow children in the standard
`color-block-support-panel__inner-wrapper` div, so the grid
layout, row borders, rounded corners, and overlapping swatches
all come from core CSS that was already loaded.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ividing line

Two final style-menu polish changes:

1. Compound color rows (Active tab, Inactive tab, Selected amount)
   now open into a tabbed popover instead of stacking the two
   ColorGradientControls. One tab per setting (Background / Text),
   exactly matching the standard "Button" row in the Color block-
   support panel.

   Built with TabPanel from `@wordpress/components` (the public Tabs
   component is gated behind `privateApis`, so we use the older but
   stable TabPanel which produces an equivalent UX).

2. Strip border-top / border-bottom on top-level controls inside our
   `.jp-donations-style-panel` PanelBodies. A few of the controls we
   render (notably BorderBoxControl / BorderRadiusControl / BoxControl)
   ship with their own dividers that read as a horizontal line above
   the settings — standard core panels don't show such a line.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Apply CSS in editor.scss to make individual control labels inside our
custom style panels (Tabs / Amounts / Donate button) match the look
of the standard supports-panel labels:

* Small uppercase grey labels (`text-transform: uppercase`, 11px,
  weight 499, color #757575)
* Consistent 8px gap between label and control
* All controls fill the panel width (100%)

Targets `.components-base-control__label` and the per-component label
classes used by ToggleGroupControl, BoxControl, BorderBoxControl, and
BorderControl. Width applied to the matching control wrappers.

This is a CSS-only approximation of the standard look — broad rules
that should hit most control labels in our panels. If a specific
control still doesn't match, follow-up tweaks can target it.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Wrap the popover content in
`<div className="block-editor-panel-color-gradient-settings__dropdown-content">`
the same way core does. The existing core CSS rule then sizes the
inner `.block-editor-color-gradient-control__panel` to width 260px
and padding 16px without us writing any of it.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Restructure each PanelBody so non-color settings (Appearance, Font
size, Padding, Border, Border radius, Alignment) are wrapped in
`__experimentalToolsPanelItem` inside an `__experimentalToolsPanel`.
This is the same pattern core's auto-rendered Typography / Border /
Spacing panels use, so we get for free:

* `components-grid` + `components-tools-panel` grid layout on the
  panel.
* `components-tools-panel-item` plus `first` / `last` classes on each
  item for proper visual separation.
* Standard label rendering (uppercase, weight, spacing) — no more
  hand-rolled CSS.
* Per-item kebab reset, panel-level "Reset all" via the dropdown
  menu.

Each ToolsPanelItem gets a stable `hasValue` / `onDeselect` callback
via a `useMemo` lookup, so JSX props don't recreate functions on
every render (react/jsx-no-bind).

Editor stylesheet now only forces label `color: inherit` so labels
inherit from `.interface-complementary-area` rather than the hardcoded
component grey.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Five small consistency fixes:

1. Reorder Tabs panel to Appearance → Colors → Font size → Padding by
   splitting the single "Tab settings" ToolsPanel into two — one above
   the colors panel for Appearance, one below for the dimensions.
2. Move Appearance / Font size / Padding out from under a "Tab settings"
   sub-heading. Ditto for Amounts and Donate button via the
   `.components-tools-panel-header { display: none }` rule below.
3. Title-case the compound color row labels (Active Tab, Inactive Tab,
   Tab Border, Selected Amount). Add a CSS rule to undo the standard
   `max-width: calc(100% - 44px)` clip so the full label is visible.
4. Drop the inner ToolsPanel's emotion 16px padding — the outer
   PanelBody already provides padding so the inner adds redundant
   spacing.
5. Adjust the between-section margin so the first non-title child sits
   flush with the panel title (was: every non-first child got 24px;
   now: only third+ children).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…earance

Old donation blocks created before the appearance toggle moved off
the block-style variation system have `className: "is-style-buttons"`
saved in their attributes. Once the variation registration was removed
from block.json, that className kept rendering the buttons style on
the frontend but the new Appearance toggle (which only reads
`tabsAppearance`) showed "Tabs" — so the toggle did nothing.

Add a one-time migration in `edit.js`: when `attributes.className`
contains `is-style-buttons`, set `tabsAppearance: 'buttons'` and strip
the class. The migration runs on next edit of any old block, so the
toggle starts reflecting the rendered state and switching back to
"Tabs" works.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Hide the inner ToolsPanel headers (already done via CSS in editor.scss)
and replace the per-section reset menus with a single "Reset" Button
at the bottom of each PanelBody. Each Reset clears all attributes for
that panel:

* Tabs Reset: appearance, all 5 colors, font size, padding
* Amounts Reset: 2 colors, font size, border, border radius
* Donate button Reset: font size, padding, alignment

The inner ToolsPanels still need a `resetAll` callback (it's a required
prop), but with the header hidden the dropdown menu it powers is
unreachable, so we pass a noop. Per-item kebabs are unreachable for the
same reason; their `onDeselect` handlers are kept so the API contract
stays valid.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1. Tabs > Buttons appearance: the active pill border now picks up the
   user-set Tab Border color too. Removed the buttons-style active
   border-color override in common.scss; the per-instance border-color
   rule now also targets `.donations__nav-item.is-active`.
2. In compound color rows (Active Tab, Inactive Tab, Selected Amount):
   Text comes before Background — both in the visible swatch order
   and the picker tab order in the popover.
3-4. Color section in Tabs and Amounts panels now shows a "COLORS"
   heading at the top. CSS only hides the header on non-color
   ToolsPanels, so the color panel's heading stays. A nested rule
   hides the kebab menu inside the colors header (we use the
   panel-level Reset button instead).
5. The panel-level Reset button is right-aligned via
   `.components-panel__row { justify-content: flex-end }`.
6. New Border Radius control under Padding in the Donate button
   panel. Adds `buttonBorderRadius` attribute (string|object) and
   emits `border-radius` on `.donations__donate-button` — uniform or
   per-corner via the existing `radiusDecls` / `build_radius_decls`
   helpers.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…remove BoxControl reset

Three small UX fixes:

1. BoxControl's built-in "Reset" button is now disabled on Tab Padding
   and Button Padding (`allowReset={false}`). The panel-level Reset
   button at the bottom of each PanelBody covers the same need.

2. Don't fall back to default text when a content area is left blank.
   Previously the editor and frontend filled empty heading / extraText
   / chooseAmountText / customAmountText / buttonText with the
   `DEFAULT_TEXTS` strings so something always rendered. Now both
   render whatever the user typed (including empty), matching the
   placeholder UX of the editor. Empty headings, paragraphs, and the
   "Or enter a custom amount" hint are conditionally not emitted in
   the PHP so they don't take vertical space when blank.

3. New `contentAlignment` block-level attribute (left / center /
   right). Surfaced via `AlignmentControl` in the BlockControls
   toolbar. Emits `text-align: <value>` on `.donations__content`,
   so all child text inherits. The existing button alignment still
   wins for the donate button because it sets `text-align` directly
   on `.donations__donate-button-wrapper`.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The Left/Center/Right toolbar control was applying `text-align` to
`.donations__content`, which centered text and inline content but did
nothing to the amount tiles — they live in `.donations__amounts`,
which uses `display: flex`, and `text-align` doesn't move flex items.

Now we also emit a matching `justify-content` rule on
`.donations__amounts` whenever `contentAlignment` is set:

* Left   → `text-align: left`   + `justify-content: flex-start`
* Center → `text-align: center` + `justify-content: center`
* Right  → `text-align: right`  + `justify-content: flex-end`

So picking "Center" centers everything (text + tiles) and the user
doesn't need a separate amounts-only alignment control.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…leared

Switch all the text fallbacks from `||` (which falls back when the
value is empty string) to `??` (which only falls back when the value
is `undefined`).

* New blocks: attributes are `undefined` for heading / buttonText /
  extraText / chooseAmountText / customAmountText, so the user sees
  the default text in the editor and on the frontend, like before.
* User explicitly clears a field: attribute becomes `""`, which is
  preserved through `??`, so the field renders blank — no fallback.
* User typed text: respected as before.

In `tab.js` the fallback is in the RichText `value` props (`??`) and
in the `chooseAmountText` / `customAmountText` destructure defaults
(destructure defaults only fire when the property is `undefined`).

In `donations.php` the heading / buttonText defaults are restored to
the `array_merge` first-array (which `array_merge` overrides only with
keys actually present in the user attributes), and the chooseAmount /
customAmount / extraText fallbacks use `??` for the same semantics.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@angelablake angelablake added the Enhancement Changes to an existing feature — removing, adding, or changing parts of it label May 1, 2026
@angelablake angelablake added [Focus] Blocks Issues related to the block editor, aka Gutenberg, and its extensions developed in Jetpack [Block] Donations labels May 1, 2026
@angelablake angelablake self-assigned this May 1, 2026
@github-actions

github-actions Bot commented May 1, 2026 •

Copy link
Copy Markdown
Contributor

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

  • To test on WoA, go to the Plugins menu on a WoA dev site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin (Jetpack), and enable the update/donations-frequency-amount-defaults branch.
  • To test on Simple, run the following command on your sandbox:
bin/jetpack-downloader test jetpack update/donations-frequency-amount-defaults

Interested in more tips and information?

  • In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
  • Read more about our development workflow here: PCYsg-eg0-p2
  • Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

@github-actions github-actions Bot added [Plugin] Jetpack Issues about the Jetpack plugin. https://wordpress.org/plugins/jetpack/ [Status] In Progress labels May 1, 2026
@github-actions

github-actions Bot commented May 1, 2026 •

Copy link
Copy Markdown
Contributor

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

  • ✅ Include a description of your PR changes.
  • ✅ Add a "[Status]" label (In Progress, Needs Review, ...).
  • ✅ Add testing instructions.
  • ✅ Specify whether this PR includes any changes to data or privacy.
  • ✅ Add changelog entries to affected projects

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:

  1. Ensure all required checks appearing at the bottom of this PR are passing.
  2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
  3. You can use GitHub's Reviewers functionality to request a review.
  4. When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!


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

@github-actions github-actions Bot added the [Status] Needs Author Reply We need more details from you. This label will be auto-added until the PR meets all requirements. label May 1, 2026
The `test_build_custom_styles_emits_tab_border_color` assertion was
written for the original 2-selector rule (`.donations__nav` +
`.donations__nav-item`). When the rule was widened to also cover the
buttons-appearance active pill (`.donations__nav-item.is-active`), the
test wasn't updated. Update the expected string to the 3-selector form
the function now emits.

Failing on every PHP test job in the matrix; this brings them green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@angelablake
angelablake force-pushed the update/donations-frequency-amount-defaults branch from 20a5c6a to 1c7acfa Compare May 1, 2026 16:16
@jp-launch-control

jp-launch-control Bot commented May 1, 2026 •

Copy link
Copy Markdown

Code Coverage Summary

No summary data is available for parent commit de201d3, so cannot calculate coverage changes. 😴

If that commit is a feature branch rather than a trunk commit, this is expected. Otherwise, this should be updated once coverage for de201d3 is available.

Full summary · PHP report · JS report

Angela Blake and others added 6 commits May 1, 2026 13:24
Match the existing "Show monthly donations" / "Show annual donations"
toggles with a third "Show one-time donations" toggle. The one-time
interval was previously always shown in the editor and on the
frontend, regardless of the user's intent — useful for one-off
fundraisers that only want to take recurring contributions.

* `controls.js`: add the new ToggleControl above the monthly/annual
  ones so the order matches the natural tab order. Extend the existing
  `toggleDonation` helper to know about the `one-time` interval.
* `tabs.js`: make the `one-time` entry conditional in the editor's
  tabs object, the same way monthly and yearly already are. Active
  tab fallback now picks the first still-shown interval (one-time,
  then monthly, then yearly) — extracted into a small helper so the
  branchy logic isn't repeated.
* `donations.php`: skip the one-time interval in the rendered output
  when `oneTimeDonation.show === false`. Treats `undefined` as on so
  legacy blocks (where `show` was never set on `oneTimeDonation`)
  continue rendering one-time by default.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@angelablake
angelablake force-pushed the update/donations-frequency-amount-defaults branch from 5faec6e to ee383f7 Compare May 1, 2026 18:28
@angelablake
angelablake marked this pull request as ready for review May 4, 2026 17:27
Our refactoring of donations.php resolved the existing PhanTypeMismatchArgument
suppression, so the baseline entry is no longer needed.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@angelablake
angelablake force-pushed the update/donations-block-style-options branch from de201d3 to de45083 Compare May 13, 2026 17:43
@angelablake
angelablake deleted the branch update/donations-block-style-options May 13, 2026 18:14
@github-actions github-actions Bot removed [Status] Needs Author Reply We need more details from you. This label will be auto-added until the PR meets all requirements. [Status] In Progress labels May 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

[Block] Donations Enhancement Changes to an existing feature — removing, adding, or changing parts of it [Focus] Blocks Issues related to the block editor, aka Gutenberg, and its extensions developed in Jetpack [Plugin] Jetpack Issues about the Jetpack plugin. https://wordpress.org/plugins/jetpack/

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant