CodeCanyon YayMail - WordPress Plugin

CodeCanyon YayMail Setup Guide for WooCommerce Emails

CodeCanyon YayMail is not meant to replace WooCommerce as a notification system. Its job is to make your store emails look professional: add branded headers, a clean order block, clear customer guidance, verifiable dynamic data, and test sending before you publish changes. This guide walks through the full process, from site preparation to building a practical email template, validating the result, and troubleshooting common issues.

This material is written for store owners, WordPress administrators, content managers, and developers who want to quickly understand where the visual builder stops and where WooCommerce, SMTP, third-party extensions, and custom hooks take over. Instead of repeating the product listing, this guide shows how to use the plugin safely on a live store.

Special attention is given to order emails, because they often have the biggest impact on customer trust, support volume, and repeat purchases. We will cover templates, the global email header and footer, previewing against a real order, test sending, conditional blocks, the limits of the free and paid versions, and situations where it is better not to overcomplicate the email.

What Problem the Plugin Solves in a WooCommerce Store

Default WooCommerce emails do their basic job: they notify users about a new order, payment, refund, note, account creation, or password reset. But in a real store, that is often not enough. Customers receive emails after payment, after an order status change, after a refund, or after account creation, and each of those messages should be clear, polished, and recognizable. If an email looks like a raw technical notification with no logo, no proper copy, and no visual structure, it does less to support the brand and is more likely to trigger extra questions.

YayMail adds a visual layer to that process. Instead of manually copying WooCommerce PHP templates into a child theme, the user opens a builder, selects an existing email type, and assembles the layout from blocks. The sources confirm the key features: a drag-and-drop editor, live preview, order selection for testing real data, shortcodes, test sending, template import and export, a global header and footer, and separate add-ons for emails generated by third-party WooCommerce extensions.

It is important to understand the product boundary correctly. YayMail is not an SMTP service, it does not create deliverability on its own, and it should not be used as a substitute for proper WordPress mail setup. If the site cannot send email, the visual template will not go out either. That is why this guide always separates design setup from send validation: first confirm that WooCommerce and WordPress generate notifications correctly, then configure templates, and only after that send a test.

The second important limitation has to do with email types. YayCommerce documentation clearly separates standard WooCommerce templates, the Pro version, and separate YayMail Addons. If your store uses subscriptions, bookings, a marketplace, custom order statuses, gift cards, or shipping extensions, do not automatically assume that all of their fields will appear in every template. You need to verify whether the extension creates its own emails, whether the data is available inside the standard email, and whether there is an integration or add-on for it.

Who CodeCanyon YayMail Is a Good Fit For, and When Another Approach Makes More Sense

The plugin is especially useful for stores where transactional emails are part of the customer experience. That includes stores with repeat orders, digital goods, shipped products, B2B orders, coupons, warranty terms, post-purchase instructions, and manual support. In those projects, the post-order email should do more than confirm that a purchase happened. It should reduce customer anxiety by making it clear what was paid for, what happens next, where support is available, when shipment is expected, how to download a file, or how to contact the store.

A strong use case for CodeCanyon YayMail is a store where an administrator needs to manage email design without being confident in PHP, but still understands the brand and customer journey. The visual editor lets that person change the email structure, add blocks, adjust spacing, colors, images, buttons, social links, the footer, and branded elements. A developer is still useful for complex dynamic data, integrations, and safe hooks, but normal copy and design updates no longer require editing theme files.

The plugin may be unnecessary if the store intentionally uses near-plain-text emails, sends very few orders, does not want to maintain an extra template layer, or already has a fully custom coded email system. It also will not solve problems caused by poor DNS or SMTP setup, missing domain authentication, blocked mail servers, or errors in a third-party extension that does not expose its data to the template.

Practical rule: use YayMail for controlled email design and structure, not to fix email delivery. Check delivery separately through WordPress, WooCommerce, and your SMTP plugin.

If the team wants fully programmable emails with custom sending logic, complex conditions, queues, an external transactional messaging service, and CRM integration, the visual builder may be only one part of the solution. In that case, it makes sense to keep YayMail for the appearance of WooCommerce emails while handling business logic in WooCommerce itself, a dedicated extension, or an automation platform.

What to Check Before Installation and First Launch

Before installing the plugin, do not start with design. WooCommerce emails depend on order statuses, email type, HTML format, sender settings, SMTP, and order data. If one of those layers is not working correctly, the builder may appear to be the problem even though the root cause is lower in the stack.

WooCommerce and Email Format

