Give Form Field Manager - WordPress Plugin

How to Configure Give Form Field Manager for WordPress Donation Forms

Give Form Field Manager is not just for "adding one more field" to a donation form. Its real value shows up when your site collects exactly the donor information your team needs to process the gift, prepare reports, follow up after payment, or route the donation correctly within a campaign. In this guide, we will look at how to plan those fields, where to place them, how to avoid overloading the form, and how to confirm that custom data actually ends up where it needs to go.

This guide is written for site owners, WordPress administrators, nonprofit staff, and webmasters who already use GiveWP or are preparing a donation site for launch. It does not cover license purchases or activation workarounds. The focus here is practical setup for a plugin you already have: preparation, field creation, conditional display, showing data in the admin area and receipts, testing, and troubleshooting.

The core principle is simple: every extra field should have a practical purpose. If a field helps clarify the purpose of a donation, collect consent, record a T-shirt size, confirm the right contact for a thank-you call, or store an internal campaign label, it is justified. If a field is added "just in case," it can reduce form completion and make data handling harder. That is why configuring Give Form Field Manager starts not with dragging blocks around, but with a data map.

How the Plugin Fits into a GiveWP Donation Form

GiveWP structures a donation form around key steps: amount selection, donor details, payment method, confirmation, and transaction recording. Give Form Field Manager adds custom fields to that flow. These fields become part of the form and can collect extra information the standard form does not ask for. GiveWP documentation describes two important directions: blocks for the visual form builder and a field set for the older settings-based form editor. In practice, that means the interface may differ depending on which editor a specific site uses.

In modern GiveWP forms, custom fields are added as blocks inside the Visual Donation Form Builder. On older sites, some forms may still open in the options-based editor. That is not a reason to rebuild every form immediately, but before you configure anything, it is important to understand which editor a specific form was created in. Otherwise, the administrator may look for blocks in one place while the actual form has to be edited somewhere else.

The plugin works like a clean layer between the question asked to the donor and the stored data record. The administrator chooses the field type, sets the label, description, required status, and any additional options. The donor sees the field on the public-facing site. After a successful donation, the value is saved with the donation and, in some setups, can also be linked to the donor record. The plugin can also display the data in donation details, show it in the receipt, and generate an email tag based on the meta key.

This setup matters because it defines the limits of the plugin. Give Form Field Manager does not replace a payment gateway, it does not create a CRM on its own, and it does not automatically make every custom questionnaire legally safe. It solves one specific problem: collecting additional data in a GiveWP form and saving it inside the donation record structure with flexibility. Everything else, such as reporting, segmentation, consent handling, exports, or passing data into third-party services, depends on which fields you add and how you use the information afterward.

What Makes a Good Custom Field

A good field answers a question that matters at the moment of donation. For example, the donor selects a fund within a broader campaign, enters a dedication name, consents to being contacted by phone, chooses a thank-you gift for a larger donation, or uploads a file if the campaign requires documentation. A field like this is clear to the donor, has a short label, does not duplicate existing GiveWP fields, and does not ask for unnecessary personal data.

A weak field often looks harmless: "Company," "Job Title," "Comment," "How did you hear about us," or "Your wishes." Sometimes those questions really are needed. But if the team never uses the answers after the donation is received, the field only adds friction. Before adding any field, ask: who will look at this value, where will it appear, what will change in donation handling because of it, and how could the field be removed without breaking the meaning of the form?

What Data Is Better Not Collected Through a Donation Form

A donation form should not turn into a full application. Be especially careful with documents, medical information, children’s data, large file attachments, and any information that requires a separate legal process. The plugin supports many field types, including file uploads, but support for a field type does not mean it should be used without risk assessment. If the information is not required to complete the donation or the immediate next step afterward, it is safer to collect it through a separate form, email, or direct communication.

Practical rule: if the donor does not understand why you are asking for a specific item, the field either needs a clearer label, should be removed, or should only appear when it actually becomes relevant.

Who This Approach Fits and When Another Tool Makes More Sense

Give Form Field Manager is especially useful for sites where a donation involves extra choices or follow-up work by the team. That includes nonprofits with multiple programs, campaigns with donation-based gifts, memorial fundraising, church giving with gift designation, educational projects, sports clubs, volunteer initiatives, and organizations that need to store donor responses neatly alongside the donation record.

The plugin also works well for agencies and webmasters who maintain client sites built on GiveWP. In that case, it saves time: many fields can be added without custom PHP, and common options such as text, date, dropdown, radio buttons, checkboxes, email, phone, URL, file upload, HTML block, section, and repeatable fields cover most routine needs. If a single field used to require a developer, now part of that work can be handled by an administrator with access to the form editor.

That said, there are cases where Give Form Field Manager may be unnecessary. If the form only collects a standard donation with name, email, and amount, the extra layer is not needed. If the organization is building a complex application with dozens of conditions, calculations, multi-page flows, scoring, and separate payment paths, a dedicated form builder may be a better fit, while GiveWP remains focused on donations. And if the site needs to collect data that must then be processed strictly inside a CRM, it is best to verify in advance exactly how those values will reach the target system: through export, integration, custom code, or manual handling.

Typical Use Cases

Below are cases where the plugin usually provides the most value. This is not a list of required fields, but a way to think through the job before setup.

• Donation designation. The donor chooses which program their gift should support when one general campaign is not specific enough.
• Dedication or memorial donation. The form collects a person’s name, a message, and permission to display the dedication publicly.
• Gift for a donation amount. When the donation exceeds a selected threshold, the donor sees additional fields for a shirt, size, or shipping details.
• Agreement to terms. A consent field is used together with clear wording, a policy link, and a separate explanation of why it is needed.
• Internal campaign label. A hidden field stores the source or internal context when that fits the form architecture.
• Additional contact method. A phone number or second email is requested only when the team will actually use it for a thank-you message or follow-up.

Where the Plugin Does Not Replace a Separate Process

If an organization wants to screen volunteers, accept applications with file uploads, manage event registration, or collect a detailed participant questionnaire, Give Form Field Manager can only help with the simple part. It should not turn a payment form into a long registration portal. For a complex process, it is better to split the path: keep the donation short, and collect the detailed questionnaire after payment, by email, or through a separate form with its own data retention rules.

