Public Archive of Previous Campaigns

[simonwiles]

As described in #540 it would be great to have a pages for public archives of previous campaigns. #540 was closed when the other part of the feature request was addressed, so I'm opening this issue to keep this part alive :)

[simonwiles]

On a related point, it would be great to generate RSS feeds from the lists of campaigns also. Seems like more-or-less the same task.

I think I might experiment with building my own using the listmonk API, but would you be interested in having this as part of the application?

[knadh]

I'd thought about this for the last release but there's one big issue with making archives public. Any personal info that's rendered in the email (eg: .Subscriber.Name, .Subscriber.Attribs.arbitrary-fields*) or any logic (eg: if/else) based on personal info that's rendered in the e-mail makes the e-mail unique to a subscriber. Such e-mails can't then be published.

[toontoet]

Maybe a solution for that is to be able to supply an additional JSON object containing the default values. A bit like you're able to add custom SMTP-headers to a campaign. This custom object could contain a substitution for .Subscriber.Name and some default values for the other attributes that are used in the campaign. The default-profile could exist on a global level and perhaps be modified or extended on the campaign level.

[simonwiles]

Yeah, I was thinking (as a first step, at least) to try to build something out using the API, and I've only just begun thinking about it but I thought I might just use a dummy subscriber of some sort to solve this problem in the first instance (which is more-or-less the same as @toontoet's solution, just a bit hacky).

[knadh]

Maybe a solution for that is to be able to supply an additional JSON object containing the default values.

While technically this can work, it may be a corner-case solution.

• The JSON structure of attribs can vary across subscribers.
• Given the ability to add logic and arbitrary functions, it may not be feasible to have one dummy payload that produces the intented content.
• That means, it is difficult for the dummy payload approach to be an easy to use, universal solution that allows easy publishing of content meant for public consumption.

[candideu]

As described in #540 it would be great to have a pages for public archives of previous campaigns. #540 was closed when the other part of the feature request was addressed, so I'm opening this issue to keep this part alive :)

Thanks for reviving this issue! 😅