YayMail works around WooCommerce emails, so WooCommerce must be installed and active. In WooCommerce settings, open WooCommerce - Settings - Emails and confirm that the notifications you need are enabled. For a visual HTML template, the Email type field is especially important. If a specific email is sent as Plain Text, a visual layout with images, columns, and colors will not render as intended.

Do not change every email at once. Start with a single customer template, such as Processing order or Completed order. That lets you separate design testing from the risk of breaking admin notifications, invoices, refunds, and account system emails.

A Test Order and a Safe Environment

To validate things properly, you need a test order with products, an address, a payment method, shipping, and the real fields you want to display in the email. An empty order or an order without shipping will not show how the product table, address blocks, coupons, taxes, discounts, and custom fields behave.

On a live store, it is best to first create a backup of your templates inside YayMail itself if that feature is available in your version, and then test changes on a limited set of emails. If the store uses a staging site, build the template there first and move it over through export and import. YayCommerce documentation specifically covers template import and export, backups, and data migration, so that path is safer than manually recreating settings on a live site.

Email Sending and the Domain

If a test email does not arrive, do not start by fixing the design. First check whether WordPress can send email at all through your SMTP plugin. YayMail documentation for test-send errors explicitly says to verify deliverability in SMTP settings before moving on to the template itself. That is the correct order, because the visual editor cannot fix a wrong SMTP password, blocked outgoing mail, or an invalid sender address.

For a production store, use a sender address on your site domain. That does not guarantee inbox placement, but it is the right baseline for transactional email. Also confirm that the sender name, email address, and customer replies go where your support team will actually see them.

Installation and Initial Validation Without Putting Orders at Risk

Installing the plugin is not fundamentally different from any standard WordPress plugin installed from a ZIP archive: open Plugins - Add New, click Upload Plugin, select the archive, install it, and activate it. What matters is not to mix that step with purchase setup, licensing, or the developer account. This guide assumes you already have the installation file and a working site.

After activation, look for the area related to WooCommerce Email Customizer. Some sources show it under the WooCommerce menu, while the current documentation shows a dedicated YayMail interface with top tabs for the template list, global email header and footer, settings, add-ons, preview, and support. Item names may vary slightly between versions, so focus on the meaning: you need the screen where the list of email templates and their statuses is visible.

Your First Action After Activation

Do not start editing every email right away. Run a short validation:

1. Open the template list and confirm that standard WooCommerce emails are visible.
2. Select one customer template that is not critical to admin-side order handling.
3. Open it in the editor and change nothing except a small test edit to the text or color.
4. Save the template and immediately preview it against your test order.
5. Send a test email to an address you can actually check in a mail client.

If everything works at this stage, you can move on to design. If saving fails, the screen freezes, or test sending does not work, use the troubleshooting section below first. Do not continue configuration until the basic flow of "open - save - preview - send test" has been confirmed.

Why It Matters to Enable Templates One at a Time

YayMail can manage template activation. If you apply a new design to all emails at once, it becomes hard to tell which specific template is causing the issue: the admin email, the customer email, a refund, an invoice, a note, or a password reset. Enabling them step by step helps separate design from order logic.

After enabling the first template, place a test order or change the status of a test order so WooCommerce sends the target notification. Then review the email in a real mail client, not just in the preview window. Preview shows the layout and data, but mail clients handle tables, widths, images, background colors, and buttons differently.

How the Editor Works: Templates, Elements, and Preview

YayMail's main strength is its visual workspace, where the user chooses an email type, adds elements, changes styles, and sees the result alongside the controls. The documentation describes a left panel with tools, elements, patterns, settings, and history, plus a right-side area with the top toolbar and email preview. It feels similar to a page builder, but it is important to remember that the final result is sent to mail clients, not rendered as a normal web page.

In email, you cannot think the same way you do when building a regular website page. Overly complex grids, heavy images, aggressive backgrounds, tiny text, and unusual fonts can render very differently in Gmail, Apple Mail, Outlook, and mobile clients. That is why it is better to build a YayMail email from simple to complex: header, key message, order table, addresses, action button, support, and footer.

The Template List and the Email Source

The email templates screen is useful for more than just seeing which emails you can edit. It also helps you understand where a specific template comes from: WooCommerce itself or a third-party extension. That matters for stores using subscriptions, shipping tools, custom statuses, gift cards, marketplaces, and multilingual setups. If an email is created by another plugin, YayMail may require Pro features or a dedicated add-on, and sometimes the third-party plugin must expose the data itself.

