How about newsletter

planeth · 2021-04-07 14:06:40

Hello dear Textpatterners’

I’m trying to figure out how I could use Textpattern as a (headless) CMS to manage the content-producing side of a newsletter.
You could see the newsletter as a collection of modules with each featuring some different piece of content. See below a rough schema.

+------------------------------------------------+
|          Summary                               |
+------------------------------------------------+

+-----------------------------------------------+
|  module type 1                                |
| +--+ +--+ +--+ +--+                           |
| |  | |  | |  | |  |  collections of pictograms|
| +--+ +--+ +--+ +--+                           |
|                                               |
| +--------------------------+                  |
| |   Title (with link) <txp:link .../>         |
| +--------------------------+                  |
| +------------------------------+              |
| |                              |              |
| |                              |              |
| |       Text                   |              |
| |                              |              |
| |                              |              |
| |                              |              |
| +------------------------------+              |
| +------------------------------+              |
| |  <txp:links id=x,y,z />      |              |
| +------------------------------+              |
+-----------------------------------------------+

+-----------------------------------------------+
|  module type 2                                |
|                                               |
| +--------------------------+                  |
| |   Title (with link) <txp:link id=  />       |
| +--------------------------+                  |
| +------------------------------+              |
| |                              |              |
| |                              |              |
| |       Text                   |              |
| |                              |              |
| |                              |              |
| |                              |              |
| +------------------------------+              |
+-----------------------------------------------+

+-----------------------------------------------+
|  module type 3                                |
|                                               |
| +--------------------------+                  |
| |   Title (with link) <txp:link .../>         |
| +--------------------------+                  |
| +------------------------------+              |
| |                              |              |
| |                              |              |
| |       Text                   |              |
| |                              |              |
| +------------------------------+              |
| +------------------------------+              |
| |                              |              |
| |                              |              |
| |       Some other text        |              |
| |                              |              |
| |                              |              |
| +------------------------------+              |
+-----------------------------------------------+
+------------------------------------------------+
|          Footer                                |
+------------------------------------------------+

Some of my needs :

click a button and add the corresponding module tag inside the body (in write panel). How would you approach this ?
Have an image picker to pick the needed pictos. Is there a plugin for that ?
Have a “link picker”. Is there a plugin ?

Thanks for any ideas about this :)

colak · 2021-04-07 14:43:05

Hi,

Stef has recently tamed the postmaster plugin for the latest txp. I have it installed in our site and although there are a couple of gremlins, these may be on my server setup. It would be great if it is tested by someone else too.

What you need is almost doable, but the hard thing is the actual newsletter plugin which is almost there.

Bloke · 2021-04-07 15:23:32

I’m currently in the process of writing a newsletter plugin that uses the power of Txp to build publications.

It’s a companion to com_connect – much like Postmaster (which I finally tamed today and Yiannis is testing), but with more of a focus on granular opt-in. So instead of being ‘subscribed’ or ‘unsubscribed’ you tie people’s interests to, say, sections, categories or potentially tags.

What this means is that your ‘subscribe’ form (which passes control to com_connect, and will therefore inherit all the built-in features of Txp’s new 4.9.0 mail handling, when I refactor the delivery process) is a bunch of checkboxes for topics that you wish to allow people to read.

Each person who subscribes has a unique (long) ID assigned to them and this is the token that allows them access to their ‘profile’ (which is just a URL to the /subscribe page with their token added as URL param). Without that token, a bare form that allows people to subscribe is displayed. With that token, a visitor has access to all the things they’re currently subscribed to and can alter which categories/tags interest them. Or uncheck them all and submit to unsubscribe. Altering any subs and sending off the form triggers an email with a confirmation token for double opt-in goodness. Undecided about sending a ‘sorry to see you go’ email, but I might leave that to admins to decide via a plugin pref or something.

Anyway, the key to delivery – and this is where your modular concept comes into play – is that a newsletter is really a collection of articles. Spring Update, for example, is your main article published at example.org/newsletter/2021/03/30/spring-update and it has a bunch of individual articles associated with it that make up this “edition”. Everything and anything can go in there, because each article is associated with categories, or is in a section, or has tags associated with it. So your “newsletter” is essentially a giant single landing page of articles collected together from the site, one after the other.

