Skip to content

feat(charitable): add the Charitable action layer and UI - #217

Open
RishadAlam wants to merge 5 commits into
mainfrom
feat/charitable-integration
Open

RishadAlam wants to merge 5 commits into
mainfrom
feat/charitable-integration

Conversation

@RishadAlam

Copy link
Copy Markdown
Member

Pull Request

Description

Adds the free side of the Charitable integration: the action controller, record helper and routes, plus the full action UI. The free plugin never touches Charitable itself — it builds the field data, fires one bit_integrations_charitable_* filter per action and logs the result, so the Task Log always has an entry even when Pro is absent.

Pairs with the Pro PR, which carries the handlers and the trigger.

Motivation & Context

Charitable is one of the most widely used WordPress donation plugins and had no Bit Integrations support. This is the free half: the twelve write actions and the screens that configure them.

Related Links: (if applicable)

Type of Change

  • 🐛 Bug fix
  • ✨ New feature
  • 💥 Breaking change
  • 📚 Documentation update
  • ⚡ Improvement
  • 🔄 Code refactor

Key Changes

Backend

  • Added Actions/Charitable/ — controller, record helper and routes
  • Added a twelve-case switch, one literal hook string per action, with LogHandler::save on every path
  • Added seven dropdown endpoints: campaigns, donation statuses, donors, users, campaign categories, campaign tags and user roles
  • Added the Charitable entry to AllTriggersName

Frontend

  • Added AllIntegrations/Charitable/ — authorization, action picker, field map, Utilities panel and the new and edit screens
  • Added the Charitable icon, and registration in the new, edit, info and action-picker screens
  • Added a refresh button to every Utilities dropdown backed by a backend list, so a campaign, donor, user, term or role added later appears without reopening the integration

Field map vs dropdown

  • Required target identifiers stay in the field map so they map from trigger data: donation id, campaign id, donor id, user id
  • The campaign a donation is created against, and the status an update sets, are required choices and render as dropdowns in the main layout
  • Everything optional — donor, user, creator, categories, tags, role and the yes/no switches — sits behind the Utilities checkboxes

Fixes found while testing

  • Fixed the yes/no utilities discarding a "No" choice. TableCheckBox derives its checked state from the stored value, so the falsy '0' unticked the checkbox and threw the selection away. Now stored as 'yes'/'no'
  • Fixed the missing integration icon, which left both the trigger and action pickers showing a placeholder and logging a console error

Checklist

  • Code follows project style guidelines
  • Self-review completed
  • Tests added/updated
  • Documentation updated if needed
  • README updated if needed

Testing

Verified against a live site running Charitable 1.8.12.3.

  • Actions — 57 checks, 0 failures. Each of the twelve actions runs the full path RecordApiHelperHooks::apply → Pro filter → Charitable, so the hook strings, argument counts and handler signatures are proven end to end. Includes persistence assertions and six failure guards
  • Triggers — 30 checks, 0 failures. Seeds eighteen real flow rows and runs in a fresh process so HookService actually loads the Pro trigger hooks, then fires every hook and confirms each entity stored a payload, each flow executed, and the action reported back through LogHandler

All test data removed afterwards. php-cs-fixer, prettier and eslint pass.

The React screens have not been exercised in a browser — a manual pass building one flow per action is still worth doing before release.

Changelog

  • New Actions: Charitable — Create Donation, Update Donation Status, Add Donation Note, Delete Donation, Create Campaign, Update Campaign, Delete Campaign, Create Donor, Update Donor, Create User Profile, Update User Profile, Mark User as Verified

Add the Charitable action controller, record helper and routes. The free
side never touches Charitable itself: it builds the field data, fires one
bit_integrations_charitable_* filter per action and logs the result, so
the Task Log always has an entry even when Pro is absent.

The controller also serves the dropdown lists the action UI needs —
campaigns, donation statuses, donors, users, campaign categories and tags,
and user roles.

Register Charitable in AllTriggersName so it appears in the trigger list.
Add the Charitable integration screens: the plugin-check authorization
step, the action picker with every action pro-gated, the field map and the
Utilities panel.

Required identifiers stay in the field map so they can be mapped from
trigger data — donation id, campaign id, donor id and user id. The campaign
a donation is created against and the status an update sets are required
choices, so they are dropdowns in the main layout; everything optional
(donor, user, creator, categories, tags, role, and the yes/no switches)
sits behind the Utilities checkboxes.

Register Charitable in the new, edit, info and action-picker screens.
GetLogo resolves an integration icon to resource/img/integ/<camelName>.webp,
so without charitable.webp both the trigger and action pickers fell back to
the placeholder and logged a console error. Add the icon.

The yes/no utilities stored '1' and '0'. TableCheckBox derives its checked
state from the stored value, so picking No wrote a falsy '0' and the
checkbox immediately unticked itself, discarding the choice. Store 'yes'
and 'no' instead; the Pro side already reads them through
FILTER_VALIDATE_BOOLEAN.
…owns

The Utilities dropdowns backed by a backend list only loaded once, when the
checkbox first opened the modal, so a campaign, donor, user, term or role
added afterwards never appeared without reopening the whole integration.

Give renderActionModal an optional refresh callback and render the same
reload button the main layout uses beside the select. It is wired to the
seven fetched dropdowns — donation status, donor, WordPress user (both
places), campaign creator, categories, tags and user role — and left off
the static ones (campaign status and the yes/no switches), which have
nothing to refetch.
Remove the two file docblocks that only restate the class name and the
explanation above the donation id lookup. Tooling pragmas stay: the
phpcs:ignore lines, the translators notes and the eslint-disable.
Copilot AI lite review requested due to automatic review settings September 2, 2026 09:22

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@github-actions

github-actions Bot commented Sep 2, 2026

Copy link
Copy Markdown

🔍 WordPress Plugin Check Report

⚠️ Status: Passed with warnings

📊 Report

🎯 Total Issues ❌ Errors ⚠️ Warnings
1 0 1

⚠️ Warnings (1)

📁 readme.txt (1 warning)
📍 Line 🔖 Check 💬 Message
0 mismatched_plugin_name Plugin name "Bit integrations - Form Integration, Webhook, Spreadsheets, CRM, LMS & Email Automation" is different from the name declared in plugin header "Bit Integrations".

🤖 Generated by WordPress Plugin Check Action • Learn more about Plugin Check

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants