Detect empty body/subject when importing from simplenews

I guess it is a strange glitch corrupting your config. Save your policy again and the error should go away.

If you think it's a bug please provide steps to reproduce.

I can confirm this error and provide a little more context/information as to why it is happening. Simply resaving a policy isn't the answer (at least for the situation I was found to be in)

Both this: Warning: Undefined array key "content" in Drupal\symfony_mailer\Plugin\EmailAdjuster\BodyEmailAdjuster->settingsForm() (line 56 of /var/www/html/web/modules/contrib/symfony_mailer/src/Plugin/EmailAdjuster/BodyEmailAdjuster.php)
And this: Warning: Trying to access array offset on value of type null in Drupal\symfony_mailer\Plugin\EmailAdjuster\BodyEmailAdjuster->settingsForm() (line 61 of /var/www/html/web/modules/contrib/symfony_mailer/src/Plugin/EmailAdjuster/BodyEmailAdjuster.php) are produced on screen and in logs.

(Initially I found the thread for issue related to version 1.0.0-alpha7 [as the only google returned search result] and saw some info regarding fixes added to dev version, so I switched to that, shortly there after realized that wasn't the case being I was on 1.2.0-beta2 prior to dev and still received the errors on dev - and then through a little digging found this thread)

Anyway..

If new policies are introduced and it has a body field (listed as "content" for Symfony mailer) and that field is empty because it hasn't been edited yet or nothing was supplied when/if the policy was imported! The listed errors are produced.

In my case when I activated the "Simple News" module new policies were generated, I'm assuming during module activation with empty body fields (not sure if they are empty by design "which could be a Simple News module issue - unrelated" (only stating that as I would assume default/generic information you could/would edit should be applied for things like email confirmation, etc.) and as in my case weren't!

So when in Symfony Mailer policies (poking around to see what Simple News added after noticing Symfony Mailer had new policies to import and importing them) and as I opened each related to Simple News I received in page errors and matching PHP warning/notices in Drupal Dblog.

Simply adding information in the body/content area of each policy stopped the error from being reproduced. Any policies without a body field produced no errors upon checking through all policies after seeing the errors.

In regards to error handling in the future it may be ideal to add a check for Symfony Mailer to check for an empty body field in which case it wouldn't produce a PHP error with a large stack trace (making users feel there is an underlying problem "bigger than it really is") but instead just a simple notice to say this policy either needs the "required" body field / content added or the field removed from the policy to save without error.

- I'm not entirely sure why a policy would have a body field listed as "required" with a red asterisk, which also prevents saving and should a user close it because they aren't quite sure what they want to provide there yet, they in turn would get these errors again when they edit said policy in the future (and illustrates further why I feel a check for an empty body field should be added - providing notice on the policy edit screen, while preventing a PHP error logged to Drupal's DBlog)

At the same time that would also eliminate Symfony mailer as seen as the culprit if another module produced policies imported with empty body fields!

Thanks for a detailed explanation.

A body policy without any content is disallowed, and the form prevents creation of this. I don't wish to write extra code to handle bad config - sorry this not negotiable😃. I am happy to write code to prevent creation of bad config.

which also prevents saving and should a user close it because they aren't quite sure what they want to provide there yet

In that case remove the body policy and add it back later when you know.

You are right, the body field is not mandatory in simplenews - I am surprised by that because it's not sensible emails with empty subject/body. We could handle that case better, although I guess it's quite unusual. The code is in SimplenewsEmailBuilder::import(). I propose that the import should skip the import if either subject or body is empty. After #3303340: Add support for required adjusters → these policy elements will likely become required.

@AdamPS

Completely understand your point in regards to bad configs!

I know most developers including myself would recognize the need for subject and body in an email policy, but for a moment lets look at it from someone who is unfamiliar altogether with Drupal and email in general.

I would argue someone trying to set up a simple site for whatever purpose installs a couple modules to handle email (lets say Symfony mailer for one and then later happens to install additional 3rd party modules) "like Simple Newsletter" they may not fully understand how things are supposed to work, and should they look into documentation for said 3rd party module expecting certain "presets" or "example" emails they can edit or tailor to their needs to be available "and they are not" because Symfony mailer just didn't allow the import or deleted fields that should exist even when they are empty (they may not realize they need to add the fields if they were deleted on import and believe the policy is intact and ready for use), it would also likely leave them frustrated, confused and seeking support in likely the wrong place.

Don't get me wrong I absolutely agree "it doesn't make sense in any regard" for a module to provide a template email (be it a preset or example meant to be edited, passed to a mailer system policy) without anything present in a subject or body field if they are supplied.

My initial suggestion was to only make things less complicated "more so" for users who aren't all that familiar with how things really work!

From what I see you've noted with #3303340 "add support for required adjusters" reads like it would handle the situation well enough providing at least better feedback in warnings.

Regardless, and in any respect this module "Symfony Mailer" feels like it is going to be the best route for Drupal handling email moving forward and why I've opted to use it in place of the current standards with my current and future Drupal site development. I don't have limitless time (currently working to rebuild and migrate several Drupal 7 sites to Drupal 9 and 10 over the coarse of this year), but if there is anything I can do to help with this project let me know, I would be happy to help!

This module does provide a preset for email body and subject. On your site you overwrote this when you imported an empty body giving invalid config. With this issue I propose that the import is skipped if it would be invalid. Hence there would always be valid config, and no need to write code to handle invalid config.

Does that resolve your concerns?

Actually, none of the email presets provided by Symfony mailer were altered or overwritten when Simple newsletter configs were imported. It was just the new presets (for simple news) that came in with an empty body, and were the only ones that Symfony mailer threw an error for when viewing/editing them in policies.

My apologies if my previous comment caused any confusion in regards to the initial issue, that wasn't my intention.

My only concern was if someone didn't know they needed to add a body field later to an imported config because it wasn't imported being it was provided empty (as a bad config) they might get confused.

Again I can't speak in regards to Simple Newsletter (there may actually be a reason their config is the way it is) possibly because "I think, not 100% sure" there are options when creating a newsletter to include other types of node content as an import by means of auto generation on a scheduled send to recipients along with options for wrapping them with custom theming and styling. Don't quote me on that last, I haven't fully had a chance to dig through that module yet (it's meant to be a replacement on a Drupal 9 site currently being built where the Newsletter module (different module) was used on a Drupal 7 site the site being rebuilt in 9.

Again don't mean to make things anymore confusing (my sincerest apologies if I have), just trying to add a little more context.

Thanks for clarifying. Are you making a proposal for something to change? If so please explain what, as I have no idea at the moment.

Thanks everybody to shine a light on the issue. As Symfony Mailer still needs some love to work (I can't get it to send HTML of any kind in the body of mail, which is sort of a show stopper for the time being) I will caress the policies if this is what's needed.

However:

I perfectly understand that an email should have a body. BUT I usually don't use a body field, in fact, I remove it whenever I start a new template, as I have no need for summary and such. As I also like consistent naming, the default body field (with no field_* prefix) sort of leads to typos.

Hence I'd say an email should have a body, but this hasn't to be a body field als provided by Drupal in most content types.

My more sophisticated Newsletters are structured like this: A title, a subtitle/claim, a first paragraph which leads into the article, a teaser-image, any number of paragraphs, built with image or thumbnail (selectable by the editor), chapter-title & subtitle, copy, link. At the end of the newsletter there's a regular formal letter ending (Sincerely … PS.: …, you name it), which isn't used in the onscreen display. And there's a large legal disclaimer, plus sender's address and what not, some more logos, badges, links … 

I'd call this a perfect email body -- but it doesn't use the unwieldy Drupal body field.

Are you telling me I'm from now on required to use a Drupal body field to create valid email?

If so, I have to change quite a lot of already existing an wonderfully working email layouts, perfectly tuned to work with all sorts of mailers. I attached a screenshot of one of the mails "without any content" …

As a long time programmer I think no module should enforce the use of certain fields -- RFC doesn't require emails to have a Drupal body field, but a body section which -- in Drupal terms -- can be comprised from various fields. Even an image with an attached "title" which gets used as the body of an email would perfectly fit the RFCs I know.

As I'm a perfect n00b when it comes to PHP scripting and Drupal procedures and API, I have no idea as how you may build the body of an email. In my C/C++/Objective C times, I would have had sort of a "mailBody" object which would have taken care of carrying any content. To prove the validity of the mail, the sending procedure would have checked something like .hasBody(), and if that evaluated to TRUE, the email could be sent.

In fact, there would be a basic object "emailMessage" keeping track of the validity of the mail, using properties and related methods like hasSubject, hasAddress, hasBCC, hasCC, hasBody which would all be checked just before sending. In this scenario, the sending would just check "isValidMail" which in turn would check the various has* methods.

Hope this helps you to find a solution, and thanks for all the great work to renew Drupal mail.

I can't get it to send HTML of any kind in the body of mail, which is sort of a show stopper for the time being

That would be a separate issue😃

As a long time programmer I think no module should enforce the use of certain fields

Nothing is forced. This issue discussion seems to be full of confusion😃.

I'm saying this

1. In general, it's completely optional to add the BodyAdjuster policy element.
2. However if you do add one, then the body field is required. If you don't want want a body please don't add one.

Maybe in future there would be a warning if the body is missing from a newsletter (because for many people that could be a mistake), however I'm open to discuss that - e.g. there could be a way to disable the warning. Anyway that's all quite far in the future, so it's too soon to have the discussion.

That would be a separate issue😃

As I've mastered all the quirks and features of mailer & simplenews (at least to the extend I'm happy with my installation) I'm ready to help others by writing a tutorial. Is there any need for this, or is it already done/in the works/…?

Is there any need for this, or is it already done/in the works/…?

Thanks. The module has some documentation. Please check that and see if you think it has any gaps.

Hm. The link shows a nice 404 screen …

Oops https://www.drupal.org/docs/contributed-modules/drupal-symfony-mailer →

@nofue

As I've mastered all the quirks and features of mailer & simplenews (at least to the extend I'm happy with my installation) I'm ready to help others by writing a tutorial.

I personally would be interested in this in regards to Simple News (and would consider it additional documentation perhaps for use in FAQ/tips for Symfony Mailer or perhaps better as a new Simple News how to's)