Hacker News Reader

Comment by HatchedLake721 | Hacker News Reader

What about keeping Wordpress under the hood to manage and update the pages, but then generate static pages off that?

I tried this last year for a Wordpress blog with ~1000 articles, and the time to generate the static pages was too long (several minutes) even for routine tasks like adding a new article. Simple things like a "New Articles" list in the sidebar can cause all pages to regenerate. I tried many different approaches (recursive wget, wordpress plugins, intercept wordpress output in PHP with ob_start() etc).

Ultimately, putting a Varnish cache seemed like the only logical answer to speed things a bit more, but that didn't avoid Wordpress security attacks.

For fun though, I built an experimental wordpress-clone dashboard that saved Hugo-compatible files instead, so I wouldn't miss Wordpress' editing features. The result was superb (<5 seconds to regenerate the ~1000 articles blog), but I missed the Wordpress plugins too much to switch to Hugo entirely.

But I still agree with you: "keep wordpress' editing experience, but generate static sites" is a pretty promising direction IMO.

I've been thinking about doing the same myself but with a direct tie-in from Node.js to MySQL to grab the post objects via mysql2... did you ping the WP JSON API for generating posts? I'm just confused as to how that would break things unless there's a serious bottleneck somewhere.

> I missed the Wordpress plugins too much to switch to Hugo entirely.

Do you mind if I ask which plugins?

Also, if you're missing plugins, it sounds like keeping the wordpress editing experience alone isn't going to be enough. The question then becomes, are you missing plugins themselves or what those specific plugins do for you that doesn't appear to be available in hugo.

As someone who does a lot of WP at their day job and has looked into other platforms, plugins like Gravity Forms are indispensable. It is nearly feature complete at this point and I have full access to the underlying code for any customizations in logic or design.

Some hosted form solutions offer features like basic e-commerce which is useful, but then doing something after a submission is almost impossible or everything is in an iframe so customization is limited.

If someone could port gravity forms to Craft, I would likely switch all new projects before the end of this year.

I imagine New Articles list would trigger all pages regeneration in any static setup, WP or not?

Yes it would. But pure static generation tools like Hugo are really fast. In my case, it was regenerating ~1000 articles in about a second, while doing it with wordpress was nearly 25 minutes.

Another similar approach is using “Serverless Pre-rendering” which is a fancy way to say serve stale and update in the background.

There is a demo using Notion as the “backend” which is kind of like Google Docs. I could see this being a great solution for less technical authors who only want to deal with content.

In the end, it’s like a static site but you don’t wait for a build step.

https://zeit.co/blog/serverless-pre-rendering

Yes, If you are fine with static pages it probably means that you would be fine using something like Varnish http cache.[1]

There might other options like caching at the DNS level with something like CloudFlare[2]

I don't work with Wordpress but generate static pages sounds like generating a cache, so these two option might be useful if you need to keep Wordpress but want the benefit of static pages.

[1] https://www.varnish-software.com/wiki/content/tutorials/word...

[2] https://wordpress.org/plugins/cloudflare-page-cache/

Varnish passes requests through to the underlying site (in this case Wordpress), which doesn't make it any more secure.

If the cache were fully populated (e.g. by spidering the site) and never became stale, then it would be roughly equivalent. Still, I'd rather disconnect Wordpress after spidering, so there's no chance of requests leaking through.

At some point your Wordpress installation version will be so far ahead that it may break your unmaintained theme eventually. Which is why I avoid this route if I can. It's hard to make promises to clients based off something so fragile.

Well, you have just built a custom theme to support the data from Netlify. I guess you could just as well have built a custom theme for Wordpress to avoid being stuck with an unsupported theme.

The difference is for my use case, Netflfy isn't a full CMS per se, the theme I built is for Jekyll which runs on top of netlify. It's just compiled static HTML files. There's nothing you can hack.

Why would your WP installation version be ahead?

If you're on WP and you forget about your website for say a year, WP version would be way high compared to the unmaintained theme that was built for an older version which would eventually break your site.

This isn't the case with a static website.

Reply on news.ycombinator.com