[Website]: Headless CMS for blog

[ssandino]

Is there an existing request for this feature?

• [X] I have searched the existing issues

Is your feature request related to a problem? Please describe.

We are planning to introduce a blog feature on our website that enables non-dev volunteers to publish articles using a headless CMS. Currently, each new page (even text only pages) requires manual coding, which is inefficient and time-consuming.

Describe the solution/feature

Our goal is to use a easy-to-use visual interface that streamlines the workflow, supports automatic deployment, and facilitates the publishing of multilingual articles.

The proposed blog articles should be published under the subdirectory: socialincome.org/journal/TITLE

Important: The headless CMS should be implemented exclusively for the blog section, and not for any other pages on the website.

Describe alternatives you've considered

No response

Criteria for Completion

No response

Anything else?

Additional considerations and information:

• Our decision to implement a blog was further validated through preliminary testing. We created basic content pages (example) and linked them to Google Search Ads via the Google Nonprofit Program, which resulted in a noticeable increase in traffic.
• We have a free NGO account for storyblok.
• We use Vercel which seems to be working with Storyblok (Demo, Code). The boilerplate design with text and image would be a solution that works for a start.

Code of Conduct

• [X] I've read the Code of Conduct and understand my responsibilities as a member of the Social Income community

[ssandino]

@renestalder, I have roughly sketched it out as discussed. Thanks for your help!!!

[renestalder]

@ssandino Thanks. Gonna take a look at it.

[renestalder]

@mkue I quickly wanted to prototype this, then noticed, we have some kind of custom setup with nextjs, as it doesn't follow the usual architecture of using pages/ folders. I also didn't find any note about this in our README.

Where do I begin to find out how this is configured, so I can adapt to that setup? I thought the next.config.js would give me some hint, but it just “magically” seems to work like it does.

It was answered by @ssandino via Slack. They have a "router switcher" hidden in the top section of the NextJS documentation, which I never noticed. My Google search always brought me to the documentation involving the other router.

[renestalder]

@ssandino Is there any need for «region» translated journal entries? Or are languages sufficient enough?

[ssandino]

Languages are sufficient – don't see a need to show journal entries based on region of a user.

[renestalder]

I have now Storyblok connected on the branch im working on, including the setup for using the visual editor.

I'm now about to integrate the journal story type I've setup in Storyblok.

[renestalder]

Another status update and why the ETA is difficult:

• While the connection to Storyblok works, to make the CMS useful, a simple content preview is necessary, to be able to check on whether content is rendererd correctly.
• As Next.js 14 uses the relatively new and experimental Server Side Components part of React, it assumes to render all content server-side per default.
• It's possible to define client-side only rendered components. For a preview, we need some kind of client-side rendering, so the unpublished content can be retrieved on demand.
• Traditionally, and also previously with Next.js 14, frameworks allow to use the same components for server-side rendering and client-side rendering, allowing to retrieve data on the client too and render it in the same components that previously were rendered on the server.
• As Next.js 14 isn't doing this the way it used to be (for the good and the worse), I'm currently trying to figure out how I can achieve this with dynamic routes/split routes.
• The alternative is to do everything twice; having every component as a server-side one and a client-side one.

It's quite a hazzle, as Next.js 14 is new enough for official documentations not covering it especially. All documentations cover Next.js 13, where this is somewhat «easy» to do as it follows well common known paradigms.

I keep you posted.

[renestalder]

@ssandino @mkue Please somebody else with NextJS experience take that over. My journey with Next so far is a rather frustrating one and this burns completely through my spare time trying to fill the gaps that are missing from the react server components feature-list and NextJS gap-filling solutions.

Also, I get the impression, all tools that help me work in sandboxed environments, in particular Docker and Storybook, are not appreciated by anybody else and getting removed from the repository (Docker being removed a while ago). Which makes working with the code, at least for me, so much more time consuming.

[mkue]

I'll take it over.

Also, I get the impression, all tools that help me work in sandboxed environments, in particular Docker and Storybook, are not appreciated by anybody else and getting removed from the repository (Docker being removed a while ago). Which makes working with the code, at least for me, so much more time consuming.

Well, someone needs to maintain these tools/environments, and with very few people actively working on this repository, and nobody apart from myself actually committed to investing time into improving the dev experience, I have no motivation to keep everything alive for people who just spend a couple of hours per year working on this codebase. You are welcome to bring those tools back if you also commit to maintaining them.