What to Check Before Installing or Changing a Form

Before installing any GiveWP add-on, do not stop at confirming that you have a ZIP file. Custom fields affect the public form, donation records, receipts, emails, and sometimes integrations. A mistake here may not stop the payment itself, but it can lead to lost data or confusing reports. Preparation should be brief, but careful.

First, make sure the core GiveWP setup is running in a supported environment. GiveWP documentation lists requirements for WordPress, jQuery, PHP, MySQL, cURL, and TLS. What matters for the administrator is the takeaway, not the table itself: the site should be on a current WordPress version, use WordPress’s bundled jQuery, run over HTTPS, and have a server environment that does not interfere with payments. If the site already has PHP errors, conflicting cache behavior, or an outdated theme, adding custom fields may simply expose those issues more clearly.

Pre-Launch Checklist

• Create a backup of the database and files before updating GiveWP, its add-ons, or the theme.
• Test the form on a site copy if it is already accepting real donations.
• Identify the form editor: visual builder or options-based editor.
• Create a field map: label, type, required status, where to store it, where to display it, and who uses the data.
• Check the payment mode and enable GiveWP test mode for controlled submissions.
• Disable aggressive optimization on donation pages if caching or minification has already caused form issues.
• Prepare a rollback plan: which fields to remove, which settings to restore, and where to confirm that older donations are unaffected.

Pay special attention to updates. GiveWP’s history includes fixes related to Form Field Manager, custom fields, and conditional logic. That is not a reason to avoid updates, but it is a reason to test the full stack of "GiveWP core + add-on + active theme + payment gateway" on a site copy. If your forms are outdated, update components step by step and test one key form after each major change.

Create a Data Map Before Adding the First Field

The most common mistake is opening the builder and adding fields as ideas come up. It is better to create a small table before you even enter the admin area. That makes it clear which fields are truly needed and which ones do not need to be asked at all.

How to plan custom fields before setup

Question	Why it is needed	Best field type	How to verify it
Where should this gift go?	The team distributes donations across programs.	Dropdown, Radio, or Checkbox depending on the number of options.	The value appears in donation details and reporting.
Would the donor like a thank-you call?	A phone number is needed only for people who agree to be called.	Radio for consent and Phone with conditional display.	The Phone field appears only after selecting "yes."
What gift size should be sent?	The gift is not available for every amount or every donor.	Dropdown for size, tied to amount and interest.	The field stays hidden for smaller amounts and is saved during testing.
May the donor’s name be shown publicly?	The team needs to respect donor privacy.	Radio or Checkbox with a clear label.	The answer moves into processing and is not confused with the billing name.

This kind of preparation only feels unnecessary until the first error happens. Once a form is already collecting donations, renaming a meta key, removing a field, or changing required status can affect reports and emails. It is better to decide in advance which fields are stable and which can be changed safely.

Installation, Activation, and the First Check

Give Form Field Manager is installed as an add-on for GiveWP. Official documentation describes installing the add-on through the GiveWP license area and also allows manual ZIP installation as a standard third-party WordPress plugin through Plugins and Add New. This guide does not cover purchasing, license keys, or accounts, but one point matters: after installation, the add-on should be active in WordPress and available inside the GiveWP form editor.

Before configuring new form logic, open a form that does not handle a critical stream of donations, or create a separate test form. This is especially important for sites where donations come in continuously. Enable GiveWP test mode and confirm that you can submit a donation without a real charge. The test transaction is not only for the gateway: it confirms that the custom field appears, validates correctly, saves correctly, and displays in the expected place.

Basic Installation Flow

1. Confirm that GiveWP Core is installed, active, and that a basic form already works.
2. Install and activate Give Form Field Manager like any standard WordPress add-on.
3. Open the target GiveWP form and make sure the editor now includes the additional Form Field Manager blocks or fields.
4. Add one simple optional field, such as a text comment for the donation.
5. Save the form and open it on the public site in a private browser window.
6. Make a test donation and review the entry in GiveWP > Donations.
7. If the field should appear in the receipt or email, verify that output specifically, not just the visible field in the form.

Do not add ten fields at once. The first validation cycle should stay small: one field, one test, one donation record. If that cycle works, you can build a more complex form. If it does not, it will be much easier to pinpoint whether the issue is in the base installation, the form editor, caching, required status, or a version mismatch between GiveWP and the add-on.

What Should Appear After Activation

In the visual form builder, custom Form Field Manager blocks should be available. In the older options-based editor, the documentation describes a separate set of field types that are added to the form and then dragged into the needed order. In both cases, after saving, the field should appear on the public form, and after a test submission the value should be visible in donation details if the relevant output setting is enabled.

Post-installation check: do not treat installation as complete until you see one test value inside the donation details. A field appearing in the editor does not yet prove that the data is being saved correctly.

Field Builder: Which Blocks to Use and Why

GiveWP documentation lists a wide range of field types. The important part is choosing them based not on the label of the field type, but on the quality of data you want to collect. The same intention can be implemented in different ways. For example, the question "How should this gift be directed?" could be built as a text field, dropdown, radio buttons, or checkboxes. But a text field will produce multiple spelling variations, while a list gives you cleaner values for later processing.

Fields for Short Responses

Text Field works well for short values: an internal number, a brief label, an organization name, a dedication line, or a participant ID. Do not use it when the donor should choose from a fixed list. Free text is easy for the donor, but hard to report on. If the team later has to sort values manually, that is a strong signal to switch the field to Dropdown or Radio.

Textarea is useful for a longer comment or message. It is easy to overestimate its value: the field looks helpful, but often creates a large amount of unstructured text that nobody reads. Use it when the message has a clear downstream purpose: it will appear in a thank-you note, be passed to the campaign coordinator, or help personalize a response.

Choice Fields

Dropdown is useful when there are many options but the donor should choose only one. It is a strong fit for fund designation, gift size, country selection inside a limited list, or participant role. Radio works better when there are only a few choices and they should be visible immediately. Checkbox fits multiple independent choices, but if the field is required, the donor must choose at least one item. The documentation also makes a separate point: if only one option should be selected, a dropdown or radio buttons are usually a better fit.

