When managing a Drupal website utilising newsletters, you might want to save custom information (such as name and age) for each subscriber. Since Simplenews 7.x-2.x, subscribers are fieldable content entities, this is possible. However, the fields are not displayed on the subscribe forms. The last few weeks I have been putting some work into making sure they do.
This blogpost is part of the on-going MD Systems Drupal 8 Internships. In these Blogs the students report monthly about their experience with Drupal 8, the development work they do and the cooperation with our Team...
Simplenews is a newsletter module for Drupal, with a D8 version in active development. The project page summarises its functionality, but for the purpose of this post let me just highlight the basic concepts of the module:
- An issue is typically a node, but can be almost anything, that has a reference to a newsletter. Issues are sent during cron runs to all subscribers of that newsletter.
- A newsletter is a named category for issues.
- A subscriber represents someone with an email address who subscribed to one or more newsletters.
- A subscription is the 1:1 relation between a subscriber and a newsletter, and it is either active or not.
Personalised subscription forms
Simplenews stores subscribers as entities, and as such they can be assigned additional data fields, thus offering personalisation. For example, the administrator can add text fields for first name and last name and an autocomplete widget for city of residence. The fields can be automatically inserted in the newsletter body (Dear [first_name]), and can be used for specialised recipient lists based on e.g. location or topic.
Simplenews has no less than four forms where visitors can subscribe to newsletters: one for blocks, one to display under a tab on the user page, one to display on a page of its own and one for the admin interface. The field support has only been partial in previous versions of Simplenews, but with the recent efforts fields may be displayed on all subscription forms, making them personalised.
One of the subscription forms, including a Name field.
Account - Subscriber field synchronisation
Newsletter subscribers and website user accounts and are both identified by email addresses, so the data associated with one of them should in many cases be associated with both. A website collecting the birth year of its regular users will likely also collect it for those who only sign up for newsletters, and vice versa. And that value is expected to be identical, constantly, for the user and subscriber respectively. Imagine the frustration if a user moves from Gothenburg to Zurich, changes the city field accordingly in their user profile, but keeps getting newsletters about events in Gothenburg!
To accomplish this, we could either synchronise the subscriber with its corresponding user every time one of them is saved. Or we could store the data only on the user account, together with a flag telling whether there is an actual user account or if it's only used for storing subscriber data.
To ensure compatibility with other modules, we didn't want to fiddle too much with the user accounts, so we went for the first approach. For each field, the administrator now creates one for users and one for subscribers. As long as they have the same type and machine name, they will be synchronised. Technically speaking, when the frustrated user in the previous example submits the profile form, a hook is invoked where the new value is copied from the field_city field of type string on the user entity, to the field_city field of type string on the subscriber entity, if it exists.
Special cases and spam danger
Suppose someone subscribes to your newsletter, entering the email address [email protected]. A confirmation mail is sent but the receiver does not act on it, so the subscription remains unconfirmed. Then someone registers an account using the same email.
Although Alice verifies, while registering the account, that she is the owner of the email address, it is very important that we do not consequently confirm the newsletter subscription. If we do, and the subscription was actually made by an impersonator, then the real Alice will receive newsletters without having agreed to it.
Per definition, sending newsletters to someone who did not explicitly agree to it is to be regarded as spam, and Internet services generally block servers that send this sort of email. If your website is very generous with sending email it might be discredited by these services and you might have difficulties reaching your users by email in the future.
Looking ahead
The features described in this post are implemented and merged into the 8.x branch of Simplenews. We have some related features ahead, like including the fields in subscriber export/import, taking appropriate actions to bounce messages and turning Subscribers into a stand-alone concept, quite independent of newsletters. It looks like those tasks are heading my way, so you will be able to read more about them in my November post. Until then enjoy the Drupal 8 beta, which was recently released during DrupalCon in Amsterdam!