Refactor website to use a static site generator?

[wouterj]

I'm currently redesigning the CMF website (more on that in the coming days). And while it may sounds strange, I propose to build the CMF website using a static site generator instead of using the CMF. The reasons:

• It's very static at the moment anyway, nothing is build dynamically and everything is based on fixture loading. Booting Symfony to render the static content only adds overhead.
• It's a very simple site, it doesn't require complex content management systems. This means choosing a highly flexible backend (Symfony CMF) doesn't seem right
• GitHub's pull request systems seems to work while for proposing, reviewing and publishing blog posts to the site. If we're going to refactor the site to use an admin bundle, we would just rebuild this system.

The downside's are that we're loosing one project to test new releases on (but we have a pretty complete CMF sandbox for this) and it seems a bit strange to not use your own system for the project's site.

/cc @dantleech @dbu @lsmith77 @ElectricMaxxx

[dantleech]

I think we basically use it as a static site anyway, we make PRs on github to add content - the only difference is that somebody has to deploy the website, and I think this is now also done by a GH hook via. platform.sh.

So it does seem that we are using the CMF just out of priniciple. In its defence, it is AFAIK the only actual "real life" CMF implementation that we manage, so as @lsmith77 said, its good that we eat our own dogfood.

Bu taking it further, i.e. adding an admin backend, does seem counter-productive, the github PR system is better for collaborative work, but given the current setup, I don't see any advantage of using a static site generator? +0.

[ElectricMaxxx]

I think we should keep that Second show case. Cause it is the only real one. We should extend it by more features instead. We would decrease the value of the the CMF if WE would replace it by something simple. We can't sell Volkswagen and drive BMW in private. My opinion.

[wouterj]

Imo, we should advocate to use the right tool for the job. The CMF is the right tool when you need both the flexibility of a framework and easiness of a content management system. The CMF website only needs to provide static pages, it doesn't need any flexible backend as it does nothing dynamically.

Serving static pages through the CMF and Symfony framework (a) makes things a lot slower without adding any benefit and (b) makes things more difficult to maintain as there are a lot more dependencies and lines of code involved in serving the simple static pages.

If I would sell Volkswagen but lived 8 minutes from the Volkwagen showroom, I would use a bicycle and not a Volkswagen.

[lsmith77]

not sure if its really all that much slower. we could also easily activate the http cache. anyway .. I do not feel strongly about it

[dbu]

its a tricky question. i really agree with both. pro cmf is:

• eat your own dogfood
• its fast enough and works well for us (with autodeploy on platform.sh)

pro static page generator:

• it would be "the right tool for the job"

now if we are about ideology, i think in this case "eat your own dogfood" is more important than "right tool for the job". which to me means: is the current setup so painful that we should move to something else? if so, i am ok switching, but if there is no compelling reason, i can accept the slightly unelegant way how we add the "fixtures" (= static content) in those yml files in pull requests.

admin interface would be a clear -1 from my side as well.

[ElectricMaxxx]

Yea for sure with the admin interface we would loose the way of reviewing we currently have. So -1 for the admin interface from me to. But i would keep the current process as well. There is one point we can't do with the static pages: publishing to a specif date - as we are doing for news and event blocks. That is a real CMF feature we are using and which i really like.