Give Tributes - WordPress Plugin

Guide to Using and Configuring Give Tributes

Give Tributes should not be treated as a decorative checkbox in a donation form, but as a working tribute layer: a donor can make a gift in honor of someone, in memory of someone, in support of a family, team, or event, while the administrator gets data that can be shown in the form, sent to the recipient, and later reviewed in reports. This guide walks through a practical setup approach without rushing: where to enable the block, which fields should stay optional, when to turn on eCard, how to test emails, what to review in reports, and which issues most often get in the way of smooth donation collection.

This material is written for a site where GiveWP is already in use, or is planned as the primary donation platform. So this is not a retelling of the general product page. The focus here is practical work with Give Tributes: how to fit tributes into the donor journey, avoid overloading the form, make sure recipient emails are not lost, and avoid creating unnecessary manual work for the team.

The article covers only confirmed features: the Tributes block in the Visual Donation Form Builder, global settings for older forms, dedication type options, field requirements, eCard, template tags, preview, test sending, and reporting. Where public sources do not confirm the exact internal behavior, the recommendations are framed as safe WordPress and GiveWP practice, not as a promise of specific functionality.

Where Give Tributes Is Actually Useful

The plugin's main job is to add meaningful context to a standard donation. For a nonprofit site, that is not a minor detail. The same field can support several different situations: a memorial fundraiser, a wedding gift, a tribute for a volunteer, a donation supporting a patient, gratitude for a coach, help for a family after an event, or an internal campaign run by the organization. If a form only collects an amount and contact details, the administrator often ends up clarifying the context manually afterward. Give Tributes moves that step into the form and makes it part of the donor experience.

In practice, the plugin is especially useful in three types of campaigns. The first is memorial and remembrance fundraising, where it matters to capture the person's name and the tribute type correctly. The second is celebratory or family events, where the donor expects the recipient to learn about the gift through an eCard. The third is campaigns with ongoing operational work: the organization not only accepts donations, but also prints cards, tracks sent notifications, prepares reports for the team, and stays in touch with relatives or honored recipients.

The most common implementation mistake is enabling every possible field at once. The donor journey becomes longer, and the team receives more data than it actually uses. It is better to start with a specific goal: do you only need "In honor of" or "In memory of," do you need a recipient email, do you need a last name, will staff print physical cards, is someone responsible for checking reports. If there is no clear answer, the feature can be introduced gently as an optional block with a clear question and a short set of choices.

Who This Workflow Fits

Give Tributes is a good fit for organizations that want to do more than simply accept a donation - they want to preserve the relationship between the donor, the honoree, and the campaign. That can include foundations, religious organizations, schools, medical initiatives, community projects, sports clubs, and event-based websites. The plugin is especially effective when donor motivation is emotional: the person is not just giving to a general fund, but tying the gift to a specific story.

The plugin may be unnecessary if the site uses only a simple donation button with no form, if the team is not ready to process extra data, if eCard is not needed, or if tributes are collected only occasionally. In those cases, a separate text field in the form or an internal CRM note may be enough, but that is not the same level of structure. Give Tributes is most useful when tributes become a repeatable working process.

What to Check Before Installation and Enablement

Before adding Give Tributes, it is worth checking not only WordPress compatibility, but also organizational readiness. GiveWP documentation shows that for the new Visual Donation Form Builder, you only need an active GiveWP installation and an active Tributes add-on, after which the block can be added to the form. But technically "active" does not yet mean "ready to publish." Tributes involve personal data, emails, form presentation, and reporting, so it is better to go through a short pre-launch review first.

• Make sure the main GiveWP form already passes a safe test donation flow and shows a correct confirmation.
• Confirm that the administrator understands which form is being edited: a new form in the Visual Donation Form Builder or an older V1/V2 form with global settings.
• Decide which tribute types are actually needed. If the site has no real use case for "In celebration of" or "In support of," do not add them just for completeness.
• Check WordPress email delivery. If regular GiveWP emails are not arriving, eCard will be difficult to validate too.
• Prepare recipient-facing copy. An email with template tags should sound clear and respectful, not like a technical receipt.
• Decide who will review tribute donation reports and what the team will do with that data.

