I had a WP website, but because of performance problems (free hoster) I have to switch to static. I have already done this, using the WP plugin “simply static”, everything worked fine.
But in order to further easy develop my website and also to build future websites, just look for a good static websitebuilder. I looked at Hugo, pelican, nikola, but everything is a bit complicated for me. I would like to have a tool that can be used similar to WP, with CMS frontend, WYSIWYG editor, theme editor and multi-languages. Grav seems to have it all.
Now my questions before I install and test Grav:
Can I install Grav completely locally on a debian based Linux (Q4OS)?
What do I need for this? Just php, or also ddev? My website is not very complicated and could probably work locally with the server built into Grav.
Can I export my locally developed website as a “static website” and upload it to my web hoster without having to install Grav on the web hoster? So just html, the theme and maybe some scripts?
The only compelling reason I think is if your site doesn’t do anything server-dynamic (no forms, no filtered displays of content etc) and you don’t want to bother keeping Grav up to date. But as @anon76427325 suggested, there are plenty of tools specifically for that and they probably do a better job. If you find them complicated, you might find Grav easier, I’m not sure.
There are companies that offer free “cloud website hosting” for static websites. Think of Netlify and DigitalOcean. Functionality like preview, staging, rollback may be included for free.
And “static” might not be that “static” as it sounds when using functions provided by the hoster. See Jamstack.
Static Site Generators often offer out-of-the-box functionality to automatically publish a static site to these hosters.
Since I use a free hoster, the possibilities are somewhat limited. In addition, I have a rather unstable Internet connection with many interruptions. So local development is more pleasant. My website is really “static”, so there are few changes, unlike a blog. It is more of a documentation website.
With the normal static website builders, I miss good options for local development (development environment from a single tool). At HUGO, I have not yet found a CMS that works locally and does not require an Internet connection. I’m still looking for it with others (pelican, nikola). Publii would also be interesting, but on debian based distributions it is not easy to make it work. It is also propietary. 11ty is another option that I will only look at if it doesn’t work with Grav.
Grav is a tool that provides everything in one and with the plugin for static website it should work. There are good themes and other useful plugins. With the admin I can change things graphically without using the terminal and looking for the correct commands.
This is the kind of use I need, because I only develop a private website for myself, alone without a team. So I will never have a lot of experience and I will never have a website that needs frequent changes. Online help such as netlify or github is also not necessary, I have a hoster and I can also save the files locally, it makes a backup obsolete.
On the host server, I only will have the minimal installation and a flat file forum. No problems with zip file uploads that are too large and no problems with max-execution-time.
So I will tackle it and install Grav soon, with the above plugin for static website. Since I don’t have much time per day, it will probably take a few weeks until I have adapted the theme, built up the structure and copied the information into it, in 4 languages.
Ok, Grav is installed locally and runs fine with the integrated server. I have installed my desired theme. Now the plugins and some test pages follow. Then I do a first test with the static plugin and upload the result to the free hoster.
It all looks pretty good and with some patience and some diligence, I will certainly be able to work well with Grav.
Thank you for Grav, to all who work on it! It is really a good alternative to WP.
One argument which I am sympathetic to is that CMS’ are not interchangeable, nor interoperable, certainly not without rigging a larger workflow of middleman-solutions for API-communication. At that point you’ve basically built a CMS around the many CMS’.
Another is that all Static Site Generators (SSG), and I do mean all – I review and test a group of them yearly – of them are lacking in various ways. They either have some idiosyncratic, home-cooked way of doing things, do not follow standards, fail to separate concerns, or lock in content or design. Even the newcomers like 11ty, which seek to overcome this, end up doing very little that help the situation at all. The Jamstack-variants are the worst examples of lock-in and messing up concerns in years.
It is why I wrote the aforementioned plugin; Grav is in no way optimized for generating static content, and thus it is not an ideal or fast solution that works out-of-the-box. The case remains for agnosticism about the CMS, and still wanting a solution for serving static content with PHP as the system and Twig as the rendering-engine.
Sadly other PHP solutions for SSG’s are below par, which is why CMS’ have specific ones like the plugin or any of the static-generation plugins for WP. For documentation-purposes I have used the Scholar theme with the Static Generator plugin, but it is more technically involved.
In which regards the previous posters, pamtbaau and hughbris, are correct. If you are looking to host documentation – with features that typically go along with that – you’ll get it set up much faster and can focus more on content when hosting with a Git-service and building with Hugo, Jekyll, or any Jamstack-solution such as Hexo. You don’t need and don’t want to use a whole server running off of Debian for that.
Thanks for your plugin! I have already tested it a little. But now I have to build my own theme first and therefore learn something new again. As soon as I’m ready, I can then apply your plugin again. So far it has worked well.
The CMS landscape is about the same as the Linux landscape, you can’t see the forest for the trees! Sometimes I wish I had some good standard applications, or at least standard definitions. For example, that themes and plugins work on all CMS, for example, in their own “container” with a standard interface. That’s how they used to do it, with Ada.
And I wish good GUI without having to use the terminal. After all, we are in 2022 and not in 1972! I’m not against nostalgia or a “background solution” just in case, but we shouldn’t do “BBB” until we’re back at the touring machine.
So, first the theme, maybe with grapesjs or uikit? Gantry is a bit cumbersome, but at least it works. Then your plugin. The advantage with Grav and your plugin is that I can work with a pleasant GUI and do not have to type commands as with HUGO or Nikola. We’ll see where I end up!
Over the forest that you can’t see because there are so many trees in the way:
Many years ago, when I was a young man, informatics was something completely new! So I studied Informatics for 3 years. There were quite a lot of subjects and not all of them interested me equally. After 3 years, I first went into hardware development and came on my business trips through some European countries. But I was not happy with this, because the head of the company did not do project management. So I just ran after the small fires without it getting better. That motivated me to get into project management and I stayed there for 15 years, the last 10 years of which also as a lecturer at schools. You have to see the whole and not just the individual trees.
Today, the Internet is everything else. If you want to be a “software developer”, you need a github account and some code. And you already think you’re in! But you’re not. When I look at a new product, like Grav, I first look at the people who made it and their education. If this does not fit, then the chances are small that it will work out well.
You go to a car salesman and say that you would like to buy the pretty red car out there. He tells you, ok, if that’s what you want, then you should first learn a little more about mechanics, aerodynamics and engines, otherwise it will be difficult. Will you buy the pretty red car? Hopefully not!
But this is exactly the case with many software products today. You want to use it and ask for the facts, the answer is, learn programming first. Will you buy the software? Hopefully not!
And now open-source and free software comes into play. How many of these products could survive on the market if they had to be sold for money? 5%, or less?
The “software developers” of the Internet time should think about this.
I’m still thinking about the possibility of using “foreign” themes or plugins without changing them, that is, with an interface. Without understanding things in depth and knowing how big the differences between different CMS are, I came up with this possible solution:
So you leave the code as it is and wait for the error, then you fix it. And if it’s fast, then it’s no problem to fix the error again and again. For example, different variable names.
It is an approach that is somewhat contrary to our normal thinking, because we want to prevent errors in principle. But sometimes it is easier to let the error happen so that it is known and then offer the right solution. For example, to provide the right variable to the theme.
Ok, too naive?
The method is actually not unnatural and we often use it in life. For example, the pandemic, i.e. SARS-CoV-2. We think science has failed, they caused the pandemic with their research and we can no longer trust them. With exception handling there is a different solution approach. We trust, but we solve the mistakes. Example:
An article about the beginning of erroneous research in switzerland:
But because we are not used to focusing on the errors, but on the prevention of the errors, we have a system that is so big and cumbersome that it becomes corrupt and the errors still happen, but there is no exception handling! It’s a pity, isn’t it?
I also arrived at Grav when looking for a static site generator (SSG). I want a static site because it’s free to host with netlify, github pages, cloudflare pages, etc.
I’ve looked at many of the Jamstack SSGs and most of them require some programming language knowledge. A few of them only require markdown. It looks like Grav is largely markdown, so that is why I’m considering it (that plus the great templates/skeletons).
If I go with Grav I’d probably try to install it on my Windows PC and use the static plugin to output a static site to upload somewhere. The only problem is that I think that would disable the contact/email form capability.
