indrek_k

Hi @dpdbaltics

Any update on this?

Uhh, this is a very very tiny change, perhaps you could consider implementing it? It doesn’t change anything for other users, but just enables your plugin users to add functionality for sending tracking codes to customers. All the other shipping plugins we are using already provide this functionality.

My final proposition would be adding an action after the order note is created.
After woo-shipping-dpd-baltic/admin/class-dpd-admin.php line 520:

do_action('woo_shipping_dpd_baltic/tracking_code', $barcode->dpd_barcode);

Thanks!

• This reply was modified 3 years, 7 months ago by indrek_k.

This is actually a pretty good solution, thanks. I wouldn’t want to modify the plugin code, but perhaps the devs could make a simple change to the code base that would allow us to utilize this? For example, adding a filter around the 2nd param of add_order_note(). That way it could still default to false, but we’d have a way to change it.

Chiming in, just in case. Originally, this notice didn’t have anything to do with cache plugins being GDPR compliant. The point is that the pages generated by this plugin must be excluded from static page cache, otherwise they won’t work properly.

I’m not sure what the situation is right now, but unless specific exceptions have been added to the code for all available caching plugins, then I would not recommend removing this notice – maybe clarify it instead.

Got it. So I understand this is actually a part of the premium plugin, correct?

I took another look at the catalog and it seems that both variable products and variations are added to the catalog. Can you please clarify if this is expected behavior?

Thank you so much, the latest release fixed this problem!

+1

This would be a game changer.

Exact same problem here.

There are a couple of typos in the previous post. The command that actually works for me with WP CLI v2.3.0 is:

wp post delete $(wp post list --field=ID --post_type="shop_order") --force

Kudos for writing the docs. Not many devs have the patience (or capability) for that.

We recently moved away from Yoast and this brief conversation with you has confirmed that it was a good choice. Thanks again.

Awesome, thanks so much! Totally didn’t notice this function.

I recommend adding a note about this to https://theseoframework.com/docs/api/actions/ and https://theseoframework.com/docs/api/filters/

Thanks again!

Until you implement this, can you please add a big red flashy warning on top of the plugin settings page? I am requesting this in hopes that it will save someone else from a lot of frustration, headache and wasted time.

I left the plugin running for a week on a production website to debug an issue. We have 3 external integrations with logistics companies and apparently one of them did some pretty expensive API calls regularly. This was a good thing to find out, so in that sense, the plugin served its purpose. However, thanks to the plugin storing LOG ENTRIES in the MAIN WP POSTS TABLE (!!!!), our wp_posts table went from 17mb to 5GB, took down a production server, took our team half a day to clean up and resulted in a non-trivial financial loss for our client.

Lesson learned: audit *every* plugin thoroughly before installing. I usually get a pretty good initial sense of the code quality by just looking at the settings page, file names and structure – and everything looked good in this case. So I am still somewhat reluctant to take the blame here, because the idea of storing log entries in wp_posts is just so utterly absurd that it never would have crossed my mind.

Please add a warning.

Hi there!

Original author of the plugin here. I understand your frustration. However, I would not blame illuminate/support here – from their point of view, this is definitely not idiotic. Keep in mind illuminate/support a component used for Laravel (and other related tools/frameworks) and in that context, a global helper function makes sense. Instead, you might argue that I should have used some other IoC container that does not depend on a component that declares global functions. Unfortunately, during development I didn’t notice the global functions and I suspect that even if I had, I would still have used the plugin because come on, who would be silly enough to define global functions like e() in their plugin nowadays? ??

This is not the first time this exact same problem has been reported and the last time, it was caused by a completely different plugin. So regardless of what @data443 decides, I recommend you also get in touch with product-enquiry-pro and complain to them, as they are also breaking a basic plugin development rule and conflicting with at least one other plugin.

Awesome!