The killer part is that when you mail out the newsletter and/or the link to the online version to read, Txp knows the subscriber’s UID. So as the main Spring Update article is passed through your delivery template (which has plaintext and HTML markup sections) it can filter the articles in that edition by their interests – cats, tags, sections – thus reducing this blogroll Spring Update page to a suite of articles specifically tailored to that person’s interests, top and tailed with your header/intro/footer content.

The “read online” link in the email has the UID embedded in the URL too so when you hit example.org/newsletter/2021/03/30/spring-update?uid=1ab65bfed87a098bdf33 it can filter the article list on the fly and only show them articles they’re interested in. Your template has all the header and footer gumph in it – entirely up to you what you put in: it’s just Pages/Forms as normal – and can contain links to change your subscription topics or unsubscribe, all based off this UID.

This also allows you to have filters at the top that could dynamically alter the newsletter content to only show particular topics.

If you don’t supply a UID in the URL or you have subscribed to stuff that isn’t in the newsletter, you could get all topics in that ‘edition’ displayed, with filters at the top and a way of subscribing to these topics, which would take the current filters the visitor has toyed with, and link them to their email address (and hence UID) in an email for them to confirm.

It’s not entirely headless as you described, but hitting an ‘edition’ URL means your content is dynamically built based on user interests filtered from the available content published in that edition. Kinda turns the idea of newsletter publication on its head a bit: you provide all the content; visitors choose which bits they’re interested in. Cuts down on your admin overhead of figuring out who needs to get what – fewer “lists” to manage – and puts the power of what people consume in their own hands, plus allows them to refine their interests at any time. Win win win.

The key to it will be linking articles to one another. It’s early days with the plugin, but with the right impetus (e.g. a project like yours) I could knuckle down and finish it.

The plugin is more of a framework than anything. It helps you manage subscribers (or more accurately, helps subscribers manage themselves) by simply storing a unique user token mapped to a bunch of ‘things’. What you do with that information is then up to you. You write the subscription form in com_connect. You write the template for formatting the newsletters. You construct all the filtering and stuff in the site templates however you want. The plugin simply provides hooks and tags that allow you to get at various bits of information and (hopefully) to help you construct an ‘edition’ based on a bunch of other articles. Nothing to stop you doing that yourself too if you like.

Postmaster’s handy but it lacks pizazz. I’m hoping the newsletter plugin will build on those foundations but do the bare minimum as a sort of ‘helper’ to give you the toolset to build newsletters however you want to suit your clients’ needs, and give visitors the power to manage their subs so you don’t have to do it (although there’s a back-end management tab to help you manage subscribers if you wish).

Longer term, it might be cool if other modules could offload subscriber lists or whatnot to third parties. But you lose the niceness of being able to manage subscriptions directly tied to Txp content as you’d then need to manage topics in two places. I like the simplicity of using Txp’s new supercharged per-section permlinks, pageless sections and (already built into 4.9.0) email routing to third parties such as SendGrid/Gmail/MailChimp/S3/Whatever to let you build a subscription experience that feels like the visitor has ultimate control over what they consume, with very little management on your part… beyond Just Write (and click Send!).

With regards image picker, definitely com_article_image is the ticket. It’s not officially released yet but I’ve been using it on client sites for months and it’s rock-solid so we might as well issue a proper release.

Link picker: don’t know. Wet_quicklink was (I think) only for choosing other articles for embedding with permlinks but it’s not super hard to write a plugin to pop up a panel of all links – perhaps with category filter – so you can choose ones to embed.

Another approach is to use the power of short codes. I’ve done that before with images. You use com_article_image to help manage the ‘list’ of IDs in the article_image field visually, then a shortcode tag embedded in the body called <txp:nextimg/> pulls the next ID from the list and renders it inline. Each successive call to the tag grabs the next image.