So before editing any non-standard email, ask two questions: does the extension create a separate email template, and are the required data points visible in that extension's standard email. If the data is not present even in the original email, the visual editor cannot pull it out of thin air. That is a common source of expectations that later turn into shortcode and field problems.

Email Elements

Use elements in the editor as building blocks, not as decoration. For an order email, you usually need:

• A logo and a short branded heading.
• A clear message about the order status.
• A product table with prices, quantities, and totals.
• A shipping address and payment details, if appropriate for that email.
• A button or link to the account area, invoice, support, or instructions.
• A footer with contact details, return policy, and social links.

Do not add every available element just because it exists. A transactional email should help the customer complete an action and understand the order status. Marketing blocks, coupons, and recommendations only make sense when they do not compete with the main information or feel like noise.

Preview with Real Data

Previewing against a test order is one of the most important stages of setup. It shows how the customer name, order number, products, addresses, coupons, shipping, and other dynamic data are populated. If the preview contains empty areas, do not rush to treat the template as finished. Check whether that data exists in the order itself, whether the correct email type is selected, and whether the fields belong to a third-party extension.

Result check: a good template should stay clear even on an order with two or three products, a discount, shipping, and a long product name. If the layout only works on a perfect short sample, it is not ready for a live site.

Detailed Configuration After Installation

YayMail setup should start from the store's repeatable email system, not from visual polish. If you build each template separately, they will drift apart within a few weeks: a different button color, a different footer, inconsistent support wording, a forgotten link, or an old logo. A better approach is to build a common foundation first and then adapt individual templates.

A Unified Brand Foundation

Start with the elements that should repeat across most emails: logo, button color, background, primary font, support contact, and links to shipping and return policies. If your version includes Global Header & Footer, use it to create a consistent top and bottom block. YayCommerce documentation describes this as a way to apply a common header and footer to all templates, while still allowing per-email overrides when needed.

A typical store setup looks like this:

• In the top block, keep the logo, a short brand line, and, if needed, a link to the customer account.
• In the bottom block, add support contacts, business hours, and links to shipping, returns, and data handling policy.
• Do not overload the footer with a full site menu. In an order email, the customer needs two to four useful links, not homepage-style navigation.
• Check text and button contrast on both light and dark backgrounds if you use a custom palette.

If an individual template looks wrong after enabling the global block, do not disable the whole system right away. First check options like Hide on this template and Override content, then decide whether only that email needs a custom override.

Templates, Patterns, and Reuse

In newer versions, YayMail expands the idea of patterns and a reusable library. That is useful for blocks that do not belong in every email but are repeated across a certain group. For example, a post-purchase support block can be used in Processing order and Completed order, while a return-instructions block may fit both a refund email and a customer note email.

Before reusing a block, check whether it contains copy that only fits one status. A common mistake is to copy a block from a "completed order" email into a "processing order" email and leave wording that makes the customer think the shipment has already gone out.

Colors, Typography, and Email Width

Simple design choices work best in email. Pick one primary brand color for buttons and links, a neutral background for the email body, and a calm text color. If global color variables or presets are available, use them as a single palette source. Do not turn every template into a separate color experiment.

Keep the email width moderate. On a large monitor in preview, a wide email can look dramatic, but in a mail client and on mobile it becomes harder to read. Place critical copy, the order summary, and the action button so the user can see them without horizontal scrolling.

Attachments, Import, Export, and Backups

If your version supports attachments, use them carefully. A shared file for all emails works for a universal document, such as instructions or service terms. A file tied to a specific template makes more sense when it is truly related to that email status. Do not attach large PDFs to every notification if a link to a site page is enough.

Before major changes, export your templates or create a backup through YayMail tools if they are available in your version. That is especially important before an update, a migration to another site, or a rework of your brand style. Restoring from a backup is faster and cleaner than manually rebuilding ten emails.

Global Header, Footer, and Brand Recognition

The global email header and footer are one of the most practical features for a store that regularly changes promotions, support details, contacts, or visual style. Instead of opening every template separately, the administrator maintains shared blocks. That reduces the risk of outdated links and inconsistent email design.

But shared structure does not mean every email should feel the same. The main content still needs to reflect the order status. In Processing order, the customer expects confirmation that the order has been received and is being handled. In Completed order, shipping details, post-delivery instructions, a support link, and, where appropriate, a review request matter more. In Refunded order, the tone should be calm and service-oriented, not sales-driven.

How to Build a Basic Header

