Hacker News Reader

Comment by falcolas | Hacker News Reader

> You don't have to do this

I updated my original comment here.

> A good practice is to set up your own cron job on the server and disable the internal cron in your wp-config.php

Defaults matter. And when I was working on it, this wasn't well documented anywhere. If it is now, great. It shouldn't be the default.

> Just install a page caching plugin of your choice[1]

A bad idea, IMO. It's still going through the PHP server and all of the routing/plugin/DB code within WP. Much better to use Varnish (and its ilk) and avoid overloading the PHP service.

> Or use a managed WordPress hosting service

Back when I worked for an remote DBA company, we were tapped many times to help optimize DB access by Wordpress. It reminded me that it's remarkably easy to start a WP hosting company, and remarkably hard to do it right.

View on HN

> It's still going through the PHP server and all of the routing/plugin/DB code within WP. Much better to use Varnish (and its ilk) and avoid overloading the PHP service.

This is incorrect. WP supercache generates static html that takes precedence over falling back to the php engine. This is the way it worked nearly a decade ago too.

I wish people wouldn’t spend so much effort bad-mouthing technology they don’t even understand. I don’t even like Wordpress but reading this is super annoying.

Caching is hard. Drupal used to, may still use the dB for caches. So you get pool issues. You have to also throttle features, like site Search or other intensive scripts. So in the main the internal caching is a step up from none.

> A bad idea, IMO. It's still going through the PHP server and all of the routing/plugin/DB code within WP. Much better to use Varnish (and its ilk) and avoid overloading the PHP service.

I'm not a big WP fan, but this statement is false in most cases. Page caching in WordPress is usually (always?) serving up the pre-rendered HTML direct from disk (or CDN) without hitting PHP. Pagely (the post we're discussing) even handle that for you w/ their own CDN. I would imagine they also support request based caching and purging, warming, etc.

Most purely content sites (non-app) can run really well with a very simple TTL based cache (instead of long lived w/ complex flushing). You can very easily use something like Fastly for cloud based varnish w/ an appropriate TTL.

I also feel the need to point out that gatsby type sites and just pre-rendering / caching as well, at least in part (possible using json from a CMS for dynamic data).

> Page caching in WordPress is usually (always?) serving up the pre-rendered HTML direct from disk

I'd be very curious how a WP plugin is managing this.

Third party hosting building in caching, normal in-line caches (like Varnish), nginx/apache caching, sure - I get those, and they behave how you say. But a WP plugin? I'm curious how that would bypass PHP & WP entirely.

Server rewrites. Usually they work adding rules to Apache .htaccess.

On the other hand, this trick was mostly useful years ago when shared hosting plans were really underpowered.

As of today, with improvements of both PHP 7.x and general server performance, even a cache system that uses PHP very early (before any DB connection) to load a pre-rendered html cache file goes a long way in terms of number of pages being served.

Actually, if this become your bottleneck, the .htaccess trick won't help a lot, and you would still look in tools like memcached, redis or reverse proxies to improve things.

So I don't normally setup WP sites, but I have as a favour. A caching plugin just generates the HTML files and you configure NGinX / Apache to the appropriate directory. Historically I think most did it via .htaccess w/ Apache for shared hosts, but I've only configured it w/ NGinX. E.g. https://www.nginx.com/blog/9-tips-for-improving-wordpress-pe...

I think a lot of third-party hosts provide this out of the box, maybe even using their own CDN. WP is so popular that it's be difficult not to find a service that handled it all for you so long as you have room in the budget.

A lot of them do it via special htaccess rules. Check the cache first for an html file, otherwise, fall back to PHP. If not, there may be a little php code running but generally much less than a “normal” request.

>I'd be very curious how a WP plugin is managing this.

If you don't know how the cache plugins do this, it's pretty obvious you are not very knowledgable about WordPress site operations. Please stop spouting falsehoods here.

You touch on a really good point here about the default cron setting (yes, it still uses the lazy cron on page load by default.) From a developer point of view this is questionable at best, but from a business point of view I reckon decisions like these are the core of why WordPress is popular.

You don't have to know what cron is to install a WordPress site. You don't have to know anything about git or setting up varnish. You just bung the files on your PHP server, put in your database credentials and away you go.

There is a big conflict here between what is practical for users and what is best practice for developers. WordPress has always put user experience first, to the point where it's easy to shoot yourself in the foot and get your site hacked by installing a bunch of badly made plugins. But this tradeoff in the favour of user experience had made it easy for millions of people to set up their own website, and is the reason WordPress is the most popular CMS in the world

>But this tradeoff in the favour of user experience had made it easy for millions of people to set up their own website

Indeed. And so many commentators here on HN (myself included) bemoan FAANG centralization and wish for decentralization and federation and the like... well, this tradeoff is relevant in that matter.

There is a big conflict here between what is practical for users and what is best practice for developers.

What about the conflict between what is practical for users and what is best practice for users?

Security isn't just a developer's concern. Having to clean up a hacked WordPress site because of crappy defaults isn't very practical for users, either.

I realize that it's really written for end users instead of developers, but that means scares me every time I see something as high profile as the White House using it. For the exact reason as you say here: "it's easy to shoot yourself in the foot and get your site hacked".

WP is absolutely NOT secure by design; it's a hot mess that has helped normalize ignoring security in our web applications. That we encourage its use, that we haven't replaced it with something better, is a damned travesty.

Hopefully the White House has access to someone who knows how to set up WordPress without shooting themselves in the foot.

The fact that WordPress.com doens't get hacked all the time means that there are definitely people who know how to do it.

> The fact that WordPress.com doens't get hacked all the time means that there are definitely people who know how to do it.

Regular reminder that wordpress.com is a different software product to wordpress.org :)

wordpress.com runs their (relatively) newer JavaScript-based stack; wordpress.org (which is what we're talking about here, unless I misread the article referenced here completely) is the LAMP stack version.

Unless the new Wordpress is written in node, comparing the new “JavaScript” stack with the old “LAMP” stack makes no sense to me. Those technologies do not serve the same purpose.

> Unless the new Wordpress is written in node, comparing the new “JavaScript” stack with the old “LAMP” stack makes no sense to me. Those technologies do not serve the same purpose.

It's written in JavaScript; it runs on node.js - at least the front-end part of it (https://github.com/Automattic/wp-calypso). I don't know what is running on the backend but I don't think it's LAMP?

The point I was making though is that "WordPress" can mean two different things - wordpress.org (the self-hosted LAMP version) or wordpress.com, which is a SaaS offering (so the language is more or less irrelevant unless you're really interested in running your own admin frontend, I guess).

We run WordPress multi-site on WP.com to power several hundred million user accounts. So whenever you visit a domain hosted by us, you're hitting 99% core WordPress, plus some custom plugins and code we run to make it multi-datacenter and super-secure.

Calypso is our JS dashboard that lets you manage all your sites in one place, plus get cool WP.com features like stats and notifications. It's just a REST API client, just like the iOS and Android apps.

Yes, but there are also a lot of people who don’t. I still use an RSS reader and basically every six months, a blog that I followed 5 years back and went dark will get taken over by spammers because no one was paying attention to it anymore.

I can’t imagine what this has to do with the White House’s website.

We’re using the White House as an excuse to talk about Wordpress.

Reply on news.ycombinator.com