inspired888

Okay. Thanks.

I found a different sticky add to cart bar plugins that does what I require. So I will run with that one.

As I did into the HTML output, I am wondering if you misunderstood my question. The necessary HTML for display stock status is there in your plugin’s output. The associated containers are all set to display (and not be hidden). Yet they don’t show up in the front-end.

My question is simply, why does it not display when it exists in the page source?

Here’s a good example of this implemented: https://solbox.dev/demo-sticky/product/motorcycle-repair-shop-violet-printed-tshirt/

Okay. Thanks for the reply.

That seems a bit odd to me. I don’t see why the In Stock / Out of Stock data would need to be any more “Real time” than it is on the underlying product page. Which obviously isn’t strictly real time. If the product is out of stock when the page loads, then it outputs the out of stock message on the product page. The sticky bar could just as easily do the same, without any additional issues.

I suggest you ask your developers to rethink their logic on this particular point.

To me it would make sense for your ATC plugin to simply output the default WooCommerce stock data that’s passed to the product page. There’s really no rational reason not to do so. Rather than intentionally blocking that data, since it’s being generated anyway for every product page when rendered.

Same issue here. 4 months later from above incidence.

Fatal error: Cannot declare class Debug_Bar, because the name is already in use in /public_html/wp-content/plugins/debug-bar/debug-bar.php on line 20

Running:
Query Monitor v3.16.4

Trying to activate … Debug Bar v1.1.6.

I also have WP Debugger running, in case that’s somehow playing a part in this, since it’s what was requesting me to install and activate Debug Bar and Query Monitor.

If I disable Query Monitor, and then enable Debug Bar, I also see this showing up … Deprecated: The called constructor method for Debug_Bar_Panel::Debug_Bar_Panel class in Debug_Bar_Panel is deprecated since version 0.8.3! Use __construct() instead. in?/public_html/wp-includes/functions.php?on line?6078 which isn’t critical, but should be addressed at some stage.

It’s worth noting … If I activate Query Monitor after activating Debug Bar, I am able to activate Debug Bar without the class error occurring, and Query Monitor activates fine after that..

• This reply was modified 3 months, 1 week ago by inspired888.
• This reply was modified 3 months, 1 week ago by inspired888.

Thanks for getting back to me Ruman, and for making the comprehensive video. I apologise for taking so long to respond. I was busy working on other projects. I will take a look at your video and see how I get on.

One of the reasons I’m didn’t follow up sooner with this enquiry, is that when I did a performance test the results were not good. I repeated the test a couple of times, using Woody and Code Snippets combined (the existing setup), compared to using FluentSnippets instead, and each time the performance dropped rather than improved. It was sitting around 84% on Gtmetrix, and would drop to around 70% when using FluentSnippets. I was expecting performance to either remain similar, or ideally to improve. But this wasn’t the case.

I’m pretty sure it’s on the verge of being abandoned. I did get a response by the developer to a recent question on the forum.

But, I actually decided to not use this plug-in after testing it out. When I tested the performance of a site on which I had perhaps 10 to 15 snippets (using two other snippet plugins), and migrated them all into this plugin, it actually degraded the performance of the site. I determined this from performance tests before and after migrating the snippets, and repeated a couple of times. So I was not impressed. Was hoping this plugin would improve not worsen performance.

I’ve found the conditional logic doesn’t actually work. So although there are settings for achieving some of what the OP mentioned, in practice it’s not usable (at least no in my experience).

Thanks for the clarification Fernando.

It might be worth adding this detail to the plugin description.

All the best … Jonathan

Great. Thank you. I didn’t see that when I skimmed over the settings.

Great. I see with 7.1.4 HPOS is now supported.

Thanks David for your work on this.

• This reply was modified 11 months, 3 weeks ago by inspired888.

Hi @gravid7,

Do you have any news or updates on this?

Thanks very much …
Jonathan

I can see that the emails (the resent emails) have their content-type set to text/plain. Obviously that should be set to text/html.

As a temporary workaround/solution, I have added code the forces all emails to have the text/html value in the content-type header.

E.g.:

add_filter( 'wp_mail_content_type', 'set_html_mail_content_type' );

function set_html_mail_content_type() {
    return 'text/html';
}

Ideally this code wouldn’t be required, as it may cause issues if at some stage a text email is intentionally sent. Not likely on this particular site, but as it’s a hack/workaround it would be good to resolve the underlying cause instead.

This issue appears to be server specific.

It’s not occurring on another site I manage, which is on a different server configuration. It also continues to occur on the site in question even with all other plug-ins disabled, and using just a default WordPress theme.

So it doesn’t appear to be a plugin conflict, nor a theme / custom theme code issue.

I’ll just chime in here … This was may issue. Autoptimize was stopping it from working. Will need to exclude the JS of this plug-in.