Keep the top of the email short. A logo, store name, and one line of context are enough. Do not place a large promotional banner above the order information. The customer opened the email to understand the status of a purchase, not to see a banner. If you need to add a seasonal promotion, it is better placed below the main information and only in emails where it does not get in the way.

How to Build a Useful Footer

The footer should answer the question, "What should I do if something is wrong?" Add a support email, links to shipping and returns pages, the customer account area, and, if needed, your legal address or business details. Social icons can be helpful, but they should not be the main content of the footer.

If the store operates in multiple languages, do not only check the text translation. Also verify that the global header and footer are inserted correctly for the appropriate language. YayMail sources mention integrations with WPML, Polylang, TranslatePress, Loco Translate, Weglot, and GTranslate in Pro comparisons, but the exact implementation depends on your stack and active extensions. So validate each language against a separate test order.

Dynamic Data, Hooks, and Conditional Blocks

The most valuable part of a WooCommerce email is not the background or the icons. It is accurate order data. In YayMail, that comes through shortcodes, WooCommerce elements, preview against a real order, and, when needed, the Hook element. But it is important not to invent variables. Use only the data that actually exists in the order, the default WooCommerce email, or a supported extension.

When Shortcodes Are Enough

For the customer name, order number, address, products, totals, coupon, payment method, and similar data, the built-in elements and placeholders are usually enough. After inserting them, test the result on an order with full data. If a value is empty, the reason may be straightforward: the field is missing from the order, the wrong email type is selected, or the data belongs to a third-party plugin.

When You Need an Add-on or Pro Integration

If the email must show shipment tracking, checkout editor fields, subscription details, bookings, gift card data, marketplace data, or a custom order status, check the list of integrations and add-ons. YayCommerce documentation makes an important point: Pro is not the same thing as having every add-on, and some extensions require a separate add-on for new email templates. That is not a minor technical detail. It matters when planning the implementation.

A practical example: if shipping tracking data does not appear in the email, first check whether the original shipping plugin displays it in its own standard WooCommerce email. If it does, there may be an integration path. If not, the data source issue needs to be solved before the email design.

A Safe Example with a Custom Hook

YayMail documentation describes using standard WooCommerce email hooks and adding a custom hook via PHP. Not every store needs that. It makes sense when a developer wants to output a short service block that is not stored as regular template text. The code below is a structural example, not a universal recipe for every store. Add it through a child theme or a plugin such as Code Snippets, and create a backup before making changes.

add_action(
    'store_email_support_note',
    function( $data ) {
        $render_data = isset( $data['render_data'] ) ? $data['render_data'] : array();
        $order       = isset( $render_data['order'] ) ? $render_data['order'] : null;

        if ( ! $order ) {
            return;
        }

        echo '<p>If your order needs a note from a store manager, reply to this email and include your order number.</p>';
    }
);

After adding the code, in the Hook element choose the Custom mode and enter the short code [yaymail_custom_hook hook="store_email_support_note"]. Then open the preview for a test order. If the block does not appear, disable the snippet, clear the site cache, and check whether a PHP error occurred. Rolling back is simple: remove the Hook element from the template and deactivate the snippet.

Do not use this kind of code for critical payment instructions, legal notices, or data that must depend on complex conditions. That is better handled as a dedicated development task and tested as part of WooCommerce logic.

Practical Example: An Order Confirmation Email That Reduces Support Questions

Let's look at a concrete scenario. The store sells physical products, ships orders after payment, and wants the Processing order email to be more than a default order table. The goal is to show that the order has been received, list the purchased items, explain the next step, provide a support link, and prepare the customer for the later completion email.

Goal

Create a clean HTML email where the customer can immediately see the order status, number, items, address, next step, and support contact. The email should not place unnecessary promotions above the order information, and all dynamic data must be verified against a test order.

Preparation

Before you begin, confirm that WooCommerce sends the Processing order email, that the email is set to HTML format, that you have a test order with a product, shipping, and a customer email, and that WordPress can send test emails. If the store uses SMTP, validate test sending in the SMTP plugin first.

Configuration Steps

1. Open the email templates list in YayMail and select the Processing order email.
2. Add or enable the global header with the logo and a short line such as "Your order is being processed."
3. Keep the order details block and the product table in the main content area. Do not remove them for the sake of a nicer banner.
4. Add a short message before the table explaining that the store has received the order and will send the next notification after processing.
5. Below the table, add a support block with an email address, help page, or brief note about what information to include when contacting support.
6. Add a footer with shipping and return terms, but do not overload it with a long menu.
7. Open Preview Email, select a test order, and check the real values.
8. Send a test email to your own address and review it in a normal mail client.

