a.a.martines

Looks like some kind person has fixed this in their own git fork of the plugin! For anyone else with this issue, you can grab their fixed version here:

I hope this plugin is still being supported. The lack of response here and in the Git support forum is concerning.

Looks like some kind person has fixed this in their own git fork of the plugin! For anyone else with this issue, you can grab their fixed version here:

I hope this plugin is still being supported. The lack of response here and in the Git support forum is concerning.

I’m having the same problem. I hope there can be a resolution to this!

I’m also seeing this same hack on 12 sites on the same IONOS 1&1 server. No themes or plugins in common across the site, so I suspect mllapan was right about them accessing the main htaccess in the server. Would be interested to know if anyone has pinned down a source!

Thank you for your response, Chris.

That message you shared did not appear when we disabled Woo Payments. It would have been great if it did! I’m not sure if it’s something you all added recently or just didn’t work on our site. It was back in December that we first disabled it. I’m glad that there’s a warning and hope other people don’t run into the same issue as me.

It’s also great that there’s documentation about it. Honestly, I didn’t even think to look into it because the idea that subscriptions could continue even after it was removed to the site didn’t cross my mind. Everyone in my network I’ve spoken to about this issue is absolutely floored that this is how Woo Payments works by default, so I don’t think I’m alone in being taken by surprise.

To address my concerns about sharing data with Woo and Automattic, I know that you all have an open source philosophy and try to be good stewards of WP in general. And I think that overall you do a very good job of it. But I’m also well aware that, to compete in our industry, you often have to be ruthlessly capitalistic, and over time I’ve seen some of the business decisions Automattic has to make and how harmful they can be.

The privacy document you shared doesn’t really reassure me here. It says things like “This documentation outlines what data is stored and shared with a payment provider when a WooCommerce site uses?payment gateways offered on WooCommerce.com. When using a payment gateway, you are not sharing this information with WooCommerce.com.” That’s an interesting statement, since the support person I worked with could see and affect every transaction that’s happened on my site. With that level of access, what’s to stop a rogue support person from affecting every site they can reach? That policy is super sparse, and doesn’t really disclose the level of access Woo has to any store that uses Woo Payments. It’s a level of access I’m not comfortable giving to a third party company as a business owner, and my clients wouldn’t be either.

Again, thank you for taking the time to respond. I do really appreciate it.

Well, glad it’s not just me! Thanks for taking the time to answer!

Unfortunately, this account has over $2k in paid plugins licensed to it, so just creating a new account won’t do the trick for me.

Thanks, Steve! Glad to hear there’s a resolution on the way. No huge rush on my end – we’ve just disabled PublishPress for now.

Thanks, Steve!

It looks like this only happens with the Classic Editor plugin enabled.

Here’s what I’m seeing in the console. My hosts error logs aren’t picking up anything in particular.

Hi Steve,

Thanks for getting back to me!

I don’t need PublishPress Revisions to save any ACF fields for me. I just need it to not cause the saving/updating issues outline above on my site for posts that have ACF fields enabled on them.

Are you saying that PublishPress Revisions will continue to cause this issue on my site due to incompatibiliy unless I pay for the Pro version, even though I don’t need any features in the Pro version?

Finally! A response! Thank you!

I contacted you through the contact form at https://www.relatedpostsforwp.com/ since there’s no email address listed. I never got a response, never got a receipt for my initial purchase on 7/30/20, and never got any password reset emails. I checked my spam each time. I used a free gmail account.

My account is under [email protected].

Apologies – this is the wrong plugin forum. Please delete/disregard.

Yup! Fortunately, this is just a development site and the CPT didn’t have any real entries, so I just deleted it and re-created it, which fixed the issue.

No luck, unfortunately! I switched off all plugins except the Classic Editor and CPT UI and switched to the Twenty Twenty theme, and the issue persists for my existing “Prayer Requests” CPT. However, when I create a new CPT and toggle supports on and off, it seems to behave as expected.

I’m just on a basic Astra child theme, but we have about a billion plugins, so I’m guessing one of them is the problem. I’ll keep you posted!

Hmm ok. Definitely a problem or conflict on my end. I’ll troubleshoot futher. Thanks for your help!

• This reply was modified 4 years, 6 months ago by a.a.martines.