Forum Replies Created

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Author Matt McWilliam

    (@mattmcwilliam)

    Hi Tony,

    Glad the donation history came across cleanly.

    Short answer: there is no separate campaign import, but you shouldn’t need one. The donation importer can create the campaign for you and attach every gift to it, so the thermometer starts at the right total. The one thing it can’t bring over is the goal, because that isn’t in the donation export, so that’s a single field you type in.

    The catch is that Charitable labels that column “Campaign Title”, and the importer doesn’t recognize that name on its own, so it was most likely left unmapped on your first run. A quick way to check: if 4K Camera Fund isn’t listed under Donor Merchant > Campaigns, your gifts came in without a campaign.

    To fix it:

    1. Go to Donor Merchant > Donations, select the gifts you imported from Charitable, and choose Delete from Bulk actions. Your donor records stay put.
    2. Run Donor Merchant > Import again with the same Charitable CSV. On the mapping screen, set “Campaign / form name” to the Campaign Title column, and check that the date is set to Date of Donation. Run the preview first (it writes nothing) and confirm the count matches your first import, then import for real.
    3. Go to Donor Merchant > Campaigns, edit 4K Camera Fund, and set the goal to $2,100. You can add a description and suggested amounts there too.
    4. Copy the campaign’s shortcode from the Campaigns list, for example [donor_merchant campaign=”1″], and put it on your campaign page in place of the Charitable form.

    One tip before you re-import: Charitable’s export includes a “Made in Test Mode” column that the importer doesn’t read, so any test donations in the file would count toward the thermometer. It’s worth deleting those rows from the CSV first.

    You could also just create the campaign by hand, but its thermometer would start at $0, because the total is calculated from the gifts linked to it.

    As for the future: I’ll make the importer recognize Charitable’s “Campaign Title” and “Date of Donation” columns automatically in the next update, so the next person moving from Charitable doesn’t have to map them by hand.

    Let me know how it goes.

    Plugin Author Matt McWilliam

    (@mattmcwilliam)

    Glad that helped, and thanks for saying so.

    That resource profile is exactly what Donor Merchant is built for. The whole plugin is 20 PHP files, about 7,200 lines, 97KB zipped, and only 14 of those files load on a front-end request (the admin classes never load for visitors). Combined with no idle HTTP calls, there is not much for it to fill your opcache with.

    If you do switch, one practical note so nothing surprises you. Version 2.5.0 added a CSV importer built for exactly this: export your donation history from Charitable, then go to Donor Merchant > Import, upload the CSV, and it will auto-detect the columns. Preview it first, which writes nothing, and imported gifts never send receipts, so your existing donors will not get emailed about old donations. It is also safe to run twice.

    The one thing that cannot come across is any active recurring donation. That is not a limitation of the importer: a subscription lives in your Stripe or PayPal account tied to the integration that created it, so no plugin can move one. The usual approach is to leave Charitable installed until its existing subscriptions run their course, while new gifts go through the new form. There is a full write-up here if it is useful: https://www.donormerchant.com/guides/migrate-donation-plugin-keep-donor-history/

    Happy to help if you hit anything during the switch.

    Plugin Author Matt McWilliam

    (@mattmcwilliam)

    Great question, and an easy one to answer because the plugin is deliberately quiet.

    When a page loads and nobody is donating, Donor Merchant makes no external or background server requests. The donation form and the goal thermometer render entirely from your own database. There is no AJAX polling, no heartbeat, no telemetry, and the plugin never “phones home” to us or to any analytics or licensing server. You can confirm it in the source: a search for wp_remote_ only turns up Stripe, PayPal, and the optional webhook/Mailchimp calls below.

    One clarification, since you asked precisely: on a page that actually contains the donation form, the visitor’s browser loads Stripe.js (from js.stripe.com) and/or the PayPal SDK (from paypal.com). That is required so card details are typed into the gateway’s own secure fields and never touch your server, which is what keeps you out of PCI scope. It is a browser-side script load, not a server call, and no donor or payment data leaves the browser until someone submits. On pages without a form, those scripts are not loaded at all: they are registered but only enqueued when a form is present.

    Your server only calls Stripe or PayPal when:

    • a visitor actually submits a donation;
    • Stripe or PayPal send an incoming, signature-verified webhook, which they initiate;
    • a donor clicks “manage my recurring gift” in the donor portal;
    • and, only if you have turned them on, an outgoing webhook (Zapier/Make) or a Mailchimp sync fires the moment a donation completes.

    Background/cron: the plugin registers a single WordPress cron event. On most days it does nothing; on the 1st of each month it emails the fundraising summary to your own admin address (if you leave that enabled). It makes no external request, just a local email, and WP-cron only runs when your site gets a visitor, so there is no persistent background process.

    So: idle pages are silent, and external or payment requests happen only on a real donation plus the incoming webhooks the gateways send you. Happy to point you to the exact lines if that would help.

Viewing 3 replies - 1 through 3 (of 3 total)