Practical rule: start by setting up one short tribute workflow and take it all the way to a verified result. Expanding types, emails, and reporting is much easier once the basic path of "the donor submits the form - the recipient receives the message - the administrator sees the record" is already working.

Compatibility with the Theme, Cache, and Email

Give Tributes works inside the GiveWP form, so externally it depends on how the theme renders the form, how the optimizer handles scripts, and how the site sends emails. If the site uses aggressive minification, deferred JavaScript loading, or page caching on form pages, check not only the visual appearance but also whether fields expand correctly after the donor selects a tribute option. For email, test both the standard donor receipt and the eCard. If normal WordPress email is unstable, start with an SMTP plugin and delivery logs rather than changing Tributes settings.

Installation and Initial Verification After Activation

After installing Give Tributes, do not publish the form right away. The documentation describes two workflows: new forms use the Tributes block in the Visual Donation Form Builder, while older V1/V2 forms use the GiveWP > Settings > Tributes screen with global settings. That distinction matters: if you are editing a new form, look for the block in the form builder; if you are maintaining an older form, check the global values and any per-form overrides.

1. Open the WordPress admin area and confirm that GiveWP is running without critical errors.
2. Activate Give Tributes the standard way for WordPress plugins.
3. Open the donation form you plan to use for the campaign.
4. If the form was created in the Visual Donation Form Builder, go to the Build tab, find the Tributes block in the add-ons group, and add it to the appropriate section.
5. If the form is an older one, open GiveWP > Settings > Tributes, enable Tributes, and review the global values.
6. Save the changes and open the public form in a view where you see the page as a donor, not as an administrator.

The first check should be short. You are not customizing every bit of copy yet - you are confirming that the fields appear at all, the switches work, the selected tribute type is saved, the form does not break payment, and the donation record reaches the admin area after submission. If something does not display at this stage, do not move on to eCard yet: first fix the basic block output.

How to Tell the Block Was Added Correctly

A tribute block should appear on the public form with a question about the dedication. Depending on the settings, the donor will see consent options, the tribute type, the honoree name, and additional fields. If the block is required, the fields should either be visible right away or be required before the form can be submitted. If the block is optional, the donor should clearly understand that they can skip the tribute and complete the donation without extra steps.

After a test donation, check the record in the GiveWP admin area. What matters is not just the payment itself, but the tribute data as well. If the donor entered a name, a type, and a recipient address, that data should be available in the donation context and in reporting. Without that check, the team may think everything works even though the data is not landing where people will actually look for it.

Configuring the Tributes Block in the Visual Donation Form Builder

In new GiveWP forms, the Tributes block becomes the key place to work. It does not just insert a single field. The documentation lists settings for the title, required state, question, response options, tribute types, last name requirement, prepended label, and notifications. So it is best to configure it the way a form editor would: first the intent, then the fields, then the required behavior, then the final public result.

Title and Question

The Tribute Title field controls the block heading. The default shown in the documentation is Dedicate Donation. On a live form, it is usually better to adapt that wording to the actual campaign context: "Dedicate This Donation," "Make This Gift in Honor of Someone," or "Give in Someone's Name." The key is not to turn the title into a long instruction. The instruction should live in the question or in supporting text.

The Question field explains to the donor what is happening. The documentation example is Would you like to dedicate this donation?. A good version depends on the campaign. For a memorial fund, a calm option works well: "Would you like to make this donation in memory or in honor of someone?" For a wedding or celebration campaign, a softer version may work better: "Would you like to tell us who this gift is for?" If the question is too generic, the donor will not understand why additional fields appear.

Response Options and Tribute Types

The Options setting controls whether the donor opts in or opts out of a tribute. By default, the documentation shows Yes, Please and No, thank you. On a public form, simple choices such as "Yes" and "No, thanks" are often enough, but it is important to keep the tone polite. If the donor declines, the form should not make it feel like they did something wrong.

Tribute Types is the more meaningful setting. In the Visual Donation Form Builder, options include In honor of, In memory of, In celebration of, and In support of. For older forms, the documentation separately mentions the ability to add, rename, and remove options. This is where it helps to be strict: keep only the types the team actually distinguishes in reports and emails. If every option leads to the same email anyway, the donor field becomes unnecessary noise.

How to Choose the Right Set of Types

