Michael Bourne

Cheers!

Hi @staceeandco

I always recommend resaving permalinks after changing plugin settings, especially since v2 has different redirect routes. This plugin is being used successfully on hundreds of V2 wineries, so I don’t believe there’s a plugin error.

I also recommend using the club button blocks the plugin provides and not hardcoding your own as you have for V1. The old /club redirects still work, but they are not a standard feature on V2.

That would be a question for Commerce7 support, this plugin does not affect their widgets in any way, it just integrates their platform as per their standard instructions in an easy way.

(their answer will be “no” for that though, to save you time)

For the sake of accuracy, and to help any future searchers, the columns breakpoint in Gutenberg is not determined by your theme, rather it is aggressively hard coded into Gutenberg core styles, with overly specific selectors and improper uses of !important.

If you want a custom breakpoint, you will need to override all of the .wp-block-columns css you find in /wp-includes/css/dist/block-library/style.min.css

Some pre-made themes might do this already.

Yes, <div id="c7-content"></div>

All default routes (profile, cart, collection, checkout, club, product) should have that div in place for C7 to inject content properly.

If you want a custom login page, you have to build it on a different slug. But most of us would recommend against that, just use the /profile page.

The login form shortcode is not meant to be used on the login page, it’s meant for custom landing pages. Your /profile/ route page should only have the standard c7 content div. With that in place, the email links will work.

Hi @quyle ,

You may have the wrong plugin here, we don’t have that file in our source nor do we support Icomoon ??

I strongly encourage users to migrate away from this plugin and use the native icon abilities provided by Elementor that were modelled after this plugin.

While we were the first to bring custom icons to Elementor, they eventually released their own version and weren’t interested in any sort of cooperation to resolve issues in their filters that enabled plugins like this to work effectively.

As such, development was paused. Efforts to have another development team take control of this plugin over the years proved fruitless.

That said, the plugin still works, has no obvious security issues, and shouldn’t cause you any problems in the near future.

Oddly enough I’m having the same problem as you on one website (Woocommerce based), but not on the other dozens of sites using this plugin (none are Woocommerce). None of the usual fixes work.

I’ll dig in a bit more and see what I can find. So far my findings are that the “javascript” options in the plugin isn’t working ta all on this one site, leading me to believe there’s a conflict somewhere. Lack of console errors is making it tough to figure out.

As for other plugins, there are none that worked as well or as lightweight as this once, hence me using it. Ironic I’m sure, but I wouldn’t move on just yet.

Ive seen it happen before. Few things to test: Under the Advanced tab, set the method to “no caching (javascript)” un” and disable “munge options” if its on. Also make sure “Disable AJAX fallback” isnt enabled if you don’t specifically need it to be.

If you’re using a caching/performance plugin with JS enhancements enabled, you might need to exclude all of the age gate JS files.

Then clear all your caches. Site, server, object, CDN, etc…

• This reply was modified 2 years, 1 month ago by Michael Bourne.

Hi @tharindu1995

Conversions need a trigger based on the purchase event in GTM, not a URL trigger. This event has a standard datalayer setup for Google Analytics 4.

https://developers.google.com/analytics/devguides/collection/ga4/ecommerce?client_type=gtm#make_a_purchase_or_issue_a_refund

Hi Betty,

As far as I know, this was always a Commerce7 issues with their V2 front end. If no payment is being collected, no name is required. it also happen son event tickets. I don’t believe they have fixed this yet.

Hi @honestweb

This is mainly a “product template” question. It sounds as though you had the default template in Commerce7. If you’d like to crate a custom layout, you can, you just need to upload it to C7. The plugin has no control over the template.

More information here: https://design-docs.commerce7.com/docs/product-templates-1

Hi Matt,

A few releases ago I added a feature to help prevent caching of that file, but every single 3rd party caching plugin for WordPress, and even some web hosts caching features will still cause this.

If you see a query string after the commerce7.js file, you need to manually add that file to an “exclusion list” in either your caching plugin, or your hosts settings.

Hi @kmcmillan

This is expected behavior. These are all required pages by Commerce7 for their dynamic routing. The pages will be created with a c7-content div in the post_content to enable widget.

The plugin does not delete these pages when deactivated, as the common scenario in deactivation is someone doing a manual integration, where they will need those pages anyways.