Multi Select is useful for multiple choices, but it needs careful handling. For donors, multi-select can be less obvious than a set of checkboxes. If the list is short, checkboxes are often clearer. If the list is long, multi-select saves space, but make sure to add a description so the donor understands that more than one item can be selected.

Contact Fields and Format Validation

Email, Phone, and URL differ from plain text because they help collect values in an expected format. The documentation notes that the email field accepts a valid email address, the URL field validates a domain name, and the phone field can support either formatted or unformatted input. These field types are worth using when the team truly needs an additional contact method or link. If the donor’s primary email is already part of the standard form, a second email should only be added for a specific use case.

Phone works best as a conditional field: first ask whether the donor agrees to be contacted by phone, then reveal the field. That keeps the form shorter for most users while giving the team a number only when needed. This is one of the clearest use cases for conditional logic.

Date, File, HTML, Section, and Hidden Field

Date is a good fit for dates related to an event, dedication, delivery, or visit. The documentation mentions date formats and optional time support. What matters here is context: do not ask for a date without explaining what it represents and who will use it.

File Upload allows the donor to upload a file that is then stored in the Media Library and visible in the donation’s custom data. This is a powerful field, but it needs caution. The documentation explicitly reminds you to account for file storage and bandwidth if multiple uploads or large files are allowed. Most donation forms do not need a file field. If yours does, restrict file types and size, explain the purpose, and verify access permissions for uploaded materials.

HTML and Section help explain form sections. They should be used for context and navigation, not as a place for long legal copy. If the donor sees half a screen of text right before payment, they may stop. It is better to give a short explanation and link to a separate page with the full policy.

Hidden Field is not visible to the donor, but it can store internal information. That is useful for an internal label, source, campaign variant, or any value that will be processed after the donation. But a hidden field is not protection against data tampering: any value that comes from the browser should still be treated as user input. Use hidden fields for processing convenience, not for security-critical decisions.

Repeatable Fields and the Point Where They Become Too Much

Repeat Field is useful when a donor may need to add several similar entries: names for dedications, participants, thank-you recipients, a list of items, or multiple option values. But repeatable fields can make a form grow quickly. If the donor has to complete many repeated rows, it may be better to collect that information after payment. Inside a donation form, a repeatable block only makes sense when the donation cannot be processed correctly without it.

Conditional Logic: Show Only the Questions That Matter

Conditional display is one of the main reasons to use Give Form Field Manager instead of a set of static fields. GiveWP’s official article on conditional fields explains the basic idea: a field can be shown or hidden based on the value of another field. This is especially useful in donation forms, where different people should move through different short paths. A donor who does not want a gift should not see a T-shirt size field. A donor who selects "Other" should get a follow-up field for clarification. A donor making a larger gift may see an extra thank-you option.

The documentation describes two ways to define a condition. The first is selecting an existing field when it is available in the interface. The second is entering a field name and value manually. That approach is needed when the condition depends on a field that does not appear in the simple selector list. For example, GiveWP shows conditions based on the donation amount using the name give-amount, as well as examples for fee recovery and payment mode. That is already a more advanced setup and is best verified with browser inspection and a full test submission.

When Conditional Logic Improves the Experience

Conditional logic is useful not when you want to make the form "smart," but when it shortens the path for most donors. A good example is the question "Would you like a coordinator to contact you?" If the answer is "no," the phone field stays hidden. If the answer is "yes," the Phone field appears. Another example is a gift size field that appears only after the donor chooses an amount above a threshold and agrees to receive the gift. A third is a text clarification field that appears only when "Other" is selected.

This kind of logic improves the form for two reasons at once. First, the donor sees fewer unnecessary fields. Second, the team gets cleaner data. An "Other" choice without clarification produces an unusable answer, while an additional text field makes the selection actionable. But it is important not to build chains of conditions that are too deep. Once the form starts behaving like a branched questionnaire with several levels, it becomes harder to test and maintain.

The "Amount -> Gift -> Size" Pattern

GiveWP’s official example of a donation gift shows the mechanics well. First, the condition checks the donation amount. If the amount is at or above the required threshold, the donor sees a gift question. If they choose "yes," a size field appears. As a result, the form does not ask for size or shipping details from people who are not part of that flow.

For an English-language site, you can adapt that chain like this:

1. Create a gift question field, for example "Would you like to receive a thank-you package?"
2. Set that field to appear based on the donation amount or selected giving level, if that logic is available in your form.
3. Add a Dropdown for size or gift variant.
4. Set the gift field to appear only when the answer to the previous question is "yes."
5. Run tests for an amount below the threshold, an amount above the threshold with "no," and an amount above the threshold with "yes."

Pay close attention to required status. GiveWP documentation highlights an important detail: a required field is only required when it is visible. If a field is hidden by a condition, the form can be submitted without it. That makes sense from the form’s point of view, but it is risky if your team assumed the field would always be required. Do not hide a required field if missing data would break donation processing.

Manual Field Name Entry

Manual field name entry is needed when a condition depends not on a simple custom field, but on another form element. This gives you flexibility, but it requires care. You need to open the form on the public site, use browser developer tools, find the correct name attribute, and copy it into the condition settings. A one-character mistake can cause the field to never appear or appear at the wrong time.

Quick check: if a conditional field is not appearing, start by checking the field name and expected value. Do not begin with reinstalling the plugin until you have ruled out a condition error.

Where Responses Are Stored and How to Keep Their Meaning Intact

Custom fields are useless if nobody can find the answers after the donation. GiveWP documentation describes several storage and display points: a field can appear in donation details in the admin area, show up in the receipt after a successful donation, be used through an email tag, and also be saved to the donor record if the relevant setting is enabled. This is one of the most important parts of setup, because this is where the form stops being a nice interface and becomes part of the team’s actual workflow.

By default, custom values are associated with the donation record. That makes sense: the response belongs to a specific transaction. For example, a donation designation or T-shirt size applies to one donation, not to the donor’s entire history. But sometimes a value describes the person rather than the payment: an extra contact method, a communication preference, or an internal donor category. In those cases, saving to the donor record may be worth considering if that option is available for the field and aligns with your data policy.

Display in Admin

