nextcloud
Move most of this to a static web page generator
We experience a lot of load on our web page and it would be a good point in time to move the whole wordpress setup to a static page generator like Hugo. The advantage of this is:
- no need to have a quite complex setup with PHP-FPM, apache and vagrant to achieve good performance
- no need to deal with cache invalidation on the server side, because the rendered stuff is what the web server serves and the kernel/web server itself takes care of caching and co
- don't abuse the wordpress import feature for the static pages like /jobs, /team, all the feature pages etc
- all the content in one place and not half of it in this git repo and the other half in the database
- getting a dev setup should then be easier - currently it involves a lot of manual steps to get the wordpress properly setup
- automatic deployments to a staging and a production server should be easier then (because no need to keep the blog posts & co in sync because they are only held available in code)
Remarks:
- some dynamic pages need to be in place, like the pricing form and the white paper form, but this should be feasible
cc @MariusBluem @Espina2 @jospoortvliet because we talked about it.
A few questions:
- Should we put the blogs also in this?
- how do we deal with secret variables like the captcha code, the (future) mautic stuff et all? Something dynamic has to run to deal with that, right?
- example: downloading a whitepaper on https://nextcloud.com/education -> that should go via Mautic; and there's a captcha of course.
- I guess it can handle translations too?
I think I we make this incrementally, and replace page by page with an apache alias to the new project. This that can be more difficult is like you said the dinamyc content, and the integrations with transifex, mautic. But Maybe the translations can be done with a cronjob, that update the .yaml configs files, and an API for the other stuff?
For the blog I suggest to use ghost, I actually made an installation on a docker container and I didn't loose more then 10/20 minutes to have the blog looking like this.
@MorrisJobke I think We just a test/staging server to get started, do you think that we can have that?
Example of ghost running Nextcloud-blog 176.78.39.118
For the blog I suggest to use ghost
Why do we need a separate system for the blog? Wouldn't it kill one of the main points by @MorrisJobke having everything in one place, easy to build and set up? Hugo or any other static site generator should work just fine for the blog.
integrations with transifex
Hugo provides this.
mautic
Should be possible
For the blog I suggest to use ghost, I actually made an installation on a docker container and I didn't loose more then 10/20 minutes to have the blog looking like this.
We should use Hugo here as well - that tool is designed for this.
Why do we need a separate system for the blog? Wouldn't it kill one of the main points by @MorrisJobke having everything in one place, easy to build and set up? Hugo or any other static site generator should work just fine for the blog.
Full ack 👍
With ghost you don't even need to touch the code to publish an article, so people just did what they want to do, write a post... So if the code is not touched, you will have less problems and less efforts on maintenance.
The backoffice for writing is really powerfull. And separation of concerns its good... Having a long project with all the pieces toghether I think it will be a worst ideia right?
But i'm not the expert here. ;)
how do we deal with secret variables like the captcha code, the (future) mautic stuff et all? Something dynamic has to run to deal with that, right?
I guess we will find a way.
example: downloading a whitepaper on https://nextcloud.com/education -> that should go via Mautic; and there's a captcha of course.
Depends where to serve this from, but a redirect to mautic and back should be possible.
With ghost you don't even need to touch the code to publish an article, so people just did what they want to do, write a post... So if the code is not touched, you will have less problems and less efforts on maintenance.
But you need a cache and have again two systems to maintain.
The backoffice for writing is really powerfull. And separation of concerns its good... Having a long project with all the pieces toghether I think it will be a worst ideia right?
I think having all in one place with proper separation of content and layout (what hugo for example provides) makes sense and is even easier - otherwise you need to theme two different software components.
The cache layer is not varnish?
This is then not needed anymore, because hugo just generates flat html files and that's it - apache is totally fine serving this and the kernel/filesystem caching capabilities are used.
Think of all content as flat markdown files with some metadata (for permalinks or categories): https://github.com/MorrisJobke/morrisjobke.github.io/tree/master/_posts for example
In this case it is Jekyll - but it is basically the same for hugo (or pelican or jekyll or every other static page generator).
The only advantage that ghost had, you like a visual tool to do that kind of thing. It's more easy to use, and user friendly.
So for non developers the experience will be more lean and easy.
The only advantage that ghost had, you like a visual tool to do that kind of thing. It's more easy to use, and user friendly.
So for non developers the experience will be more lean and easy.
That's correct. On the other side we have really good people and @NinaNC as well as @jospoortvliet are fine with it. And from an administrative point of view the completely static rendered HTML is far better and more scalable. Sadly everywhere compromises need to be made :/ But I guess this will be a good way to move the current website to.
In the end any solution it will better then the current one, so it will be always a win in any case.
BTW its possible to have like a search on hugo page. So if you for example want to search for specific blog post?
BTW its possible to have like a search on hugo page. So if you for example want to search for specific blog post?
At least their website offers some options: https://gohugo.io/tools/search/
And there is a long thread about it in their forums: https://discourse.gohugo.io/t/how-are-you-implementing-site-search/986
So for both posts and the pages of the site itself - we can use full html, css, javascript if needed, right? Anywhere? So if in a blog post I want a nice looking button or quote like in https://nextcloud.com/blog/nextcloud-13-brings-secure-file-sync-and-collaboration-to-the-next-level/ I can do that? It isn't super duper common but I would like the flexibility ;-)
Note that the quote part there is just the normal blockquote that is CSS styled in the site theme, so not special, though sometimes I add inline css, putting it in a div to make it float right and stuff like that.
Actually I care more about that than being easy to use - we don't need a graphical editor... As long as I can put up a preview on staging before we release so we can review and edit it before it goes out.
If all of this should work, my next question is: when do we start, and how?
So for both posts and the pages of the site itself - we can use full html, css, javascript if needed, right? Anywhere? So if in a blog post I want a nice looking button or quote like in https://nextcloud.com/blog/nextcloud-13-brings-secure-file-sync-and-collaboration-to-the-next-level/ I can do that? It isn't super duper common but I would like the flexibility ;-)
I guess so, but need to check. I will provide you with some first steps today or tomorrow, so you can get a feeling for this thing.
Content is written in markdown but you can add as much HTML and inline CSS code as you want (I run my blog/webpage also with Hugo and do this regularly). Not sure about JavaScript though.
As the content is static as such, we would have to consider how to implement l10n, especially how to apply updated translation.
The docs on their side is available here: https://gohugo.io/content-management/multilingual/
