How to Run a Halloween Sale on a WordPress Plugin

On paper, a Halloween sale on a WordPress plugin is a 5-minute job. You create a coupon, put a banner on the homepage and send an email. Then the coupon starts touching parts of the site you didn’t think about: the pricing cards, the FAQ, the structured data in your page head, the license terms and the deal roundups that list your offer with whatever code they were given.

When those parts disagree, buyers notice before you do. A banner keeps promising 35% after the code has died, the FAQ still says no discount is running, or a yearly plan renews at the sale price you only meant for the first payment. The fix is to treat the sale like a small release: write the offer down once, give it a start and an end and make every part of the site read from that.

I set this up for Core Forms earlier this month, and the sale starts on October 20, so everything below comes from that setup. The code HALLOWEEN takes 35% off both plans until November 2, India time, which brings the lifetime license from $249 to $161.85 and the first year of the yearly plan from $59 to $38.35.

Write the Offer in One Sentence

This assumes you have already decided the sale is worth running. If you haven’t, my guide to Halloween sale strategy covers the break-even math and how deep a software discount should go.

Before you open the store settings, write the whole offer as one sentence a buyer could read. Mine is: 35% off every Core Forms plan with code HALLOWEEN, from October 20 to November 2 in India time, on the first payment only, for new purchases.

That sentence has to answer these questions:

• What is discounted. The plans and products the code covers, and the ones it doesn’t.
• By how much. One percentage, or a fixed amount, applied the same way on every plan.
• When. A start date, an end date and the time zone both are in.
• For how long. The first payment only, or every renewal. For a yearly plan, the first payment is almost always the right answer.

Every other piece of the sale gets copied from this sentence. If the banner, the email and the roundup listing all quote it, they can’t drift apart.

Set Up the Coupon

Core Forms is sold through FluentCart on gauravtiwari.org, so the coupon lives there, alongside codes for my other plugins. Any plugin store has the same handful of settings, and these are the ones that matter:

• Type and amount. Percentage, 35.
• Product restriction. The code covers only the 10 plugin plans. My store also sells PDF books, and a whole-cart coupon would have discounted those as well. In FluentCart this restriction is stored against each plan, called a variation, so a product with a lifetime and a yearly plan needs both selected.
• Recurring off. The discount applies to the first payment, and renewals bill at the regular $59.
• Stacking off. One code per order. A Halloween code stacked on any other code gives a discount you never priced.
• Scheduled start and end. The code switches itself on and off. FluentCart saves these dates in UTC, so a sale that starts at midnight in India is stored as 18:30 the previous evening. Check what time zone your store saves dates in before you trust the schedule.

A scheduled coupon can’t be tested before it starts. I’d create a private test code with the same settings, run it through checkout on each plan and then delete it.

Make Every Price on the Site Agree

The checkout is the easy part, because the coupon controls it. The trouble is everything on the site that shows the offer.

On core-forms.com the sale bar and the popup check the date in the visitor’s browser, so they switch off on their own when a campaign ends. The pricing cards, the FAQ answer, the meta descriptions and the JSON-LD price in the page head are built into static HTML, and those can’t check anything. A scheduled job compares the offer the live site is serving with the offer the calendar says should be running, and it rebuilds and deploys the site only when the two differ. On most days it does nothing at all.

You don’t need the same setup, but you need an answer to the same problem. If your site is WordPress, these are the places that usually hold a stale offer:

• The pricing page and every pricing block reused on other pages.
• FAQ answers about discounts, which are written once and forgotten.
• Cached pages, which can keep serving the banner after the code expires.
• Product schema with an offers price, which Google can show in search results.
• Popups and bars from a separate plugin with their own schedule.

The banner and the coupon should end at the same moment. If they can’t, let the coupon outlive the banner by a few hours. A buyer who arrives after the banner is gone loses nothing, while a buyer who sees a banner and then gets an invalid code writes to support.

Check the License Terms

A discounted license should be exactly the same license as a full-price one. Core Forms covers unlimited sites, personal and client, with every feature, on both plans, and the coupon doesn’t change that. Say that plainly on the pricing page.

Then spell out the two things that do vary:

• Renewals. The yearly plan renews at $59 a year after the discounted first payment. Put that on the pricing page and in the receipt.
• Refunds. Core Forms comes with a 14-day money-back window on both plans. If you run a deeper sale at Black Friday, some October buyers will still be inside that window, and they can refund and buy again at the better price.

If you sell your plugin with your own license server, the software license manager guide covers activation limits, and how license activation works explains what the key check actually does. A sale changes neither, and it shouldn’t.

Give Roundup Curators One Sheet

Deal roundups put your offer in front of buyers who may never visit your site, and every curator needs the same facts. I put them in one deal sheet with a separate banner for each plugin, so a roundup can list every offer without writing back to ask.

The sheet should carry:

• Product name, plan names and what each plan covers.
• Regular and final prices for every plan, worked out to the cent.
• The code, the dates and the time zone.
• What the code excludes and whether it stacks.
• A banner in a common size, and the link the roundup should use.

Every code you print in that sheet has to work. Mine listed HALLOWEEN35, while the store had HALLOWEEN, so I created HALLOWEEN35 as an identical second code instead of chasing the listings. Both codes give the same 35% on the same 10 plans.

You can see how a roundup presents these offers in my WordPress Halloween deals list, which includes every plan of Core Forms with the final prices.

Send the Emails and Build the Page

The sale needs fewer emails than people think. A launch email, a reminder halfway through and a last call before the deadline are enough for a plugin with an engaged list. The Halloween email templates on my blog include subject lines for each.

If the offer needs more explanation than a banner can hold, give it a page of its own. This walkthrough for a Halloween landing page in WordPress covers the structure, and the same page works for Black Friday with the dates and the code changed.

The Day the Sale Ends

On November 3, open the store and check it yourself. The coupon should show as expired, the site should show the regular price everywhere and the FAQ should say no discount is running. Then write down how many orders came through the code and on which plans, because that number is the only reliable input you’ll have when you plan Black Friday 3 weeks later.

A Halloween sale is a small release, and like any release it goes wrong at the edges: the old FAQ answer, the cached pricing page, the curator who got last week’s code. If you only do one thing from this list, write the offer sentence first and paste it everywhere the offer appears. Every mismatch above starts with the same offer typed out separately in two places.