The Display in Admin setting makes the value visible inside donation details. This is useful for a team that handles responses manually. For example, a coordinator opens a donation record and immediately sees whether a call is needed, which option was selected, and whether a comment was left. If a field should affect internal handling, this display option is usually worth enabling.

The check is simple: make a test donation, open GiveWP > Donations, go into the specific record, and find the custom fields section. If the value is not visible, verify that admin display is enabled, that the field was saved in the form itself, and that the test submission was not made before the latest version of the form was published.

Display in Receipt

Display in Receipt shows the value in the receipt the donor sees after a successful donation. This is not appropriate for every piece of data. Donation designation, a public dedication, or a selected gift may be helpful in the receipt. An internal campaign label, department code, or hidden traffic source should not be shown to the donor if it has no user-facing meaning.

A WordPress forum thread mentioned a symptom where meta keys appeared in the receipt instead of custom data. The public thread does not reveal the final fix because the add-on is premium, but the symptom is still useful for troubleshooting: if the receipt displays a technical key, you should review the meta key, email tag, field display settings, the versions of GiveWP and the add-on, and then contact priority support if the issue still happens on a current setup.

Meta Key and Email Tag

The meta key is the name under which the value is stored in the database. The documentation explains that it is generated automatically from the field label, but it can be changed. The email tag is created from the meta key and lets you output the value in GiveWP emails. That is why renaming a field and changing its meta key should be done carefully. The label can be adjusted to make the field clearer for donors, but the meta key is best stabilized after launch so that reports and emails do not break after a rename.

If a field needs to appear in email, work step by step: create the field and lock in the meta key, then verify the automatic email tag, then add the tag to the email template, and only after that run a test donation. Do not change the label, meta key, and email template all at once. Otherwise, if something breaks, it will be hard to see where the chain failed.

Save to Donor Record

The Save to Donor Record setting is not always needed. It fits data that describes the donor over time. For example, a preferred contact method may belong to the person rather than to one payment. But a T-shirt size for a single campaign, a memorial message, or a selected gift option is better stored with the donation itself. If everything is pushed into the donor record, the profile becomes noisy and it gets harder to tell which data is still relevant.

It helps to divide data into three groups: "for one transaction," "for long-term donor work," and "internal technical label." The donation record is right for the first group. The donor record may make sense for the second. For the third, you should also verify that the hidden value will not end up in a receipt, email, or export where the wrong person might see it.

Detailed Setup After Installation: From the First Field to a Stable Form

After installation, the administrator’s job is not just to add a set of fields, but to bring the form to a stable state: the fields are clear, the conditions work, values are saved, emails do not break, and the data does not overwhelm the team. You can use this section as a step-by-step Give Form Field Manager setup guide for your first live form.

Step 1. Pick One Form and One Use Case

Start with a form that genuinely needs custom fields. For example, you may have a campaign called "Help for Families," and the team wants to know how the donor wants the gift used: food, medicine, or urgent aid. Do not change every form on the site at the same time. Each campaign may have its own context, and fields that are useful on one form may be unnecessary on another.

Open the form in the GiveWP editor. If the form was built in the Visual Donation Form Builder, add Form Field Manager blocks in the right place in the form. If the options-based editor is being used, work with the field set in that interface and drag fields into the proper order. In both cases, save the form after every meaningful change.

Step 2. Add Fields from Simple to Complex

Start with a field that does not depend on any conditions. For example, a Dropdown labeled "Where should your donation go?" Prepare three to five clear options. Avoid long option labels, because they do not display well on mobile forms or in reports. If the options need explanation, add a short description before the field or use Section to group them.

Next, add a field that requires format validation: Phone, Email, URL, or Date. Treat the placeholder only as a hint, not the only source of meaning. The donor should still understand the field even after the placeholder disappears during input. Turn on required status only where the promised action cannot be completed without that value.

Step 3. Configure Admin and Receipt Display

For each field, decide where it should appear. If the value is needed by a coordinator, enable Display in Admin. If the donor should see a confirmation of their selection, enable Display in Receipt. If the value is strictly internal, do not show it in the receipt. If the value needs to appear in email, verify both the email tag and the email setup.

Do not enable display "everywhere" just to be safe. That creates noise. For example, an internal department selection may help the administrator but mean nothing to the donor. On the other hand, agreement to terms may be important to show in the receipt so the donor can see what they agreed to.

Step 4. Add Conditional Logic

Add conditions only after the base fields are already saving correctly. First test the field in a static state, then make it conditional. For simple conditions, use an existing field as the source. For more advanced conditions based on system fields, verify the field name carefully with browser tools. For amount-based logic, test several values: below the threshold, exactly at the threshold, and above the threshold.

If the field is required, check two states: visible and hidden. When visible, the form should require a value. When hidden, the form should submit without it if that behavior makes sense. This matters especially in chains where one field depends on another. For example, a gift size should be required only for a donor who chose the gift.

Step 5. Document the Meta Keys

Once the form is ready, write down the meta key for each field in the project’s working document. This does not require a complex documentation system; a simple table with the field label, type, meta key, purpose, and display location is enough. A month later, that table will help you understand why a specific tag is used in an email, which values can be exported, and which fields should not be renamed without testing.

Required step before launch: make a test donation after the final form save and verify the public form, the donation record, the receipt, and the email. Reviewing the form editor alone is not enough.

Practical Example: A Donation Form with Program Selection and a Gift for Larger Donations

Let’s walk through a concrete use case. An organization is collecting donations for three purposes: food, medicine, and urgent aid. For larger donations, the team is willing to send a thank-you package, but only to donors who want one. The form needs to collect the donation purpose, consent to receive the gift, and the gift size, without burdening every donor with unnecessary questions.

Goal

Create a short form where every donor chooses the donation purpose, while additional questions about a thank-you package appear only in the relevant use case. After a test donation, the team should be able to see all responses in the donation record and, if needed, in the receipt.

Preparation

Before setup, GiveWP and Give Form Field Manager should both be active. The form should open in the GiveWP editor. Test mode should be enabled so you can complete the full path without a real payment. The team should decide in advance which donation amounts qualify for a gift, which sizes are available, and whether a physical gift will be sent at all. If the gift requires a shipping address, do not add address fields immediately: first make sure you already have a separate process for delivery and address storage.

