Hacker News new | ask | show | jobs
by JeanMarcS 2814 days ago
For sure everyone have his favorite way of doing things and what seemed obvious for some will look strange for others.

As I tested myself several SSG, I (as many it seems !) thought « Well, none fit my needs so let’s make one »

My problem was that I need an interface for the final clients, which are no tech at all, to be able to edit content.

Solutions like Hugo are not possible as it would means install it on a computer at the client office, and make him/her understand how to deploy. No go.

As the post states, they would also have to learn some stuff. Even more no go.

So for those case, the solution is to use a CMS like Wordpress. Which I don’t want.

So I built my own, using the best of both worlds.

For the backoffice, for managing content, a PHP/MySQL classic, with a media gallery and a tinyMce. Pages are in categories which can have subcategories and pages, as deep as you want.

Each page must have a template.

A preview button (which is the key) and an export site button.

And that’s all.

Of course, it only suits my needs (as me or some clients like web agencies will be in charge of the templating) and have no means of going public, so don’t fit what OP was looking for.

But it works, it was a two days job to create, and as it’s all mine, I can add any functionality I want.

6 comments

For Hugo in particular, Forestry[0] is really nice. If you're already using Netlify for deployment, they also have a CMS[1] that works well with most Static Site Generators.

[0] https://forestry.io/

[1] https://www.netlifycms.org/

So for those case, the solution is to use a CMS like Wordpress. Which I don’t want.

There are already a few CMSs for static sites, much like the solution you've made. The old-school one is Movable Type, but nowadays there's also one by Netlify, Publii, Siteleaf and a few others. There are also plugins for Wordpress that generate static sites from it (meaning you don't have to expose WP itself to the outside world).

That said, making your own solution can be the best option.

I reimplemented the Wordpress API on my own static site service so that Wordpress clients can be used seamlessly.

The idea is that Wordpress clients can be used to create content, but the output is a static site served from S3 and Cloudfront.

If you want to try it, send me an email: hello@perspect.com

How do you solve the dynamic parts that are sometimes required in a site ?
What in particular are you asking about?

There's nothing to stop you from using JavaScript in the browser to do any number of things.

I use Gatsby and then teach clients how to write markdown. Then they edit markdown content in gitlab, once they save (commit), the CI/CD regenerates the website and deploys to S3/Cloudfront.

There are other solutions, such as using wordpress or contentful to provide content and then regenerate the website when something changes. I think the creator of Gatsby is creating something like that as a business.

The article in the top of this thread is interesting. I can just add that in Hugo we have tried to make it simple for the simple stuff, but also make the "harder stuff" possible. We have naming conventions for layout files to keep it DRY (to avoid having to set "layout: blog" or something in every content file (you can)) and we have some special meaning behind "index.md" and "_index.md" -- which among other things allows for a navigable and not so rigid content tree. We even have plans to, in near future, to extend that tree into the content files themselves (ToC, paragraphs, sections). We may have different trade-offs than the article writer: With many sections and thousands of files in a deeply nested content tree, Hugo's layout system its speed may make more sense. Or not. So we do try, but it is hard to make everyone happy. I'm bep on GitHub.
Jekyll has most of what you're looking for as a plug in: jekyll-admin[0].

It doesn't handle authentication, so you'll need to put /admin under authentication on the web server level, but it allows you to edit and write pages, save them to drafts, view them as drafts, publish them, modify their metadata...

The only downside is image hosting, where the friction is still a bit too high.

[0] https://jekyll.github.io/jekyll-admin/