Hacker News Reader

Comment by eatonphil | Hacker News Reader

Just a reminder, always add on some static page generator on top of Wordpress so you completely avoid the class of problems with "too many database connections". Yes that error is MySQL specific but the class of problems you're avoid is: not hitting the database for fairly static content like blog posts.

View on HN

Some 10ish Years ago what I really needed for work was a way to have a dynamic/staging environment with wordpress, and then to be able to deploy a fully statically generated version of the site. We had dozens of government agencies we were working with at the time, and there just wasn't anything suitable available.

One of wordpress's delights on the DB layer at the time (may still be true?) is that a sizeable number of the database entries were marshalled php objects. So many of them also ended up encoding the domain name in some way, that what we ended up doing was writing some code to essentially just rsync files from one server to the other, and then download the tables from MySQL, update all the records one at a time, and then upload to the new database location. It worked, remarkably well, but yikes. The potential fragility in that solution always scared me.

When I left that company was when static site generators started to take off, but they were all still very techie oriented, with markdown files, rather than any kind of dynamic website to create the content in.

That was one of those rare cases where it felt like I could actually see a potential product & market.

long long ago i never trusted wp or other cms/ blogging software but since i wanted to play with all of them at the time i would just download the html it outputs delete the php files and replaced them with the static html. Adding new content either involved repeating the process or i wrote some simple newpost.php that would update all the html files. the traffic to the admin area looking to run known exploits was quite funny.

I suppose one could automate the process and temporarily de-weaponize the website to enable updates then swap the html back in when done.

Is there a plug-in or another software that does this? I’ve been looking for ways to statically “archive” a Wordpress site so I can host it on GitHub Pages but still have the editing/theme/plug-in support. I don’t care about the search functionality.

Simply Static

https://wordpress.org/plugins/simply-static/

Has anyone actually done this? I looked into it briefly, came away thinking it was going to be non-trivial to get working (or might have downstream bugs), and gave it up as not worth it.

But I could have been completely wrong. Anyone have real world experience?

(BTW - My site is small and 99% of users are not logged in, and 99% of pages are unchanging, so a perfect use case for a static site.)

Yep. Did it this weekend. Moved main blog over to a different subdomain, added basic auth to stop it being crawled, added Simply Static, pressed button and a few minutes later the main site was updated.

Some perf tweaks I made were to point the main site’s wp-content/uploads at the WP htdocs via a nginx path mapping, and to tell SS to never export anything in uploads. Reduces the site generation to just the html, css, and JS.

The only issue I've found so far is that archive URLs like /YYYY/MM/, which would be handled by Wordpress to list all posts in that month, don't get exported by Simply Static. I suspect it's because they're all available by a select dropdown that's using a JS hook for onChange(). I solved this by creating an unlinked page, and put in an Archives block, then told Simply Static to add that unlinked page to the crawl list.

The other caution is that it doesn't export anything that's not linked. So if you've got no links to the yearly archives, then you get no index.html files for /YYYY/ either. Unfortunately, the Archives block in Wordpress doesn't offer a toggle between months and years, so you can't just create another block in the "archive finder" page and set it to years.

The support forum section of wordpress.org for the plugin appears to be a lot of people asking for support and no comments by the plugin author. If it works for you, then that's probably not an issue.

Yep, it wasn't too hard to get it working. I modified my theme slightly to get rid of the search bar that doesn't work, and I hid comments, since those won't work either.

My homepage running on vanilla Wordpress: https://www.skyfaller.space/

The same site using Simply Static: https://static.skyfaller.space/

Does it feel slightly faster?

You can feed both URLs to Google's Page Speed tool. The dynamic page scores 75/96 (mobile/desktop), and the static scores 72/98. So perhaps for your specific case it's not much of an improvement (I'd consider the 3 point drop for static mobile to be within margin of error).

[0] https://pagespeed.web.dev/report?url=https%3A%2F%2Fwww.skyfa...

[1] https://pagespeed.web.dev/report?url=https%3A%2F%2Fstatic.sk...

Actually for me the Wordpress version loaded faster! But I guess pagespeed is the right way to check.

Problem with these plugins is that if you have a large database with posts/pages, it could run into memory/CPU issues while trying to generate the static files and can intermittently fail unless you are on a beefy server.

Cloudflare is a great option for this.

Sure that's fine too all I mean is that you can run WP on a $5 Linode/DO VM and handle the front page of HN but you need to do static page generation.

I think people underestimate what's possible cheaply and simply with static pages. (Not saying Cloudflare is not free for this load but it is a separate additional step you'd need.)

I hadn't realized how easy static pages were to add to Wordpress - looks like it's just a plugin. Yeah that's probably easier than Cloudflare (which is still very easy).

and caching...

Outside of using a CDN, just simply using static files gives you caching for free at the file system level. Linux automatically keeps files in RAM when they’re used.

It's not just static files but database calls to construct pages

Hmm? Generating static pages avoids database calls to construct pages. You do it once when you publish/edit a post. Then every reader never makes a database call again.

I think we're arguing the same point, via different means.

Just to help with future understanding of how threads go off the rails: eatonphil added a comment about using static files instead of dynamic, then your reply was “and caching”, meaning “in addition to static files, also use caching”. At this point in the conversation, we’re talking about only static files with caching, so it doesn’t really follow that you’re bringing up “database connections” again, since that’s already been excluded in this thread.

I should have put caching also helps if you can't produce static stites via the application (i.e. some shopping cart software), not just wordpress.

Ah, now I understand what you meant.

Reply on news.ycombinator.com