Description
The Challenge
A donation form has a narrow job. It has to collect a name, an email address, a gift amount and a payment method, and it has to do that without making a donor hesitate. Yet nonprofits rarely get to stop there. A food bank wants to know whether a donor is giving in memory of someone. A school foundation needs a graduation year attached to every gift. A church wants a dropdown for designated funds. Each of those requests means a custom field, and custom fields usually mean code, a stack of add-ons, or a compromise nobody likes.
The default fields cause their own friction. First name, last name, email and payment details are non-negotiable, but the wording that surrounds them often is not. A label that reads well for a retail checkout can feel cold on a form asking someone to support a shelter. Placeholder text, tooltips and field labels shape how a donor reads the page, and editing them has traditionally required template overrides or filters buried in a theme.
Then there is the data. A custom field is only useful if the answer lands somewhere sensible. Information about the person belongs with the donor record. Information about a specific gift belongs with the donation. When fields are bolted on without that distinction, reports get messy and follow-up becomes manual work.
How Give – Visual Donation Form Builder Helps
Give – Visual Donation Form Builder brings a drag-and-drop editing interface to GiveWP donation forms. Instead of configuring a form through nested settings screens, an administrator works on the form itself, placing fields where they should appear and seeing the structure take shape. The interface resembles other form builders, but it is shaped around the needs of fundraising rather than general contact forms.
Two capabilities set it apart from a generic form plugin. First, custom fields can be added to various locations across the donation form, not just appended at the bottom. Second, each custom field can be mapped to either donor metadata or donation metadata. That mapping decides where the collected answer is stored, so a donor’s preferred pronoun can live with the donor, while a tribute message stays with the specific gift.
The third distinguishing piece is control over required fields. The default fields every donation form depends on, including first and last name, email and the relevant payment fields, are customizable. Labels can be renamed, placeholder text rewritten and tooltips added or changed. The fields keep doing their essential work, but they speak in your organization’s voice.
Behind the interface sits a larger body of work. The project involves UX and UI design, frontend and backend database development, and a substantial overhaul of the payment gateways API. That scope tells you what this plugin is: a rethinking of how GiveWP forms are built and stored, not a cosmetic layer.
A note on project status
The project’s own documentation describes this codebase as historical code from GiveWP’s journey toward a new form builder, and it carries an explicit warning that it was a work in progress and not intended for accepting live donations. Treat it accordingly. It is a good fit for studying how the builder was constructed, testing the concept on a staging site, or learning the architecture before building on it. Evaluate it in a safe environment before deciding what role it plays in your own workflow.
Core Features
- Drag-and-drop form editing: Arrange the structure of a donation form visually rather than through settings panels.
- Custom fields in multiple locations: Place additional fields in different positions across the form, so a question appears next to the content it relates to.
- Donor and donation metadata mapping: Choose whether a custom field’s data attaches to the donor or to the individual donation, keeping records organized for later reporting.
- Editable required fields: Change the labels on first name, last name, email and payment fields without disturbing how they function.
- Custom placeholder text and tooltips: Guide donors with short, specific hints written in your organization’s language.
- Nonprofit-specific design: The interface is tailored to fundraising forms instead of adapting a general-purpose builder.
- Payment gateway API overhaul: The underlying work includes a significant rework of how payment gateways connect to the form.
- Monorepo package structure: Related functionality is separated into packages inside a single repository, which allows technical differences between parts of the codebase.
- NPM workspaces: Commands can be passed to an individual package with the workspace flag, and packages are namespaced under the givewp scope.
- Separate build and watch scripts: Compile everything for the add-on and form builder, or target only the form builder, with dedicated dev and watch commands.
Built for developers who want to look inside
The setup is straightforward for anyone comfortable with a command line. Clone the repository into the plugins directory of a WordPress installation, run Composer to install PHP dependencies, then run NPM to install JavaScript dependencies. From there, the build command compiles all assets for the add-on and the form builder. A dev command handles the add-on alone, while a separate dev command for the form builder compiles only that package. Watch variants of both recompile assets as files change, which suits iterative work on the interface.
Because the plugin is distributed under the GPL, you are free to read, modify and extend it. That matters for a codebase organized as a monorepo. You can adjust one package, study how the builder handles field mapping, or adapt pieces of the approach for a project of your own, with the license guaranteeing that freedom.
Practical Applications
Memorial and tribute campaigns
A hospice charity runs an annual remembrance appeal. Donors often want to name the person they are honoring and add a short message. With a custom field mapped to donation metadata, that tribute text is tied to the specific gift rather than to the donor’s permanent profile. The next year, the same donor can honor someone different without overwriting anything.
Donor profile enrichment
A university alumni office wants graduation year and preferred contact method. Those details describe the person, so mapping the fields to donor metadata makes sense. Every future gift from that alumnus carries the same context, and the development team can segment outreach without cross-referencing spreadsheets.
Rewording the form for a specific audience
A youth sports charity writes to parents, not corporate sponsors. Renaming labels, adjusting placeholder text and adding a tooltip beside the email field to explain why it is needed lets the form sound like the rest of the organization’s communication. The required fields stay intact. Only the language changes.
Prototyping and learning
Agencies and plugin developers can use the repository to understand how a visual builder, a metadata layer and a revised gateway API fit together inside one WordPress plugin. The package structure and the separated build scripts make it practical to work on the form builder in isolation.
Frequently Asked Questions
Where does the data from a custom field end up?
You decide when you add the field. Each custom field can be mapped to either donor metadata or donation metadata. Choose donor metadata for facts about the person, such as a graduation year, and donation metadata for details about a single gift, such as a tribute message. This keeps repeat donors’ records clean while preserving gift-specific context.
Can I change the labels on the name and email fields?
Yes. The default required fields, which cover first and last name, email and the relevant payment fields, can have their labels changed. You can also edit placeholder text and add tooltips. The fields remain required and keep their function, so the form still collects what it needs to process a donation.
Is this ready to accept live donations?
The project’s own documentation describes the codebase as work in progress and advises against using it on a live site to take donations. It is best suited to staging environments, evaluation and development work. If you plan to build on it, test thoroughly, including every payment flow, before it gets anywhere near real donor money.
