jpowersdev

Hi @enzorabante,

It looks like your theme is doing some interesting stuff with the scroll position at the top of the dayco.js file. You might take a look at that.

Jon

Hi @enzorabante,

If you just want something to activate the tab when the hash is in the current URL, the following should work:

jQuery(document).ready(function($) {
  if (window.location.hash) {
    const {
      hash
    } = window.location;

    if (hash.includes('#tab-')) {
      const title = hash.replace('#tab-', '#tab-title-');
      const titleElement = document.querySelector(title);

      titleElement.querySelector('a').click();
    }
  }
});

Let me know if that helps,
Jon

Hi @enzorabante,

Can you provide the script you are using? I’m not seeing it in my browser tools.

Thanks,
Jon

Hi @girofleeash,

First, I just wanted to say that the message you are seeing is a warning, and will go away if you turn off debug mode (or at least debug display, if you’re seeing it on the page).

That message means that the tab title is not available when the admin editor is trying to use it. Plugins like WPML that automatically edit product meta and/or take over the editing interface can cause strange bugs like this.

Are you still able to edit the tabs?

Jon

Hi @saimoon,

That other scrolling movement is coming from elsewhere in your theme. I wasn’t able to easily track it down using browser tools, but you might have better luck (as you have access to the files).

You could also just start blocking JS files from enqueueing (if there are several) until you track down the culprit, then start looking into modifying it from there.

Let me know if that helps,
Jon

Hi @rayge,

Unfortunately, what you’re experiencing is somewhat out of our control. If your Divi theme template files are circumventing the WooCommerce tabs system (that our plugin extends), there is little we can do.

Not sure if this meets your needs, but you could create a child theme that overrides the tabs.php file with the modifications you’ve described, which would prevent you having to do it each time your theme is updated.

If you find a way to inject tabs into the divi tabs module via code, you can fetch our tabs by pulling the yikes_woo_products_tabs meta for a given product.

Let me know if that helps,
Jon

Hi @eugenealtman,

It looks like the tab link for the description tab has been hidden using display: none;, but the tab markup is still being rendered, so the content for that tab is displayed when the page loads (as is standard). You’d need to altogether prevent the description tab from rendering on the page to do what you’re looking to do.

I’m not sure if Elementor has the ability to truly remove tabs, but I would recommend you do one of two things:

1. Use our Premium addon, which allows you to disable the built-in woocommerce tabs as described here – https://yikesplugins.com/knowledge-base/custom-product-tabs-pro-settings/
2. Use the woocommerce tabs filter to unset the description tab as described here – https://woocommerce.com/document/editing-product-data-tabs/#section-1

Let me know if that helps,
Jon

Hi @1erwin2,

This looks like an issue with the JS in your theme. I’m seeing the following snippet in your theme’s custom JS file –

// *only* if we have anchor on the url
    if (window.location.hash) {
        $(window).load(function () {
            var sectionid = window.location.hash;
            sectionid = sectionid.replace('/', '');
            if ($(sectionid).length > 0) {
                $('html, body').animate({
                    scrollTop: $(sectionid).offset().top - hHeight
                }, 1000);
            }
        });
    }

That snippet attempts to animate the scroll to an element. The problem is, the tab is hidden when the animation happens, so the offset is 0 (the top of the page). You’ll need to either remove that section, or modify it to handle tabs correctly.

Jon

Hi @lorysapo,

No problem! wp_postmeta stores all the “meta” about your different posts, and is basically) where anything other than title and body content lives. If you replaced the whole table, that would be pretty similar to restoring a backup, as anything newer than the backup would still be missing.

Jon

Hi @lorysapo,

Unfortunately it’s not a table, it’s a meta key. There will be thousands of rows in the wp_postmeta table, but some of them will have that key. You could delete all of the items with that key, but you’d still have to find a way to import the values from the previous database with only that key.

Jon

Hi @annettepixie,

We have a fairly extensive list of filters and actions that you can hook.

That being said, there shouldn’t be a space in & #39;. If you find a way to get rid of that, it should be correctly treated as a single quote.

Let me know if that helps,
Jon

• This reply was modified 2 years, 11 months ago by jpowersdev. Reason: It was decoding the html entity

Hi @lorysapo,

Unfortunately, if you’ve deleted the plugin completely, the plugin will clean up the database to avoid leaving any unwanted data. There’s not an easy way to undo that beyond restoring a backup.

The tabs are stored in the wp_postmeta table. yikes_woo_products_tabs is the key, and each will be associated with a certain Post ID. You could take the backup, set it up on another environment, and create a script to pull out the tab meta assignments into a spreadsheet. Then you could create another script to upload that information to your new site. We don’t have any sort of automated tool for this, but extending WP CLI is probably your best bet here.

You might also be able to find some sort of plugin that allows you to copy just meta, or just certain types of meta between sites. I’ve never used a tool like that, but it strikes me as the sort of thing that would be on the plugin marketplace.

I’m sorry that this likely isn’t the answer you’re looking for. Missing and corrupted data is often very tricky to resolve.

Let me know if that helps,
Jon

Hi @saimoon,

I see what you’re talking about. First, I do want to say that our plugin doesn’t provide any styles or scripts to manage this. The script you are using generally works, but it’s entirely dependent on your theme.

To address the scroll position, you can do something like this:

const container = tab.parentElement.getBoundingClientRect();

jQuery('html, body').animate({
    scrollTop: container.top
}, 300);

That will get the physical position on screen of the “tab list” element and use that to determine the scroll position.

However, and I can’t be sure this will happen if you replace what you have, but in my testing there was some other script causing it to scroll back and forth to the top of the page a few times before settling on the correct position. I didn’t find anything immediately, but there are a few minified scripts in your theme that deal with scrolling. You should probably investigate those if you see this behavior as well.

Let me know if that helps,
Jon

Hi @kiwimeg,

I can’t speak for all versions of Divi or the Divi Builder, but a few months ago we encountered some tickets regarding an update made to the Divi Builder that circumvented the normal WooCommerce tabs in favor of their own tabs system, rendering our plugin useless on pages using the Builder. You can have Divi installed, but if you use it to edit your products, those products likely won’t have access to the WooCommerce tabs that our plugin extends.

Jon

Hi @sitebites,

Ah, thank you.

I took a look at your homepage, and in the browser console I’m seeing an error that your Mailchimp popup form embed script is failing to load the form. Uncaught Error: xhrFailed is the message. It’s possible that the embed script needs parameters changed, or something like that. It’s not coming from our plugin, but changes in your Mailchimp account is the likely culprit as it was with our plugin.

Let me know if that helps,
Jon