You could do the same with Links by embedding their IDs in a custom field and having a shortcode grab them one by one to display them. Or make your template simply use that list as the basis of a <txp:linklist id='<txp:custom_field name="LinkIDs" />' />.

Lots of fun!

Last edited by Bloke (2021-04-07 15:43:24)

planeth · 2021-04-07 16:10:30

Whoaa, I feel like I’ve open a Pandora box :)

Sorry to disappoint about using the new plugin, but the sending part will be done outside Textpattern.
I can understand the “collection of article” newsletter, except that I want to avoid this.
We send it every week, we do not offer a “pick your choice” and I want to make absolutely easy for the editors to produce the content.
Asking them to create a new article for each piece and figuring out how to link them together is a no-go AFAIC.

I’ll definitely test the com_article_image and try to replicate with the links.

I would really like, though to offer a “click to add this module” :)

Last edited by planeth (2021-04-07 16:19:53)

Bloke · 2021-04-07 16:22:41

That’s cool, hehe.

If they’re preparing content every week, I’m not sure how that differs from a ‘newsletter’ article. You still have to write the content somewhere. You don’t need to offer the ‘pick your choice’ stuff – that’s an extreme example. You could still code your com_connect subscription form to be “enter your email to subscribe to stuff”. Done. They get a UID and can then visit the same page to unsubscribe at any time.

Articles too, you don’t need to link them at all. Each article could be a standalone piece in a section; one a week. You write it, you hit Publish, check it looks okay, click Send and it gets sent out to everyone who’s subscribed. Identical plugin framework: you design how you want to create content and publish it.

Or forget the subscription side of things. Manage that elsewhere, fine. Just create an article each week, get its URL and paste it into a MailChimp template to send out. Or view the article source code, copy and paste into a third-party template to send it as-is.

Questions/observations then:

If it’s being sent from outside Txp, how does the content get from a Txp article to this delivery place? Do you have to output a PDF or something that you then upload to another system that holds the subscriber base? Or is the currency simply a URL that gets sent out?
Mailing out from your own server is something I wouldn’t advocate (although Yiannis has been doing it for decades with no ill effect) but in 4.9.0 – available to try out now – you can offload delivery to any service you like to mitigate the risk.
‘Click to add this module’ – where are the modules stored? What are they? Somebody has to produce them and make them available for selection. If your content creators can’t create an article in Textpattern’s back end – even if you offered them a simplifed dashboard with just ‘Title’ and ‘Click these links’ and ‘type a block of text here’ and ‘drag these images in’ – how are they going to make these modules?

I’m not being awkward, just trying to get my head round what exactly they’ll be doing if they’re not creating content. And what it is you’re trying to solve by building something. And where these blocks of content are going to come from and how it’ll be assembled to produce a weekly bulletin.

planeth · 2021-04-07 16:43:01

Bloke wrote #329703:

Articles too, you don’t need to link them at all. Each article could be a standalone piece in a section; one a week. You write it, you hit Publish, check it looks okay, click Send

This make sense. So you would create one section per week ?

If it’s being sent from outside Txp, how does the content get from a Txp article to this delivery place? Do you have to output a PDF or something that you then upload to another system that holds the subscriber base? Or is the currency simply a URL that gets sent out?

We are using an API provided by the hosting service. Give the url, pull the HTML and do the sending (very roughly)

‘Click to add this module’ – where are the modules stored? What are they?

For me this “module” thing is just a pre-written/pre-fill tag that you can copy/paste in your content
But if I go with a one section per week, this solves the case, I guess

Bloke · 2021-04-07 16:57:02

planeth wrote #329705:

So you would create one section per week ?

If you wanted to. Or one article inside a section per week. You don’t have to display the section in the permlink scheme. /title is perfectly valid – and you can set it just for that section in 4.8.x.

If the sticking point is that your content creators can’t use the Write panel because it’s too complicated then the way to do that is to either:

a) Write a teensy plugin that simply hooks into the bits of the Write panel you don’t want and return '', effectively turning those bits of the UI off. So for users of a particular group (e.g. staff writer), kill off excerpt and custom fields and date/time and categories and meta, etc. Just intercept those bits and return nothing (or hidden form fields with fixed content) so they effectively disappear. Then you’re left with a cleaner panel, which is less overwhelming.

