Create a temporary subscriber for recipient that is User entity

Not sure if we ported everything to 8.x, but there are/used to be newsletter options for hidden/automatic signup when registering, which should basically cover this? Not when creating users in a different way than the register form maybe, but not sure if it should really apply there.

IS 1 & 3 yes. Seems like a clean and safe solution.

With IS 2 I'm not sure we've really got the right model nailed for what would be most helpful in these base classes, but I also think it doesn't matter much because it's all been opened up by moving addToSpool(), you've made rich examples, and we're only talking about saving people a few lines of code. Therefore I suggest you do whatever is quick and easy here, I don't see optimising further should be a priority. In my project I'm expecting to make only minimal use of the base classes and not use their helper methods.

1. This whole temporary subscriber dance is fairly complex - is this the appropriate issue for adding at least one end to end test for this?

2. +++ b/src/Entity/Subscriber.php
   @@ -111,16 +111,15 @@ class Subscriber extends ContentEntityBase implements SubscriberInterface {
   +      return user_load_by_mail($mail);
   

   The interface says this function returns \Drupal\user\UserInterface|null.

   But user_load_by_mail returns false if there is no user with that mail, and in this case the method previously returned null.

3. In the IS you say
   

   In SpoolList after the call to Subscriber::create(unserialize($spool_data->data)) then if the uid is set call fillFromAccount()

   .
   This doesn't seem implemented?

4. +++ b/src/Entity/Subscriber.php
   @@ -298,12 +297,9 @@ class Subscriber extends ContentEntityBase implements SubscriberInterface {
   +    // Fill from a User account with matching uid or email.
   +    if ($user = $this->getUser()) {
   +      $this->fillFromAccount($user);
   

   This change seems unrelated - just calling your attention to that in case it was unintentional. If I understand right, it only effects persistent subscriber entities not temporary ones.

   It also has the effect of preventing the creation of a persistent subscriber whose email is not the same as the email on his user account (because ::fillFromAccount() syncs these). But if we're insisting these are the same, why bother storing an user id reference on the subscriber at all?

5. +++ b/src/Plugin/simplenews/RecipientHandler/RecipientHandlerBase.php
   @@ -126,13 +126,13 @@ abstract class RecipientHandlerBase extends PluginBase implements RecipientHandl
   -   *   Field to set: snid or data
   +   *   Field to set: snid, uid or data
   

   This comment, and maybe variable name, is possibly misleading (although I struggle to do better) as "uid" here is not a field to be set on the spool.

6. +++ b/src/Plugin/simplenews/RecipientHandler/RecipientHandlerBase.php
   @@ -143,12 +143,17 @@ abstract class RecipientHandlerBase extends PluginBase implements RecipientHandl
   +    if ($field == 'uid') {
   +      $field = 'data';
   +      $values = array_map(function($v) { return ['uid' => $v]; }, $values);
   

   Worth a comment explaining?

All makes sense, thanks Adam!