Setup Steps

1. Open the relevant GiveWP form and add a Dropdown field labeled "Where should your donation go?"
2. Add the options: "Food," "Medicine," and "Urgent Aid." Make the field required if that designation is truly needed for every transaction.
3. Enable admin display for this field so the coordinator can see the selection in the donation record.
4. Add a Radio field with the question "Would you like to receive a thank-you package?" The options are "Yes" and "No."
5. Set the gift question to appear conditionally based on the donation amount or giving level, if that connection is available in your form.
6. Add a Dropdown field with gift size or T-shirt size options. Show it only when the donor chooses "Yes."
7. Save the form and open it on the public site.

Verification

Run three tests. First, use an amount below the threshold: the gift question should not appear. Second, use an amount above the threshold and answer "No": the size field should not appear, and the donation should submit without a size. Third, use an amount above the threshold and answer "Yes": the size field should appear, and if it is required, the form should enforce a selection.

After each test, open the donation record in the admin area. Confirm that the selected program is saved and that gift-related data appears only on the appropriate transactions. If the field is shown in the receipt, open the receipt and confirm that the donor sees a human-readable label rather than a technical meta key. If email is involved, check the email tag in an actual test email or in your mail log.

The Most Common Friction Point

The most common failure in this setup is that the condition is tied to the wrong value. For example, the administrator enters "Yes," but the field actually stores "yes" or some other value. The second common issue is using the wrong field name in the amount-based condition. When entering a name manually, verify the name attribute on the public form. If you are unsure, first build a condition based on an existing Form Field Manager radio or dropdown field, where the stored values are visible in the interface, and only then move on to a manual field name.

Verifying the Outcome: What to Check After a Test Donation

Verification should cover the whole chain, not just the appearance of the form. A custom field goes through several stages: display, input, required validation, submission, saving, admin display, receipt display, email display, and export or integration. If one stage breaks, the form may look fine while the team still does not get the needed outcome.

Public-Facing Form

Open the form as a regular donor would. A private browser window is best so the administrator login does not affect the test. Check the field order, labels, hints, required markers, conditional fields, and mobile-width behavior. If a theme or page builder is involved, make sure spacing does not break and that long option labels do not turn into a hard-to-read block.

Do not forget the error state. Leave a required field empty and submit the form. The message should be understandable. If it appears in English on a non-English site, decide whether it needs translation through the standard GiveWP or WordPress translation workflow. Do not edit plugin files directly, because those changes will disappear after an update.

Donation Record in the Admin Area

After the test submission, open the specific donation record. Check the custom fields section. It is important to verify not only that the value exists, but also that the label is correct. If the field is displayed under an internal key, the coordinator will have trouble understanding it. If the value is empty, go back and review required status, conditional display, and save behavior.

If the value can be edited inside the custom fields metabox, test saving an update with the update button. This is useful when the team corrects a donor typo or adds information manually after an offline conversation. For manual donations, the documentation notes that Form Field Manager data may not be added on the initial manual transaction screen, but in the transaction details after the donation has been created. That detail is worth documenting for the team if they enter donations manually.

Receipt and Email

If the field should be visible to the donor, check the receipt after a successful test. If the field is needed in email, check the email. Here it is important not to confuse two separate tasks: Display in Receipt controls the receipt, while the email tag controls email. Make sure the email shows the value itself, not an empty spot or a technical tag.

For borderline fields, make the decision intentionally. For example, agreement to terms may be useful to include in the receipt. An internal campaign source is not. Gift size probably should be shown if the donor needs confirmation of the choice. An internal coordinator comment should not be shown if it is not part of public communication.

Export and Reporting

If the team plans to export data, test exports after several trial donations. Do not rely on a single value. Create a small set: an empty optional field, a selected dropdown, several checkboxes, a conditional field in its visible state, and a conditional field in its hidden state. That will show you how the values actually appear in tabular data and whether they are easy to filter.

If the data needs to move into a CRM, such as Salesforce or another system, use the meta key as the stable technical reference point. Official documentation on sending custom data to Salesforce explains that the GiveWP form’s meta key is used to retrieve the value on the GiveWP side. That confirms the broader rule: meta keys should be fixed and should not be changed without checking all connected reports and integrations.

Practical Ways to Use the Plugin Without Overloading the Form

Extra fields are easy to add, but keeping the form short is harder. Below are ideas that usually provide real value in donation use cases. Each one has a limit: when it helps and when it is better not to use it.

Consent with a Short Explanatory Block

For consent, it works well to pair a short explanatory HTML block or text block with a consent-style field or checkbox. On the WordPress forum, GiveWP support specifically noted that Form Field Manager can be used to add custom fields, including linked checkboxes, as well as a separate explanatory block. The practical benefit is that you do not bury an important condition inside a long paragraph. The donor sees a brief explanation, a policy link, and a separate confirmation field.

The limit here is simple: do not turn the form into legal counseling. If the consent relates to personal data or email communications, the wording should be reviewed by the person responsible for policy documentation. The plugin lets you configure the field, but the meaning of the text and the data retention policy remain the site’s responsibility.

Clarifying the "Other" Option

The "Other" option is often needed, but without clarification it is almost useless. The solution is to create a Dropdown or Radio with fixed options and a separate text field that appears only when "Other" is selected. That way, the donor does not see an extra question unnecessarily, and the team gets an explanation only where it is actually needed.

To test it, select a standard option and make sure the clarification stays hidden. Then choose "Other," fill in the clarification, and review the donation record. If the clarification is required, it should only be required when visible.

Gift, Delivery, and Being Careful with Addresses

Donation-based gifts can motivate some donors, but they also add operational work. Before asking for size or address, confirm that the organization is truly prepared to send the gift. If shipping is not confirmed, it may be enough to ask whether the donor wants a thank-you email or call. If shipping is confirmed, address fields should only appear for donors who actually selected the gift.

Do not collect an address "for future use." An address is sensitive operational data: it should be stored for a limited time, shared only with the people handling shipment, and deleted or archived under internal rules. Give Form Field Manager helps you collect the value, but it does not remove the team’s responsibility for data handling policy.

