Demo module for simplenews

1. +++ b/modules/simplenews_demo/config/install/block.block.simplenewssubscription.yml
   @@ -0,0 +1,44 @@
   +  newsletters:
   +    demo: demo
   
   +++ b/modules/simplenews_demo/config/install/simplenews.newsletter.demo.yml
   @@ -0,0 +1,16 @@
   +id: demo
   +name: 'Demo newsletter'
   

   I think we want to have multiple newsletters and two blocks.

   One block with only one newsletter selected.

   And one block with to manage multiple newsletters at the same time.

2. +++ b/modules/simplenews_demo/simplenews_demo.install
   @@ -0,0 +1,54 @@
   +  $site_mail = \Drupal::config('system.site')->get('mail');
   +  $site_name = \Drupal::config('system.site')->get('name');
   ...
   +  $config->set('newsletter.from_address', $site_mail);
   ...
   +  $config->set('newsletter.from_name', $site_name);
   ...
   +  $newsletter->from_name = $site_name;
   +  $newsletter->from_address = $site_mail;
   

   Confused. So we don't have feasible defaults?

3. +++ b/modules/simplenews_demo/simplenews_demo.install
   @@ -0,0 +1,54 @@
   +  // Create a newsletter issue
   ...
   +    'type' => 'simplenews_issue',
   +    'title' => 'Demo newsletter issue',
   

   We also want to have issues in multiple send states.

   At least:
   - One that was sent
   - One that is waiting for publishing to be sent
   - One that is draft
   - (One that is stopped)
   Unsure if we should have one in sending state with an active spool. ;-)

   This should allow us to have a representative overview with all the icons available.

   Followup (?): Add simplenews_scheduler as a demo dependency and add a scheduled newsletter for demo.

   Followup (?): Add maillog or similar to show mails sent in UI.

   Followup: Add a HTML mail example with swiftmailer... (problem is the external library dependency for demo)

4. +++ b/modules/simplenews_demo/simplenews_demo.install
   @@ -0,0 +1,54 @@
   +  simplenews_subscribe('a@a.com', 'demo', FALSE);
   +  simplenews_subscribe('b@b.com', 'demo', FALSE);
   

   Use example.com for examples
   https://www.drupal.org/coding-standards#example

   We want to have subscribers in different states.
   - One that is subscribed to one newsletter only.
   - One that is subscribed to all newsletters provided
   - One that is partially subscribed and partially unsubscribed
   - One that is unsubscribed from everything.

Ah, the demo module should also add some fields to the subscriber to show the fieldability.
A feasible thing would be first / last name... and city.
The values should also be populated by SOME of the subscribers. Not all.

And we should have one subscriber that is also a user at the same time.

We should also depend to mailsystem.

Adding dependencies for modules that are on drupal.org is easy and doesn't need a follow-up (scheduler + maillog). mailsystem and swiftmailer is currently not possible, but once they are then I'm pretty sure we can solve the composer problem.

It shouldn't be hard to download additional composer dependencies on simplytest.me.

I suggested a followup to avoid making a monster demo issue. Each of the added contrib needs a demo scenario that results in some additional configuration.
Fine if it is quickly done. Fine if postponed as a followup, if the demo scenario is not clear, and needs discussion.

The nodes lack a body. That's not representative.
The two blocks and newsletters should have a more meaningful name.

Similar to tests, demos should be less abstract and more by example.
We could use three newsletters, for instance:
- Press releases
- Special offers
- Weekly content update

The weekly content update should be a scheduled one that contains a view with an appropriate filter... ;-)
And i'm missing the things from #3: We want to have fields on subscribers with demo data.
And the newsletter should use the corresponding token to welcome the recipient.

The sent issue should also display a fake sent count (not 3, better e.g. 5) in the admin UI. It currently shows no count at all.

And now the nice bugs:
Interesting is this message on the newsletter tab: "This newsletter issue is pending, of 0 mails already sent." although the admin content newsletter issue tab listed a count of 3... I guess it's a bug? Even multiple bugs combined (bad english). :-)
And stopping the pending newsletter resulted in a Notice: Undefined index: in Drupal\simplenews\Form\NodeTabForm->buildForm() (line 93 of modules/simplenews/src/Form/NodeTabForm.php).
And then, also it lists "Send newsletter issue to 0 subscribers." although 3 targets are there.
And if i click "send now" i get Drupal\Component\Plugin\Exception\PluginNotFoundException: The "" plugin does not exist. in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 57 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).
However, if i edit the node and hit save, the tab starts to work again.
I guess your demo node is just not yet in valid state.
We still should check where Simplenews can be improved to avoid fatal errors for others with inconsistencies...