For a memorial fund, two options are usually enough: "In memory of" and "In honor of." For an education or sports campaign, "In support of" may be useful. For a family celebration, "In celebration of" makes sense. If the campaign is mixed, do not try to cover every case with one form. It is better to create separate forms or campaigns with different wording than to force the donor to choose between four similar options.

Required or Optional Tribute

The Required field setting in the new block, and the Required or Optional setting in older forms, determines whether a donor can submit a donation without tribute data. The documentation notes that in a required scenario, the fields display automatically and the dedication type is preselected. That can be helpful for campaigns where every donation is meant to be tied to a person. But for a general fund, making it required can sharply reduce form completion because donors may not understand whom they are supposed to name.

After choosing a mode, always run two tests: a donor with a tribute and a donor without one. If the optional block gets in the way of the second path, the setup is too aggressive. If a required block does not show the fields immediately, the donor may hit an error only at submission time, which is worse for trust.

Prepended Label and Last Name Requirement

Prepended label adds a label before the honoree's first and last name. The documentation uses Honoree by default. For a live site, choose a short, clear label such as "Honoree," "Name," "Recipient," or "Person This Gift Honors." Long labels tend to look awkward next to name fields.

Only require the last name if the team truly needs it: for printing cards, searching reports, communicating carefully with a family, or telling people with the same first name apart. If the eCard is going to someone the donor knows well and the message will make sense with a first name only, requiring a last name can feel unnecessary. Every required field should have an operational reason behind it.

eCard: Recipient Email Without Extra Manual Work

eCard is the most sensitive part of Give Tributes because it connects the donation form to a person who may not be the donor at all. In the documentation, eCard is enabled with a separate setting, after which you get options for a custom message, message length, subject, recipient last name requirement, email content, logo graphic, header graphic, preview, and test sending. At that point, you are no longer just building a form - you are managing a communication that goes out on behalf of the organization.

When to Enable eCard

Enable eCard when the recipient truly needs to hear about the donation quickly and without manual handling. It works well for gifts, wedding fundraisers, memorial messages, family support, congratulations, and campaigns where emotional impact matters. If the organization already calls the recipient, prints a physical card, or sends a message manually, an automated eCard may be unnecessary or may even conflict with the internal process.

Review the tone of the email separately. A recipient may see the eCard during a difficult life moment, so the text should be calm, respectful, and free of marketing language. Template tags help insert the donor name, amount, form, honoree name, and other data, but they do not replace editing. Read the email as if you were the recipient and had never seen your admin area or heard of GiveWP.

Email Subject and Template Tags

The ECard Email Subject field can use template tags. The documentation lists tags such as {donor_name}, {amount}, {form_title}, {tribute}, {honoree_name}, {honoree_fullname}, {sitename}, and {download_card}. In the context of this article, those tokens matter not just as code a developer might paste, but as a reminder that the email should be dynamic while still being clear after the values are inserted.

For the subject line, avoid using too many variables. Good options include "A donation has been made in your honor by {donor_name}" or "For {honoree_name}: a new tribute on {sitename}." If the subject includes the amount, think carefully about whether it is appropriate for the recipient to see it. In some campaigns the amount matters, while in others it may be private donor information.

Email Content and Message Length

ECard Content works as the email content editor. The documentation shows that it can use template tags and formatted text. But the more complex the email becomes, the greater the risk that it will render poorly in a mail client. Start simple: a greeting, the fact of the donation, the connection to the campaign, a thank-you, and the organization's signature. Add images and longer blocks only after testing in several mail clients.

Message Length limits the donor's custom message. The documentation default is 255 characters. That is a reasonable starting point: enough for a personal note, but not for a long letter that could break the layout. If your audience is used to writing longer messages, raise the limit gradually and review the eCard preview each time.

Preview and Test Send

The documentation points to two ways to validate the setup: Preview eCard, which opens a live preview using a recent donation, and Send Test Email, which sends the email to a chosen address. Use both. The preview shows how the data is inserted, and the test email shows actual delivery, appearance in the mail client, and possible sender-related issues.

Do not publish eCard without a test send. If the message looks fine in the preview but never arrives or lands in spam, the recipient will experience that as a failure of the whole campaign, not as a minor technical issue.

New and Old Forms: Where to Find the Settings

