getsnoopy

Hi @bruberries, thanks for your answer. As a response:

The bug is not that MailPoet decided to choose some defaults that make sense for a large number of users; it’s that it doesn’t give the ability for users to opt out of the defaults that it (i.e., your team) chose.

The point of the template editor is to give users the ability to customize templates, is it not? That is, to allow them to make the forms and such blend in with their WordPress installation’s theme. (Even if that isn’t your goal, this indeed still does happen, as all of MailPoet’s templates still get the WP installation’s theme styles applied to them as a matter of course. And it clearly isn’t your goal to completely override the styles of the host installation’s theme and solely use MailPoet’s custom styles.) As such, this means that what is correct behaviour is determined by the user’s installed WP theme, and that requires MailPoet to be as adaptive as possible, not to be as tight/closed as possible.

Things like rem, em, and % units all use the theme’s defaults as baselines, which means the styles are more adaptive. Similarly, not having a forced Input Padding means that the theme’s default styles for input elements take over and the form elements look like they belong on the website…which, ironically, is what basically every user wants. Just the same, having the class be placed on the actual element being targeted (which is what the template editor UI implies, seeing as there’s no mention anywhere of an intrusive “Paragraph” element being inserted as a wrapper) allows users to target the actual element in question instead of a MailPoet paragraph element that is foreign to the user’s installed WP theme.

Again, though I (and many others like me, going off your very own Feature Request board) clearly believe that not having these forced things as defaults is the best way to go, it’s fine if you want to have them as defaults (and changing them would be a feature request). But to not give users an opt-out is the bug because you’re not allowing for possibilities your team hasn’t considered, which is highly likely given that—as you mentioned—there are thousands of themes out there, and it’s breaking layouts/styles as a result. Moreover, it seems like at least one of the things I mentioned above has already been a “feature request” on your Feature Request board for over 6 years, to no avail.

Finally, I found yet another couple of style issues with your template editors:

1. The Confirmation Email template editor (under Settings > Sign-up Confirmation > Enable visual subscription confirmation emails) doesn’t respect the Content background colour setting located under the Styles accordion header because there’s a background-color: inherit rule that’s clobbering the CSS style rule that sets the user-chosen background colour.
2. The footer of the email (where the “If you received this email by mistake” text exists) doesn’t follow the Text styles defined under the Styles accordion header, nor does it allow any sort of font or other customization.
3. The font size fields for the various textual elements (e.g., Heading 1, Text, etc.) are drop-down menus with fixed options instead of text boxes / number spinners that allow manual control, which is yet another point of frustration where I can’t control the text sizes in emails to match those on my website.

Like I said, it seems like CSS/style functionality in the plugin is broken in far too many places, so I would strongly recommend a sweep across your entire code base / feature set to make sure everything works properly.

Hello,

I’ve ruled out plugin conflicts, as I deactivated both of those plugins to no avail.

As for the code snippet, here was the output of it (i.e., the element was on the page, but it didn’t have any value in it):

widgetId: 

As for the workaround, yes, I’m already using workaround for the time being, but I wanted to surface this issue to you so that you could work on a fix for it.

Another aspect of this issue is that setting Font Family to Theme’s default fonts doesn’t have any effect as well, since there’s a large selector in some fixed CSS coming from the plugin that essentially targets all the text of the form and sets the font family and size of text in it explicitly, not allowing the body styles to cascade through:

.mailpoet_form_html p, .mailpoet_form_html ol, .mailpoet_form_html ul, .mailpoet_form_html li, .mailpoet_form_html dl, .mailpoet_form_html dt, .mailpoet_form_html dd, .mailpoet_form_html blockquote, .mailpoet_form_html figure, .mailpoet_form_html fieldset, .mailpoet_form_html form, .mailpoet_form_html legend, .mailpoet_form_html textarea, .mailpoet_form_html pre, .mailpoet_form_html iframe, .mailpoet_form_html hr, .mailpoet_form_html h1, .mailpoet_form_html h2, .mailpoet_form_html h3, .mailpoet_form_html h4, .mailpoet_form_html h5, .mailpoet_form_html h6, .mailpoet_form_iframe p, .mailpoet_form_iframe ol, .mailpoet_form_iframe ul, .mailpoet_form_iframe li, .mailpoet_form_iframe dl, .mailpoet_form_iframe dt, .mailpoet_form_iframe dd, .mailpoet_form_iframe blockquote, .mailpoet_form_iframe figure, .mailpoet_form_iframe fieldset, .mailpoet_form_iframe form, .mailpoet_form_iframe legend, .mailpoet_form_iframe textarea, .mailpoet_form_iframe pre, .mailpoet_form_iframe iframe, .mailpoet_form_iframe hr, .mailpoet_form_iframe h1, .mailpoet_form_iframe h2, .mailpoet_form_iframe h3, .mailpoet_form_iframe h4, .mailpoet_form_iframe h5, .mailpoet_form_iframe h6
{
	font-family: Arial, Helvetica, sans-serif;
	font-size: 16px;
}

@bsfherman, yes, I’m aware of there being an option to change the suffix. But from the screenshots in the plugin directory and elsewhere, it seems like the default suffix is “mins”. Is this not true anymore?

Hi @dnutbourne, any update on this matter? It seems like the issue still exists.