@mailchimp/mailchimp_marketing, Buttondown and etc.

[rsipakov]

Hey there,

I would like to provide the option of implementing a subscription newsletter based on the package "@mailchimp/mailchimp_marketing" for this template (branch demo/translate).

Simple subscription form added in index.js.
The API is added in pages/api/subscribe.js
Also, you need to create a ".env.local" file with following:

# example for U.S. (in this case you need use "us1")
MAILCHIMP_API_KEY=YOUR_API_KEY-us1
MAILCHIMP_API_SERVER=us1
MAILCHIMP_AUDIENCE_ID=YOUR_AUDIENCE_ID

Do not forget to add Environment Variables to the settings where you deployed your site (example for Vercel: Project Settings/Environment Variables). And add your .env file to the .gitignore file.

In the next step, we will try to translate this subscription newsletter form and notices.

You can fetch directly from this branch.

The way for Buttondown

[timlrx]

I am on board with this since I am also looking to add a newsletter component to my site.

The only potential issue is that this might break the pure static site functionality of the existing template. I think it is fine as long as it is designed in a way such that if you want to deploy it to github pages, it's still possible by maybe changing the endpoint for the newsletter to one of those form backend for static site service providers and deleting the API routes folder.

On the implementation, I propose adding it in the siteMetadata.js file as a newsletter property, similar to comment or analytics. You can then add a provider with various options, so it will look like this:

newsletter: {
    provider: 'mailchimp', // supported providers: Mailchimp, convertkit, ....
    mailChimpConfig: {
      apiKey: process.env.MAILCHIMP_API_KEY,
      apiServer: process.env.MAILCHIMP_API_SERVER,
      audienceId: process.env.MAILCHIMP_AUDIENCE_ID,
   },
   converKitConfig: {
    ...
   },
   ...
}

In pages/api, you will then have mailchimp-subscribe.js, convertkit-subscribe.js etc. Then based on the provider config, we will call the appropriate api.

[GautierArcin]

I'm also on board ! I'm also very interested in the idea, thank you.

Question unrelated to the default implementation (that should be not localized), but since you seems to be using it on a website with two locales, how do you do to make sure that each email is sent in the correct language to each user ?
You separate email list by local ?

[rsipakov]

@GautierArcin This is where you first need to determine the following: What is the goal of your project?

1. • to deliver the same content for all users but in different languages?
2. • or will each language region have its content?

I'm pretty sure it will be a single piece of content. For example, you want to make it user-friendly for a different language group, like English and Spanish languages for South Florida.

That's a great option @timlrx suggested for the main template.

For the translation option, I recommend making only the notices translated. Then the owner creates newsletter content with different languages, either in one letter or with a link to the HTML version of the letter in another language.

For the second option, you probably need to create different subscription lists. And here, it depends on the user on which page he made the subscription (English or French). But I'm sure in micro-projects, it is not appropriate.

[rsipakov]

I am on board with this since I am also looking to add a newsletter component to my site.

The only potential issue is that this might break the pure static site functionality of the existing template. I think it is fine as long as it is designed in a way such that if you want to deploy it to github pages, it's still possible by maybe changing the endpoint for the newsletter to one of those form backend for static site service providers and deleting the API routes folder.

On the implementation, I propose adding it in the siteMetadata.js file as a newsletter property, similar to comment or analytics. You can then add a provider with various options, so it will look like this:

newsletter: {
    provider: 'mailchimp', // supported providers: Mailchimp, convertkit, ....
    mailChimpConfig: {
      apiKey: process.env.MAILCHIMP_API_KEY,
      apiServer: process.env.MAILCHIMP_API_SERVER,
      audienceId: process.env.MAILCHIMP_AUDIENCE_ID,
   },
   converKitConfig: {
    ...
   },
   ...
}

In pages/api, you will then have mailchimp-subscribe.js, convertkit-subscribe.js etc. Then based on the provider config, we will call the appropriate api.

@timlrx Suppose I understand you correctly that you adhere to the concept of a hundred percent static site. But I don't think APIs violate that. Because one of the concepts of the JAM stack is "Supercharging with services".

[timlrx]

@rsipakov APIs don't, but deploying nextjs with APIs means that it is no longer a 100% static site (i.e. next export will not work, so the user needs to delete the APIs folder and modify the API endpoint accordingly before deploying it to github pages or any static web hosting service). I don't see it as much of a problem, just have to add some documentation on it.