Scheduled with view would be quite complicated or hacky, not sure we should do that here, and we'd also need actual content to show. Instead, it might be enough for a start with some tokens in node title and body, and make sure that cron runs after we created the content, so that we immediately create a scheduled issue.

Some issues you've seen might be due to recent core changes, that we're working on fixing. Other than that, I agree :)

1. Nice. With Pending / Stopped special offers, i see the wrong newsletter assigned in the screenshot. :-)

   +++ b/modules/simplenews_demo/simplenews_demo.install
   @@ -0,0 +1,197 @@
   +    'title' => 'Pending special offers',
   ...
   +      'target_id' => 'press_releases',
   ...
   +    'title' => 'Stopped special offers',
   ...
   +      'target_id' => 'press_releases',
   

   Yay! And also found it in code. ;-)

2. +++ b/modules/simplenews_demo/simplenews_demo.install
   @@ -0,0 +1,197 @@
   +      'handler' => 'special_offers',
   ...
   +      'handler' => 'simplenews_all',
   ...
   +      'handler' => 'special_offers',
   

   I guess an accidental rename.

3. +++ b/modules/simplenews_demo/simplenews_demo.install
   @@ -0,0 +1,197 @@
   +    'body' => 'Expired special offers!',
   

   Those are not really expired. Instead is typically more an upcoming newsletter in preparation...

Demo problems:
- scheduled newsletter is not created
- date format should use week/year or so, as it is a weekly newsletter
- count is still 0, at least of the scheduler template. might also be a non-demo issue
- demo user is blocked (status needs to be 1)

Generic problems discovered by the demo (needs separate issue(s)):
- scheduled newsletter initially shows a notice, goes away after saving the node
- saving scheduled newsletter settings of the template sends the newsletter.
- simplenews_scheduler notices about pager on editions page
- body on node detail page is still not visible.
- "..., of 1 already sent." => 0 is missing.
- hide test and send fieldsets completely for a scheduler template (if scheduler checkbox is enabled)

+++ b/modules/simplenews_demo/simplenews_demo.install
@@ -0,0 +1,203 @@
+    'status' => 1,
+    array(
+      'target_id' => 'weekly_content_update',
+      'handler' => 'simplenews_all',
+      'handler_settings' => array()
+    ),
...
+    'simplenews_issue' => array(

This looks totally wrong, see also interdiff. Is the key missing here?

And yeah, if we talk of a possibly followup and you don't want to fix it as part of this issue, please create the separate task. :-)

Fails seem to be from API change of user_pass_rehash() that now needs the uid.
Let's fix it first. :-)

Yes, please open a new issue for that, because we also need to backport that fix to 7.x, that's a SA change (it kind of works there, but throws php warnings, to not break it but force modules to update asap).

double post.

Well.. #2456461: user_pass_rehash() uid missing. ist committed.. But now simplenews tests seem broken due to other core issue(s)... ;-)

Yes and no, we still have that random fail in SimplenewsSourceTest and the branch test happened to run into that, re-tested now.

Very nice. Some minor inputs.

1. +++ b/modules/simplenews_demo/simplenews_demo.install
   @@ -0,0 +1,203 @@
   +    ->setComponent('field_first_name', array(
   ...
   +    ->setComponent('field_last_name', array(
   ...
   +    ->setComponent('field_city', array(
   

   Our subscribers all don't have field values. Some subscribers should have the fields setup. Preferrably one with all and one with parts such as first name only.

2. +++ b/modules/simplenews_demo/simplenews_demo.install
   @@ -0,0 +1,203 @@
   +  $demo_user->activate();
   +  $demo_user->save();
   

   A second blocked user would be nice. And also some additional inactive subscriber.

3. +++ b/modules/simplenews_demo/simplenews_demo.install
   @@ -0,0 +1,203 @@
   +    'next_run' => strtotime('yesterday, 8:00'),
   ...
   +    'start_date' => strtotime('yesterday, 8:00'),
   

   Not too troublesome, but this should be in UTC, and strtotime uses default_timezone. Might result in some unexpected local time shift.

And then we can close this demo setup for some time! ;-)

Test fails are not related. But let's open an issue for that, that seems to be reproducable.

Nice, committed!