Hidden Source Label

A hidden field can store the form source, campaign code, or internal context. This is useful when the same form is used in multiple places or when the team wants to distinguish page variants. But hidden fields should not control financial decisions or access rights. Their value can come from the browser, so any critical validation must happen inside trusted site logic or the payment system.

For a simple site, the safest use of hidden fields is as supporting labels for reporting. After a test donation, confirm that the value is saved but not shown in the receipt if the donor does not need to see it.

How It Works with Other GiveWP and WordPress Features

Give Form Field Manager rarely works in isolation. Custom fields affect the form, but the data then needs to be checked, displayed, sent, exported, or used by the team. Below are combinations that make practical sense without claiming a formal integration unless the source explicitly confirms one.

Test Mode as a Safe Lab

GiveWP Test Mode lets you complete a donation without an actual charge. For Form Field Manager, this is the best way to verify new fields before launch. Turn on test mode, configure the payment gateway for testing, submit several versions of the form, and review the resulting records. If the form contains conditional logic, one test is not enough to prove it works. You need at least a successful path, a path without the conditional field, and a path that triggers a required-field error.

After testing, make sure you can distinguish test donations from live ones. GiveWP documentation describes tools for viewing test donations and deleting test transactions. Do not delete live data along with test data: review the selected option carefully before cleanup.

GiveWP Emails and Email Tags

If a custom field needs to appear in an email, use the email tag generated from the meta key. This works especially well in admin notifications: for example, the email can immediately show the selected program, the donor’s call preference, or the chosen gift size. In donor emails, display only the values that help the donor confirm their choices. Internal labels, technical values, and administrative codes should stay in the admin area.

The practical order is this: create the field, save the meta key, verify the email tag, add it to the appropriate email template, make a test donation, and review the actual message. If the email does not arrive, troubleshoot email separately, because the problem may be WordPress mail delivery rather than Form Field Manager.

Export and CRM

For reporting, predictable values matter. That is why reporting fields are usually better as lists or radio buttons rather than free text. If the organization sends data into Salesforce or another CRM, the meta key becomes the technical bridge between the form and the external field. Any integration should be tested on a site copy, and when there is uncertainty, the safest move is to rely on GiveWP documentation and the documentation for the target service.

This is not the place to promise automatic compatibility with every CRM. The accurate statement is that custom field data can be used in downstream processing if the selected integration path can read those values. For some sites, a CSV export is enough; for others, a code-based bridge or paid integration is required.

Cache, Theme, and Visual Builder

Form fields run on the public site, so they can be affected by the theme, JavaScript optimization, caching, and page builders. If conditional fields do not respond, the form does not submit, or the button behaves oddly, do not jump straight into changing Form Field Manager settings. First test the form without optimization, in test mode, on a default theme, or in a safe diagnostic setup. GiveWP documentation includes general resources on cache behavior, custom CSS, and WordPress diagnostics that are especially useful for these conflicts.

For appearance changes, use standard WordPress and GiveWP methods. Do not edit plugin files. If you need a small CSS adjustment, add it through a custom CSS tool, a child theme, or a safe code snippets plugin. But before writing CSS, inspect the actual classes on your form in the browser, because the structure may vary between GiveWP templates and form versions.

Form Models for Different Donation Campaigns

The same field set can work very differently across campaigns. That is why it helps to choose a form model before launch: a short mass-donation form, a designation-driven form, a thank-you gift form, or a form designed for internal reporting. Give Form Field Manager gives you tools for all of these, but the quality of the outcome depends on how precisely you limit the questions.

Short Form for Broad Campaigns

For a broad fundraising campaign, the goal is not to collect as much information as possible, but to move the donor to the donation quickly. In this model, one extra field is often enough if it truly helps the campaign. For example, a dropdown for donation purpose or a consent checkbox with a separate condition. Everything else is better moved after payment: a thank-you email, a separate survey, a signup form, or manual follow-up.

Testing this model is straightforward: the donor should not feel like they are filling out an application. If the form asks for a phone number, comment, job title, organization, referral source, and marketing consent, it is no longer a short form. Even if each field "might be useful," together they work against the main goal. In a broad campaign, Give Form Field Manager is best used as a precise instrument, not as an excuse to expand the form.

Donation Designation Form

When an organization has multiple programs, the designation field may become central. The best field type depends on the number of options. For two or three choices, Radio works well because the donor can see all options immediately. For a longer list, Dropdown is usually better. If the donor may choose more than one option, use Checkbox or Multi Select, but decide in advance how the team will divide the donation amount across those choices. The plugin can save the selection, but it should not replace the financial rules behind allocation.

In a form like this, enabling Display in Admin is often helpful so the coordinator sees the designation directly in the donation record. Display in the receipt is often justified as well, because it confirms to the donor that they selected the intended option. But if the designation is only used as an internal page classification, the receipt display may not be necessary.

Form with a Thank-You Gift

A gift-based flow requires more conditions. It is not enough to ask for a size or address; those questions should appear only when they are actually needed. First comes the condition based on donation amount or giving level, then the question about whether the donor wants the gift, then the gift size or variant, and only after that any shipping details. This order keeps the form from filling up with unnecessary fields and reduces the amount of unused personal data collected.

Verify separately that the team is actually prepared to act on the answers. If the administrator can see the gift size but not the contact details or delivery method, the process will break. If an address is collected but there is no rule for storing and deleting addresses, the flow should not go live. The plugin helps you ask the questions, but the operational process has to be ready before publication.

Form for Manual Processing and Offline Donors

Some organizations enter donations manually, for example after a cash contribution, bank transfer, or event. In that setup, custom fields help keep the context attached to the transaction. The manual donations documentation notes an important detail: Form Field Manager data can be added in the transaction details after the donation has been created. This is useful when an operator first records the donation and then enriches the entry with a designation, comment, or internal label.

For this model, create an internal staff guide. It should answer three questions: which fields are always filled, which are filled only when data is available, and which must not be changed after confirmation. If several people edit records, a consistent process matters more than a complex form. Otherwise, the same information will end up inconsistently in a comment, a dropdown, or a donor note, and reporting will become difficult.

Form for Campaigns with Public Recognition

