[Support request] GP Premium WooCommerce module incompatibility with Beaver Themer

Home Forums Support GP Premium WooCommerce module incompatibility with Beaver Themer

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #1098964
    wekhter

    Hi, I was experiencing a strange issue when trying to customize my shop archive pages with Beaver Themer (official beaver builder plugin). When investigating where the issue was coming from, I realized that it happened whenever the GP Premium WooCommerce module was active.

    Background info: Beaver Themer is an official add-on for Beaver Builder that lets you customize certain things that are normally restricted to theme template files. It has targeting rules similar to GP Premium Elements, but includes a visual interface and can target & customize the actual layouts of things like archive pages/search results.

    Issue: While the GP Premium WooCommerce module is active, WooCommerce post archive modules end up losing a closing /div tag. This means that any elements added after a post archive are no longer editable/selectable in the builder interface, since they confuse the editor into thinking that those modules are part of the post archive module. Deactivating GP Premium WooCommerce module lets modules inserted after post archives to be editable again.

    It seems like the archive customization options in GP Premium WooCommerce module is altering the archive in such a way that it’s going to Beaver Themer with either an additional opening tag somewhere, or missing an ending tag. Help appreciated!

    #1099136
    David
    Staff
    Customer Support

    Hi there,

    are you able to share a link to an archive page with Beaver Themer and the GPP Woo module enabled so we can see if theres anything odd with the front end markup that may explain the issue.

    #1099205
    wekhter

    @David Here’s a link: https://gozen.com/shop/

    Also I wrote the issue slightly backwards in my first post, it’s not that there’s a missing closing /div tag, it’s that there’s an extra closing /div tag so modules after the archive posts aren’t nested properly. I was trying to be as specific as possible and got my explanation mixed up, oops!

    The following screenshot shows that after each fl-module-post-grid (the post archive module), the next module moves up a level. Every single one of these modules is supposed to be contained within fl-col-content.

    screenshot of improper nesting

    #1099395
    Tom
    Lead Developer
    Lead Developer

    Hi there,

    The GPP WooCommerce module does add an opening div (<div id="wc-column-container">) and a closing </div> later on to close it.

    Does the wc-column-container element exist on the page?

    #1099764
    wekhter

    @Tom No, it does not (just did a ctrl+f in the source code)

    #1100441
    Tom
    Lead Developer
    Lead Developer

    Hmm, so something in Beaver Themer is removing that element for some reason.

    Is it possible to ask their support team if a hook like this would be removed when using themer?:

    add_action( 'woocommerce_before_shop_loop', 'generatepress_wc_before_shop_loop' );

    That function adds the opening div element.

    Then we close the element with this (which I assume is still active on the page, causing this issue):

    add_action( 'woocommerce_after_shop_loop', 'generatepress_wc_after_shop_loop' );

    Perhaps they’re doing something with the woocommerce_before_shop_loop hook?

    #1102556
    wekhter

    They gave this answer:

    add_action( 'template_redirect', function(){
      if ( FLBuilderModel::is_builder_active() ) {
        remove_action( 'woocommerce_before_shop_loop', 'generatepress_wc_before_shop_loop' );
        remove_action( 'woocommerce_after_shop_loop', 'generatepress_wc_after_shop_loop' );
      }
    });

    Which just removes GP’s action when the builder is open. Not ideal since it still leaves the malformed divs on the site itself, but at least lets the pages be edited.

    #1102717
    Tom
    Lead Developer
    Lead Developer

    What’s strange is the first action is being removed by default it seems. I wonder if that solution would do the same thing with only the second remove_action?

    #1223996
    markus

    Also had this issue. This is working for me:

    Create a page redirect from the assigned WooComm shop page to a page I can edit in my page builder (shop-editable)

    i.e. redirect /shop to /shop-editable

    #1224002
    Leo
    Staff
    Customer Support

    Thanks for sharing 🙂

Viewing 10 posts - 1 through 10 (of 10 total)
  • You must be logged in to reply to this topic.