Expected Result

The customer sees a branded email, but the main information still comes first. The order number, products, and address do not get lost among decorative blocks. The button or link leads to the place where the user can check the order or get help. If the email is opened on a phone, the table should not make it hard to read.

A Common Issue That Gets in the Way

If order data is missing in the test email, do not replace it with manual text. Check whether the correct test order is selected, whether the required fields are filled in, whether a required WooCommerce element was removed, and whether the missing variable actually belongs to a third-party extension. Manual copy goes stale quickly and can mislead the customer.

How to Validate the Email Before Publishing

Validation should happen in several layers. Preview inside the editor is useful, but it does not replace a real send. A test send is useful, but it does not replace an order with real data. And an order with ideal short product names does not replace one with variations, discounts, shipping, and a long address.

Validation in the Editor

In Preview Email, choose the email type you are editing and a test order whose structure is as close to real life as possible. Check the following:

• Whether the customer name, order number, and products are populated.
• Whether the address blocks, coupons, shipping, and total amounts are empty.
• Whether long product names are cut off.
• Whether buttons and links are visible against the email background.
• Whether a technical shortcode appears instead of a value.

Validation in a Mail Client

After previewing, send a test email. Open it in webmail and on a phone. If possible, test at least one Outlook-family client, because it is often stricter about tables and styles. Do not chase perfect pixel matching across every client. The goal is for the email to remain readable, keep all essential data visible, preserve working buttons, and present the brand cleanly.

Validation on a Real WooCommerce Event

The final test is the actual event that triggers the email. Create a test order or change the status of an existing test order so WooCommerce sends the notification you are targeting. If the editor's test email arrives but the WooCommerce-triggered email does not, the cause may not be YayMail at all. It may be the settings of that specific WooCommerce email notification, the order status, the recipient, or the mail queue.

Quick takeaway: a template is only truly ready after three checks: preview with data, a test email from the editor, and a real WooCommerce event on a test order.

Practical Ways to Use It Without Overloading the Email

After the basic setup is complete, it is tempting to add everything to your emails: banners, coupons, product suggestions, reviews, videos, social links, extra instructions, and personalized blocks. In a WooCommerce email, all of that should be used carefully. The main information must stay first, and extra blocks should support a specific scenario.

Processing Order Email

For Processing order, a short confirmation, a clear order table, expected processing time, a support link, and a note about the next email work well. A coupon for the next purchase can sit lower in the email if it does not distract from the current order.

Completed Order Email

In Completed order, useful additions include post-delivery instructions, a download link for digital goods, a product care note, a review request, or a repeat-purchase block. But the review request should stay subtle. The email is still transactional, not a marketing campaign.

Refund Email

In Refunded order, an aggressive upsell does not belong. It is better to explain what happened, when processing will occur, where to reach out, and what information to prepare. The tone should reduce tension, not sell.

Emails with Custom Statuses

If the store uses a custom order status, first check whether the extension creates a separate email and whether there is support in YayMail Pro or an add-on. For these emails, it is especially important not to rely on generic copy. A "ready for pickup" status needs an address and business hours, a "pending approval" status needs instructions for both the manager and the customer, and a "handed off to carrier" status needs tracking.

A Precise Video Walkthrough of the YayMail Interface

For a visual introduction to the product, you can watch a video that shows the YayMail interface and the general logic of the builder. It is useful as a quick reference for searches like "how to use YayMail" and "WooCommerce email customizer setup," but you should still compare your final actions against the current documentation and your plugin version.

When CodeCanyon YayMail Is the Right Choice

CodeCanyon YayMail is worth using if you want to manage WooCommerce emails as part of the customer experience: make them branded, clear, testable, and more useful after a purchase. The plugin works especially well where there are multiple order statuses, repeat purchases, post-payment instructions, support touchpoints, coupons, tracking, or multilingual scenarios.

Before launch, keep a short checklist in mind: WooCommerce emails are enabled, HTML format is selected, a test order is prepared, SMTP has been validated, the first template is saved, the preview with real data looks correct, the test email arrives, and a real WooCommerce event sends the intended notification. If that path is covered, you can gradually roll out the remaining templates.

If, after setup, you can see that the product fits your workflow, move on to the download section and go to download CodeCanyon YayMail. Install it first on a staging site or on one safe template, then expand the setup to the rest of the store emails.