GiveWP has evolved, and the Tributes documentation separately covers the new path through the Visual Donation Form Builder and the older path for V1/V2 forms. That is not just historical trivia. On a real site, forms from different generations often coexist: a new campaign is built in the block-based builder, while older donation pages continue accepting payments. If an administrator configures the wrong screen, they may save changes and never see them on the form that actually matters.

New Forms in the Visual Donation Form Builder

For new forms, the workflow is straightforward: open the form edit screen, go to Build, add the Tributes block from add-ons, and configure the settings inside that block. This approach is convenient because the tribute setup lives next to the rest of the form structure. You can see where the block sits, how it relates to the donation amount, personal information, and payment fields, and you can verify the result directly on the form.

For a team, this is the better path when each campaign has its own logic. For example, a memorial fundraiser may require the honoree name, a wedding fundraiser may make eCard the central feature, and a general fund may keep tributes optional. In that case, per-form configuration is safer than global defaults.

V1/V2 Forms and Global Settings

For V1/V2 forms, the documentation describes the GiveWP > Settings > Tributes screen. That is where site-wide defaults are enabled: the Tributes feature itself, eCards, the fieldset title, tribute options, prepended label, section location, display style, required/optional behavior, notification option, and reports. Those values serve as the baseline, but they can be overridden at the form level.

Global settings are useful when the site has many older forms that follow the same policy. But they become risky when forms differ. Changing the global fieldset title or display style can unexpectedly affect a campaign that has not been edited in a long time. Before changing global parameters, make a list of active forms and check at least the most visited ones.

Where to Place the Tribute Block in the Form

In older Tributes settings, there is a Tribute Section Location parameter. The documentation lists placement options such as below donation level fields, below the top donation amount field, above or below payment options, above or below personal info fields, and above or below credit card fields. In the Visual Donation Form Builder, the same logic is handled by where you place the block in the form structure. In both cases, the real question is the same: when is the best moment to ask the donor about a tribute?

If you ask too early, the person may not even have chosen an amount yet and may see extra fields as friction. If you ask too late, they are already thinking about payment and may miss the contextual part entirely. For most campaigns, a good position is after the amount and before personal details. At that point, the donor has already decided to participate but has not moved into the payment step yet.

How Placement Affects Form Completion

Tribute fields should not interrupt the payment flow. If the form is short, placing the block after personal info may be fine. If the form is already long, it is usually better to position Tributes so that an optional decline quickly hides the extra fields. For a required tribute, by contrast, the block should be visible early enough that the donor understands the requirement before reaching the final step.

Test the form on desktop and mobile. Do not use a phone as the only model for visual testing, but make sure radio buttons, a dropdown, or buttons do not take up too much space. The documentation offers Radios, Dropdown, and Buttons as display style options. Radio buttons are usually clearer, a dropdown saves space, and buttons make the choice more prominent. The best option depends on the number of tribute types and the width of the form.

Practical Scenario: Memorial Fundraiser with eCard

Let us walk through a scenario that shows the value of Give Tributes clearly. Imagine a nonprofit launching a memorial fundraiser. The goal is to let the donor make a gift in memory of someone, enter the honoree's name, write a short message to the family, and send an eCard. The fundraising team wants to see those donations in reports so it can prepare a tribute list when needed.

Goal

Create a form where the donor can choose the tribute type "In memory of," enter the person's name, leave a message, and send a recipient notification. At the same time, a donor who does not want to send an eCard should not get stuck in the form.

Preparation

Before configuration, create or select the GiveWP donation form, verify the payment test flow, prepare the eCard copy, and decide which data is needed. For a memorial campaign, the important fields are usually the honoree name, last name if needed, recipient email, a short message, and a clear email subject. If the team sends physical cards, decide in advance whether an address field is needed and who will handle it.

Setup Steps

1. Open the form in the Visual Donation Form Builder and add the Tributes block to the section after amount selection.
2. Rename the block title so it fits the campaign, for example, "Dedicate This Donation."
3. Use the question to explain that the donor can make the gift in memory or in honor of someone.
4. Keep only the needed tribute types. For a memorial campaign, In memory of and In honor of are often enough.
5. Make the tribute optional if the campaign also accepts general donations, or required if the entire fundraiser is built around a specific memorial context.
6. Enable eCard if the recipient should receive an automated email.
7. Configure Custom Message, the message limit, and the email subject, using template tags carefully.
8. Save the form, open the public page, and complete a test donation.

