jpowersdev

Hi @rscrouse3211,

Unfortunately, the issue is not with the version of our plugin, but rather Divi’s Builder replacing the standard way of interfacing with WooCommerce tabs.

We had a conversation about a month ago with some members on the support forum stating that due to a Divi update, our plugin no longer works with the Divi Builder. If you use the regular editor for a given product, our tabs should show. If you use the Divi Builder, they will not.

Here is the thread – https://wordpress.org/support/topic/all-custom-tabs-are-gone/

Let me know if that helps,
Jon

Hi @jessie1,

Your theme’s markup looks pretty standard, so the conflict is probably elsewhere.

Since you are using Elementor, can you try enabling Page-Builder compatibility?

Let me know if that helps,
Jon

Hi @antwake,

Glad I could help. Let us know if you need anything else.

Jon

Hi @andrew55,

It’s ES6 syntax, and your editor may be set up for an older version of JS.

You can replace it with window.onload = function () { if you’re struggling to update your editor.

Jon

Hi @andrew55,

Please try using the following instead:

// Run when the page is done loading.
window.onload = () => {
    // Define function for scrolling to a tab.
    function scrollToTab(tabTitle) {
        // Define variables.
        const tabLink = document.querySelector(<code>#tab-title-${tabTitle} a</code>);
        const tabContent = document.getElementById("tab-" + tabTitle);

        // Handle scenario where tab does not exist.
        if (!tabLink || !tabContent) {
            console.log(<code>Tab '${tabTitle}' not found on page.</code>);
            return;
        }

        // Click the link to expand the tab.
        tabLink.click();

        // Scroll to the parent container of the tabs.
        tabContent.parentElement.scrollIntoView();
    }

    // Define the click handler for links to a given tab.
    function handleTabClick(event) {
        if (event.target.hash && event.target.hash.includes("tab-")) {
            // Ignore other click events.
            event.preventDefault();

            // Scroll to the tab in question.
            scrollToTab(event.target.hash.replace("#tab-", ""));
        }
    }

    // Register click event listener.
    document.addEventListener("click", handleTabClick);

    // Check if the current location includes a tab hash.
    // Scroll to the tab if it does.
    if (window.location.hash && window.location.hash.includes("tab-")) {
        scrollToTab(window.location.hash.replace("#tab-", ""));
    }
};

If the page contains a hash including tab- or if a given link on the page contains a hash including tab-, the above code will click on the link to open that tab, and then it will scroll to it. Otherwise, it will log to the console that the tab was not found.

Please let me know if you have any trouble getting it to work,
Jon

Hi @antwake,

I’m sorry, I misunderstood. Unfortunately no, the tag (or some other manually added information) is the only way to distinguish. There’s not much you can do to retroactively determine their origin.

The subscriber count is based on submissions from the forms themselves, not data coming from Mailchimp. You may be able to compare those numbers with the numbers from Mailchimp to get a general sense of the success of each form contributing to the single audience.

The data is stored in the wp_options table by default unless the YIKES_EMCE_CUSTOM_DB constant is set to true, in which case it uses the table you referenced. The table is created regardless during the activation process, and is deleted when deleting the plugin.

Let me know if that helps,
Jon

Hi @rscrouse3211,

It should be in the same place as the Description, Additional Information, and Reviews tabs (which are part of WooCommerce). Does your product page contain those tabs? If not, it might be the case that your theme doesn’t use tabs, or has them hidden for some other reason.

I’d be happy to check the HTML of the page, but it looks like your site has basic auth enabled.

Jon