Thu P. a11n

Hi @nickrytlewski,

Thank you for reaching out, and I’m truly sorry for the frustration this has caused. I completely understand how concerning it is to see a payment method enabled on your store without your consent.

I want to assure you that we’re fully aware of the issue with the Link button being unable to be disabled, and we’re actively working with Stripe to resolve it as a priority. In the meantime, if you’d like Link disabled on your Stripe account right away, please get in touch with us here and we’ll take care of it for you: https://woocommerce.com/my-account/contact-support/#contact-us

I also noticed you’ve implemented custom code as a temporary workaround while we work on a permanent fix. Please know that enabling Link without merchant consent is absolutely not our intention. This was triggered at the account level, and we’re prioritizing a proper solution for all affected merchants as quickly as possible.

Thanks so much for your patience and for flagging this. We’ll keep you updated as soon as we have more information to share.

Hi there,

Thank you for taking the time to write such a detailed and well-structured feedback — we appreciate it!

I’d like to address each of your points:

1. Additional CSS classes applied to the wrapper element You’re right that the “Additional CSS classes” field currently adds classes to the mailpoet_paragraph wrapper <div> rather than directly to the form input or button element itself. I understand this limits the usefulness of theme-predefined CSS classes that expect to be applied directly to the element. I’ll make sure to note this feedback for future development.

As a potential workaround for now, you could use the Custom CSS panel in the form editor (available under the form’s Settings tab) to target the specific elements with more precise selectors. For example, you could use .your-custom-class input or .your-custom-class .mailpoet_submit to target elements within the wrapper.

2. Input Padding with no “unset” option & inline styles This is a known area of feedback. The inline styling approach for padding does make it difficult to override with standard CSS classes, as you noted. There is an existing feature request on our feedback board to address this: Remove inline styles from forms. I’d encourage you to add your vote there so the team can better gauge demand for this improvement.

In the meantime, the most reliable (though admittedly not ideal) workaround is to use !important declarations in your theme’s Additional CSS (via Appearance > Customize > Additional CSS for classic themes, or Appearance > Editor > Styles > Additional CSS for block themes) to override the inline styles.

3. No CSS unit selection for padding fields That’s valid feedback. The form editor currently only supports pixel values for padding, whereas the core WordPress editor allows for other units.

4. Font Family set to “Theme’s default fonts” not working I understand the frustration with the broad CSS selector that explicitly sets font-family: Arial, Helvetica, sans-serif on all form text elements. When “Theme’s default fonts” is selected, it should ideally allow the theme’s body font styles to cascade through rather than applying a fixed fallback.

As a temporary workaround, you can override the font-family using the form’s Custom CSS panel or your site’s Additional CSS by targeting the form elements specifically.

Thank you again for the thorough feedback. These are valuable observations that can help improve the form editor experience. It would be great to log these to our Feature Request Board, where other users can vote for your ideas and help with prioritization.

Hi there,

It must be frustrating when payments suddenly stop working on your store. I want to clarify that the error PAYMENT_SOURCE_NOT_ENABLED_FOR_TARGET: This account has not been enabled to take payments is returned by Square’s API — it means Square is rejecting the payment at the account level. This isn’t a bug or issue with the WooCommerce Square plugin itself.

This is a documented Square-side error (reference), and it’s typically resolved by:

1. Checking your Square location status — Go to Square Dashboard → Locations and confirm the connected location is active. Reactivate it if it’s inactive.
2. Completing any pending identity verification — In your Square Dashboard, check Get Paid → Verify Your Identity.
3. Disconnecting and reconnecting Square in WP admin > WooCommerce → Settings → Square to refresh the OAuth token.
4. Contacting Square Support directly — ask them to verify your account and location are fully enabled for API card processing.

If after resolving the Square account issue you’re still running into trouble with the WooCommerce Square plugin, we’re happy to help! Please create a support thread here: WooCommerce Square Support Forum — that way we can properly troubleshoot with your site details and logs.

If we can help get things working again, we’d really appreciate it if you’d consider updating your review. We’re here to help! 🙂

Hi @zimbo000,

The wp_mailpoet_scheduled_task_subscribers table tracks which subscribers were sent each newsletter. A row is created per subscriber per send, and marked as processed once complete. After that, the data is only used by the Inactive Subscribers feature.

So how far back to keep depends on that:

• Not using Inactive Subscribers? You can safely delete all older processed data.
• Using it? Keep data at least as far back as the inactivity period you’ve set in MailPoet → Settings → Advanced.

The other large tables are mostly statistics — _statistics_opens, _statistics_clicks, _statistics_newsletters track email engagement, while _sending_queues stores email content for each send job, and _newsletter_links tracks links in your emails. You can apply the same date-based cleanup approach from the KB article to any of them.

Just remember to back up first before making any changes on your database.

Feel free to get back to us in case you have any additional questions!

Hi @zimbo000, thanks for contacting us!

I understand you need to reduce the size of your database for MailPoet tables. We have documented our recommendations on how to safely approach that here: https://kb.mailpoet.com/article/402-reducing-database-size-for-mailpoet-tables

Feel free to get back to us in case you have any additional questions!

Hi @artankrasniqi1988, thanks for sharing your ideas! Currently, MailPoet doesn’t provide a way to manually mark posts as “sent” and should not be used in future emails as you described. However, this is an interesting idea that some users might find useful. It would be great to have you add this as a feature request, which is where developers go to look for future plugin features and improvements and other users to vote for your request.

Since each site’s configurations is different, when you have a moment, feel free to contact us by creating a ticket so we can look into your exact use case and setup to identify the issue.

Hi @gdegonzajr, thanks for sharing this with us.

To investigate further, we may have you install a debug version of the plugin on a staging site, please contact us at WooCommerce.com > My Account > Support. You may need to create an account before you can access that page.

Please include a link to this forum thread, so that we can keep track of what’s already been done.

We will be able to help you further there.