I found Grav the other day and I have installed it and looked at it and I really like what I see. Earlier I have tried Jekyll but every time I wanted to post a new article on my blog it took 45+ minutes to re-generate. It will become apparent why in a moment.
So - I want to switch from Wordpress to Grav.
Only problem is: I got close to 7000 posts in my blog. (Hence the 45+ minutes rebuild time with Jekyll…)
The export from Wordpress works fine with some tweaks to allow the timeout to be loooooonger. But what do I do then? Where do I put the exported articles? I tried to move them into /Users/posts under a “01.blog” directory and all of a sudden the whole server grinds to a halt. Is that because it’s generating the static pages?
Some more questions:
I tried to download a skeleton file but in that there is no /admin page to actually work with the site. Why?
Is there a generic way (like in Wordpress) do decide if your front page is a static page or a blog flow of posts, or is it up to the theme design to decide?
Do you have any general advice for someone like me running a blog with this many posts? Is Grav not the right choice?
Grav is a flat-file system and as such it does not need an admin. In fact, many people don’t use the admin plugin at all. Because of this Grav (and skeletons too) actually don’t come with the admin plugin by default. You can install it however by using Grav’s built-in package manager:
$ bin/gpm install admin
Easy peasy.
You can pick which page in your page structure by changing the value of pages: home: in your user/config/system.yaml file. If you have the admin installed, this is in the Configuration -> System tab.
7000 posts is quite a lot for Grav to handle. It will require some server optimizations and possibly new hosting on a modern VPS with SSD drives. There are other ways to get around some of these page problems. You could take some of your older blog posts, and merge them into single pages organized by month perhaps, or even year. This would decrease the number of pages Grav is working with dramatically.
If these don’t sound like options your interested in, then you might want to consider another platform that uses a database to keep track of your many posts.
First off, with 7000 posts you will need optimization on the system-level for smooth operation. Grav can theoretically support thousands of pages, but as it is filesystem-based you need strategies to do this without re-caching all of them on change. See this discussion for an example of 30.000-1.000.000 pages, as well as different ways of achieving this efficiently.
Second, each post should have its own folder, named as the slug of the post, under /01.blog. And within each of those folders, a Markdown-file to hold the content. For example /01.blog/my-first-post/post.md. You will need to either use the WP2Grav-plugin for WordPress or some equivalent converter to retrieve the content and place it in the folders.
Third, the theme decides how pages are displayed, but you can set the page to use as the home-page in configuration. Skeletons will generally include sample content, a theme, and some plugins. However, Admin is rarely included. But you need only download the Admin-plugin and drop it into the /user/plugins-folder to install.
Thanks all for your replies. I guess my normal NFS server will not cut it so I need to build myself a SSD-based storage for this. The reason I want to leave Wordpress is performance, or the lack of it. I’m currently forced to run six web servers with 6 CPU cores and 8GB of RAM each behind a Nginx load balancer just to get decent performance.
Yes, I do have lots of traffic so I thought it might be a good idea to run the entire site with static files instead.
In some regards static files are the most optimal in terms of performance, but load-balanced you do not really get the benefit of a dynamic system. I think you could cut that load-balancing down to 2-3 servers, and much less resources per, with Grav and aggressive-caching like discussed in the issue I linked to above. There are various examples of people having tested this out, though few proper articles with explanations of setups and results as far as I’m aware.
One example springs to mind: Busuu (blog post). As I recall their traffic is comparable in terms of server-needs, and when discussing it with Sebastien he detailed that they use load-balancing as a strategy in addition to optimizing their new site.
I have not tested this but here’s a suggestion. If you only have a blog and not a full website and you don’t mind converting your posts to Markdown (I use Desk.pm - Mac app) and uploading them to a folder on the server, then check out Pico and see if it’s simpler and more lightweight. http://picocms.org/
Hi, I also have the many pages problem. I have two different sites (directories of local businesses and accommodation) each with over a thousand pages, but in future they will (hopefully) grow several times that. The sites presently run in Ruby Middleman, exported as static HTML files. All content is in markdown with a local program keeping track of taxonomy-based stuff where modifications are made directly to relevant markdown files. I have reached a Middleman bottleneck where updating of many static HTML files simply takes to long and the complexity of selective updating becomes impractical. My thinking is to copy the local updated *.md files to the web server which will somewhat eliminate the present static file bottleneck.
I am also evaluating Pico and Phile but both platforms hovers on the edge of being abandoned with little new activity this year - on both those platforms I have increased page loading times dramatically using caching, plugins and turning the automatically generated menu system off completely.
What attracts me to Grav is the active development and rich amount of content - I am extremely impressed so far. Today I will learn, experiment and copy the MD files over to a local development server and see what happens.