b) Write a dashboard plugin that makes a simplifed article creation page directly on the Start panel:

Title field.
Text (body) field. If they want more than one ‘block’, just type more than one paragraph in here and let Textile/line break filters do the hard work!
An optional links panel. If they don’t choose any, those links aren’t populated.
An article image field that a tweaked com_article_image can hook into for drag/drop image goodness.
A publish button.

Route (a) is much less work, as the com_article_image plugin will just work. As long as you leave the article image field on the page!

We are using an API provided by the hosting service. Give the url, pull the HTML and do the sending (very roughly).

Then once you’ve published an article in Txp, you have a URL endpoint. example.org/section/your-article-title this week. And example.org/section/a-different-article the week after (or if using /title permlink scheme you’d get: example.org/your-article-title and example.org/a-different-article etc of course).

Your page template for that section can be told to output only the code in the article without any <html><head>...</head><body>... furniture. The browser will render it just fine (validators will complain, but so what).

You can either view source of that URL to get the HTML and paste it into your third-party template manually, or just supply that article URL to your API for it to suck the HTML into the template (that presumably already has your header/footer in it?) for sending. Or just get the page template to output whatever you need – complete or partial HTML with or without header/footer and other HTML furniture, it doesn’t matter – to plug into your API.

Does that give you any more integration ideas?

Last edited by Bloke (2021-04-07 17:07:55)

planeth · 2021-04-08 06:45:43

Bloke wrote #329706:

a) Write a teensy plugin that simply hooks into the bits of the Write panel you don’t want

Or I could use adi_write plugin.
I’ll go with the a) right now. I think it’s easier for an editor to write the whole issue in one article.
Is rah_textile_bar plugin still usable in the latest version ?

Your page template for that section can be told to output only the code in the article without any <html><head>…</head><body>… furniture. The browser will render it just fine (validators will complain, but so what)

Or could I use the form output feature for the API call? So I still get a valid HTML page when accessed through a browser. Because I still need to have an archive page anyway

Does that give you any more integration ideas?

Yes, it does, thanks Stef ;)

Bloke · 2021-04-08 07:34:30

planeth wrote #329709:

Or I could use adi_write plugin.

Yep, that would work too. Not sure the status of bot_write_tab_customize but that’s another contender.

Is rah_textile_bar plugin still usable in the latest version ?

Maybe, but smd_textile_bar is its successor that also allows form/shortcode insertion if you wish.

Or could I use the form output feature for the API call?

Absolutely. That would allow you to have a web-accessible archive page as you say and just extract the chunk the API needs. Great idea!

Last edited by Bloke (2021-04-08 07:35:14)

jakob · 2021-04-08 09:03:46

Bloke wrote #329712:

Not sure the status of bot_write_tab_customize but that’s another contender.

Yes this version still works.

planeth · 2021-04-08 17:12:27

Great ! Thank you Jakob :)

planeth · 2021-05-05 09:02:58

To give you a brief update on how this is going —which may be of some utility for someone else— this is how I’ve structured the whole thing:

One section is the container for all subsequent components. It’s called “Edition”
I created a pageless section “Component” which hold the different types of components of the newsletter, and gives us a nice archive
I use 2 calls to article_custom with breakby/ breakform. One to generate a summary with links to each components, the second to generate the content per se.

<txp:article_custom 
  section="component" 
  month='<txp:posted format="%Y-%m-%d" />'
  sort="Category1 asc"
  breakby="<txp:category1 />"
  breakform="summary-categories"
  form="summary-links"
  limit="20" />

The set of articles – one with Section=edition and any others with Section=component are linked together by the date of publishing

Now I need to add some contextual text depending on the category of the component.
Each category has a description field, so I tried to use the meta_description tag but this does not work :(
I’ve resolved to use a bunch of variable / if_variable. If you have a more robust solution I’m all ears !

Textpattern CMS

Textpattern CMS support forum

#1 2021-04-07 14:06:40