Another concern I had was that you may not want all emails to be made public (in the case of special discounts or access, let's say). A solution I believe which would address this would be to have a toggle for each email campaign which allows the admin to decide whether or not the particular campaign should be part of the archive.

For emails campaigns with if/else, this setting could be automatically disabled.

For emails with things like .Subscriber.Name, I believe MailChimp just displays the variable in the public archive (for ex: "Hi {{Subscriber_Name}}!").

[shemtovo]

The way other mailing platform are solving this is be offering a toggle in each campaign offering to publish the email as a page, and having a default user that is then used parameters. E.g. in the campaign page let one choose to publish a campaign to web, and when doing so require them to fill the information they want for every parameter they used in their campaign

[knadh]

Work in progress. Will be available in the next release.

Campaigns can be optionally published. The dummy subscriber + attribute metadata can be supplied as a JSON params and the public archive will be rendered with this. Any complex logic in the message body that depends on dynamic subscriber attributes, that has to be handled manually. Fair trade-off.

Kindly share any suggestions / feedback.

[candideu]

Kindly share any suggestions / feedback

This looks great!! Excited to try it out. 😊

In terms of feedback: I'm wondering if it should a part of the "Campaign" tab rather than its own separate tab...

[knadh]

Thanks @candideu. That's what I attempted first, but then the campaign tab becomes too long, especially given the Custom headers textarea. I think it makes sense for Publish to be a different tab because tomorrow, if there are more publishing related features, they can be grouped there well. In addition, everything in the main campaign tab pertains to the properties of the campaign. However, publishing isn't a property, but an action taken after a campaign and all its properties are defined.

[simonwiles]

Very excited for this, thank you!

I'm doing something very similar in production using a few lines of nginx config to rewrite pages (see https://adho.org/newsletter/75b3923d-db6d-4d8c-ac53-9f232ca3995e for an example). An app-level solution will be much better!

I decided I needed to strip the unsubscribe link completely, and I also chose to hide the "This email was sent to you..." and "You can also view this message in your browser." stuff when presenting content in this way. Removing the unsubscribe link seems important, but it might be nice to allow customization of other aspects of the template. A good general solution (perhaps for a subsequent release) might be to allow using a different template for "published" campaigns.

[knadh]

A good general solution (perhaps for a subsequent release) might be to allow using a different template for "published" campaigns.

Yep, looks like this has to be done. There's no universal way to meaningfully strip out newsletter specific template elements.

[simonwiles]

I agree. You could make a reasonable case that removing newsletter-specific template elements is a secondary feature though, I think, as long as the unsubscribe link is deactivated 🤷

[Sjors]

Work in progress. Will be available in the next release.

Very cool, happy to test if you open a pull request. Or has this merged already?

[knadh]

@Sjors The WIP is available in the public-archives branch.

[knadh]

[Sjors]

Testing it at https://list.btcwip.com/archive, couple of things:

1. RSS doesn't work yet
2. It seems to put all mailinglists on the same page a) it every list gets its own page, it should probably have a friendly URL, like blah.com/my-fancy-list (or blah.com/archives/my-fancy-list, if it can't be at the root, but having the archive on the landing page is probably nicer)
3. I only have one old post, but for larger archives it would be handy to have a way to bulk publish the archive.

[knadh]

1. Working on this.
2. listmonk campaigns can be tied to multiple lists, both public and private. Rendering a list based categorisation on the frontend seems difficult. It would be possible to easily build a custom frontend to show arbitrary categorisation based on campaign tags.
3. We can document a simple SQL query that does this. It's as simple as UPDATE campaigns SET archive=true, archive_meta='{....}' WHERE status='finished';.

[Sjors]

(1) 🎉

(2) I only have one mailinglist, so it's fine for my use case. I just want to make sure this doesn't have to be changed later on, because reorganising the URLs might break existing RSS feeds.

(3) that seems simple enough

[knadh]

but having the archive on the landing page is probably nicer

Indeed. Considered this, but it's possible that a lot of auth proxies would've hidden /. Making / public with archives might break existing installations. We can add a Maliling list archive link on / below the login button though.

[Sjors]

It might be better to move the login button away from / altogether and put it on /admin. That's similar to how Wordpress uses /wp-admin. On a public facing landing page it's nice to have some intro text, a big subscribe button and the archive (and nothing admin related that would confuse potential subscribers). But this would be a breaking change.

[knadh]

@Sjors best to consider this breaking change when the homepage inevitably changes when a non-BasicAuth user system is added.

For now, subscribe/archive links have been added to the homepage along with an RSS feed and also a setting in the admin to turn public archive on and off. You can test it if you'd like: public-archives.

[Sjors]

Mmm, now my /archive page just says "{"message":"Not Found"}", the home page has a login and subscribe button, but no archive link.

[knadh]

Is this enabled in Settings -> General?

[Sjors]

Found the setting, but it requires that I set a site name, which I tried, but it doesn't save the result. Maybe the db migration changed?

Update, yes, looks like I manually need to add these:

INSERT INTO settings (key, value) VALUES
 			('app.site_name', '"Mailing list"'),
 			('app.enable_public_archive', 'true'),

[knadh]

Ah yes, there are new migrations in the branch. I assumed you were doing a fresh install.

Can you do a --install on your test instance?

Or, you can run UPDATE settings SET value=value - 'v2.3.0' WHERE key='migrations'; and run --upgrade again on the new binary.

[Sjors]

That worked. I think you forgot to add the rss svg though?

[knadh]

Oops. Added.

[Sjors]

Thanks. It would be nice to have the post itself in the RSS feed, not just the title. Though it could wait for a followup if complicated.

[Sjors]

The RSS icon so close to the subscribe button might be confusing. Maybe one can go on the left and the other on the right? Also, they should probably both be above the list, since the list could get long.