Verifying the Result

After the test, check three places. On the public form, the fields should appear only in the expected mode. In the donation record, the tribute data should be present. In email, the eCard should arrive with the correct subject, names, and text. If the email does not arrive, do not immediately rewrite the eCard content. First check whether standard GiveWP and WordPress emails are being sent, then SMTP, then the recipient address, and then test sending.

A Detail That Often Gets Missed

The most frustrating failure is when the administrator tests only the form but never checks the report or the eCard. Visually, everything can look ready because the fields are there. But later the team cannot find the data, or the recipient never receives the message. With Give Tributes, a complete verification always includes the form, the record, the email, and the report.

Tribute Reports and Team Workflow

The documentation describes Tribute Reports under legacy reports: GiveWP > Reports > Legacy Reports > Tributes. When the relevant features are enabled, you may see links for Tribute Donations and eCards. That is especially important for organizations where tributes do not end with an automated email. The team may print cards, reconcile sent notifications, prepare lists for a campaign coordinator, or check which donations still need manual handling.

The tribute donations report helps you see donations where a honoree was specified. The documentation notes sorting by donation ID, honoree name, and date/time. The eCard report shows donations where an eCard was sent and may be sortable by date sent or donation ID. Do not treat these reports as a replacement for accounting reports. Their value is operational: who was named, what was sent, and what still needs attention.

How to Build Reports Into the Workflow

Assign someone to own report review. If the organization sends cards once a week, the report should be checked before each mailing. If eCard is fully automated, the report may only need review after campaigns or when recipients complain. If the report shows no data, start diagnosis with a test donation and the form, not with export tools.

• Check that the needed Tributes and eCards features are enabled for the form used in the test.
• Match the donation ID between the donation record and the report.
• Filter test records separately so the team does not send a real message based on a test submission.
• Do not store unnecessary personal data if it is not needed to process the tribute.

Small Visual Improvements Without Risk

The public documentation does not provide reliable confirmation of Tributes-specific PHP hooks that can be safely recommended for every site. That is why this guide does not include invented snippets for the plugin's internal logic. The safest level of customization is a careful CSS adjustment to the block appearance in the theme or through the standard Additional CSS area. It does not change the payment flow, does not interfere with email sending, and is easy to roll back.

Before editing CSS, open the form in the browser, inspect the classes used in the actual markup, and confirm that the rule does not affect other forms. The example below is intentionally gentle: it improves spacing and readability for the tribute block, but it does not hide required fields or change form behavior.

/* Light styling for the GiveWP tribute block.
   Add it to the theme or child theme's Additional CSS
   after checking the classes used on your form. */
.give-tributes,
.givewp-tributes {
  margin-top: 1.25rem;
  padding: 1rem;
  border: 1px solid rgba(0, 0, 0, 0.12);
  border-radius: 8px;
  background: #fff;
}

.give-tributes label,
.givewp-tributes label {
  line-height: 1.45;
}

.give-tributes input,
.givewp-tributes input,
.give-tributes select,
.givewp-tributes select {
  max-width: 100%;
}

The check is simple: open the form with tributes enabled, try each option, submit a test donation, and confirm that required messages, name fields, and eCard still appear correctly. Rolling back is simple too - remove the CSS and clear the cache. If the site uses an optimizer, test the form after clearing the cache and in a private window.

Checking the Result Before Publishing

Before you share the link with donors, test the form as a regular visitor. It is not enough to see the settings in the admin area. You need to complete the whole path: open the page, choose an amount, enable or disable the tribute, fill in the honoree, choose eCard, submit a test donation, and check both the record and the email. That takes less time than investigating a complaint after the campaign is live.

After a successful check, document a short internal rule set: who owns eCard text changes, who reviews reports, who verifies emails after updates, and who is allowed to disable eCard if complaints start coming in. That may sound like unnecessary bureaucracy, but in memorial and family fundraising, an email error is felt much more sharply than a mistake in a standard inquiry form.

How to Avoid Overloading the Form and Preserve Donor Trust

