There are two common possibilities here.

Possibility #1: Your shortcode may not be active

The first is that your plugin hasn’t been enabled, and so the shortcode isn’t active. Go to Plugins on your Dashboard and be sure Seamless Donations is active. You can also double-check this by looking at your Dashboard sidebar for a Seamless Donations set of items (with a little palm tree icon).

Possibility #2: CSS is hiding your form

Another possibility is that your form is there (it’s in the source code of the page), but it’s being hidden in some way by the CSS of your theme. To confirm your form is loading, inspect the source (see the basic skills guide) of your page and search for “<!– SD” (that’s a less-than sign, an exclamation point, two dashes, a space, and the capital letters S and D — no quotes).

You should see a string that looks like “<!– SD 4.0.8 form engine mode –>” except the version number will likely be different. If you see that string, then Seamless Donations has loaded, but is probably being hidden by an overly aggressive CSS selector ((see the basic skills guide) in your theme.

An easy way to test that is to temporarily switch themes to one of the WordPress standard themes (Twenty Thirteen is good for this) and see if the donations form shows up. If you don’t see the “<!– SD” string, then the form is not loading on your page. If the form isn’t loading, the most likely scenario is that you’re not using the seamless-donations shortcode on the page or the plugin isn’t enabled.

This is often caused by caching. Session IDs are created as a function of the time the page was requested, the user’s browser, IP address, remote address, and some other unique factors. All of those are hashed together to form a unique code. Unless a page is requested twice microseconds apart, the session ID for two pages served should always be different. But sometimes, they’re not.

It’s actually quite difficult to cause this, because the IDs are generated in a few simple lines of code, based on information at the server level. Pretty much the only way you’re going to see duplicate IDs is if you’re not actually getting a new page each time a user goes to your donation form page. And that is almost always a function of caching.

Keep in mind that caching doesn’t always happen through WordPress plugins. Your host may provide some level of caching (even if they don’t tell you). One of our users, Marcus, noticed this problem with a GoDaddy-hosted site, and he kindly provided a work-around.

“I found with GoDaddy that there isn’t a way to disable all caching – but there is a way to disable caching on a specific page – via this knowledge base article on GoDaddy’s support site. When adding ?nocache=1 to the end of the donation URL (in this case http://mysite.com/donate/?nocache=1) the PayPal forwarding works every time in all browsers. So I went ahead and edited my WordPress Menu options to send to the custom link of http://mysite.com/donate/?nocache=1 instead of just the normal Donate page.”

Thanks, Marcus. So check with your host, and if you use GoDaddy, make sure you add the ?nocache=1 when you send people to your donation page.

This is an odd symptom, which is related to how the custom post type API displays data. In most cases, there’s an easy fix.

In your WordPress dashboard, go to Settings->Permalinks and — without changing anything — simply save changes. Then, go back to the page you were having problems with and refresh. All should be working now.

Possibility #1: Enable the Label Tag option

Before you go through the work of trying to diagnosing this problem, there’s a feature in Seamless Donations that may help. At the bottom of the Form Options tab is a tweak option. It’s called “Label Tag” and if you check it, you might find Seamless Donations works better with your theme.

Possibility #2: Aggressive CSS selector

If that doesn’t work, it’s almost always due to an overly aggressive CSS selector (see the basic skills guide) in your theme, which is hiding the buttons. The easiest way to check is to use Inspect Element (see the basic skills guide) on one of the amount items.

You’ll probably see an HTML span tag that looks something like “dgx_donate_giving_level_200”. Expand that tag by clicking on the little arrow. If you see an INPUT tag with the type of “radio,” then you know that the button is being generated. Now, it’s just a matter of tracking down what in your theme is hiding those buttons.

An easy way to test that is to temporarily switch themes to one of the WordPress standard themes (Twenty Thirteen is good for this) and see if the donations form shows up.

This problem can be identified by looking at your button names in the Seamless Donations Form Options tab. If they’re all the same (and, if in particular, they are all “Save Changes,”) then you’ve encountered one of the weirdest quirks I’ve yet found.

Most likely, there is a record in the wp_options database table called “Submit” with the value of “Save Changes”. A few users have found this to be the legacy of the Headway template, but for some reason, it causes all the Seamless Donations button names to be overwritten. My code has nothing to do with it, but it’s possible one of the frameworks I use is influenced by this option.

To fix it, you’ll have to go into something like PhpMyAdmin and remove the record. Be careful though. Be sure to make a backup first.

Most search engines respect the robots.txt file. The best way to prevent pages from being indexed is to edit your robot.txt file to include “Disallow: /donor/” for donors, “Disallow: /donation/” for donations, and “Disallow: /funds/” (notice funds is plural) for funds. Don’t use the quotes and make sure you’re using WordPress permalinks.

Seamless Donations 5.0 added the ability for donors, donations, and funds to be listed as Public, Private, or Password Protected. Also allowed donor, donation, and funds pages to be unpublished, if desired. Make sure you’re running the latest version of Seamless Donations so you have all the bug fixes and improvements.