I don’t get it. Their setup is so much more complicated and limiting than what they had on Wordpress. I won’t argue with their reasons to move (which don’t stack up for me either but agree to disagree).
Moving from WordPress to Jekyll (and static site generators in general)
31–40 of 60 posts
Re: Moving from WordPress to Jekyll (and static site generators in general)
#32I've been using ai coding tools in the last few months with static site generators. This is hugely empowering and completely obsoletes most CMS systems. Especially for more complex publication workflows. I'm using hugo, not jekyll. But I don't think it matters which site generator you pick. The key point is using something that is code driven. And then have AI drive the code changes. Basically all routine site mainte…
I went the other direction: instead of replacing the CMS, I open sourced a FUSE like layer [1] that mounts any backoffice system as a filesystem while the source of truth is in WordPress, Mysql, Postgres, .... Most backoffice systems map naturally to a file tree, so you mount them locally and let your agent read and write through that.
In the POC I ran, I mapped a whole wordpress site as a fs which was versioned controlled via git so when you did a git checkout of something, the whole db would get updated on the fly
Re: Moving from WordPress to Jekyll (and static site generators in general)
#33I've been using ai coding tools in the last few months with static site generators. This is hugely empowering and completely obsoletes most CMS systems. Especially for more complex publication workflows. I'm using hugo, not jekyll. But I don't think it matters which site generator you pick. The key point is using something that is code driven. And then have AI drive the code changes. Basically all routine site mainte…
This is super interesting! Thanks for sharing. I’m wondering myself how to put up a site with usual product stuff, blog and manual. The blog is running already on hugo on full llm automation but I had though it would not work for documentation (this is for non-techies so want something more product-manual -like and less SDK-docs flavour) or landing page that well. So this is you company’s site and it’s on Hugo? https…
Re: Moving from WordPress to Jekyll (and static site generators in general)
#34I have a legacy WP blog that I wanted to migrate to some static architecture for ages but IMHO users should be able to comment and maybe even post a pingback. I know, old MT days. But social media is always about getting (positive) comments and feedback, not just dropping statements and knowledge. I also don't want to tie my site to disqus or other 3rd party cloud services and their implication on GDPR.
> legacy WP blog ... users should be able to ...
(What's your blog about?)
Re: Moving from WordPress to Jekyll (and static site generators in general)
#35I've been using ai coding tools in the last few months with static site generators. This is hugely empowering and completely obsoletes most CMS systems. Especially for more complex publication workflows. I'm using hugo, not jekyll. But I don't think it matters which site generator you pick. The key point is using something that is code driven. And then have AI drive the code changes. Basically all routine site mainte…
This is super interesting! Thanks for sharing. I’m wondering myself how to put up a site with usual product stuff, blog and manual. The blog is running already on hugo on full llm automation but I had though it would not work for documentation (this is for non-techies so want something more product-manual -like and less SDK-docs flavour) or landing page that well. So this is you company’s site and it’s on Hugo? https…
Interesting facts:
- the domain was registered a few weeks ago
- most of the heavy lifting was done by our non technical CEO by prompting codex; not by me.
- he got a bit carried away with some features and he was able to pull off a little robot (powered by vector search and embeddings), audio transcriptions, and a few other nice features. He has a product/ux background and a good eye for detail but no coding skills whatsoever.
- we use a lot of skills and guard rails to guide content generation, SEO optimization, etc. Our SEO agent does competitive analysis on a schedule, figures out optimal SEO phrases and maintains a list of approved SEO language.
- our content generation skills guard against typical AI slop smells, weaves in SEO language where possible, and uses a sub agent to act as harsh critic on content. AI slop only happens if you let it happen. You can see on the querylight documentation site that I have a bit more of that there. I need to improve the skills for that one.
If you want to get your feet wet with this, I would just recommend doing it and start with simple changes. Use Claude Code, Codex, or whatever you prefer.
One of the first successes I had with another website was "add the logo for company x to the logo wall". It went off and figured out the website, got the logo svg, figured out where to put it and hooked it up in the right place. For me that was a oh "it can do that now" kind of moment. A lot of content changes are like that.
Re: Moving from WordPress to Jekyll (and static site generators in general)
#36Earlier quoted context omitted.
This is super interesting! Thanks for sharing. I’m wondering myself how to put up a site with usual product stuff, blog and manual. The blog is running already on hugo on full llm automation but I had though it would not work for documentation (this is for non-techies so want something more product-manual -like and less SDK-docs flavour) or landing page that well. So this is you company’s site and it’s on Hugo? https…
Could you use an open source CMS for non technical folks, i.e. Decap?
In my view, a CMS is intended for people doing stuff. If you transition that stuff to AI Agents, why keep the CMS around? And if AI does all/most of the coding, it's not such a big leap for non technical people to get their hands dirty anymore.
Re: Moving from WordPress to Jekyll (and static site generators in general)
#37There is a WordPress migrate-tool that worked flawlessly.
Re: Moving from WordPress to Jekyll (and static site generators in general)
#38Wordpress is better because it's easy to setup these days, can be fast if you enable caching, and has a comment system, which is a big deal if you want people to interact with your content. Other things like contact forms can easily be added. The CMS is also amazing. With SSGs, you have a few options for comments, like Disqus, but the ad-free version costs money, it's slower because it needs to load JS, and your comm…
The comment system bundled with Wordpress is not enough for "serious blogging", you'll need plugins to manage spam, allow users to use social accounts, etc. You'll also need plugins for caching. Oh, and you'll need plugins for SEO as well, because the core Wordpress doesn't handle the bare minimum of SEO and isn't flexible enough to allow you to do it yourself. And each plugin expands the attack surface to a system t…
Social accounts aren't necessary either. Users can simply not login, or use their email address. If you still want social accounts, it's a one click plugin install. With SSGs, you have to bake it yourself or buy a comment system that includes social auth.
SEO is a big deal, and Wordpress doesn't allow it by default. However, you can install a minimalistic SEO plugin like "The SEO Framework". If you want more advanced SEO, you can install a plugin like Yoast. With an SSG, you have to build your own theme that will allow SEO using frontmatter from your HTML pages, or use an existing theme that has that functionality.
Adding plugins introduce additional attack surfaces, but if you're building a full-fledged SSG to rival wordpress, you're connecting to various APIs, and writing your own code that could easily introduce security bugs. Wordpress plugins can auto update, but SSGs require you to fix bugs on your own time.
Wordpress version changes can break your site, but you can easily backup and restore your content for easier migrations these days. SSGs can also break your site if you want to keep the generator up to date. For example, if you use Jekyll 2, you'll have to spend some time refactoring your project when upgrading to version 4. Now, if you have integrations that you built yourself, this could take considerable effort.
I don't personally see how an SSG can compare to Wordpress. Sure, if you enjoy writing Markdown files in Vim then go ahead, but for people who mainly want to write content and provide a service that visitors can interact with, Wordpress wins all the time.
Re: Moving from WordPress to Jekyll (and static site generators in general)
#39Wordpress is better because it's easy to setup these days, can be fast if you enable caching, and has a comment system, which is a big deal if you want people to interact with your content. Other things like contact forms can easily be added. The CMS is also amazing. With SSGs, you have a few options for comments, like Disqus, but the ad-free version costs money, it's slower because it needs to load JS, and your comm…
Counter-point: static sites are unhackable, require no maintenance and are free to host. Now that I've migrated the website for a local (volunteer) event, they will never have to worry about their site breaking on them again. Multiply that by every nonprofit without tech knowledge and that's a lot of potential Jekyll fans.
Re: Moving from WordPress to Jekyll (and static site generators in general)
#40I've been using ai coding tools in the last few months with static site generators. This is hugely empowering and completely obsoletes most CMS systems. Especially for more complex publication workflows. I'm using hugo, not jekyll. But I don't think it matters which site generator you pick. The key point is using something that is code driven. And then have AI drive the code changes. Basically all routine site mainte…
> This is hugely empowering and completely obsoletes most CMS systems. I went the other direction: instead of replacing the CMS, I open sourced a FUSE like layer [1] that mounts any backoffice system as a filesystem while the source of truth is in WordPress, Mysql, Postgres, .... Most backoffice systems map naturally to a file tree, so you mount them locally and let your agent read and write through that. In the POC…
From a glance at you documentation I take it that I could just write a plugin for filestash ?