A tribute works best when it helps the donor express intent, not when it forces them to understand your admin logic. So after the technical setup, it is worth going through an editorial layer: remove unnecessary options, shorten labels, review the emotional tone, explain why the recipient's email is needed, and do not ask for data the team will never use. On a fundraising site, that is part of trust. The donor is giving both money and personal data, so the form should feel predictable.

Start with the question the donor sees. It should answer a simple situation: "Would you like to dedicate this donation to a person or an event?" If the question turns into a legal explanation, move that into a short note or page text. The block itself should focus on the action. That keeps the form from turning into a long instruction sheet.

Minimum Field Set for a First Launch

For a first rollout, the tribute type, honoree name, and an optional message are often enough. A last name, address, multiple recipients, and additional options are better introduced only after the team understands how it will use that data. Be especially careful with address-like fields for card delivery. If the organization does not print physical cards, an address may create unnecessary responsibility and make the form harder to complete.

• For a general fund, keep the block optional, use a short question, and offer two main tribute options.
• For a memorial campaign, pre-expand the fields and explain whose name should be entered.
• For a gift campaign, make eCard the central feature, but do not force the donor to write a long message.
• For a campaign with manual card mailing, add only the fields that truly feed into the mailing process.

A good form collects exactly as much data as the next action requires. If the next action is not clearly defined, the field is better left out. That rule is especially important for tribute donations because the data often concerns not only the donor, but also the person the donation honors.

Message Tone for Different Campaigns

The same eCard template rarely works for every use case. A memorial email should be restrained, without excited calls to action or bright marketing language. A celebratory email can feel warmer. A support message for a person or family should be especially careful: it should not reveal more information than the donor expects, and it should not make assumptions about the recipient's situation.

Read every email out loud. If it sounds like a system notification, add human context. If it sounds like a promotional blast, dial the tone back. If the subject line uses too many variables, reduce it to one or two. The recipient should be able to quickly understand who made the donation, whom it honors, and which organization sent the message.

Localization and Clear Labels

GiveWP and its add-ons may display English labels in the admin area or on the form depending on localization and settings. For the public-facing side, what matters most is not the language used in the documentation, but how clearly the donor understands the field. In the block settings, review the title, question, response options, and tribute type names. If part of the text cannot be translated through settings, use standard WordPress translation mechanisms rather than editing plugin files.

Do not mix English and another language in the same helper text unless it is an exact UI label or a code reference. A poor example would be: "Select tribute type for the eCard." A better one would be: "Choose the dedication type for the recipient email." Small details like that reduce the feel of a technical form and make the donation experience more respectful.

Safe Operation After the Campaign Goes Live

Once the form is published, working with Give Tributes is not over. You still need to monitor emails, reports, GiveWP updates, and changes on the page. That is especially important for campaigns where tributes carry emotional weight: a failed email, an incorrect name, or a missing block will be felt much more strongly than a routine interface issue.

What to Check After Updates

After updating GiveWP, the theme, a cache plugin, or a mail plugin, run a short regression test. Open the form, select a tribute, submit a test donation, and verify the eCard and the report. You do not need to test the entire site, but the donation flow should be on the mandatory checkpoint list. If the organization runs seasonal campaigns, do this test before each active fundraising period.

If the field appearance changes after an update, disable custom CSS first for testing. If the behavior breaks - for example, fields do not expand after selecting "Yes" - check script optimization and caching. If emails stop arriving, check SMTP and regular WordPress email. That order saves time: do not change Tributes settings until external causes have been ruled out.

How to Keep Internal Setup Notes

For each form that uses tributes, it is useful to keep a short internal note: why the block is enabled, which tribute types are used, whether the field is required, whether eCard is enabled, who reviews the reports, and when the setup should be reconsidered. That can live in team documentation, a project task, or the campaign description. What matters is that the next administrator does not have to guess why the form is configured this way.

This is especially helpful for agencies and freelancers handing the site over to a client. The client does not need a technical treatise, but does need a clear instruction: where to change the eCard text, how to send a test email, where to find reports, when not to touch the required toggle, and how to disable eCard temporarily if delivery problems begin.

When It Is Better to Create a Separate Form

Sometimes a team tries to cover every campaign with one form: memorial donations, holiday giving, a general fund, support for a specific family, and tributes for volunteers. Technically, you can add many tribute types, but from the donor's perspective it becomes a heavy choice. If the copy, required behavior, eCard, and reports vary significantly, create a separate form. That makes testing easier, results cleaner, and the donor experience easier to explain.

