Hacker News Reader

Comment by seriocomic | Hacker News Reader

I've recently jumped on the static bandwagon after being an early adopter and user of WordPress since CafeLog/0.71 days. What a blessing it has been.

I've taken two different approaches: 1. Maintain a local WordPress instance that builds the site using all the theme/plugin magic that WordPress is famous for, but have a static-export of that into Github -> Netlify.

2. Small sites being powered by Cloudflare Workers - using pure JS.

The jump to React.js / Vue / Go / Ruby et.al for an old PHP/HTML/CSS hack like me was too hard (and I tried them all!), so I settle for WordPress (the devil I know) for the build/back-end, and incorporate and embrace static on the front end. This separation is key - in my mind - for speed and security.

View on HN

I've seen people say WordPress is the devil, but honestly, I have found if you want a simple blog, it works extremely well. I selfhost two WordPress instances with a LAMP stack on Debian (the hardware is literally in my basement), and the maintaince I do is log in maybe once a week to make sure that Debian/WordPress auto updated. Most of the time I don't even do that because Debian/WordPress email me to tell me it's updated.

I think one of WordPress' biggest issue is that I have not really found a good how to to really set it up (they advertise their "5 minute deploy", but it leaves a lot of things lacking). If I set it up, I have a series of articles I used to set it up.

The other issue I've anecdotally seen is when someone installs a bunch of plug ins then gets into a dependency hell when trying to update.

WordPress is great for simple blogs.

The people (probably like me) who would call WP the devil is people who have had to maintain 15 year old intertwined WP instances riddled with outdated portions of the platform, insecure hand-coded modifications, terribly functioning custom plugins, horrible data hygiene for exporting and re-appropriating content, and terrible, clunky infrastructure setups. WordPress makes all of those easier, and encourages them when it’s anything more than a simple blog or product page or something. It’s easy for new features to be requested and sold and horrible to sell fixing any of the above problems. It goes on deaf ears once people get used to the web products just being there. And once clients get used to the blog interface, you dare not recommend any change no matter how good for the business.

I’ve seen smart, talented people just give up in the face of that kind of monstrosity, shelve all their plans for improvement and just buy into the duct-tape patch jobs of yore and developing one-off plugins for every request because it’s fast and needed to be done yesterday because something else has been requested or broken.

After my rambling let me reiterate that Wordpress is great for its intended application. But it is horrible for the extrapolated purpose many companies and teams have bent, twisted, and surgically manipulated it to be used. It’s not Wordpress’s fault exactly. It’s those who’ve recommended wp as a tool to solve problems it wasn’t meant for, and industry that has built up around that to make it appear as if it’s a viable solution.

The one time I was brought on to a WordPress project, it was deployed via ftp and there was an ominous text file (not named Readme) in the root that said something like "we had to use a lot of symlinks to get things to work. Be careful deploying"

That sounds hauntingly familiar. How bad is your PTSD? haha

This. Client wants a "simple" site, but insists on custom themes and plugins that break or are unsupported or abandoned by the developer.

Wordpress has had a history of serious security vulnerabilities that gave it a bad rap for folks that have been following the industry for a long time. I think automattic has done a great job overall in improving Wordpress and you don't hear about mass defacements or easy hacks for the standard wordpress install anymore.

The plugin ecosystem however opens you up once again: here the devil is in the details. Every plugin you install might be the giant blinking red light that says: hack me, steal my data, etc.

On balance though wordpress is pretty good these days.

Part of the reason for highly visible security vulnerabilities in Wordpress is just a result of the massive user base. Heavily used platforms are naturally more heavily targeted by malicious users since they are easier to find, and exploits are more readily available.

In truth, most software at any given time probably has serious security vulnerabilities that just aren't as obviously exploitable, and I wouldn't say that the volume of published exploits related to Wordpress is indicative of a poorly managed or written piece of software.

I used "devil" in the context of the axiom "better the Devil you know..." - so while I understand and relate to much of the anti-WordPress commentary, I wouldn't call it "the Devil". Just to clarify!

Ahh, fair enough! I have just seen a lot of hate to it, and I personally think some of that is unfair to WP.

How do you handle search?

Search and comments are the casualties of static-sites - unless you bow and crumble to the use of something 3rd party (Disqus or Google Site Search to name some poor examples)

Can't you point algolia at a static site and get decent search or have I misunderstood?

You can check out Lunr. The Jekyll theme Minimal Mistakes has that as a search option and builds a JSON index file.

The demo site uses Algolia though https://mmistakes.github.io/minimal-mistakes/

Hugo provides a Json output that can be used by a js script to provide simple search. I guess the same is possible for other systems.

Comments, contact forms and other features that "creates" content are more difficult.

staticman[0] for comments is a neat solution that avoids those surveillance companies. it can use heroku hobby tier for processing and github as the content backend for a free, hosted comments solution for static sites (fully acknowledging that heroku and github are both owned by other surveillers).

[0]: https://github.com/eduardoboucas/staticman

Comments are not as important as search, I guess. If the site has tons of pages, not having search might be annoying to the user

For a lot of situations something like jekyll search [0] works wonders. It basically generates a json file (you can customize it quite a bit). For even decently sized blogs it's quite quick and doesn't require a page refresh.

[0] https://github.com/christian-fei/Simple-Jekyll-Search

HTML form to jam the search string into a format like below (:

    https://duckduckgo.com/?q=site%3Ayour-site.tld+the+user+search+string

Can’t speak for GP, but I have a static site written in Gatsby. Yes (prepares boring-to-mention downvote armor) it is absolutely riddled with JavaScript. But if you want the ability to “search” without having a backend, Gatsby can do that.

May I know how do you do that?

Here’s some docs from their site: https://www.gatsbyjs.com/docs/adding-search/#reach-skip-nav

But they assume some context, which I’ll give you: At compile time, Gatsby is capable of making a list of all the posts on your site that you can query with GraphQL (at compile time) or use in the JS of your pages. In fact, saying it makes a list of all “posts” is selling it short, because Gatsby can store and manipulate arbitrary data structures. So if you’ve got a Documentation site with a table of contents and three levels of content within it... that’s all queryable at compile time too. It’s extremely flexible.

Now, it’s not like your pages will actually be using GraphQL to query a DB when the user arrives on the page: all the data is basically “baked in” to the page when it is compiled. But for a static site where the “data” only changes when you add/change some content and recompile, this works really well.

That’s great thank you!

Reply on news.ycombinator.com