If the campaign displays donor names, dedications, or thank-you messages, custom fields need to respect privacy. Ask separately whether the donor’s name may be shown publicly, and do not automatically tie that answer to the billing name. A donor may pay under their own name but want to be published as "anonymous" or dedicate the gift differently. In that case, a radio or checkbox for public display and a textarea for a short dedication message are a better fit, assuming the text will actually be reviewed before publication.

Testing this model should cover more than the form itself. If the data is published anywhere on the site, make sure the team reviews the text manually before publishing and that the field is not rendered automatically without moderation. Form Field Manager collects the value, but the decision to show it publicly has to account for both editorial and legal context.

Troubleshooting Common Issues

Problems with Give Form Field Manager usually do not happen because "the whole form is broken." More often, one part of the chain is configured incorrectly: the field was added in the wrong place, the condition is listening for the wrong value, required status conflicts with a hidden field, the meta key changed, cache is interfering with JavaScript, or the core plugin and add-on versions are out of sync. Below is a practical troubleshooting map.

The Field Does Not Appear on the Form

Symptom: the field exists in the editor, but the donor does not see it on the site. Possible causes include an unsaved form, editing the wrong form, cache showing an older page version, the field being hidden by conditional logic, or the current form template not supporting the expected output.

What to check: open the public form in a private window, clear page cache, confirm that the correct form is embedded, temporarily disable conditional logic for that field, and save the form again. If the field appears after the condition is removed, the issue is in the condition, not in the plugin installation.

How to fix it: rebuild the condition step by step. Start with a simple condition based on another Form Field Manager field, then move to a more advanced condition based on a manually entered field name. If the site uses JavaScript optimization, temporarily exclude the donation page from aggressive optimization and repeat the test.

A Conditional Field Appears at the Wrong Time

Symptom: the field shows for everyone, for no one, or only on the wrong choice. The cause is usually an incorrect condition value. With manual field names, the issue may be an error in the name attribute. With list-based selection, there may be a mismatch between the visible label and the actual saved value.

What to check: run three tests: a value that should show the field, a value that should hide it, and an empty value. If the condition depends on donation amount, test below the threshold, exactly at the threshold, and above the threshold. If the condition depends on a checkbox, verify which value it submits when enabled.

How to fix it: simplify the condition to one source and one value. Do not chain multiple conditions together until the base behavior is confirmed. If the manual field name seems unreliable, temporarily replace it with a condition based on a created dropdown or radio field, where the stored values are easier to control.

The Form Will Not Submit Because of a Hidden Required Field

Symptom: the donor cannot see the required field, but the form will not submit or shows a confusing error. GiveWP documentation states that a required field should only be required when visible. If the behavior differs, the most likely places to investigate are whether the field is still technically visible, whether the theme conflicts with the logic, or whether cache is interfering.

What to check: open the form without cache, inspect the DOM in browser tools, and confirm that the hidden field is actually hidden by logic rather than merely hidden by CSS. Then temporarily make the field optional and repeat the test.

How to fix it: do not hide critically required fields behind complex conditions. If a value is always needed, show the field to everyone. If it is needed only for part of the donor base, required status should only apply to that branch, and the logic must be tested across multiple paths.

The Value Appears in the Form but Is Not Saved with the Donation

Symptom: the donor fills out the field, the payment succeeds, but the value is missing from the donation details. Possible causes include forgetting to save the field after editing, testing the wrong form, admin display being disabled, the field depending on a condition and therefore not actually being submitted, or a version conflict between GiveWP, the add-on, and the theme.

What to check: first confirm that the field is enabled for admin display, then repeat the test using a simple optional field with no conditions. If the simple field saves correctly, the problem is in the specific configuration. If no field saves, review component versions, WordPress logs, and possible conflicts.

How to fix it: rebuild the chain starting from a minimal field. Update GiveWP and the add-on together if you are using an outdated combination. If the issue still happens on a current version and without conflicts, contact GiveWP support, because premium add-ons are not usually diagnosed in depth on the public WordPress forum.

The Receipt Shows a Meta Key Instead of the Value

Symptom: the donor sees a technical string such as a meta key or email tag instead of a human-readable value. A similar user report has appeared on the WordPress forum. The exact cause was not disclosed publicly, but the verification order still matters.

What to check: make sure the field still exists, that the meta key was not changed after the tag was added to the email or receipt, that receipt display is enabled, and that the test donation was created after the most recent form save. Also check whether the problem appears only for new fields or for older ones as well.

How to fix it: remove the technical tag from the email or receipt, copy the current email tag again from the field settings, and create a new test donation. If the receipt still shows the meta key, record the GiveWP and Give Form Field Manager versions, capture a screenshot of the field settings, and send that information to support.

A Critical Error or Memory Exhaustion Appears After an Update

Symptom: WordPress reports a technical problem, and the message references the add-on file or exhausted memory. Public forum posts have mentioned critical errors after updating GiveWP components and memory exhaustion in the context of Form Field Manager. Because the add-on is premium, public replies often redirect users to priority support.

What to check: verify that GiveWP Core and Form Field Manager were updated together, that PHP memory is sufficient, that an older add-on version is not being used with a newer core, and that conflicting optimization plugins are not active. If the site is down, use the standard safe WordPress recovery path through a backup or plugin deactivation via hosting tools.

How to fix it: do not update a live site without a copy and a rollback plan. If the error appeared after an update, restore the working state from backup or apply an official maintenance release once it is available. Do not try to patch add-on files manually.

The Data Exists in the Admin Area but the Team Cannot Use It in Reports

Symptom: custom responses are saved, but they are difficult to use in exports because of inconsistent spelling, empty values, unclear keys, or mixed variants. The cause is often editorial rather than technical: a free-text field was used where a fixed list should have been used instead.

What to check: review 10 to 20 test or live records and decide whether the values can be filtered without manual cleanup. Check which fields are required, which are conditional, and which could be replaced with a fixed-choice field.

How to fix it: for reporting fields, use Dropdown, Radio, or Checkbox. Leave free text for comments that a person will actually read. Keep meta keys documented in a working table so exports and integrations do not depend on accidental renames.

Limits You Should Accept Up Front