A separate form is especially useful when one scenario requires a tribute and another makes it optional. Mixing those modes in a single form tends to be awkward: some donors will see unnecessary fields, while others will not understand why the form requires an honoree name. Splitting forms often produces a cleaner result than trying to configure one universal block.

Troubleshooting: Fields, Emails, Reports, and Cache

Give Tributes issues usually do not show up as one obvious error. More often, they appear as a break between layers: the block does not show up, fields stay hidden, the form does not submit, the eCard never arrives, the report is empty, or saved changes do not appear on the page. Approach troubleshooting as a chain: settings - public form - test donation - email - report - cache and compatibility.

The Tributes Block Does Not Appear on the Form

Symptom: the setting exists in the admin area, but the donor does not see the tribute section on the public page. Possible causes include editing the wrong form, not actually adding the block in the Visual Donation Form Builder, applying global settings to older forms, serving a cached page version, or hiding an optional block until "Yes" is selected.

Check the form by ID or by the page where it is embedded. Open the builder and make sure the Tributes block is really present in the form structure. Then clear the page cache and open the form in a private window. If the block is optional, select the opt-in choice and see whether the fields expand.

The Donation Will Not Submit Because of Required Fields

Symptom: the donor clicks submit, but the form asks for a field they did not expect to fill in. The cause is usually required mode, the last name requirement, or a required eCard field. The fix depends on the campaign: if the tribute truly must be required, make the block visible earlier and explain what needs to be filled out. If this is a general fundraising flow, switch the block to optional mode.

The eCard Does Not Reach the Recipient

Symptom: the form is submitted, but the recipient never sees the email. Do not start by rewriting the template. First check whether standard WordPress and GiveWP emails are arriving. Then use Send Test Email, verify the address, the spam folder, the SMTP log, and the From/Reply-To setup. If the test email does not arrive, the issue is broader than Give Tributes.

If regular email works but the eCard does not, check whether eCard is enabled for that specific form or globally for older forms, whether the recipient fields are filled in, and whether sending is disabled in the selected notification option.

Template Tags Show Up as Plain Text

Symptom: the recipient sees {donor_name} or {honoree_name} instead of a real value. Possible causes include a typo in the tag, placing it somewhere unsupported, not filling the necessary fields in the test donation, or using the wrong email template. Compare the tags with the list in the eCard settings, create a new test donation with all relevant fields filled in, and open Preview eCard.

The Tribute Report Is Empty

Symptom: the form shows the fields, but the expected record does not appear in reports. Check that the test donation was completed and did not remain in an unsuccessful status. Then open the specific donation record and make sure the tribute data was actually saved. If the data exists in the record but not in the report, check the legacy reports section and the enabled features. If the data is missing from the record, go back to the form and review the required/optional settings.

Saved Changes Do Not Appear on the Public Form

Symptom: the administrator changes the text or mode, but the public form still looks the same. Possible causes include page cache, optimizer cache, editing a different form, changing global settings instead of per-form settings, or a conflict with the page builder. Clear the cache, confirm the form ID, temporarily disable aggressive optimization on the donation page, and run the test again.

When to roll back a setting: if making tributes required causes form completion to drop or donor complaints to appear, switch back to optional mode, preserve the basic donation flow, and only then determine which fields are truly necessary.

When Give Tributes Is the Right Choice

Give Tributes is a strong fit for a site where tributes are part of real fundraising operations, not just a random extra field. If the organization accepts memorial gifts, tribute donations, campaigns honoring specific people, eCard notifications, and wants that data visible in reports, the plugin handles the job more cleanly than a generic form. Its strength is the full chain: donor form, tribute type, honoree data, eCard, preview, test email, and reports.

Before launch, do not try to build the perfect form for every possible case. Put together one clear workflow, test it with a donation, confirm that the email arrived and the report shows the record, and only then expand the tribute types, wording, and styling. That order reduces the risk of mistakes and helps the team understand why each field exists in the form.

If the product looks like a good fit after testing, you can download the latest version of Give Tributes and test it on a staging copy or a test form before publishing. Do not enable required tributes on a live page until you have completed the full path end to end: public form, test record, eCard, report, and rollback of any questionable setting.