Give Form Field Manager makes the form more flexible, but it does not override the core principles of a good donation form. The more questions you ask, the greater the chance that a donor will postpone the payment. The more conditions you add, the harder testing becomes. The more sensitive the data, the more carefully you need to define storage and access rules. That is why the best configurations are not the most elaborate ones, but the ones that collect the minimum necessary information and give the team a clear outcome.

Not Every Field Should Be Required

Required status should be enabled only when the absence of a value interferes with donation handling. A designation choice may need to be required if funds are truly allocated based on that selection. A comment, phone number, public dedication, or gift preference is often better left optional or conditional. Required fields improve data quality, but they also add friction. There is no universal right answer here: use practical need as the deciding factor.

Not Every Value Should Be Shown to the Donor

Receipt display is helpful for confirming a choice, but the receipt should not turn into a technical report. Show the donor things they can recognize and verify: designation, gift, consent, dedication. Do not show internal values, hidden sources, or internal codes. If you are unsure, enable admin display but leave receipt display off.

Not Every Problem Should Be Solved with Code

GiveWP has developer documentation and supports code-based extensions, but for most tasks Form Field Manager exists precisely so you do not need custom development. If you need a phone field, consent checkbox, designation choice, or conditional gift flow, start with the plugin settings. Code snippets only make sense where the documentation confirms the mechanism you need and the team can safely test and roll back changes. For a typical administrator, working through fields, conditions, email tags, exports, and standard settings is the safer path.

How Give Form Field Manager Affects Speed, SEO, and Security

Custom fields are not an SEO tool. They should not be used to "improve indexing" on a donation page. Any SEO impact is indirect: the form becomes clearer, the donation flow becomes shorter, and the page does a better job of helping the user complete their goal. Search value comes not from the number of fields, but from the quality of the campaign page, transparent messaging, fast loading, and trust in the donation process.

Performance depends on the number of fields, the form template, the theme, the payment gateway, third-party scripts, and cache behavior. A single dropdown or checkbox is almost never the main bottleneck. But a large set of conditional fields, file uploads, a heavy page builder, and aggressive JavaScript optimization can cause problems. So do not evaluate site performance in the abstract; test the specific form: page load, condition behavior, test donation submission, and mobile-width operation.

Security of User Input

Any field filled out by the donor is user input. Even if a field looks as harmless as a comment, it still needs to be treated as data that requires proper storage, output handling, and access control. GiveWP and WordPress handle much of the processing, but the administrator is responsible for deciding what data is collected, who can access donation records, which files are allowed to be uploaded, and where the values are displayed.

Be especially careful with File Upload, HTML, and hidden fields. A file may be large or sensitive. An HTML block may contain markup that changes how the form is perceived. A hidden field is not a reliable protection mechanism. For a public form, the safest approach is to collect the minimum necessary data and enable additional fields only when there is a clear use case.

Compatibility with Themes and Optimization

If the form is embedded in a page builder layout or a heavily styled theme, check spacing, width, labels, and error messages. A donation form is a critical part of the site, so it should not be optimized blindly. If a caching plugin combines scripts or defers execution, conditional fields may stop responding. For a donation page, it is often more sensible to exclude it from the most aggressive optimization rules than to chase a separate issue in every custom field.

From an accessibility perspective, clear labels and descriptions matter. A placeholder does not replace a label. Radio buttons and checkboxes should have understandable text, and required fields should have an obvious purpose. If a donor is using a keyboard or screen reader, the form should still feel consistent. Conditional logic should not suddenly change the page in a way that causes the user to lose context.

Questions About Setup and Limitations

Can I add fields without code?

Yes. That is the main purpose of Give Form Field Manager: adding custom fields through the form interface. For standard use cases such as text, selections, checkboxes, phone, date, consent, HTML explanations, files, or repeatable blocks, code is usually unnecessary. Consider code only for custom logic that cannot be built through settings.

Why is the custom field not visible in the receipt?

Check whether receipt display is enabled for that field through Display in Receipt. Then create a new test donation after saving the form. If the receipt shows a technical key or an empty space, review the meta key, email tag, and component versions.

Should I save a custom field to the donor record?

Only if the value describes the donor over time. A preferred contact method may belong in the donor record. A gift size, the purpose of a specific donation, or a comment tied to a single transaction is usually better stored with the donation record. Otherwise, the donor profile becomes noisy very quickly.

Can conditional logic be based on the donation amount?

Yes. GiveWP’s official materials include examples of conditional display by amount using the field name give-amount. This is an advanced setup, so verify the field name, the expected value, and several different test amounts. If your form uses a different template or editor, do not copy the example blindly.

What should I do if the form stops working after an update?

First, check whether GiveWP Core and Form Field Manager were updated together. Then disable cache and optimization on the donation page, test the form on a default theme or a site copy, and review the error log. If the issue involves a premium add-on and still happens on a current version, contact GiveWP support.

Can the plugin be used to collect consent for a privacy policy?

Technically, yes: you can add an explanatory block and a consent field or checkbox with a link. But the wording of the consent, the legal language, and the data retention policy remain the site’s responsibility. Do not treat a technical checkbox as sufficient if you are collecting real personal data.

Do I need to use every available field type?

No. The field types are a toolkit, not a form blueprint. A good donation form is usually short. Use only the fields your team will actually process after the donation, and show less common questions conditionally.

When Give Form Field Manager Is the Right Choice

Give Form Field Manager is worth using if you already work with GiveWP and want to expand a donation form carefully without custom development. It is especially useful for donation designation, consent collection, comments, gift-related flows, additional contact details, hidden internal labels, and any data that needs to appear in the donation record, receipt, or email.

Before launch, keep your attention on the practical chain: the field appears in the right place, the donor understands the question, the conditional logic does not block submission, the value is saved, the team can see it in the admin area, and the donor only receives the data that belongs in the receipt. If that entire chain passes a test donation, the form is ready for a careful rollout.

If, after reading this, you know which fields your campaign needs, how to verify your conditions, and where to find the saved responses, you can move on to the download section and download Give Form Field Manager for further testing on a site copy. Start with one form, one use case, and several test donations. That is the easiest way to end up with a useful form rather than a long questionnaire donors do not want to complete.