Whitehouse.gov Chooses WordPress, Again(pagely.com)
pagely.com
Whitehouse.gov Chooses WordPress, Again
https://pagely.com/blog/whitehouse-gov-chooses-wordpress-again/
370 comments
Simplicity? Perhaps in its use, but not the code. The code and hosting requirements are, frankly, Frankenstein's monster levels of frightening.
~~You have to~~ WP expect you to install it such that it can modify its install folders - all of them. Security-fucking-nightmare.
It will use incoming requests to trigger "cron" jobs (which can include self-upgrades), via a non-loopback HTTP request.
It falls apart under any kind of load, both because of unoptimized DB queries, and because of PHP. You have to put a cache in front of it to be able to handle getting on HN, let alone Reddit.
Arbitrary plugin installation, in a non-sandboxed environment (see prior point about an application-writable install). Need more be said?
You really have to dedicate an admin to it if you want to keep it secure and performant. I still get angry remembering my experience installing, securing, and setting up caching in front of it.
~~You have to~~ WP expect you to install it such that it can modify its install folders - all of them. Security-fucking-nightmare.
It will use incoming requests to trigger "cron" jobs (which can include self-upgrades), via a non-loopback HTTP request.
It falls apart under any kind of load, both because of unoptimized DB queries, and because of PHP. You have to put a cache in front of it to be able to handle getting on HN, let alone Reddit.
Arbitrary plugin installation, in a non-sandboxed environment (see prior point about an application-writable install). Need more be said?
You really have to dedicate an admin to it if you want to keep it secure and performant. I still get angry remembering my experience installing, securing, and setting up caching in front of it.
>Simplicity? Perhaps in its use, but not the code.
Nobody but other devs cares about the simplicity of the code if the code works.
>The code and hosting requirements are, frankly, Frankenstein's monster levels of frightening.
Huh? Wordpress/PHP hosting requirements are the easiest to meet in the industry. Not to mention the most widely available...
>~~You have to~~ WP expect you to install it such that it can modify its install folders - all of them. Security-fucking-nightmare.
Yeah, so? It's self-updatable. Use a dedicated user/group.
>It falls apart under any kind of load, both because of unoptimized DB queries, and because of PHP.
Absolutely not "because of PHP". If anything PHP is faster than both Ruby and Python, two other common choices.
>You have to put a cache in front of it to be able to handle getting on HN, let alone Reddit.*
That's the case with most CMS, PHP or not.
>Arbitrary plugin installation, in a non-sandboxed environment (see prior point about an application-writable install).
It only happens if you chose to do it. Plugins don't magically install by themselves.
So it's not much different than any environment where you can download a jar, a python package, a ruby gem, etc and have them add functionality into the CMS.
>Need more be said?
More, no. Better, yes.
Nobody but other devs cares about the simplicity of the code if the code works.
>The code and hosting requirements are, frankly, Frankenstein's monster levels of frightening.
Huh? Wordpress/PHP hosting requirements are the easiest to meet in the industry. Not to mention the most widely available...
>~~You have to~~ WP expect you to install it such that it can modify its install folders - all of them. Security-fucking-nightmare.
Yeah, so? It's self-updatable. Use a dedicated user/group.
>It falls apart under any kind of load, both because of unoptimized DB queries, and because of PHP.
Absolutely not "because of PHP". If anything PHP is faster than both Ruby and Python, two other common choices.
>You have to put a cache in front of it to be able to handle getting on HN, let alone Reddit.*
That's the case with most CMS, PHP or not.
>Arbitrary plugin installation, in a non-sandboxed environment (see prior point about an application-writable install).
It only happens if you chose to do it. Plugins don't magically install by themselves.
So it's not much different than any environment where you can download a jar, a python package, a ruby gem, etc and have them add functionality into the CMS.
>Need more be said?
More, no. Better, yes.
> Nobody but other devs cares about the simplicity of the code if the code works.
They care when you start quoting a week for a simple addition that should take an hour, because every time you have to wade into a mess, in which one wrong semicolon in functions.php brings down the entire website.
Of course you test and you test, but you're surrounded by landmines at all times.
They care when you start quoting a week for a simple addition that should take an hour, because every time you have to wade into a mess, in which one wrong semicolon in functions.php brings down the entire website.
Of course you test and you test, but you're surrounded by landmines at all times.
> They care when you start quoting a week for a simple addition that should take an hour
Exactly, this is the key point. If it’s a website that literally will never change then fine (edit: what I mean here is if you are confident WP can meet your needs without resorting to hacks, and can meet your future needs - in my experience, it’s when more functionality gets added on by random developers that things get messy, true of development in general though!).
I guess using headless WP might help? The clients I’ve worked with who’ve had WP sites in the past have made a point of saying they definitely don’t want WP again (due to security nightmares, usability etc) so honestly haven’t investigated it too deeply recently.
Exactly, this is the key point. If it’s a website that literally will never change then fine (edit: what I mean here is if you are confident WP can meet your needs without resorting to hacks, and can meet your future needs - in my experience, it’s when more functionality gets added on by random developers that things get messy, true of development in general though!).
I guess using headless WP might help? The clients I’ve worked with who’ve had WP sites in the past have made a point of saying they definitely don’t want WP again (due to security nightmares, usability etc) so honestly haven’t investigated it too deeply recently.
> in which one wrong semicolon in functions.php brings down the entire website.
Don’t immediately deploy code into prod until you’ve tested it?
Don’t immediately deploy code into prod until you’ve tested it?
How do you test wordpress without deploying it? \s
This conversation is feeding my suspicion that a lot of the problems people have with Wordpress come from not knowing how to work with Wordpress.
The professional approach is a local copy for development, a staging copy on hosting for QA, and then production. Code goes up in deployments; DB and files come down in regular synchronization. If there are multiple devs you might also have an integration copy on hosting.
This is not specific to WP; I’ve seen the same workflow work for other DB-backed CMSs like Drupal.
The professional approach is a local copy for development, a staging copy on hosting for QA, and then production. Code goes up in deployments; DB and files come down in regular synchronization. If there are multiple devs you might also have an integration copy on hosting.
This is not specific to WP; I’ve seen the same workflow work for other DB-backed CMSs like Drupal.
I've worked in environments using the exact approach you described, and it definitely seems like the prevalent workflow using these CMSs.
Still doesn't help that most WP sites I've ever seen inevitably were those huge card castles just waiting to crumble at the next plugin update. Cause of course, the remarketing plugin the client needs/wants installed just introduced some weird edge-case bug when used in combination with the latest version of the forms plugin you use. Or they ask (demand) administrative privileges "cause they're paying" and proceed to start messing with the configuration themselves and destroy everything. All the local development copies in the world won't make it less temperamental and brittle.
Its success - IMHO - doesn't have much to do with its technological merits but familiarity. Most "content" people know how to use WP, so companies like to have WP for their content management.
Or maybe I'm just bitter of my time working in the kind of environments that tend to focus on WP. Although last news I got were they were starting to use it more as headless CMSes.
Still doesn't help that most WP sites I've ever seen inevitably were those huge card castles just waiting to crumble at the next plugin update. Cause of course, the remarketing plugin the client needs/wants installed just introduced some weird edge-case bug when used in combination with the latest version of the forms plugin you use. Or they ask (demand) administrative privileges "cause they're paying" and proceed to start messing with the configuration themselves and destroy everything. All the local development copies in the world won't make it less temperamental and brittle.
Its success - IMHO - doesn't have much to do with its technological merits but familiarity. Most "content" people know how to use WP, so companies like to have WP for their content management.
Or maybe I'm just bitter of my time working in the kind of environments that tend to focus on WP. Although last news I got were they were starting to use it more as headless CMSes.
Have a dev site, which is easy with modern tools.
Even can do a CI/CD system.
Even can do a CI/CD system.
We do it with a secondary copy of our website.
Honestly though, there's a lot of talk about changes here without much talk of the most obvious class of changes that Wordpress is designed to support: adding content to your website or blog.
For all its faults it does make that very easy, and it's designed with the intent that you will do so by working directly on the live site (you can obviously preview and review content before making it live).
Changing layout and templates is trickier, likewise creating a new page layout, and that's where a staging or development site comes in handy.
Honestly though, there's a lot of talk about changes here without much talk of the most obvious class of changes that Wordpress is designed to support: adding content to your website or blog.
For all its faults it does make that very easy, and it's designed with the intent that you will do so by working directly on the live site (you can obviously preview and review content before making it live).
Changing layout and templates is trickier, likewise creating a new page layout, and that's where a staging or development site comes in handy.
Indeed, I have 3 copies of my wordpress site.
The main one, where people update content.
Then there's a backup that gets auto restored every morning (with appropiate sed etc to change URLS), which is suitable for developing and testing any code changes
The third is one which is manually restored from the backup, and suitable for longer term experiments, how best to organise pages, etc.
The main one, where people update content.
Then there's a backup that gets auto restored every morning (with appropiate sed etc to change URLS), which is suitable for developing and testing any code changes
The third is one which is manually restored from the backup, and suitable for longer term experiments, how best to organise pages, etc.
Programs in any language can crash due to a single character syntax error.
Even in static languages, if the syntax error is in something that will be reflected/eval'ed, etc (which in many languages includes regexes -usually not validated at compile time-).
What's funny is that this error would have been impossible to make within WP's built-in file editor. It lint checks before letting you save any edits.
If people avoid installing plugins and custom themes, and absolutely do not change the theme so that automatic updates have to be turned off, and they also install automatic updates, then its pretty fine.
As someone who works professionally at a hosting company, no one does this. The history of Wordpress security has followed window XP with users who downloads random files from the internet and click cancel every time something want to update. Every hosting company that I know has to implement firewall rules to address WordPress security, just like the old days of windows.
The default configuration is also not fine. At minimum you need to disable rpc calls to the login, as the password attacks trigger a lot work that eats resources and processes. RPC is on per default in order to make the WordPress mobile app work.
As someone who works professionally at a hosting company, no one does this. The history of Wordpress security has followed window XP with users who downloads random files from the internet and click cancel every time something want to update. Every hosting company that I know has to implement firewall rules to address WordPress security, just like the old days of windows.
The default configuration is also not fine. At minimum you need to disable rpc calls to the login, as the password attacks trigger a lot work that eats resources and processes. RPC is on per default in order to make the WordPress mobile app work.
The NFS requirement for multiple Wordpress hosts are an instant deal breaker for me when discussing CMS on the cloud.
Wordpress made sense when the web was a collection of independent servers. However in today’s cloud-orientated hosting landscape there are a thousand better ways to provide said content. Both at the beginner level and at the enterprise.
Wordpress made sense when the web was a collection of independent servers. However in today’s cloud-orientated hosting landscape there are a thousand better ways to provide said content. Both at the beginner level and at the enterprise.
Those independent servers haven’t gone away just because there are new toys in the box. They are still fast, cheap and ubiquitous.
I’m no fan of PHP or Wordpress by any stretch. But I agree with the pragmatic choice in this case. It will probably only need one dev to maintain the site. But even that would be overkill. You just never want a bus factor of 1. Especially for such a high profile site. But I’m digressing...
But cloud vs VPS aside, I do wonder is they are self hosting due to security reasons. Imagine a bad actor hacking into the WP installation! It does have a bad security record.
I’m no fan of PHP or Wordpress by any stretch. But I agree with the pragmatic choice in this case. It will probably only need one dev to maintain the site. But even that would be overkill. You just never want a bus factor of 1. Especially for such a high profile site. But I’m digressing...
But cloud vs VPS aside, I do wonder is they are self hosting due to security reasons. Imagine a bad actor hacking into the WP installation! It does have a bad security record.
Sorry, by “independent servers” I meant self hosting / on prem. And while that hasn’t gone away entirely it has diminished massively as companies deprecate on prem hardware as hardware ages and replaces those resources with cloud services.
Stuff like NFS made sense for on prem but it’s a terrible solution for building services on AWS (for example).
Security wise, any popular CMS will be a security nightmare. It’s not even a PHP thing. In an ideal world you’d stick your CMS behind a WAF and put some additional policies around your admin APIs (if at all possible). Wordpress, for all of its warts, actually made those parts easy to do.
Stuff like NFS made sense for on prem but it’s a terrible solution for building services on AWS (for example).
Security wise, any popular CMS will be a security nightmare. It’s not even a PHP thing. In an ideal world you’d stick your CMS behind a WAF and put some additional policies around your admin APIs (if at all possible). Wordpress, for all of its warts, actually made those parts easy to do.
> Security wise, any popular CMS will be a security nightmare.
I disagree, and I think it comes from a different understanding of what web security is.
Popular CMS software benefits from millions of people hammering on installations. If the community constructs a sane process for handling vulnerability reports (and WP has), then the average user of that software benefits from a robust continuous testing regime that they could never afford themselves. Testing and patching is an extremely important component of web application security in the long run, and also very expensive to do well. Most custom CMS projects do not bother to do it at all, and yet fool themselves into thinking they are secure because they wrote their own code.
No one can write secure software on the first try. The most well-funded and well-regarded software companies in the world spend tremendous effort on coding practices and testing, and still ship vulnerabilities.
Continuous testing and patching is always required. If your website is the only one running your CMS software, your first hint of a vulnerability may be when it gets exploited in production.
I disagree, and I think it comes from a different understanding of what web security is.
Popular CMS software benefits from millions of people hammering on installations. If the community constructs a sane process for handling vulnerability reports (and WP has), then the average user of that software benefits from a robust continuous testing regime that they could never afford themselves. Testing and patching is an extremely important component of web application security in the long run, and also very expensive to do well. Most custom CMS projects do not bother to do it at all, and yet fool themselves into thinking they are secure because they wrote their own code.
No one can write secure software on the first try. The most well-funded and well-regarded software companies in the world spend tremendous effort on coding practices and testing, and still ship vulnerabilities.
Continuous testing and patching is always required. If your website is the only one running your CMS software, your first hint of a vulnerability may be when it gets exploited in production.
You’re overlooking a key thing there though. You’re assuming every hack is a targeted one. And that simply isn’t the case.
Whenever a new vulnerability is discovered for WP (or any popular suite, be it a shop like Magento or message board like phpBB) you then get hordes of bots that trawl the internet looking for sites that run out of date versions of said software just for the purpose of hacking it. Even search engines become tools for bots to hunt out these insecure platforms.
I’m not someone who advocates security through obscurity however the vast majority of WP et al hacks are not targeted and thus a home grown CMS technically wouldn’t fall foul in the same way.
HOWEVER please don’t twist my words into saying that home grown CMSs are “more” secure. I’m making no such claim what-so-ever (and nor did I in my previous post when you want off on a soliloquy about how I apparently suggested that — I did no such thing!). My statement is and was only that any popular CMS will be a security nightmare. That point is very much true.
This is why I also brought up the point about WAF and additional policies on your admin path. The former buys you a little more time with updates (assuming you’re with a reputable WAF that supports the CMS platform you’re hiding against) because they can identify suspicious requests (ie ones that look like they’re triggering a known vulnerability) and simply block those requests from your site (technically the WAF is a reverse proxy with some firewalling, request heuristics, etc).
As for the point about admin policies: if you can IP whitelist who gets access to /admin then that saves you a lot of pain early on. But that’s obviously not always practical. However there are plenty of other ways to harden access.
Disclaimer: in a former life I used to repair and harden hacked CMSs, shops like Magento, etc.
Whenever a new vulnerability is discovered for WP (or any popular suite, be it a shop like Magento or message board like phpBB) you then get hordes of bots that trawl the internet looking for sites that run out of date versions of said software just for the purpose of hacking it. Even search engines become tools for bots to hunt out these insecure platforms.
I’m not someone who advocates security through obscurity however the vast majority of WP et al hacks are not targeted and thus a home grown CMS technically wouldn’t fall foul in the same way.
HOWEVER please don’t twist my words into saying that home grown CMSs are “more” secure. I’m making no such claim what-so-ever (and nor did I in my previous post when you want off on a soliloquy about how I apparently suggested that — I did no such thing!). My statement is and was only that any popular CMS will be a security nightmare. That point is very much true.
This is why I also brought up the point about WAF and additional policies on your admin path. The former buys you a little more time with updates (assuming you’re with a reputable WAF that supports the CMS platform you’re hiding against) because they can identify suspicious requests (ie ones that look like they’re triggering a known vulnerability) and simply block those requests from your site (technically the WAF is a reverse proxy with some firewalling, request heuristics, etc).
As for the point about admin policies: if you can IP whitelist who gets access to /admin then that saves you a lot of pain early on. But that’s obviously not always practical. However there are plenty of other ways to harden access.
Disclaimer: in a former life I used to repair and harden hacked CMSs, shops like Magento, etc.
It’s extremely rare for automated attacks to scale against popular CMSs before the patch for that vulnerability is available. In the vast majority of cases the script kiddies find out about the vulnerability when the patch is released. Then some bad guy has to write the script to target it, and distribute that and/or scale it. All a site owner has to do to win, is patch faster than that.
We always aimed to evaluate security patches same-day. The shortest lag we saw was “Drupalgeddon”—about 12 hours. In some cases we would see a lag of up to a month between the release of a patch and the signatures of automated attempts to exploit the underlying vulnerability. We eventually got rid of our IDS because all it did was log failed attempts to exploit vulnerabilities we had already patched, and fruitless door-knocking like password brute force attempts.
I’m sure you saw a lot of CMS installations that got hacked. I’m also sure that most them were because of either poor patch discipline, or misconfiguration, or both.
I guess it’s true that if someone is going to be bad at running a website, a popular CMS might be a bad experience for them. But even then a popular CMS may have an advantage: it’s a lot easier to find professional help for a popular CMS than for a niche or custom one.
Honestly, running any software at all is going be a nightmare for a lot of people. Hence the success of products like Squarespace and Wix; now they don’t have to.
We always aimed to evaluate security patches same-day. The shortest lag we saw was “Drupalgeddon”—about 12 hours. In some cases we would see a lag of up to a month between the release of a patch and the signatures of automated attempts to exploit the underlying vulnerability. We eventually got rid of our IDS because all it did was log failed attempts to exploit vulnerabilities we had already patched, and fruitless door-knocking like password brute force attempts.
I’m sure you saw a lot of CMS installations that got hacked. I’m also sure that most them were because of either poor patch discipline, or misconfiguration, or both.
I guess it’s true that if someone is going to be bad at running a website, a popular CMS might be a bad experience for them. But even then a popular CMS may have an advantage: it’s a lot easier to find professional help for a popular CMS than for a niche or custom one.
Honestly, running any software at all is going be a nightmare for a lot of people. Hence the success of products like Squarespace and Wix; now they don’t have to.
> We eventually got rid of our IDS because all it did was log failed attempts to exploit vulnerabilities we had already patched, and fruitless door-knocking like password brute force attempts.
All that means is that you’ve misconfigured your IDS. You’re supposed to filter out stuff that’s not a threat, not remove the entire IDS instance entirely!
You shouldn’t throw the baby out with the bath water https://en.m.wikipedia.org/wiki/Don't_throw_the_baby_out_wit...
All that means is that you’ve misconfigured your IDS. You’re supposed to filter out stuff that’s not a threat, not remove the entire IDS instance entirely!
You shouldn’t throw the baby out with the bath water https://en.m.wikipedia.org/wiki/Don't_throw_the_baby_out_wit...
> It’s extremely rare for automated attacks to scale against popular CMSs before the patch for that vulnerability is available. In the vast majority of cases the script kiddies find out about the vulnerability when the patch is released. Then some bad guy has to write the script to target it, and distribute that and/or scale it. All a site owner has to do to win, is patch faster than that.
Again you’re over estimating the average IT team’s ability to keep on top of WP patches. And again I have to reiterate my point about the advantages of a good WAF (web application firewall).
I’m not making a theoretical argument here. I’ve seen and have had to fix numerous sites from companies with competent developers and sys admins but who were simply unlucky enough not to notice that one RCE vulnerability in time.
> I’m sure you saw a lot of CMS installations that got hacked. I’m also sure that most them were because of either poor patch discipline, or misconfiguration, or both.
Neither actually. Just busy teams in medium sized business having a plethora of projects and too little time to manage everything with the same degree of love that your larger companies or start ups do when they have a dedicated team working in a single product.
Remember the appeal of WP for many is that it is “plug and play” so it often gets installed in organisations as a way of reducing the burden on existing developers and/or sysadmins. A strategy that makes complete sense on paper but can back fire spectacularly.
Let’s also remember that WP also appeals to the hobbyists too. You can’t accuse them of being incompetent sysadmins because they never set out to be technical. Instead they were sold on how easy WP is to install and manage.
Again this is why I keep discussing WAFs. Using them is non-obvious but it does reduce the burden on whatever individual or team manage WP.
> But even then a popular CMS may have an advantage: it’s a lot easier to find professional help for a popular CMS than for a niche or custom one.
Oh i agree. Choosing an established CMS isn’t a bad decision as there are plenty of benefits in doing so.
> Honestly, running any software at all is going be a nightmare for a lot of people. Hence the success of products like Squarespace and Wix; now they don’t have to.
This I agree with too.
Again you’re over estimating the average IT team’s ability to keep on top of WP patches. And again I have to reiterate my point about the advantages of a good WAF (web application firewall).
I’m not making a theoretical argument here. I’ve seen and have had to fix numerous sites from companies with competent developers and sys admins but who were simply unlucky enough not to notice that one RCE vulnerability in time.
> I’m sure you saw a lot of CMS installations that got hacked. I’m also sure that most them were because of either poor patch discipline, or misconfiguration, or both.
Neither actually. Just busy teams in medium sized business having a plethora of projects and too little time to manage everything with the same degree of love that your larger companies or start ups do when they have a dedicated team working in a single product.
Remember the appeal of WP for many is that it is “plug and play” so it often gets installed in organisations as a way of reducing the burden on existing developers and/or sysadmins. A strategy that makes complete sense on paper but can back fire spectacularly.
Let’s also remember that WP also appeals to the hobbyists too. You can’t accuse them of being incompetent sysadmins because they never set out to be technical. Instead they were sold on how easy WP is to install and manage.
Again this is why I keep discussing WAFs. Using them is non-obvious but it does reduce the burden on whatever individual or team manage WP.
> But even then a popular CMS may have an advantage: it’s a lot easier to find professional help for a popular CMS than for a niche or custom one.
Oh i agree. Choosing an established CMS isn’t a bad decision as there are plenty of benefits in doing so.
> Honestly, running any software at all is going be a nightmare for a lot of people. Hence the success of products like Squarespace and Wix; now they don’t have to.
This I agree with too.
What are a few of the better ways you would suggest at the moment? (Honest question from a WP dev?)
That very much depends on a case by case scenario.
I’ve seen WP used for everything from personal blogs, international news sites, shopping sites, and even fantasy sports games. The diversity of WP is definitely a strength. But it does mean that there’s not going to be a 1 size fits all alternative.
I’ve seen WP used for everything from personal blogs, international news sites, shopping sites, and even fantasy sports games. The diversity of WP is definitely a strength. But it does mean that there’s not going to be a 1 size fits all alternative.
>The NFS requirement for multiple Wordpress hosts are an instant deal breaker for me when discussing CMS on the cloud.
There's no "NFS requirement for multiple Wordpress hosts" tho.
There's no "NFS requirement for multiple Wordpress hosts" tho.
In theory that’s true but in practice there needs to be a common file system for WP to function properly otherwise you end up with a lot of kludges that break the admin panel or that adds other caveats to WPs normal behaviour.
I wouldn't suggest it personally, and don't think it's common.
> The NFS requirement for multiple Wordpress hosts are an instant deal breaker for me when discussing CMS on the cloud.
Unless you have a very dynamic site (posts hourly, multi-daily), would making it static-y be a solution?
* https://wp2static.com
Do a post via web GUI, it gets written out to disk, and then you rsync (or auto-git or whatever) to distribute it.
Unless you have a very dynamic site (posts hourly, multi-daily), would making it static-y be a solution?
* https://wp2static.com
Do a post via web GUI, it gets written out to disk, and then you rsync (or auto-git or whatever) to distribute it.
Depends on a persons use case because but not all WP installs are blogs / news sites.
However if you can and are going down the static site route then I’d wager there are easier platforms to start with.
I built a static site generator that takes markdown files and “compiles” them to HTML using pandoc. The whole thing is just 1 shell script. But that use case also wouldn’t suite most other people.
So it really depends on what the team need and what the site does.
However if you can and are going down the static site route then I’d wager there are easier platforms to start with.
I built a static site generator that takes markdown files and “compiles” them to HTML using pandoc. The whole thing is just 1 shell script. But that use case also wouldn’t suite most other people.
So it really depends on what the team need and what the site does.
NFS for sharing uploads folder? shift the media to a CDN when it’s uploaded and serve it from there. There are multiple plugins that do this.
That’s only half the battle. The working directory is designed to be writable so you either end up with PHP files copied onto the host with some complex syncing that breaks the admin panel, or you accept that the hosts share a common file system.
There are plenty of ways of doing it without NFS.
CMS in general, yes. WP specifically, no.
Often the “loads of ways” on WP require changing its normal behaviour and thus breaks ones ability to use the admin console. Or use some other kludge that might suit some subset of people some of the time. But ultimately it keeps coming back to kludges or other workarounds that introduce as many caveats as they solve.
Often the “loads of ways” on WP require changing its normal behaviour and thus breaks ones ability to use the admin console. Or use some other kludge that might suit some subset of people some of the time. But ultimately it keeps coming back to kludges or other workarounds that introduce as many caveats as they solve.
[deleted]
Wordpress is also the only CMS that offers multisite hosting - single codebase, single webserver, one docker container - for running multiple sites with different configuration.
You wanna run 2 blogs on Ghost - run 2 instances, same for _everything but Wordpress_.
You wanna run 2 blogs on Ghost - run 2 instances, same for _everything but Wordpress_.
Well, Drupal has multisite capability, too. I don't think using multisite is actually that good an idea. Having two separate websites be dependent on the same codebase is very prone to cause serious life cycle problems. I'd advice against using multisite on WP or Drupal.
We have been doing this successfully for many years, no problems. Some multi site installs have up to 300 sites running on them.
You have to know when to use the available technology.
Spot on. I am currently working on a project that has over 25,000 multisites running in WordPress Multisite. The amazing thing besides the sheer number is WordPress has not been a problem, throw it on AWS and the scaling issues are solved. People who proclaim that WordPress can't scale have never built anything scalable with it.
Awesome example, thank you for sharing!
Textpattern does that easily enough. You can even run your admin stuff on a different domain if you so desire.
Typo3 can do that too.
Well it’s a security shitshow and a fav for hackers looking for an easy exploit vector: just compromise it once and voila! All website consumers are at risk.
Just a shame there’s no liability for negligently causing users to get infected.
Just a shame there’s no liability for negligently causing users to get infected.
WordPress is not without its design flaws, some of which make sense from the point of view of helping non-techies run their own sites (such as making updates easy.) But as someone who has built 100s of sites with WordPress I feel the need to defend it on a few points here:
> You have to let it modify its install. Security-fucking-nightmare.
You don't have to do this, you can set up sane permissions and use the wp cli[0] tool to install updates manually. I prefer to version sites with git and install updates locally, then git pull down on to the live server.
> It will use incoming requests to trigger "cron" jobs (which can include self-upgrades), via a non-loopback HTTP request.
A good practice is to set up your own cron job[1] on the server and disable the internal cron in your wp-config.php, like this:
> It falls apart under any kind of load, both because of unoptimized DB queries, and because of PHP. You have to put a cache in front of it to be able to handle getting on HN, let alone Reddit.
Just install a page caching plugin of your choice[2]
> You really have to dedicate an admin to it if you want to keep it secure and performant. I still get angry remembering my experience installing, securing, and setting up caching in front of it.
Or use a managed WordPress hosting service like Kinsta[3] if you don't want the hassle. They'll handle all this sysadmin faff for you...
[0] https://wp-cli.org/
[1] https://www.siteground.co.uk/tutorials/wordpress/real-cron-j...
[2] https://en-gb.wordpress.org/plugins/w3-total-cache/
[3] https://kinsta.com/
> You have to let it modify its install. Security-fucking-nightmare.
You don't have to do this, you can set up sane permissions and use the wp cli[0] tool to install updates manually. I prefer to version sites with git and install updates locally, then git pull down on to the live server.
> It will use incoming requests to trigger "cron" jobs (which can include self-upgrades), via a non-loopback HTTP request.
A good practice is to set up your own cron job[1] on the server and disable the internal cron in your wp-config.php, like this:
define('DISABLE_WP_CRON', true);
> It falls apart under any kind of load, both because of unoptimized DB queries, and because of PHP. You have to put a cache in front of it to be able to handle getting on HN, let alone Reddit.
Just install a page caching plugin of your choice[2]
> You really have to dedicate an admin to it if you want to keep it secure and performant. I still get angry remembering my experience installing, securing, and setting up caching in front of it.
Or use a managed WordPress hosting service like Kinsta[3] if you don't want the hassle. They'll handle all this sysadmin faff for you...
[0] https://wp-cli.org/
[1] https://www.siteground.co.uk/tutorials/wordpress/real-cron-j...
[2] https://en-gb.wordpress.org/plugins/w3-total-cache/
[3] https://kinsta.com/
> I prefer to version sites with git and install updates locally, then git pull down on to the live server.
I’m working on my first WP project and am trying this approach. A question I have is how do you handle plugins that have hooks that only run once when installed? Those hooks don’t run if you pull in via git. Also if they make changes to the dB (migrations), how is that managed if the plug-in was installed on a different server?
I’m working on my first WP project and am trying this approach. A question I have is how do you handle plugins that have hooks that only run once when installed? Those hooks don’t run if you pull in via git. Also if they make changes to the dB (migrations), how is that managed if the plug-in was installed on a different server?
That is all usually still triggered even when using git. Git doesn't manage the database, so when the files make it to production and the plugins are activated, they see a database they haven't been installed in and then correctly run their hooks. Same for migrations. Migrations are managed with database entries, so if your production database doesn't have those entries, it will still run the migrations.
You can check out WP CLI to automate some of this as well.
You can check out WP CLI to automate some of this as well.
As far as I know there aren't any real hooks available for running code on plugin install, only activation. But I think OP is referring to core WordPress code and not plugins.
> You don't have to do this, you can set up sane permissions and use the wp cli[0] tool to install updates manually. I prefer to version sites with git and install updates locally, then git pull down on to the live server.
Yup this is exactly how I do that.
I also have a cron that checks "git status" and emails me if anything changes.
Yup this is exactly how I do that.
I also have a cron that checks "git status" and emails me if anything changes.
> You don't have to do this, you can set up sane permissions and use the wp cli[0] tool to install updates manually. I prefer to version sites with git and install updates locally, then git pull down on to the live server.
Curious as to how you manage WP with git, particularly around when new files are added by core/plugin updates, which I've always found a bit of a hassle to deal with?
Curious as to how you manage WP with git, particularly around when new files are added by core/plugin updates, which I've always found a bit of a hassle to deal with?
The most common approach is to store everything but the wp-content folder in git, including plugins. A way to save space there is by using composer so your Repo only needs to include custom plugins that your team wrote.
It can be a hassle on shared hosts, but most managed hosts have a git workflow that their agency partners utilize so it’s not too bad if you’re doing anything on a professional level.
It can be a hassle on shared hosts, but most managed hosts have a git workflow that their agency partners utilize so it’s not too bad if you’re doing anything on a professional level.
The problem is the only thing I really care about is the stuff in wp-content! I've inherited a few sites with custom themes and it's the changes in plugins that I'm most interested in so I can track issues. Almost anything else that comes from latest.zip I am not concerned with.
I just haven't found a good workflow I guess. I'm gradually trying to strip all the plugins which are not required (there are so many) so I can just focus on the core ones that are hard requirements but even one or two decent -sized plugins is a huge responsibility to manage if you're trying to pretend you're tracking all the changes to any level of detail.
I just haven't found a good workflow I guess. I'm gradually trying to strip all the plugins which are not required (there are so many) so I can just focus on the core ones that are hard requirements but even one or two decent -sized plugins is a huge responsibility to manage if you're trying to pretend you're tracking all the changes to any level of detail.
I keep things really simple to be honest, normally I exclude wp-content/uploads and wp-config.php in .gitignore. And set the perms so WP can't write to the filesystem on production, except for the uploads directory. We install and test updates on a dev environment first then commit everything and pull it in on production.
If you don't let production write to the filesystem, doesn't that get rid of one of the main advantages of WP, that users can configure the site by adding plug-ins and such? Or on the 100s of sites, you are responsible for all the plug-ins?
> If you don't let production write to the filesystem, doesn't that get rid of one of the main advantages of WP, that users can configure the site by adding plug-ins and such? Or on the 100s of sites, you are responsible for all the plug-ins?
The short answer is yes, you're right - losing being able to write to disk means a lot of functionality is lost. But it does improve security in some contexts so the trade-off might be worth it to some people.
I wrote a small plugin that lets me flick between read-only and read/write filesystem permissions with the press of a button - so when I need to administer it, I just allow writing, and the rest of the time I leave it locked off.
Doesn't work in all circumstances (e.g., if there are plugins that need to write to the disk), but for sites which predominantly have static content it means I don't need to worry as much about things writing to disk in the event something is compromised.
The short answer is yes, you're right - losing being able to write to disk means a lot of functionality is lost. But it does improve security in some contexts so the trade-off might be worth it to some people.
I wrote a small plugin that lets me flick between read-only and read/write filesystem permissions with the press of a button - so when I need to administer it, I just allow writing, and the rest of the time I leave it locked off.
Doesn't work in all circumstances (e.g., if there are plugins that need to write to the disk), but for sites which predominantly have static content it means I don't need to worry as much about things writing to disk in the event something is compromised.
If your using a versioned codebase you likely don't want that anyway. Otherwise you'll have untested code on production, and you'll have to commit it to the project repository from production.
Normally you want all code changes to happen locally, and get tested locally, before they ever make it to production. Which means your client will need to get you to install the plugin.
It depends on the project and client though. There are levels of engagement that are a lighter touch, and in those cases you just accept the mess and risk associated with users managing plugins.
Normally you want all code changes to happen locally, and get tested locally, before they ever make it to production. Which means your client will need to get you to install the plugin.
It depends on the project and client though. There are levels of engagement that are a lighter touch, and in those cases you just accept the mess and risk associated with users managing plugins.
Check out the roots.io project for some software development ‘best practices’ as applied to Wordpress for development and deployment.
Thanks! Looks super interesting.
Disable automatic updates on production. You don't want automatic updates on a production site anyway, they could bring your site down without you knowing. Instead, install updates and plugins locally, test locally, then push to live. That's really true for any code versioned software.
The pricing alone of wordpress hosting supports the counter argument that it is indeed too complicated.
Pretty much any shared hosting can support Wordpress. Kinsta was a suggestion where you pay for someone to manage and install things for you which is a lot more than hosting.
Right. I have a shared hosting site I used to host some projects on and now I keep it solely for a single wordpress site for a relative.
My thinking was a wordpress-specific provider might be cheaper so I went out looking for one with disappointing results. `
My thinking was a wordpress-specific provider might be cheaper so I went out looking for one with disappointing results. `
Happy to host your relative's site on WP.com, here's a 50% off coupon for HN peeps that will work the next 48 hours: HNEWSJANMATT . Please tweet me if you want any extra help from our team on the migration. I hope your relative is very happy.
> 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.
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.
> 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.
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).
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.
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.
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.
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.
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.
[deleted]
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
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
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.
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.
> 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.
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).
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.
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.
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.
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.
>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.
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.
I've had to run Wordpress against my will a number of times and while it's true that it a hacky mess it's also pretty well documented and as long as you use it as intended the end result is quite usable. It's PHP so pretty well tested deployments, metrics out of the box, individual interpreters for customers work well, it can be chrooted. Basic stuff like this has been built in with PHP for a decade.
> WP expect you to install it such that it can modify its install folder
Only if you want to have your users install plugins and modify the software with the web control panel. That may be the whole reason why you chose Wordpress, of course. Otherwise it runs well in a read only environment, apart from the attachments folder, and it is also documented.
> It will use incoming requests to trigger "cron" jobs
This is optional, for people who ran it on shared web hosts and didn't have access to crontab. It's all documented in the install instructions.
> It falls apart under any kind of load,
Well, yes. That's unfortunately true for all popular CMS software. It's a similar situation as with Gtk and Qt which are all flaming garbage under the hood. As an X11 user I accept that but I don't have to like it.
It's not noticeable for end users because as you realized in is intended to run with caching. That's the one big thing that should be better documented in the installation instructions. I had to evaluate half a dozen caching schemes just to choose one that seems to work well and is popular enough. There really should be one straightforward way to do it.
> WP expect you to install it such that it can modify its install folder
Only if you want to have your users install plugins and modify the software with the web control panel. That may be the whole reason why you chose Wordpress, of course. Otherwise it runs well in a read only environment, apart from the attachments folder, and it is also documented.
> It will use incoming requests to trigger "cron" jobs
This is optional, for people who ran it on shared web hosts and didn't have access to crontab. It's all documented in the install instructions.
> It falls apart under any kind of load,
Well, yes. That's unfortunately true for all popular CMS software. It's a similar situation as with Gtk and Qt which are all flaming garbage under the hood. As an X11 user I accept that but I don't have to like it.
It's not noticeable for end users because as you realized in is intended to run with caching. That's the one big thing that should be better documented in the installation instructions. I had to evaluate half a dozen caching schemes just to choose one that seems to work well and is popular enough. There really should be one straightforward way to do it.
So much this. It's been a bit over five years since I had to run it, but this is what I remember.
If you run multiple webservers, upgrading is extra fun, because when you upgrade, it assumes it can update the mysql schema (which is pretty much totally insane; a www-user writable php script shouldn't be able to create/remove/alter tables). The best way I found was to make a copy of the database, install the new version of Wordpress pointing at the new DB, thoroughly test, and then deploy new version pointing to new DB; then kill the old DB.
And woe is you if your webservers are geographically distant, because there's no way to send reads to a nearby DB mirror; and there's no way to run in read-only, because pingbacks still write to the DB even when they're disabled.
One of the best weeks of my last job was when I was able to finally convince my boss to replace Wordpress for our static company blog with a series of Makefiles and simple PHP to smoosh in all the translations.
If you run multiple webservers, upgrading is extra fun, because when you upgrade, it assumes it can update the mysql schema (which is pretty much totally insane; a www-user writable php script shouldn't be able to create/remove/alter tables). The best way I found was to make a copy of the database, install the new version of Wordpress pointing at the new DB, thoroughly test, and then deploy new version pointing to new DB; then kill the old DB.
And woe is you if your webservers are geographically distant, because there's no way to send reads to a nearby DB mirror; and there's no way to run in read-only, because pingbacks still write to the DB even when they're disabled.
One of the best weeks of my last job was when I was able to finally convince my boss to replace Wordpress for our static company blog with a series of Makefiles and simple PHP to smoosh in all the translations.
This is the plugin we use to run WP databases across many servers and geographic locations: https://wordpress.org/plugins/hyperdb/
> You have to let it modify its install. Security-fucking-nightmare.
You really don't. I've deployed it to Heroku, where the filesystem resets every 24h. It's a part of their famed five minute install for not-very-technical users on shared hosting, but it's by no means a requirement.
You really don't. I've deployed it to Heroku, where the filesystem resets every 24h. It's a part of their famed five minute install for not-very-technical users on shared hosting, but it's by no means a requirement.
It is if your users expect to be able to add plugins themselves, or you want it to do automatic version upgrades.
We disabled it (except for the attachments folders), and boy did it throw up all over the logs.
Using a filesystem reset is a nice way around WP's requirements. I'd personally hesitate to rely on it for a popular site, since it still leaves a site vulnerable to code injection for those 24 hours.
We disabled it (except for the attachments folders), and boy did it throw up all over the logs.
Using a filesystem reset is a nice way around WP's requirements. I'd personally hesitate to rely on it for a popular site, since it still leaves a site vulnerable to code injection for those 24 hours.
> It is if your users expect to be able to add plugins themselves, or you want it to do automatic version upgrades.
I'm fairly certain for the White House's sort of use case this is not an issue.
> Using a filesystem reset is a nice way around WP's requirements. I'd personally hesitate to rely on it for a popular site, since it still leaves a site vulnerable to code injection for those 24 hours.
We did not permit it to have write access to its own filesystem, at all. It worked fine. Uploads went straight to S3 via a plugin.
I'm fairly certain for the White House's sort of use case this is not an issue.
> Using a filesystem reset is a nice way around WP's requirements. I'd personally hesitate to rely on it for a popular site, since it still leaves a site vulnerable to code injection for those 24 hours.
We did not permit it to have write access to its own filesystem, at all. It worked fine. Uploads went straight to S3 via a plugin.
> I'm fairly certain for the White House's sort of use case this is not an issue.
One can only hope.
> We did not permit it to have write access to its own filesystem, at all. It worked fine.
Cool beans - you installed it sanely. But contrary to how WP expects to be installed. I've corrected the original statement.
One can only hope.
> We did not permit it to have write access to its own filesystem, at all. It worked fine.
Cool beans - you installed it sanely. But contrary to how WP expects to be installed. I've corrected the original statement.
With all due respect, you have demonstrated a shocking lack of knowledge about Wordpress. It’s been a long time since I’ve read so many falsehoods spoken with such certainty. That’s not a good thing.
> But contrary to how WP expects to be installed.
No, this is incorrect. WP is compatible with no write access and recognizes it in the default setup workflow.
No, this is incorrect. WP is compatible with no write access and recognizes it in the default setup workflow.
> because of unoptimized DB queries, and because of PHP
Don’t blame PHP. We use it to handle millions of concurrent users and it does it without breaking a sweat. It scales horizontally better than basically anything, Modern versions of PHP are remarkably fast, up to 3x faster than Python in recent benchmarks.
The real problem is Wordpress, it’s written like 20 years ago PHP to avoid breaking any plugins. The API is largely writing to global variables.
On top of that, the quality of the given plugins is usually dubious at best, and a lot of people just slather more and more of them on, and they often interfere with each other.
Don’t blame PHP. We use it to handle millions of concurrent users and it does it without breaking a sweat. It scales horizontally better than basically anything, Modern versions of PHP are remarkably fast, up to 3x faster than Python in recent benchmarks.
The real problem is Wordpress, it’s written like 20 years ago PHP to avoid breaking any plugins. The API is largely writing to global variables.
On top of that, the quality of the given plugins is usually dubious at best, and a lot of people just slather more and more of them on, and they often interfere with each other.
> We use it to handle millions of concurrent users and it does it without breaking a sweat.
Have you tried doing the same with other technologies?
> It scales horizontally better than basically anything
How does it horizontally scale better than projects written in Golang/C#/Ruby/Python/whatever?
> up to 3x faster than Python in recent benchmarks.
Computational speed rarely matters. If it does, you would usually fallback to C/C++/Rust library doing the heavy lifting, when using 'slow' languages, or just move the workload to async processes.
Web applications spend most of the time doing I/O operations, where async programming makes a lot of sense. Async with PHP is still in its infancy, compared to Python, which has native support for it.
Have you tried doing the same with other technologies?
> It scales horizontally better than basically anything
How does it horizontally scale better than projects written in Golang/C#/Ruby/Python/whatever?
> up to 3x faster than Python in recent benchmarks.
Computational speed rarely matters. If it does, you would usually fallback to C/C++/Rust library doing the heavy lifting, when using 'slow' languages, or just move the workload to async processes.
Web applications spend most of the time doing I/O operations, where async programming makes a lot of sense. Async with PHP is still in its infancy, compared to Python, which has native support for it.
WP only needs to modify itself if it updates itself. You can manage updates yourself with a git or even a CI workflow if you want to. These work the same way for WP as they do for a static blog codebase.
Or, you can keep folders locked down until it’s time to update, then unlock and let it update itself, then re-lock the permissions. This can be done manually or with a job scheduler.
WP needs a caching strategy for performance but so do static blog generators. The static copy is the cache, and rebuilding it is the cache purge.
Edit to add: Wordpress is so popular there are dedicated hosting companies, which makes all this stuff super easy. I managed WP myself for years; now I just have an account at WP Engine and they handle all this stuff for me.
Or, you can keep folders locked down until it’s time to update, then unlock and let it update itself, then re-lock the permissions. This can be done manually or with a job scheduler.
WP needs a caching strategy for performance but so do static blog generators. The static copy is the cache, and rebuilding it is the cache purge.
Edit to add: Wordpress is so popular there are dedicated hosting companies, which makes all this stuff super easy. I managed WP myself for years; now I just have an account at WP Engine and they handle all this stuff for me.
There's plugins and WP developers galore. Actually, for $89.99 per month you can have a team that watches and fixes your site as and when things go bad. All of the above does not appeal to the masses. Hide my WP takes away the security risk in minutes of adding the plugin.
It is amazing how tech people are so far off from understanding real, everyday non-tech people and their needs.
It is amazing how tech people are so far off from understanding real, everyday non-tech people and their needs.
I've been in the top 10 of HN and I think I saw at most 10-20RPS.
My $5/mo VPS running WordPress can handle about 50rps for an article page...
My $5/mo VPS running WordPress can handle about 50rps for an article page...
50RPS must be tuned or cached in some way, as the memory load for 50 requests to the full app should overwhelm the 1GB server and ~50-100ms is typical and the $5 instance has one core.
No tuning. I just installed WP, nginx, and MariaDB.
Here are the numbers from when I was testing how much comment threads impacts load time:
http://imgur.com/gallery/IQk2kun
Here are the numbers from when I was testing how much comment threads impacts load time:
http://imgur.com/gallery/IQk2kun
Ah, sorry. I expected Apache. Nice numbers.
Huh. That's a lot lower than I expected for a high ranked HN post. I'll agree, WP didn't start having issues until the 50-100+ range.
My site has also hit #2 on HN multiple times and never broken 10RPS during any of those times, AFIK.
Thank you for sharing. :)
The difficulties you mentioned seem naive at best. Throwing a cache in front of a high traffic site is common sense these days and not really stack-specific; keeping up with security updates is hard with any stack (npm package upgrades can be quite the nightmare); installing... have fun docker composing your app with a mysql image, I guess?
IMHO, this isn't that fair of a characterization of WordPress in the first place, considering that the alternatives that the GP mentioned don't come close to doing half of what WordPress can do. I could similarly sing praises about how static site generators are so much easier to maintain as a developer than next.js + whatever you cobbled up to handle data persistence, CMS auth, admin UI, SEO, domain specific logic (drafting, theming, social media integration, etc), but again, it's very much an apples vs oranges comparison.
IMHO, this isn't that fair of a characterization of WordPress in the first place, considering that the alternatives that the GP mentioned don't come close to doing half of what WordPress can do. I could similarly sing praises about how static site generators are so much easier to maintain as a developer than next.js + whatever you cobbled up to handle data persistence, CMS auth, admin UI, SEO, domain specific logic (drafting, theming, social media integration, etc), but again, it's very much an apples vs oranges comparison.
While, as others already pointed, most of your examples are debatable, I think parent was mostly talking about the simplicity about EDITING content, ie the benefits for the end user.
WordPress has become so ubiquitous in web publishing that often it is a client requirement when asking for a new website to a web agency.
Using WordPress is a skill that people put in their CVs, in the same lines where they talk about their MS Office proficiency.
WordPress has become so ubiquitous in web publishing that often it is a client requirement when asking for a new website to a web agency.
Using WordPress is a skill that people put in their CVs, in the same lines where they talk about their MS Office proficiency.
After a decade of dealing with a fleet of wordpress sites (most of our smaller clients has a wordpress site), our team has settled on a workflow when dealing with wordpress sites for our clients:
- a custom docker image suitable for use in docker/kubernetes environment. Vanilla wodpress docker image is not suitable for most of our needs, so we build our own images which includes everything we need an nothing more.
- security issues are rare if you follow basic security practice: strong password for administrative users, not installing plugin/themes from sketchy sources (pirated plugins/themes), and keep the number of installed plugins minimal.
- Sometimes a site was hacked by automated bots exploiting zero days in some popular plugins, but we have a clamav instance scanning the wordpress fleet's nfs volume regularly that flags them in timely manner. Containerization is a huge win here because it allows us to quickly redeploy the site with fresh install and prevent the bots from jumping between hosts (none of the bots we're dealing with are sophisticated enough to escape the container).
- Content was a major headache. Each site can use different themes with varying level of quality. We solved this by using Beaver Builder for all new sites with a custom, super minimal theme. This allow our content people to build the site layout visually while minimizing code bloats. This setup is also very cache friendly, unlike some of the themes I encountered in the past.
- Caching is very easy as everything is containerized. Just add a new memcache/redis container into the pod, which is just a few lines of yml or a checkbox in our internal tool. Same with daily backup and granting sftp access to external parties.
- When a client outgrows wordpress, we'll transition them away into a custom solution.
- a custom docker image suitable for use in docker/kubernetes environment. Vanilla wodpress docker image is not suitable for most of our needs, so we build our own images which includes everything we need an nothing more.
- security issues are rare if you follow basic security practice: strong password for administrative users, not installing plugin/themes from sketchy sources (pirated plugins/themes), and keep the number of installed plugins minimal.
- Sometimes a site was hacked by automated bots exploiting zero days in some popular plugins, but we have a clamav instance scanning the wordpress fleet's nfs volume regularly that flags them in timely manner. Containerization is a huge win here because it allows us to quickly redeploy the site with fresh install and prevent the bots from jumping between hosts (none of the bots we're dealing with are sophisticated enough to escape the container).
- Content was a major headache. Each site can use different themes with varying level of quality. We solved this by using Beaver Builder for all new sites with a custom, super minimal theme. This allow our content people to build the site layout visually while minimizing code bloats. This setup is also very cache friendly, unlike some of the themes I encountered in the past.
- Caching is very easy as everything is containerized. Just add a new memcache/redis container into the pod, which is just a few lines of yml or a checkbox in our internal tool. Same with daily backup and granting sftp access to external parties.
- When a client outgrows wordpress, we'll transition them away into a custom solution.
Just a quick note regarding Beaver Builder: when the Full Site Editor arrive on WordPress this year, we will be able to use native functionality to build the entire website, without relying on a third-party page builder to do this.
When is it scheduled to arrive?
They said (1) that there's no fixed date for the launch, as this is an ongoing effort.
But considering that the initial version of the Site Editor is already part of the official Gutenberg plugin (2) – and they usually include features from the current version of the plugin in the main app – it is expected to be released with version 5.7 of WordPress, next March.
(1) – https://make.wordpress.org/core/5-7/
(2) – https://wordpress.org/plugins/gutenberg/
But considering that the initial version of the Site Editor is already part of the official Gutenberg plugin (2) – and they usually include features from the current version of the plugin in the main app – it is expected to be released with version 5.7 of WordPress, next March.
(1) – https://make.wordpress.org/core/5-7/
(2) – https://wordpress.org/plugins/gutenberg/
There is some truth in here. However, CMS come and go and Wordpress is here to stay. Rules, rights, extensibility. It ain't perfect, however overall rating is still best in my opinion.
I pretty much enjoy headless CMS, but at the moment in my opinion nothing beats the ease and use of Wordpress overall, devs and authors.
I pretty much enjoy headless CMS, but at the moment in my opinion nothing beats the ease and use of Wordpress overall, devs and authors.
> It falls apart under any kind of load, both because of unoptimized DB queries, and because of PHP.
This is simply not true - modern PHP is very fast.
This is simply not true - modern PHP is very fast.
I love Wordpress but don't use it for 90% of the things I do. I grew up with Wordpress and I love that the code is simple for someone new to PHP. Wordpress for me, with no programming background at the time, was so much easier than Zend for example, which was very popular at the time.
[deleted]
I have worked for several years with WordPress. Everything you say is true if the devs are incompetent. Then yes, the variety of ways one can shoot themselves in the foot and completely dead with the system is astounding. I have seen horrible wp installations galore myself.
However that is not fault of the tool itself. There is nothing preventing a competent dev or small team to set up staging and qa environments, a ci pipeline if they are so inclined, write proper tests, be discriminating in the plugins they install and the quality of code they write. And the start threshold for the system is incredibly low, the fact that so much boilerplate functionality is _already there_ saves a lot on development costs and allows you to focus on functionality that really matters.
TL;DR if your wp installation is bad, it's not wordpress, it's you.
However that is not fault of the tool itself. There is nothing preventing a competent dev or small team to set up staging and qa environments, a ci pipeline if they are so inclined, write proper tests, be discriminating in the plugins they install and the quality of code they write. And the start threshold for the system is incredibly low, the fact that so much boilerplate functionality is _already there_ saves a lot on development costs and allows you to focus on functionality that really matters.
TL;DR if your wp installation is bad, it's not wordpress, it's you.
The threads of replies debating the technical "simplicity" of Wordpress are missing this part:
> easily modify content
If you have non-technical users editing a site, this one aspect takes precedence over everything else, and it's there that Wordpress continues to generally obliterate whatever workflow may qualify as "simple" to the average HN reader. If you've never used Wordpress' Gutenberg editor (or others based on the same model such as Medium or Squarespace), you should try it. The ability to not only change formatting but page structure and layout in a guided, template-driven way is simply not comparable to editing a Markdown file.
I'm pretty ambivalent on Wordpress' technical merits and its plugin ecosystem is a terrible attractive nuisance for the uninitiated, but if you want to give content authors a robust tool for publishing, there's not much else like it.
> easily modify content
If you have non-technical users editing a site, this one aspect takes precedence over everything else, and it's there that Wordpress continues to generally obliterate whatever workflow may qualify as "simple" to the average HN reader. If you've never used Wordpress' Gutenberg editor (or others based on the same model such as Medium or Squarespace), you should try it. The ability to not only change formatting but page structure and layout in a guided, template-driven way is simply not comparable to editing a Markdown file.
I'm pretty ambivalent on Wordpress' technical merits and its plugin ecosystem is a terrible attractive nuisance for the uninitiated, but if you want to give content authors a robust tool for publishing, there's not much else like it.
Pretty much this.
I as an experiment decided to use GitHub pages for my personal website and used some random simple looking theme that appeared on its face easy to manage. It wasn’t. The whole process is annoying, making changes to the site is annoying, adding content isn’t straightforward and if this is how all Jekyll sites are I don’t understand why anyone bothers with this sort of set up
I as an experiment decided to use GitHub pages for my personal website and used some random simple looking theme that appeared on its face easy to manage. It wasn’t. The whole process is annoying, making changes to the site is annoying, adding content isn’t straightforward and if this is how all Jekyll sites are I don’t understand why anyone bothers with this sort of set up
From an operations perspective, gatsby and next.js are much simpler though. You are just deploying static content behind a webserver or even something like s3. Horizontal scaling is almost trivial. With wordpress though, you have to worry about a database as well, scaling is more complicated, you need to run php on your webservers (which has security implications), updates that include schema updates frequently require downtime, etc.
You’re not wrong, but you’re missing the point.
The “operations” perspective is the least important perspective on any marketing site/blog.
Design flexibility in production, marketing features and multi-author content production are the only thing that matters.
Gatsby is built by developers, for developers. And it’s hilariously out of touch with the needs of anybody else.
We’re almost 10 years into the static site ecosystem and there’s still no easy way to do even 1/10th of what Wordpress can do without building everything from scratch and duct taping it together with a rigid headless CMS in the middle.
The “operations” perspective is the least important perspective on any marketing site/blog.
Design flexibility in production, marketing features and multi-author content production are the only thing that matters.
Gatsby is built by developers, for developers. And it’s hilariously out of touch with the needs of anybody else.
We’re almost 10 years into the static site ecosystem and there’s still no easy way to do even 1/10th of what Wordpress can do without building everything from scratch and duct taping it together with a rigid headless CMS in the middle.
> The “operations” perspective is the least important perspective on any marketing site/blog.
It definitely isn't for the marketing sites and blogs I maintain. Site stability and reliability trump how convenient it is for marketing content creators to release changes. Better to have a site that doesn't have the latest change than a site that is completely down, or worse a site hacked because of a vulnerability in the CMS. Is that true for every site? Absolutely not! Although it seems like it would be for whitehouse.gov.
It definitely isn't for the marketing sites and blogs I maintain. Site stability and reliability trump how convenient it is for marketing content creators to release changes. Better to have a site that doesn't have the latest change than a site that is completely down, or worse a site hacked because of a vulnerability in the CMS. Is that true for every site? Absolutely not! Although it seems like it would be for whitehouse.gov.
> Site stability and reliability trump how convenient it is for marketing content creators
You’re optimizing for the wrong thing then. Content creation, driving traffic to the site, and converting that traffic is the harder, more important task.
Your role is the easiest, most trivial one.
On the spectrum of engineering problems, I’d place self driving cars and sentient AI somewhere on the right side labeled difficult.
On the left side of the scale, at the far edge labeled easiest, I’d place “keeping a wordpress site online.”
40% of the internet is powered by Wordpress, so I think a few hundred million people have figured it out.
On the other hand, 99% of all websites get little to no traffic. Maybe this is the difficult part you should be optimizing for instead?
You’re optimizing for the wrong thing then. Content creation, driving traffic to the site, and converting that traffic is the harder, more important task.
Your role is the easiest, most trivial one.
On the spectrum of engineering problems, I’d place self driving cars and sentient AI somewhere on the right side labeled difficult.
On the left side of the scale, at the far edge labeled easiest, I’d place “keeping a wordpress site online.”
40% of the internet is powered by Wordpress, so I think a few hundred million people have figured it out.
On the other hand, 99% of all websites get little to no traffic. Maybe this is the difficult part you should be optimizing for instead?
> On the other hand, 99% of all websites get little to no traffic. Maybe this is the difficult part you should be optimizing for instead?
Well, the sites I'm talking about get enough traffic that if they are down for a few minutes people notice, and a single wordpress server isn't enough to handle the traffic ;). If you have little to no traffic that's less of an issue.
Well, the sites I'm talking about get enough traffic that if they are down for a few minutes people notice, and a single wordpress server isn't enough to handle the traffic ;). If you have little to no traffic that's less of an issue.
There are static site builders for Wordpress so you can use WP only as an admin tool and deploy a package to s3 or whatever. Build times are relatively trivial unless you have 10s of 1000s of pages.
Horizontal scaling for static content is just as trivial if not more trivial in WordPress with the plugins.
[Edit] downvotes are fine but let's open up discussion.
Further edit, WP has great static content manager plugins. It's not direct to S3 but a single server can handle a lot of traffic in that mode.
The part that becomes significantly easier is updating that content or adding new ones. You don't need devops to rebuild and redeploy.
[Edit] downvotes are fine but let's open up discussion.
Further edit, WP has great static content manager plugins. It's not direct to S3 but a single server can handle a lot of traffic in that mode.
The part that becomes significantly easier is updating that content or adding new ones. You don't need devops to rebuild and redeploy.
I think we are talking about different things. I'm not talking about static assets that you use in your site. I mean the entire site is static, and thus doesn't require any database or any server-side page generation. Which means not only that it is easier to scale since you don't even have any state in the database, but each node can also handle more traffic, because it is doing less. (And if you something like s3 or github pages, or netlify, you don't even need to worry about individual servers).
> The part that becomes significantly easier is updating that content or adding new ones. You don't need devops to rebuild and redeploy.
From my perspective as an SRE, that's actually a bad thing. I've seen content creators take down big parts of the site because they changed or deleted an asset. Most of the time that could have been caught by automated tests as part of a build pipeline, if one had been in place.
There is certainly a trade-off though. Wordpress and Drupal are great for quick turnaround content creation and editing. If you want your changes to be live as soon as you make them , Wordpress is better at that than a static site generator. On the other hand if you want rock-solid stability, and want any changes to go through a gamut of automated tests, Wordpress is not a good fit. It is possible, but it definitely isn't easy.
> The part that becomes significantly easier is updating that content or adding new ones. You don't need devops to rebuild and redeploy.
From my perspective as an SRE, that's actually a bad thing. I've seen content creators take down big parts of the site because they changed or deleted an asset. Most of the time that could have been caught by automated tests as part of a build pipeline, if one had been in place.
There is certainly a trade-off though. Wordpress and Drupal are great for quick turnaround content creation and editing. If you want your changes to be live as soon as you make them , Wordpress is better at that than a static site generator. On the other hand if you want rock-solid stability, and want any changes to go through a gamut of automated tests, Wordpress is not a good fit. It is possible, but it definitely isn't easy.
> I think we are talking about different things.
No, you aren’t. Wordpress has plugins to generate static html for all of the posts so visitors can be served without database hits.
No, you aren’t. Wordpress has plugins to generate static html for all of the posts so visitors can be served without database hits.
There are also webhosts that specialize exactly in this kind of feature, generating those static assets and hosting them for you.
This is why I generally recommend a solution like Publii (also Open Source) for simple sites that don't need extreme flexibility. It's “client friendly“ as WordPress, but generates static content in nature.
>you need to run php on your webservers
are you suggesting to run it remotely? on even a small site the performance impact would be noticeable. also, you'd then be securing two systems instead of one
are you suggesting to run it remotely? on even a small site the performance impact would be noticeable. also, you'd then be securing two systems instead of one
[deleted]
Wait, what non-trivial site doesn’t require a database?
All websites require a source for their data (i.e. a database), but many websites don't really need to be directly connected to a SQL database for nearly every page request or similar and can just use really simple files in S3 or something.
Many, many informational web sites do not require a database, including many non-trivial sites I've done for clients. Hugo is particularly adept for non-trivial static sites (via it's ability to use built-time API json data, etc).
Most corporate blogs with comments disabled would be fine as a filesystem, rather than a database.
JSON files in a git repo will get you really far if you want it to.
Is that because WordPress is simple, though? There are similar CMSes you can use with e.g. Gatsby. They’re just a glorified build systems, after all — there’s nothing inherently complex about the content management experience. And on the flip side, it’s possible to load up WordPress with enough plugins that it becomes a nightmare to use.
I think we see people choose WordPress because it’s familiar, popular, battle-tested and has a big community with a lot of plugins. It’s a good choice for a lot of people. But that doesn’t mean people picking other options are just taken in by the hype.
I think we see people choose WordPress because it’s familiar, popular, battle-tested and has a big community with a lot of plugins. It’s a good choice for a lot of people. But that doesn’t mean people picking other options are just taken in by the hype.
Yes because Wordpress includes frontend rendering (of both the actual pages and the backend admin) by default. This means you get working HTML powered by dynamic content out of the box, and it keeps working as content changes without needing constant builds for static sites.
I see the benefits of modern component-driven frontend systems but I think the better opportunity would be to integrate this cleanly into existing server-side engines rather than try to recreate the backend entirely or disassemble it down to such low-level build steps.
I see the benefits of modern component-driven frontend systems but I think the better opportunity would be to integrate this cleanly into existing server-side engines rather than try to recreate the backend entirely or disassemble it down to such low-level build steps.
Wordpress also has a really rich ecosystem of mature and widely used plugins that are quite easy to install.
The podcast ones for instance, they'll allow you to schedule the publishing of a new episode, then upload the episode to all the major platforms, format the images, titles and descriptions automatically for the different platforms, cross post to the social media accounts announcing the new episode, allow you to put in show notes for the blog, and embed a way to listen to the show on the site, all built in, for free, using an interface that is clean and well documented.
Of course I could do that myself but come on now, that simplifies my life so much.
I'm ok with my government saving money and not hiring six figure tech workers to custom roll effectively a press release website. Honestly, they could redirect it to a medium blog and save on the hosting fees as well. The real infrastructure is going to be at the departments, NASA, Smithsonian, CDC etc...
The podcast ones for instance, they'll allow you to schedule the publishing of a new episode, then upload the episode to all the major platforms, format the images, titles and descriptions automatically for the different platforms, cross post to the social media accounts announcing the new episode, allow you to put in show notes for the blog, and embed a way to listen to the show on the site, all built in, for free, using an interface that is clean and well documented.
Of course I could do that myself but come on now, that simplifies my life so much.
I'm ok with my government saving money and not hiring six figure tech workers to custom roll effectively a press release website. Honestly, they could redirect it to a medium blog and save on the hosting fees as well. The real infrastructure is going to be at the departments, NASA, Smithsonian, CDC etc...
Governments should moderately prefer self-hosted solutions to cloud services, especially when a president just got banned from all social media platforms.
The SolarWinds hack is another cautionary tale about not self-hosting.
Not really. What guarantee do you have that your cloud hosting provider wasn't also running SolarWinds services behind their firewalls.
"Self-hosting" in this case means running your own data center as well.
Great example. All of Trump's tweets are preserved at the National Archive, the department entrusted with doing that. https://www.newsweek.com/donald-trump-national-archive-tweet...
All of the concerns are handled by robust existing infrastructure. That's the point. That ultimately the website backend doesn't matter, our intuitive logic and apprehensions about this stuff simply doesn't apply
Let's take an extreme example, pretend they use GoDaddy as their registrar and someone falls for a phishing email hijacking the domain. The Whitehouse not only could probably seize it back with a single phone call but also get the right people on the phone to stop the DNS record propagation at the root servers as well.
It's kinda like how the police keep their cars running when they're parked and nowhere around. They don't have to worry the same way you and I do about someone smashing the window and driving off, the infrastructural support for their vehicle is vastly different.
Or how the president doesn't have to worry about when to leave for somewhere to beat traffic because the police literally clears the road the president is currently traveling on of all vehicles like Moses parting the sea. It's a completely different kind of logic
All of the concerns are handled by robust existing infrastructure. That's the point. That ultimately the website backend doesn't matter, our intuitive logic and apprehensions about this stuff simply doesn't apply
Let's take an extreme example, pretend they use GoDaddy as their registrar and someone falls for a phishing email hijacking the domain. The Whitehouse not only could probably seize it back with a single phone call but also get the right people on the phone to stop the DNS record propagation at the root servers as well.
It's kinda like how the police keep their cars running when they're parked and nowhere around. They don't have to worry the same way you and I do about someone smashing the window and driving off, the infrastructural support for their vehicle is vastly different.
Or how the president doesn't have to worry about when to leave for somewhere to beat traffic because the police literally clears the road the president is currently traveling on of all vehicles like Moses parting the sea. It's a completely different kind of logic
I excluded plugins because additive functionality and ecosystem are independent of the core product, but yes Wordpress (and server-side apps) can be extended to do much more than a plugin in a static build process.
Evaluating WordPress without its plugin ecosystem is like evaluating Linux or github or node.js without its developer ecosystem. Of course the bare platform will be worth a lot less without the social networking effect and the diverse applications it supports.
The comparison is the simplicity of Wordpress/server-based vs Gatsby/frontend frameworks to get a working site. The ecosystem is a separate concern.
> rich ecosystem of mature and widely used plugins
...which is a bit like Russian Roulette.
...which is a bit like Russian Roulette.
For the uninitiated, yes. This is no different from other CMSs that offers plugins from third-party developers.
Like next.js?
Wordpress makes sense if the goals are:
- Big upfront design
- Leverage existing plugins to minimize new development
- Use managed hosting
- Hand off to non-technical or semi-technical people and spin down development to just occasional contract work
If you actually have a FTE developer, it doesn’t fit as well at all. Among other problems, it does not work with a git centric development flow, which any modern dev will insist on.
- Big upfront design
- Leverage existing plugins to minimize new development
- Use managed hosting
- Hand off to non-technical or semi-technical people and spin down development to just occasional contract work
If you actually have a FTE developer, it doesn’t fit as well at all. Among other problems, it does not work with a git centric development flow, which any modern dev will insist on.
Eh, the efficiencies you describe happen regardless of whether the dev team is full-time or outsourced, and I think there are ways of doing git flows with WP.
> it does not work with a git centric development flow, which any modern dev will insist on.
Yes, it does. Just use Trellis and Bedrock.
Yes, it does. Just use Trellis and Bedrock.
I am not familiar with them, but a quick Google seems to suggest they won’t work with WPEngine, Wordpress.com, etc. In any event, they’re bolt on solutions, but the core of Wordpress is still a mess of configuration split between files on disk and the database. There is nothing so valuable about Wordpress that you couldn’t just get a more reliable solution from scratch than by bolting more stuff onto WP. I’ve heard people say “oh, our users are already trained on WP, so it’s a good CMS” but I don’t buy that at all. I’ve had users praise my homegrown CMSes before. There’s not much difficulty in pairing a WYSIWYG text editor and some form fields with modern web stacks these days.
> “oh, our users are already trained on WP, so it’s a good CMS” but I don’t buy that at all. I’ve had users praise my homegrown CMSes before. There’s not much difficulty in pairing a WYSIWYG text editor and some form fields with modern web stacks these days.
I don't think even the admin UI is well organised or consistent though. Most users just know how to create and edit posts. Once you start installing a few required plugins too, the UI becomes even more a mess of controls that users are scared to touch.
I don't think even the admin UI is well organised or consistent though. Most users just know how to create and edit posts. Once you start installing a few required plugins too, the UI becomes even more a mess of controls that users are scared to touch.
Gatsby isn't a CMS in the WP or Drupal sense of the word. Gatsby to me is more of an "integration first" minded architecture. That is, Gatsby is a way to unite multiple services, CMS's and content sources. But other than using .MD files Gatsby doesn't really have the ability to manage content in a true CMS sense. It's not like you log into some Gatsby admin panel and add content.
It’s true that Wordpress is very good at letting you modify content easily. That is, as you say, a major reason to use it.
However. That assumes you are only needing to edit text with basic formatting (bold, underline, etc...) As soon as you get into anything more complex you pretty much have to understand HTML and CSS.
I just ran into this with three different Wordpress installs. Two use Divi and the third uses WP Bakery. Those are really nice plugins and in 100% of the cases, the person using the site told me they don’t understand what’s going on and kept making a mess of something.
I’m guessing that for The Whitehouse site they will mostly be doing minimal content editing. Then again, they have the resources to have a person who understands HTML and CSS manage the site when things get tricky.
I’m not saying Wordpress is bad but it very quickly can become not as easy to use as most people make it out to be.
However. That assumes you are only needing to edit text with basic formatting (bold, underline, etc...) As soon as you get into anything more complex you pretty much have to understand HTML and CSS.
I just ran into this with three different Wordpress installs. Two use Divi and the third uses WP Bakery. Those are really nice plugins and in 100% of the cases, the person using the site told me they don’t understand what’s going on and kept making a mess of something.
I’m guessing that for The Whitehouse site they will mostly be doing minimal content editing. Then again, they have the resources to have a person who understands HTML and CSS manage the site when things get tricky.
I’m not saying Wordpress is bad but it very quickly can become not as easy to use as most people make it out to be.
This is why we built Gutenberg, which is the new editor in WP that allows you to do rich layouts without using Divi or Bakery. Gutenberg is what the new White House site uses! You can do really advanced things with it.
I built out a site using headless WP with Next.js as the frontend. With server side rendering of React, we still took advantage of caching the HTML in a CDN like you would with vanilla WP but it was much easier to build our own theme as desired with React.
While configuring certain parts of Wordpress was tricky at times, especially because deploying it is at odds with the stateless nature of modern containerized infra. Particularly plug-in installation with WP cli requirng a DB connection which makes it tough to fully configure your installation at container build time. I still think it struck a balance between developer experience and a good experience for the content team.
While configuring certain parts of Wordpress was tricky at times, especially because deploying it is at odds with the stateless nature of modern containerized infra. Particularly plug-in installation with WP cli requirng a DB connection which makes it tough to fully configure your installation at container build time. I still think it struck a balance between developer experience and a good experience for the content team.
Have you been using the preview feature of Next for this to allow for a fast feedback loop for content?
We didn't use it initially because the site was built before they launched that feature, but it definitely reduced some of the boilerplate that we had to write ourselves to wire up Next to WP.
We had already setup a preview page that was wired up to the Wordpress Admin's Preview button that used the endpoint provided by WP to preview content in our UI.
We had already setup a preview page that was wired up to the Wordpress Admin's Preview button that used the endpoint provided by WP to preview content in our UI.
Is there a CMS that has a Wordpress-like admin panel and content editing tools that builds and deploys the needed updates to a static site when you save an article, etc.?
Yes, there are lots now! There are some good ones, but some are definitely way pricier than I think they should be. With Next.js, you can even use Wordpress as a cms to back a static blog (https://github.com/vercel/next.js/tree/canary/examples/cms-w...)
Just a few off the top of my head:
- https://graphcms.com - https://prismic.io - https://www.sanity.io - https://www.datocms.com/ - https://www.cosmicjs.com/
More at the top of this Next.js docs page:
https://nextjs.org/docs/basic-features/data-fetching#simple-...
I've spent quite a bit of time playing with Nextjs, so if you have more specific questions feel free to let me know.
Just a few off the top of my head:
- https://graphcms.com - https://prismic.io - https://www.sanity.io - https://www.datocms.com/ - https://www.cosmicjs.com/
More at the top of this Next.js docs page:
https://nextjs.org/docs/basic-features/data-fetching#simple-...
I've spent quite a bit of time playing with Nextjs, so if you have more specific questions feel free to let me know.
Most static site generators can use WordPress as a data source, and rebuild via a webhook.
This looks like Publii: https://getpublii.com/ Much more client-oriented than Getsby, Jeckyl or Hugo.
But Dev's are the people who had issues with WP. WP has been given this awful image but when you can buy a fully functional LMS system for $69 with 6 months support, you just can't beat the value.
Want to ensure people don't laugh at your WP site - use Hide My WP. You block most common intrusion attacks such as PHP injections, you see where the attempts are being made and the site works. Need to convert the whole thing to a PWA? There's a plugin for that which will do in in minutes and cost $30.
It's like the beer/wine connoisseurs who insist that the 'common' option is just not good enough for them. But $9 wine or $100 - most end users don't know the difference.
Want to ensure people don't laugh at your WP site - use Hide My WP. You block most common intrusion attacks such as PHP injections, you see where the attempts are being made and the site works. Need to convert the whole thing to a PWA? There's a plugin for that which will do in in minutes and cost $30.
It's like the beer/wine connoisseurs who insist that the 'common' option is just not good enough for them. But $9 wine or $100 - most end users don't know the difference.
I have been thinking about what solution is for this. Do you think users would be happy with a WordPress backed headless app?
The other issue is that visual content editing in WordPress is pretty tricky. Site owners want cool modern design, but editable in the WordPress admin, and meeting them in the middle has proven difficult using Gutenberg. They often find the new UI brittle and difficult to work with, even for core WP blocks. The developer experience is also pretty cumbersome.
If anyone has found an idiomatic approach that works, I'd love to hear it!
The other issue is that visual content editing in WordPress is pretty tricky. Site owners want cool modern design, but editable in the WordPress admin, and meeting them in the middle has proven difficult using Gutenberg. They often find the new UI brittle and difficult to work with, even for core WP blocks. The developer experience is also pretty cumbersome.
If anyone has found an idiomatic approach that works, I'd love to hear it!
> They often find the new UI brittle and difficult to work with, even for core WP blocks.
There's a new (official) UI system in the works that aims to solve usability issues in WordPress components.
https://g2-components.com/
There's a new (official) UI system in the works that aims to solve usability issues in WordPress components.
https://g2-components.com/
> different content/marketing teams, they hate it so much
A refreshing change from them making everyone else's life hell then? :)
A refreshing change from them making everyone else's life hell then? :)
Nothing is stopping you from setting up a site in Hugo or something similar. I don't really understand why dynamic rendering or a huge amount of JS is required other than continue down the road of bloat.
They can just static dump a site, bar search, and most issues vanish.
A pretty standard stack I've done recently is Netlify, Gatsby (I'd lean next at this point) with Prismic, Hubspot and GTM. It's barely more investment to setup than WordPress but lets you build something visually sophisticated really easily and you get user friendly CMS, CRM and all the analytics and user engagement stuff. And running headless means there's almost zero attack surface.
Which CMS were you using though? Netlify CMS? Last I looked at it, there was a lot to be desired (not to belittle their effort, but not even close to WP in terms of functionality).
Worth mentioning you can also run WP headless and build your front end in w/e js framework du jour you prefer.
Worth mentioning you can also run WP headless and build your front end in w/e js framework du jour you prefer.
They mentioned Prismic, so I assume they are using that as CMS
The very point of OP is that this micro-service approach is bound to provide a poorer user experience for non-technical users - the vast majority will reason about and operate a monolithic CMS with much more ease.
Poorer author experience maybe. The end user experience will likely be better. And the business results of using a proper CRM and audience engagement product will be far superior.
Have you ever tried to customize or add functionality to Wordpress? Because if it’s anything like Drupal or other PHP based tech of a certain era, it’s hell
Yes, a few months ago, it was ridiculously easy. It literally took me 20 minutes to customize how the side bar was working and embed some new dynamic content. I even inherited off a parent theme so any updates to the theme wouldn't over-ride my changes.
I've never even written much PHP in the past. I even added it into the the theme editor so the client could change the text/etc. themselves.
Not sure what you did, but you clearly did it wrong if you think it's hard. It just worked.
I've never even written much PHP in the past. I even added it into the the theme editor so the client could change the text/etc. themselves.
Not sure what you did, but you clearly did it wrong if you think it's hard. It just worked.
That's one problem with Wordpress' default renders; it sends developers down those relatively narrow paths of customizing existing output. It's easy if requirements are flexible enough to allow that, but not the right CMS for truly customized content architecture and presentation.
> truly customized content architecture and presentation
Can you give an example of something like that which is not possible with WordPress?
Can you give an example of something like that which is not possible with WordPress?
Customized presentation is possible by starting with a blank template. Most do not do that, so if they want to customize, they spend time modifying and working around the default views. This has an effect of constraining the look. The difficulty emulating controller-like behavior means that adding multiple pieces of content to a view takes extra work.
As for the content architecture, Wordpress cpt are limited in their ability to relate to others and to define flexible custom fields (even with ACF.) It’s possible to hack together something like what a more flexible CMS or application framework can do, but it’s fragile and takes a lot of boilerplate, which, similar to template customization, steers the developer towards a similar architecture to other sites.
For these reasons, increased development and maintenance cost make it unlikely that an attempt to develop something truly customized on Wordpress will be successful. That said, many only know Wordpress development so may still get further with it than with a closer fit to their project.
As for the content architecture, Wordpress cpt are limited in their ability to relate to others and to define flexible custom fields (even with ACF.) It’s possible to hack together something like what a more flexible CMS or application framework can do, but it’s fragile and takes a lot of boilerplate, which, similar to template customization, steers the developer towards a similar architecture to other sites.
For these reasons, increased development and maintenance cost make it unlikely that an attempt to develop something truly customized on Wordpress will be successful. That said, many only know Wordpress development so may still get further with it than with a closer fit to their project.
It is hell, but there are also millions of contractors that still sit in that webmaster space between designer and developer who will do it cheaply.
add_shortcode is incredible. It's probably my favorite part of wordpress, and writing a plugin is so easy, just a single file zipped up or scp'd. Especially with custom post types or adding a new table.
> just a single file zipped up or scp'd
And now your page displays a white page. Error in the log is an exception with no stacktrace/location. This was my experience in production a few times.
It's a fun system if it works, but without a testing pipeline and a staging environment it's a lottery with a possible mystery breakage on every update/change.
And now your page displays a white page. Error in the log is an exception with no stacktrace/location. This was my experience in production a few times.
It's a fun system if it works, but without a testing pipeline and a staging environment it's a lottery with a possible mystery breakage on every update/change.
> It's a fun system if it works, but without a testing pipeline and a staging environment it's a lottery with a possible mystery breakage on every update/change.
That describes every platform, programming language, layer of the stack, etc. that I've ever worked with.
That describes every platform, programming language, layer of the stack, etc. that I've ever worked with.
There's a whole possible scale of responses and of encouraged workflow though.
Wordpress and a lot of php community does actually like the "drop in some code and it usually works" approach. This encourages continuing on that path.
On the other side, the failure can be handled in many ways. "This module could not be loaded and will be ignored." is one. Ensuring some preparation / validation is needed before upload is another.
Let's not go to extremes like "you're expected to have a staging environment for your personal blog because the framework cannot possibly help you".
Wordpress and a lot of php community does actually like the "drop in some code and it usually works" approach. This encourages continuing on that path.
On the other side, the failure can be handled in many ways. "This module could not be loaded and will be ignored." is one. Ensuring some preparation / validation is needed before upload is another.
Let's not go to extremes like "you're expected to have a staging environment for your personal blog because the framework cannot possibly help you".
At the end. All of our tooling sucks. Although I have to say generally the apache error log guides me to the right place.
If your log only shows an exception without any kind of stack trace or location, I’m sorry but Wordpress is not the problem.
drupal is much better, IMO, and assuming you actually know how the framework is designed. Wordpress has the 'loop' you hook into and everything happens in it. Drupal has more of a pub/sub model with hooks which seemed much easier to build standalone plugins. At the end of the day I'd say the most important part is understanding how they are built and where you are supposed to spend your time as a dev to make your users happy.
Add feature to WP should be easier than Drupal. In WP, you only write pure PHP. (Lack of APIs for common elements) But in Drupal, mostly you have to interact with Drupal APIs.
I was curious after seeing the accessibility statement what the previous administration's had.
https://www.whitehouse.gov/accessibility/
https://obamawhitehouse.archives.gov/accessibility
https://georgewbush-whitehouse.archives.gov/accessibility.ht...
https://trumpwhitehouse.archives.gov/accessibility
With that last one not being surprising at all.
https://www.whitehouse.gov/accessibility/
https://obamawhitehouse.archives.gov/accessibility
https://georgewbush-whitehouse.archives.gov/accessibility.ht...
https://trumpwhitehouse.archives.gov/accessibility
With that last one not being surprising at all.
I was surprised that the accessibility widget on the current website has a feature called “high contrast mode” that does not significantly increase the contrast ratio between the primary text and the background. It also significantly lowers the contrast between the secondary text and the background, sometimes as low as 2.1 (7 is the recommended minimum).
Given the icon they chose, it seems like “dark mode” would be a more appropriate name.
Given the icon they chose, it seems like “dark mode” would be a more appropriate name.
Accessibility compliance widgets are such a shot to the nads for accessibility. Sites drop in an accessibility plugin and never think about accessibility again. You need a real audit, and an accessibility first mindset to build a genuinely accessible website.
A data point to support your claim: The main body text becomes white on dark grey with a contrast ratio of 14.22, compared to the original dark blue text on white background with a contrast ratio of 14.93.
Yup. And the red error text that displays on text input forms has a contrast ratio of just over 2. It seems like they just forgot that this error text needs to be a different color when the background color is dark.
"Large font size" doesn't make the actual body text any larger. Is there some interaction with settings encountered with low vision users that makes that make sense?
What is the point of this page besides signaling? It seems completely useless from an informational standpoint.
All of those pages I looked at cite specific things they intend to support (alt tags, text resize) and give a way to reach them. If something stops working, which is incredibly common over a 4-8 year span, a user knows they should be working and have a way to reach out.
Ideally, appropriate accessibility features would just be expected. I'm not intimately familiar with web accessibility, but webaccessibility.com (a random site I found) ranked the landing page for the last three administrations in the mid-to-high 80s.
Ideally, appropriate accessibility features would just be expected. I'm not intimately familiar with web accessibility, but webaccessibility.com (a random site I found) ranked the landing page for the last three administrations in the mid-to-high 80s.
Ah but to a certain audience that’s all that matters. Follow through and actions are meaningless, it’s what someone appears to say that matters.
[deleted]
In this age where the trend is JAM stack, it is refreshing to see that something battle-tested like WordPress was chosen.
There's a reason WP has withstood the test of time. (WordPress developers being a dime a dozen also help make the case)
There's a reason WP has withstood the test of time. (WordPress developers being a dime a dozen also help make the case)
JAM stack (this term is trademarked by Netlify, FYI) is such an awful trend for anyone but developers. The web runs on WordPress because it's SO easy for anyone to stand up a quality, functional website. I drop in on a local WordPress event a few times a year and many of the people there are 60+ and very much non technical but have put together great sites that benefit humanity.
it's SO easy for anyone to stand up a quality, functional website
And its also really easy for it to be left without updates or security patches, with an insecure admin account password, and with a set of plugins that open up more security problems.
It might be a bit harder to get up and running with a static site generator but the fact that it's essentially unhackable (through the site itself; the host server has the same issues as any website) is a massive advantage.
And its also really easy for it to be left without updates or security patches, with an insecure admin account password, and with a set of plugins that open up more security problems.
It might be a bit harder to get up and running with a static site generator but the fact that it's essentially unhackable (through the site itself; the host server has the same issues as any website) is a massive advantage.
WordPress has automatic updates, and you actually have to enter a hard to guess password when creating an account.
The plugin issue is not specific to WordPress.
The plugin issue is not specific to WordPress.
The plugin issue is not specific to WordPress.
The fact that other platforms and applications are insecure isn't relevant; we're comparing static sites to WordPress.
However, to answer the point, static sites are significantly more secure than every single dynamic platform that supports a plugin architecture because plugins can be, and often are, written without security in mind.
Unless you really need a dynamic website you should be deploying static assets to the enduser. Practically every business website would be better off being delivered as a static site, even if the admin still use WordPress to edit the content.
The fact that other platforms and applications are insecure isn't relevant; we're comparing static sites to WordPress.
However, to answer the point, static sites are significantly more secure than every single dynamic platform that supports a plugin architecture because plugins can be, and often are, written without security in mind.
Unless you really need a dynamic website you should be deploying static assets to the enduser. Practically every business website would be better off being delivered as a static site, even if the admin still use WordPress to edit the content.
I agree that WordPress security is a huge issue, the biggest potential problem is that not when a random website goes down but when someone finds a mass-exploit and then gets access to millions of websites.
> It might be a bit harder to get up and running with a static site generator but the fact that it's essentially unhackable
You could also use WordPress to generate a static site, just add a caching level on top.
> It might be a bit harder to get up and running with a static site generator but the fact that it's essentially unhackable
You could also use WordPress to generate a static site, just add a caching level on top.
> JAM stack (this term is trademarked by Netlify, FYI) is such an awful trend for anyone but developers
JAMstack sites are annoying to build, so much minutiae and configuration, abstractions on top of abstractions, and you never own the codebase as it's frameworks and libraries all the way down. You spend half your time trying to figure out if X could work with Y, rather than just making X do Y's job by writing some actual code for a change.
JAMstack sites are annoying to build, so much minutiae and configuration, abstractions on top of abstractions, and you never own the codebase as it's frameworks and libraries all the way down. You spend half your time trying to figure out if X could work with Y, rather than just making X do Y's job by writing some actual code for a change.
> you never own the codebase as it's frameworks and libraries all the way down.
Frameworks and libraries aren't really necessary for JAMstack. JAMstack really just means relying on external services for dynamic content. You don't have to use Gatsby or Hugo or whatever. A JAMstack site can be a single HTML page with a script tag (and all mine usually are).
I built my own static site generator and I feel so much more ownership over the code. You should try it. Not only is it my code all the way down, but it only runs on my machine. All the generated assets will remain functional and security bug free as long as browsers understand HTML, CSS and JS, even if I never update the code again.
Frameworks and libraries aren't really necessary for JAMstack. JAMstack really just means relying on external services for dynamic content. You don't have to use Gatsby or Hugo or whatever. A JAMstack site can be a single HTML page with a script tag (and all mine usually are).
I built my own static site generator and I feel so much more ownership over the code. You should try it. Not only is it my code all the way down, but it only runs on my machine. All the generated assets will remain functional and security bug free as long as browsers understand HTML, CSS and JS, even if I never update the code again.
TIL they have a trademark application pending https://uspto.report/TM/88746545
what is the implication of such a trademark? can unaffiliated companies not use the term now? this is a little surprising.
what is the implication of such a trademark? can unaffiliated companies not use the term now? this is a little surprising.
That reason might be familiarity. Or inertia. Or breadth of available resources to work with it, as you mentioned.
Or all of the above. And that might be a good enough reason, but to imply it's the best technical option warrants some skepticism.
Or all of the above. And that might be a good enough reason, but to imply it's the best technical option warrants some skepticism.
I'm not asking this to be snarky, but by what metric would you decide something was the best technical option?
There's no single metric, but in particular I believe that inherent inefficiency with WordPress design will incur more cost to scale, as an example.
Not to mention things little security issues.
I don't have an agenda against WordPress and very often when people ask me what they should use for simple projects I say "just use WordPress."
My rule of thumb is that will probably be alright for a simple, small project, but will have to grow up to something else to scale reasonably.
Not to mention things little security issues.
I don't have an agenda against WordPress and very often when people ask me what they should use for simple projects I say "just use WordPress."
My rule of thumb is that will probably be alright for a simple, small project, but will have to grow up to something else to scale reasonably.
> but in particular I believe that inherent inefficiency with WordPress design will incur more cost to scale
WordPress essentially generates static pages and is trivially set-up to run behind a CDN like Cloudflare.
You can easily have WordPress sites in the Alexa top 50k that run on a $5 VPS - behind Cloudflare.
> My rule of thumb is that will probably be alright for a simple, small project,
Right. Simple, small projects. Like whitehouse.gov.
As long as you use Wordpress for what it was designed for, it really doesn't matter what scale you have.
WordPress essentially generates static pages and is trivially set-up to run behind a CDN like Cloudflare.
You can easily have WordPress sites in the Alexa top 50k that run on a $5 VPS - behind Cloudflare.
> My rule of thumb is that will probably be alright for a simple, small project,
Right. Simple, small projects. Like whitehouse.gov.
As long as you use Wordpress for what it was designed for, it really doesn't matter what scale you have.
> inherent inefficiency with WordPress design will incur more cost to scale
Check out Cloudflare's Automatic Platform Optimization tool from last year [0]. It uses Workers to cache static and dynamic content from WordPress on the edge. Just $5/month.
IMHO, that would "scale reasonably" for many use cases.
[0] https://blog.cloudflare.com/automatic-platform-optimizations...
Check out Cloudflare's Automatic Platform Optimization tool from last year [0]. It uses Workers to cache static and dynamic content from WordPress on the edge. Just $5/month.
IMHO, that would "scale reasonably" for many use cases.
[0] https://blog.cloudflare.com/automatic-platform-optimizations...
CDN literally everything is - to me - a last resort you can use when your underlying application cannot handle any direct traffic.
It's an expensive compromise that you shouldn't need unless you're in Alexa top 100 territory.
It's an expensive compromise that you shouldn't need unless you're in Alexa top 100 territory.
That's a perfectly fair attitude. I was just trying to show that it's not very expensive to scale WordPress. :)
Why does it have to scale? Doesn’t a CDN solve most scaling issues for a content site.
[deleted]
[deleted]
Are we at the point that creating and editing a page in a JAM stack site is as easy as WordPress for non-technical users?
Not a snarky or leading question, I honestly don’t know. I use Hugo for my own internal design things, because I want partials and such, but I have no idea where the ecosystem is at for the “we need a poli-sci intern to copyedit this” use case.
Not a snarky or leading question, I honestly don’t know. I use Hugo for my own internal design things, because I want partials and such, but I have no idea where the ecosystem is at for the “we need a poli-sci intern to copyedit this” use case.
Maybe, for basic use cases. I use Forestry as a CMS for my Jekyll site. I only have two templates: page and blog post.
Does a user need to create a page entire?
Used be that we had writers, editors, type setters, printers and book-binders, and I think the output was more professional.
I think there’s still a case for the non-technical users just writing the words, and keeping away from the presentation and delivery.
Used be that we had writers, editors, type setters, printers and book-binders, and I think the output was more professional.
I think there’s still a case for the non-technical users just writing the words, and keeping away from the presentation and delivery.
There are already solutions for this, like Stackbit and Publii.
JAM stack ? The first letter I guess is Javascript?
“JavaScript, APIs, Markup”
For a second I thought you're being sarcastic until I looked it up.
Next thing we know, the kids these days will invent some mindblowing new concept like "HappyText Makestuff Language" aka HTML that actually allows you to link to other documents!
I think if WP ever finds a way to do two things:
- continuously serialize WP to static files
- Make it easier to work with Wordpress as a CRM (No Code or at the very least don't force developers to touch PHP)
JAM stack would near instantly cease to make any business sense (though developers would still love using it of course).
A lot of the issues with Wordpress are sort of long-tail -- combinations of plugins exposing leaks in the abstractions, etc.
BTW, if anyone is working on solving this, I'd love to know about it.
- continuously serialize WP to static files
- Make it easier to work with Wordpress as a CRM (No Code or at the very least don't force developers to touch PHP)
JAM stack would near instantly cease to make any business sense (though developers would still love using it of course).
A lot of the issues with Wordpress are sort of long-tail -- combinations of plugins exposing leaks in the abstractions, etc.
BTW, if anyone is working on solving this, I'd love to know about it.
> continuously serialize WP to static files
Any cache plugin for WordPress does this already, but if you mean something that does this in order to host elsewhere (like in Netlify), WP2Static is a solution.
Any cache plugin for WordPress does this already, but if you mean something that does this in order to host elsewhere (like in Netlify), WP2Static is a solution.
Ah thank you -- WP2Static is something I didn't know about.
Do some cache plugins actively walk your site and generate the pages? How do they handle when user login plugins are present? I'd expect a naive/basic caching plugin to add to the cache when a page was visited, not necessarily ahead of time.
Do some cache plugins actively walk your site and generate the pages? How do they handle when user login plugins are present? I'd expect a naive/basic caching plugin to add to the cache when a page was visited, not necessarily ahead of time.
This depends on the plugin or cache system being used, but it can be done ahead of time, yes. Generally, the cache is created on the first visit and purged when a change occurs. Highly dynamic pages can be excluded from the cache by default, like the login or the cart page on an E-commerce website. Some solutions even allow to change the caching period for specific parts of the code, on the fly (fragment caching).
Or you can just roll with JAMstack as it's literally about what you're asking for.
The problem I'm saying exists with JAM stack is that it's great for developers but bad for non-technical people -- wordpress is the opposite, and if I could get JAM stack properties out of Wordpress, I wouldn't use JAM stack for any projects which involved having non-technical people modify the site (which is a lot of them).
You could check out Strattic which gives users the best of both worlds - edit your site as usual in WordPress, and click a button to deploy a static, Jamstack version of the site. All the power of WordPress with none of the headache. https://www.strattic.com
It's Jamstack and it's more than just a trend.
[deleted]
Looking through the FAQ on the USDS website that is linked in the source, it seems a lot less bureaucratic than I would've ever anticipated. No job descriptions, no dress code. It seems more like a startup than I would've expected from a government org.
https://www.usds.gov/faq
https://www.usds.gov/faq
We're trying. There's still a lot of bureaucracy around USDS (which we work with to make things happen), but the org itself aims to be an excellent working environment. Happy to answer questions.
They're trying to hire people for a role where the industry custom is to dress less formally. It's possible they loosened up the rules after dumping the mega-IT project contractors behind the first healthcare.gov site and going with smaller, decentralized teams for the rebuild.
I also host a Wordpress site for some non-technical people that are part of the legal community.
I chose it because they just need to publish basic info, much like most govt places, and all the non-tech people find it easy to add content.
It's been up and running for 8 years using the same webhost. Easy to keep up to date, and easy to use, and it solves their business problem.
Nothing wrong with WP when you just want to post simple information.
I chose it because they just need to publish basic info, much like most govt places, and all the non-tech people find it easy to add content.
It's been up and running for 8 years using the same webhost. Easy to keep up to date, and easy to use, and it solves their business problem.
Nothing wrong with WP when you just want to post simple information.
My go-to for creating a static website to be managed by non-tech people is Svelte + some markdown renderer. I put all the info into Markdown files so it can be easily changed, kind of like Jekyll.
You’re getting downvoted because this would only be suitable for the most simple of blogs/sites that rarely need updating. And I’m sorry, giving non-technical people a code editor and telling them to write markdown & front matter and deal with git is just hilarious.
It’s the typical “developer’s developer” solution. Fun for the dev to set up and write an article about how they built it on Dev.to, but with zero thought put towards the marketing functionality or flexible content production that any end user will need.
Developers don’t understand that their role in the process of creating a marketing site is the least important one. The marketing functionality (advanced SEO, newsletter sign up, form collection, landing page generation, dynamic header banners etc) and multi-author content production is all that matters. Otherwise nobody will ever be visiting the site.
Content is king. Not “developer pleasure is King.” Hence why Wordpress runs most of the internet.
It’s the typical “developer’s developer” solution. Fun for the dev to set up and write an article about how they built it on Dev.to, but with zero thought put towards the marketing functionality or flexible content production that any end user will need.
Developers don’t understand that their role in the process of creating a marketing site is the least important one. The marketing functionality (advanced SEO, newsletter sign up, form collection, landing page generation, dynamic header banners etc) and multi-author content production is all that matters. Otherwise nobody will ever be visiting the site.
Content is king. Not “developer pleasure is King.” Hence why Wordpress runs most of the internet.
I don't get why you get downvoted. I'm doing the same thing with a simple react app that displays markdown, it's working great.
More and more non-tech people are happy to be introduced to github. It's just an 'article' dir where you upload your markdown file, then click on 3 green buttons to create a PR.
They're happy to discover the integrated discussion system, issues, kanban, etc.
Of course, tailor it to your audience. Some people cannot read English and will be frightened by the interface.
More and more non-tech people are happy to be introduced to github. It's just an 'article' dir where you upload your markdown file, then click on 3 green buttons to create a PR.
They're happy to discover the integrated discussion system, issues, kanban, etc.
Of course, tailor it to your audience. Some people cannot read English and will be frightened by the interface.
> Political affiliations aside, I think we can all breathe a bit easier today knowing they didn’t choose Drupal.
Strongly disagree. Drupal is a great CMS and there's a reason the government uses it so extensively.
Strongly disagree. Drupal is a great CMS and there's a reason the government uses it so extensively.
I was a Drupal dev for ~10 years. Once upon a time, I built many sites with it, and I recommended it to many folks. Despite its flaws (and it always had flaws), it was a great piece of software in its heyday, and it had (and still has?) an amazing community.
I'd still choose it over WordPress any day. But the days when I'd recommend either of them (or indeed anything in PHP) are long gone. Your best bet now is probably a static site generator such as Hugo. If you insist on staying in database-driven CMS land, at least go with Django or Rails.
I'd still choose it over WordPress any day. But the days when I'd recommend either of them (or indeed anything in PHP) are long gone. Your best bet now is probably a static site generator such as Hugo. If you insist on staying in database-driven CMS land, at least go with Django or Rails.
Does no one else ever have users want to setup content to go live at specific dates and times?
Static site generators are great for truly static content but that's extremely rare anywhere where content is frequently edited.
Static site generators are great for truly static content but that's extremely rare anywhere where content is frequently edited.
Hugo metadata allows to define a publication date for content. Then you need to run the Hugo build periodically to have the content published.
The hugo cli has options to build "drafts" and "futures" so that you can preview them.
I have used Hugo in the past to generate websites from external content sources, such as trello, gitlab, GitHub, RSS feeds, Dropbox, headless CMSes, etc. Some of them provided webhooks to trigger the build, others required polling and periodic rebuild, yet others can commit to a git repo and trigger a CI pipeline. Most of the time, hugo was more of a composable solution to a given flow than a constraint i had to build around thanks to its capabilities to use "data content" and not only markdown files. Using json as the metadata "front matter" for documents often proved very handy when using API sources.
Hugo is very fast, so build time wasn’t a big concern. There was no incremental build however, so for a very large corpus it could be an issue. The most problematic issue is that Hugo doesn’t ever delete anything from a previous build, but overwrites on top, so that could be problematic if you involuntarily publish something and then want it off. The same kind of issues you get into with caching or object storage. My "solution" was the classic parallel builds, symlink and cleanup dance.
Would recommend.
I have used Hugo in the past to generate websites from external content sources, such as trello, gitlab, GitHub, RSS feeds, Dropbox, headless CMSes, etc. Some of them provided webhooks to trigger the build, others required polling and periodic rebuild, yet others can commit to a git repo and trigger a CI pipeline. Most of the time, hugo was more of a composable solution to a given flow than a constraint i had to build around thanks to its capabilities to use "data content" and not only markdown files. Using json as the metadata "front matter" for documents often proved very handy when using API sources.
Hugo is very fast, so build time wasn’t a big concern. There was no incremental build however, so for a very large corpus it could be an issue. The most problematic issue is that Hugo doesn’t ever delete anything from a previous build, but overwrites on top, so that could be problematic if you involuntarily publish something and then want it off. The same kind of issues you get into with caching or object storage. My "solution" was the classic parallel builds, symlink and cleanup dance.
Would recommend.
Just wanted to add that I use Hugo in combination with a super simple CI/CD pipeline, and I just rsync the public/ directory every time the pipeline runs with the delete option enabled. This makes it relatively trivial to delete content after the fact, because I can just delete the content from the repository and have the pipeline remove it.
IMO this is the single most relevant issue with static generators. Hopefully it will be adressed soon.
You just use a headless cms that have post scheduling. Like Prismic for example.
There is nothing wrong with Wordpress and the LAMP stack. It’s fine for many great use cases. It powers, and will continue to power many of the biggest sites in the world.
Static sites are a tradeoff, and you’re often dealing with other messes especially with non-technical users.
Static sites are a tradeoff, and you’re often dealing with other messes especially with non-technical users.
The problem isn't LAMP, the problem is wordpress. It stores state that should be in files in the database, and state that should be in the database in files, so they are tightly coupled, and you have to snapshot both at the same time.
It's also a security nightmare and runs dynamic code on every page load by default, so a fresh wordpress install in its default state will fall over when on HN on Reddit or Slashdot, unless you install third party caching plugins to avoid that.
It's a bad app.
It's also a security nightmare and runs dynamic code on every page load by default, so a fresh wordpress install in its default state will fall over when on HN on Reddit or Slashdot, unless you install third party caching plugins to avoid that.
It's a bad app.
It's clearly not “bad” for a lot of people, as it powers a huge portion of websites, everywhere.
The vast majority of those people contract out the (complicated) maintenance in keeping it secure and performant, or they get hacked and their site goes down, or they get ~no traffic so performance doesn't matter and neither does their choice of blog software.
Entire large businesses (WPEngine, for example) have been built upon the overhead costs from blog operators having to compensate for it being a bad app.
My close friend is one of the sysadmins for the WP instance mentioned in TFA. Pull back the curtain and it's pretty ugly and resource-intensive to run WP at scale; I've done it myself.
Entire large businesses (WPEngine, for example) have been built upon the overhead costs from blog operators having to compensate for it being a bad app.
My close friend is one of the sysadmins for the WP instance mentioned in TFA. Pull back the curtain and it's pretty ugly and resource-intensive to run WP at scale; I've done it myself.
The only problem not addressed is that the browser directly interfaces with code that has access to the database and host computer. A static site generator is leagues more secure since you can lock anything that touches the database/CMS content behind multiple layers of authentication and 2fa, significantly reducing the attack surface.
Come off it. Much as I prefer Ruby and Python the CMS domain is dominated by PHP and ASP.Net. Whilst there are Rails and Django-based CMSes their combined adoption is a drop in the ocean compared with Drupal alone, never mind Wordpress.
Agreed. I love Drupal, and hate WordPress. It seems like Drupal module developers are more interested in solving trivial problems so they can focus on the bigger ones, while WordPress plugin developers are more interested in making a buck with a trivial solution.
The problem is finding people who actually know how to use it. It's great, but it takes years to learn properly. Before that it can be frustrating as hell.
It seems easy enough at first, like you can just use whatever contributed modules you need, but that only works on simple sites (like the same ones Wordpress is great for). To use Drupal well, you have to actually know the APIs and write your own custom modules, otherwise the site becomes a buggy resource hog.
I like Drupal, I have multiple 8/9 sites I still run and I've used it since 6, but there's some pretty good reasons not to use it.
It seems easy enough at first, like you can just use whatever contributed modules you need, but that only works on simple sites (like the same ones Wordpress is great for). To use Drupal well, you have to actually know the APIs and write your own custom modules, otherwise the site becomes a buggy resource hog.
I like Drupal, I have multiple 8/9 sites I still run and I've used it since 6, but there's some pretty good reasons not to use it.
I haven't used Drupal since Drupal 7, but I really liked the Fields API. Drupal felt like it had more built in that WP should have built in but didn't. I believe Drupal 8 went with a templating language as well. That's something else I wish WordPress would adopt.
Drupal uses twig for templating now.
I think that statement should be considered in the context that it's a blog from a company that specialises in and promotes Wordpress hosting.
I'm pretty sure the Obama administration used Drupal 6. Current Drupal is rather a different beast
Drupal 6 was kind of a mess technically, but it had the best ecosystem of contributed modules.
Drupal 7 lost some modules, and Drupal 8+ lost a lot more.
Drupal 7 lost some modules, and Drupal 8+ lost a lot more.
The Obama-era whitehouse.gov was Drupal 7.
What is the reason
I got the responsibility for a wordpress page and been told that they had some issues with the page not being available several times already.
After looking at the FTP, I've found out that the hoster locked down the page due to wordpress plugins which did not have been updated and turned into malware providers or something like that.
The whole thing is a monster. It has almost 30 plugins for the most stupid thing (like scrolling text). So the first thing I did was updating it. Unfortunately it looked messed up afterwards. So I rolled back the backup and started updating it one by one. I was left with one plugin which I could not remove or it would break down parts of the design. So I'm again left with an possible problem for the future.
The joke is: the page is mostly static. There is one single news section which has not been used for more than a year...I hate this thing...I wish I could give it to somebody to rebuild in plain HTML or something but the boss doesn't want it...
After looking at the FTP, I've found out that the hoster locked down the page due to wordpress plugins which did not have been updated and turned into malware providers or something like that.
The whole thing is a monster. It has almost 30 plugins for the most stupid thing (like scrolling text). So the first thing I did was updating it. Unfortunately it looked messed up afterwards. So I rolled back the backup and started updating it one by one. I was left with one plugin which I could not remove or it would break down parts of the design. So I'm again left with an possible problem for the future.
The joke is: the page is mostly static. There is one single news section which has not been used for more than a year...I hate this thing...I wish I could give it to somebody to rebuild in plain HTML or something but the boss doesn't want it...
WordPress is definitely the Jenkins of the CMS world. Easy for a desktop user to set up, absolutely trash for literally every best practice, but nobody's made anything better [for free] yet.
If you are trying to deploy WordPress today with DevOps best practices (version control/12 factor app/etc): set it up with Bedrock (https://roots.io/bedrock/), manage dependencies with Composer, and use environment variables for the runtime configuration. Then use Phinx (https://phinx.org/) to do database migrations. A custom db migration script will be needed to change database settings based on the environment you're deploying to.
Containerization is pretty annoying, because apparently php-fpm will not serve non-PHP content (without creating security concerns). So you need a web server to serve all the static content that comes with Wordpress/Plugins/etc, and php-fpm to serve the PHP. This means you have to either 1) duplicate the static content between two different containers, 2) duplicate the static content into some other storage medium (S3?) and serve it using some web server, or 3) create a frankenstein's monster container of both php-fpm and a web server, and pick your poison on how to make that suck as little as possible.
I have opted for #3 as operationally it's the simplest. You build one container with all the dependencies, static content, and sql migrations, and deployments therefore become just a single container with a single port (http/https) and passing in the env vars. I'll probably upload it somewhere if somebody wants it. It's a docker-compose configuration, plus the Frankentainer, and some scripts, and it all fits into a Bedrock install. I haven't hooked migrations up to it yet, but once that's done, it will actually not suck very much to maintain a WordPress install.
If you are trying to deploy WordPress today with DevOps best practices (version control/12 factor app/etc): set it up with Bedrock (https://roots.io/bedrock/), manage dependencies with Composer, and use environment variables for the runtime configuration. Then use Phinx (https://phinx.org/) to do database migrations. A custom db migration script will be needed to change database settings based on the environment you're deploying to.
Containerization is pretty annoying, because apparently php-fpm will not serve non-PHP content (without creating security concerns). So you need a web server to serve all the static content that comes with Wordpress/Plugins/etc, and php-fpm to serve the PHP. This means you have to either 1) duplicate the static content between two different containers, 2) duplicate the static content into some other storage medium (S3?) and serve it using some web server, or 3) create a frankenstein's monster container of both php-fpm and a web server, and pick your poison on how to make that suck as little as possible.
I have opted for #3 as operationally it's the simplest. You build one container with all the dependencies, static content, and sql migrations, and deployments therefore become just a single container with a single port (http/https) and passing in the env vars. I'll probably upload it somewhere if somebody wants it. It's a docker-compose configuration, plus the Frankentainer, and some scripts, and it all fits into a Bedrock install. I haven't hooked migrations up to it yet, but once that's done, it will actually not suck very much to maintain a WordPress install.
I am not sure if this is relevant, but I just remember someone announcing this site yesterday: https://wpgitupdater.dev/
You can do this yourself with Dependabot for free. It's pretty easy to set up and you don't host anything to use it.
I like the custom response header on https://www.whitehouse.gov/ —
x-build-back-better: https://usds.gov/This thread is full of pro and anti wordpress/php and of anti and pro jamstack.
I'd like to see the project's requirements.
I'd like to see the project's requirements.
Requirements and time to work. January 20th at noon was the absolute-ish deadline, but when did the work begin? Was it November 4, or sometime later given the lack of concession from the previous administration?
I am sure it was rushed a bit and reused things.
The contrast and typo sliding menu was present on the bidenharris and or joebidden.com websites.
The contrast and typo sliding menu was present on the bidenharris and or joebidden.com websites.
I'm surprised they dropped the IE supports. (It's failed on my testing, and the CSS syntax they used shown they never think about it.)
For their 2% rules, they shouldn't drop the minors.
https://github.com/uswds/uswds/issues/3877
This is a super clean and simple feature website. They could offer supports very widely, and the cost won't be high! (I'm a web developer)
This is a super clean and simple feature website. They could offer supports very widely, and the cost won't be high! (I'm a web developer)
IE11 will soon be a security hazard and not worth the effort to code for.
Please stop spreading misinformation.
https://docs.microsoft.com/en-us/lifecycle/faq/internet-expl...
"Internet Explorer 11 is the last major version of Internet Explorer. Internet Explorer 11 will continue receiving security updates and technical support for the lifecycle of the version of Windows on which it is installed."
https://docs.microsoft.com/en-us/lifecycle/faq/internet-expl...
"Internet Explorer 11 is the last major version of Internet Explorer. Internet Explorer 11 will continue receiving security updates and technical support for the lifecycle of the version of Windows on which it is installed."
> Please stop spreading misinformation.
IE is already a security hazard for users. IE doesn't support any of the content security policies implemented in other modern browsers, which makes its a target for every possible XSS scheme and what not.
https://caniuse.com/?search=csp
If your users use IE you are putting them at greater risk than any other browser users and the former should be actively discouraged to do so.
IE is already a security hazard for users. IE doesn't support any of the content security policies implemented in other modern browsers, which makes its a target for every possible XSS scheme and what not.
https://caniuse.com/?search=csp
If your users use IE you are putting them at greater risk than any other browser users and the former should be actively discouraged to do so.
XSS is only a problem if you make it one.
Maybe if you stop forcing your users into your authoritarian ideals, people might start to change their perception of you.
Maybe if you stop forcing your users into your authoritarian ideals, people might start to change their perception of you.
That gets you to 2025, which is "soon" under some definitions.
Even IE6, that's no security problems on a well-made & trusted website. And a website doesn't support IE6 can't prevent the attacts usually (eg. XSS)
> effort
this simple theme can code in ONE day.
> effort
this simple theme can code in ONE day.
Now it has an RSS/Atom feed, unlike the previous version: https://whitehouse.gov/feed
The whitehouse probably needs a fast way to publish. this is why they used wordpress. They are fully cached behind Akamai CDN. So u can hit this website with any load u want.
The performance of wordpress is excellent if you dont have many plugins. It is super-easy to design. you can see the results before you publish and You dont need a developer to publish.
So if u have a static wordpress website, just add a CDN in front (not using a plugin like many do, but by editing your DNS)
So if u have a static wordpress website, just add a CDN in front (not using a plugin like many do, but by editing your DNS)
> performance of wordpress is excellent if you dont have many plugins
Even without plugins, WP performance will start to degrade due to how it handles post "meta" data. As the wp_postmeta table grows larger in size, it will generate longer running queries as it tries to query against non-indexed key + values. At a certain point, your only option is to start modifying WP core code and the DB tables for your specific needs...which at that point, the poor software architecture becomes an enormous problem. Granted most small blogs will never see these kinds of issues since they will never reach these inflection points, but they needlessly exist none the less.
Even without plugins, WP performance will start to degrade due to how it handles post "meta" data. As the wp_postmeta table grows larger in size, it will generate longer running queries as it tries to query against non-indexed key + values. At a certain point, your only option is to start modifying WP core code and the DB tables for your specific needs...which at that point, the poor software architecture becomes an enormous problem. Granted most small blogs will never see these kinds of issues since they will never reach these inflection points, but they needlessly exist none the less.
This is not really true. I help run and launch professional news organizations on WordPress, some of which have tremendous archives of 100s of thousands of posts.
The post meta table can scale fine to hundreds of thousands of post objects without needing special infra or handling. The WordPress core has a caching layer for metadata, and either way it's not like "SELECT * FROM wp_postmeta WHERE meta_key = 'foo' AND post_id = 1234" is going to be a performance bottleneck regardless of the size of the meta table.
The post meta table can scale fine to hundreds of thousands of post objects without needing special infra or handling. The WordPress core has a caching layer for metadata, and either way it's not like "SELECT * FROM wp_postmeta WHERE meta_key = 'foo' AND post_id = 1234" is going to be a performance bottleneck regardless of the size of the meta table.
I'm not referring to single meta_key look ups but was referring to non-indexed key + value queries on large wp_postmeta tables. Eventually a developer will need to do a meta_key + meta_value look up in some query which will tank performance on large table sizes. With plugins like Advanced Custom Fields, the wp_postmeta table can drastically increase in size and a developer can quickly fire off dozens of non-indexed key + value queries in one request. Given JSON support in MySQL, Postgresql, et al, there is no need to not migrate away from such a poor schema. Source: also work in the media world and have large WP installations in my charge. WP is a resource burden.
Since it mentions they're using NewRelic, I thought I'd mention a fun potential security hole for those using AWS integrations (and probably others). You have to create a custom read-only IAM role to absorb all the AWS events into NewRelic. But if you don't put in your particular NewRelic customer ID in the policy, the policy allows any customer in NewRelic to add that AWS account to their own NewRelic account and ingest its metrics. Since you don't have to include the customer ID in the role to make the integration work, it's likely there are a lot of AWS accounts out there with misconfigured IAM policies allowing any unscrupulous NewRelic customer to view their metrics.
Few years back I heard in the Google Dev conference that they are going to partner with WP/Automattic to make it more secure among other things. What happened to it?
I feel improving the security architecture of plugin integration could go a long way. Although using lesser plugins, only from trusted developers, keeping them updated, using other security plugins(Firewall, 2FA etc.) and regular backups can help keep WP instance safe to some extent; There's absolutely no excuse or explanation for random database errors with WP and that was the final nail in the coffin for me.
I started building my own CMS using Go for complex websites and for simple websites static web pages using Hugo with markdown does the job.
I feel improving the security architecture of plugin integration could go a long way. Although using lesser plugins, only from trusted developers, keeping them updated, using other security plugins(Firewall, 2FA etc.) and regular backups can help keep WP instance safe to some extent; There's absolutely no excuse or explanation for random database errors with WP and that was the final nail in the coffin for me.
I started building my own CMS using Go for complex websites and for simple websites static web pages using Hugo with markdown does the job.
At least 4 Google developers contributed to WordPress 5.6
I'm disappointed by their choice in site design and I'm sure it'll be infuriating to interact with for those with disabilities. It's a real wasted opportunity to use this instead of something more battle tested and fit for purpose such as the design used by the gov.uk site.
https://www.gov.uk/
https://www.gov.uk/guidance/government-design-principles/
https://www.gov.uk/
https://www.gov.uk/guidance/government-design-principles/
I see no infinite scrolling on https://whitehouse.gov/ It clearly has an end point and a footer. Also, the "briefing room" has pagination.
Not sure what pages you are looking at.
Not sure what pages you are looking at.
It would seem you're correct, faulty memory I suppose?
I don't think that's a direct comparison. gov.uk looks closer to something like https://www.usa.gov/, which is similarly functional. The Whitehouse website is more political and maybe would be closer to to Downing Street's page https://www.gov.uk/government/organisations/prime-ministers-... which has more photos.
I agree that might be a fairer comparison however I would argue is just as a accessible as https://gov.uk/ (to be expected since it's the same site), I don't think the addition of images makes it less so.
I really like that persistent link-background highlight effect when you click a link.
I'm not sure what I'm supposed to get from looking at gov.uk. For me, it was a negative experience, and I'm glad it's not used in the US.
It might be a negative experience for you but I believe sacrificing elegance in favour of accessibility is a fair trade to make when building something that will be used by a diverse group of people.
Accessible design is good design. Everything we build should be as inclusive, legible and readable as possible. If we have to sacrifice elegance - so be it. We’re building for needs, not audiences. We’re designing for the whole country, not just the ones who are used to using the web. The people who most need our services are often the people who find them hardest to use. Let’s think about those people from the start.
https://www.gov.uk/guidance/government-design-principles#thi...
In my personal experience however, using gov.uk has being a mostly pleasant experience and don't much care for opinionated "elegant" design.
Accessible design is good design. Everything we build should be as inclusive, legible and readable as possible. If we have to sacrifice elegance - so be it. We’re building for needs, not audiences. We’re designing for the whole country, not just the ones who are used to using the web. The people who most need our services are often the people who find them hardest to use. Let’s think about those people from the start.
https://www.gov.uk/guidance/government-design-principles#thi...
In my personal experience however, using gov.uk has being a mostly pleasant experience and don't much care for opinionated "elegant" design.
The site looks good...but as a matter of personal preference, I prefer high information density. I'd literally have preferred it if they straight up used HN front page style, or some similar.
Given that this was the most non-cooperative transitions in modern times, if not ever, is it possible they had to make certain compromises?
The same calculated compromises made by a vast part of the internet choosing WordPress and PHP. These technologies might not make sense if you have little experience with PHP or certain requirements, but there are good reasons many organizations use them. With a little dedication, it's possible to find out why without having a lot of experience with them.
Wonder if they had to contend with missing letters in keyboards, there's some historical precedent for that.
It’s funny. Until this year that was the only anecdote I ever heard about any presidential transition.
https://www.salon.com/2001/05/23/vandals/
https://www.salon.com/2001/05/23/vandals/
The one thing great about WordPress is the massive number of themes available (and plugins, if you're not a programmer).
I wish very much that there were 10% as many attractive themes available for static sites. Yes, you can port them, but it's a pain. And yes, you can design them, but it takes more time and most programmers don't have the design chops to pull it off.
I wish very much that there were 10% as many attractive themes available for static sites. Yes, you can port them, but it's a pain. And yes, you can design them, but it takes more time and most programmers don't have the design chops to pull it off.
That one great thing is arguably also the one horrible thing. The entry bar for plugins and themes is, well, non-existent which results in a lot of sub-par code that makes it onto sites of unsuspecting users. Configurability, while also usually a great thing, is taken to such a level with WordPress that you're often better off designing something catered specifically to your needs instead of loading half a dozen customizable themes/plugins/libraries
> themes available for static sites
By this do you mean plain HTML/CSS themes that you can edit yourself, or themes that are integrated and can be edited within static website providers?
By this do you mean plain HTML/CSS themes that you can edit yourself, or themes that are integrated and can be edited within static website providers?
The latter. There are dozens of Jekyll themes, Hugo themes, etc.
the massive number of themes available (and plugins, if you're not a programmer)
and ease of starting with an almost-free "unlimited" shared hosting.
These are the only 2 good things about WordPress.
> I wish very much that there were 10% as many attractive themes available for static sites. Yes, you can port them, but it's a pain.
That's what I always did whenever I needed a website design.
and ease of starting with an almost-free "unlimited" shared hosting.
These are the only 2 good things about WordPress.
> I wish very much that there were 10% as many attractive themes available for static sites. Yes, you can port them, but it's a pain.
That's what I always did whenever I needed a website design.
Do you think there’s a market for high quality paid themes for static site generators like Hugo?
I think there's a small market. I've gone looking for high quality hugo themes before. I was willing to pay for one.
I agree. There's a small market. But currently, even though there's probably a dozen or two paid Jekyll or Hugo themes, only a couple are actually attractive, well-designed theme.
Let's not forget this is the government. You can't simply just build stuff. There are many levels of red tape. Software has to be approved, etc. It's far easier to stay with the status quo and use what's already been approved then try to convince management there are simpler, more secure ways of building sites.
On the other hand, whitehouse.gov being the target of a zero-day WP exploit isn’t going to be a huge deal since it’s just a website for putting public available, or soon-to-be publicly available stuff. The only big attack vector i can see is it being used as a sure-fire way to target senior administration officials with other exploits like a chrome or Firefox zero-day.
If it was an important target, would it make more sense to choose a somewhat more secure platform OR to build a proprietary solution?
I think it would definitely be better to do a SSG or even wordpress with static output since you can throw it all behind authentication, which greatly reduces the attack surface.
Once upon a time my team built The Players’ Tribune with headless Wordpress + Nextjs + CDN , which I believe is a fairly common choice these days, on that it strikes a nice middle-ground between a refined editing experience for the end-user and a not overly-complex experience for the dev team. For a static content-heavy site, it worked fine.
But the real issue at stake here is more subtle than the question of the experiences of end-users vs developers, or of ecosystems vs. complexity, or is insecure vs secure.
The real issue is writing “static content-heavy site” as if static and content-heavy must go together. There is an assumption that a content-heavy site will be static. This is not true.
I’m baffled that almost all content-heavy sites relegate dynamic content to “Related content” and “Recommended content” to sidebars and post-content sections. Facebook and social media, one could argue, have become successful in large part because their content is dynamic in the same way ad-tech is dynamic — presenting the content contextual to a particular user’s interest and behavior. Tik Tok does this the best.
The enduring legacy of Wordpress (regardless of whether you use Wordpress or some alternative) is that the content-is-static mindset has become an unquestioned axiom. The very idea of a WYSIWYG is that content is and always will be static.
Although Tik-Tok has demonstrated the power of dynamic delivery of content, the content itself still remains static. How could it not be, most people still locked into the static-content mindset might ask.
But there’s no reason that individual chunks of content can’t be dynamic too. After all, we do have different sized thumbnails for previews of content on different screen sizes. So why not different versions of headlines? Or different versions of an entire article (not simply teaser vs. body).
The reason is that, as always, our imaginations are limited by our tools. Our content tools embed an impoverished imagination.
The content-world is waiting for a startup to give us a CMS that embeds an imagination where content is dynamic, both in delivery and in substance. Moreover, with tools like GPT3, the generation of adjusted content is now practical. While an editor could write 100 versions of an article, based on combinations of style, tone, and length, GPT3 could generate drafts that would reduce an editor’s work to ... editing.
The CMS is ripe for fundamental innovation. Here’s hoping someone is working on it!
But the real issue at stake here is more subtle than the question of the experiences of end-users vs developers, or of ecosystems vs. complexity, or is insecure vs secure.
The real issue is writing “static content-heavy site” as if static and content-heavy must go together. There is an assumption that a content-heavy site will be static. This is not true.
I’m baffled that almost all content-heavy sites relegate dynamic content to “Related content” and “Recommended content” to sidebars and post-content sections. Facebook and social media, one could argue, have become successful in large part because their content is dynamic in the same way ad-tech is dynamic — presenting the content contextual to a particular user’s interest and behavior. Tik Tok does this the best.
The enduring legacy of Wordpress (regardless of whether you use Wordpress or some alternative) is that the content-is-static mindset has become an unquestioned axiom. The very idea of a WYSIWYG is that content is and always will be static.
Although Tik-Tok has demonstrated the power of dynamic delivery of content, the content itself still remains static. How could it not be, most people still locked into the static-content mindset might ask.
But there’s no reason that individual chunks of content can’t be dynamic too. After all, we do have different sized thumbnails for previews of content on different screen sizes. So why not different versions of headlines? Or different versions of an entire article (not simply teaser vs. body).
The reason is that, as always, our imaginations are limited by our tools. Our content tools embed an impoverished imagination.
The content-world is waiting for a startup to give us a CMS that embeds an imagination where content is dynamic, both in delivery and in substance. Moreover, with tools like GPT3, the generation of adjusted content is now practical. While an editor could write 100 versions of an article, based on combinations of style, tone, and length, GPT3 could generate drafts that would reduce an editor’s work to ... editing.
The CMS is ripe for fundamental innovation. Here’s hoping someone is working on it!
Dynamic headlines or articles sound terrifying. Look at where the content surfacing algorithms of Facebook, Twitter, and YouTube have gotten us in terms of divisiveness. Changing the article actual content based on the desires of the reader just seems wrong. Different people end up with different analyses on the same story. This happens already naturally. I fear doing so artificially will lead to no good.
Nice overview by Matt from WordPress: https://ma.tt/2021/01/new-whitehouse-gov/
I remember first learning about Whitehouse.gov running WordPress back in 2018 when The Council of Economic Advisers published a paper[1] that linked to our website as a reference[2]. The paper was a single PDF file that resided in a /wp-content/uploads/2018 directory on Whitehouse.gov. There are government websites[3] that link to this PDF file that now returns a 404 because the new Whitehouse.gov only appears to have an uploads folder starting with 2021. Poking around, I found the Archived Trump White House Website[4] that still houses the PDF in the same /wp-content/uploads/2018 directory.
I wish the new Whitehouse.gov website gave a more descriptive 404 indicating the change or better yet, perform a 301 redirect so the original Whitehouse.gov link[5] works.
[1] https://trumpwhitehouse.archives.gov/wp-content/uploads/2018...
[2] https://www.last10k.com/sec-filings/unh/0000731766-18-000005...
[3] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7357013/#idm140...
[4] https://trumpwhitehouse.archives.gov/
[5] https://www.whitehouse.gov/wp-content/uploads/2018/03/The-Pr...
I wish the new Whitehouse.gov website gave a more descriptive 404 indicating the change or better yet, perform a 301 redirect so the original Whitehouse.gov link[5] works.
[1] https://trumpwhitehouse.archives.gov/wp-content/uploads/2018...
[2] https://www.last10k.com/sec-filings/unh/0000731766-18-000005...
[3] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7357013/#idm140...
[4] https://trumpwhitehouse.archives.gov/
[5] https://www.whitehouse.gov/wp-content/uploads/2018/03/The-Pr...
For a public facing CRUD system, there are three types of users:
1. Viewers
2. Writers/Editors
3. Maintainers
Technology tools are just means to an end.
I am sure there are people from https://www.usds.gov reading this. And I hope they would cherish the great opportunity of a green field to build a secure, robust public service system that are enjoyable to use for all types of users.
Wish them the Best.
1. Viewers
2. Writers/Editors
3. Maintainers
Technology tools are just means to an end.
I am sure there are people from https://www.usds.gov reading this. And I hope they would cherish the great opportunity of a green field to build a secure, robust public service system that are enjoyable to use for all types of users.
Wish them the Best.
What are the best alternatives these days to WordPress for non-technical people? I know of Squarespace and Webflow. Any others?
My clients love Wagtail. The 'streamfields' feature makes it really easy to offer editors plenty of flexibility without offering them the opportunity to butcher the site.
The development experience means I love it too. I never did find a simple Wordpress workflow for managing staging and live sites in git. With Wagtail/Django keeping the configuration in code, a git workflow works.
Edit: Apologies if you were actually asking about a solution to allow non-technical people to create a site, rather than manage it.
The development experience means I love it too. I never did find a simple Wordpress workflow for managing staging and live sites in git. With Wagtail/Django keeping the configuration in code, a git workflow works.
Edit: Apologies if you were actually asking about a solution to allow non-technical people to create a site, rather than manage it.
For non-technical people, Wordpress is a mess as it relies on clumsy plugins for WISIWIGish editing.
From my research, it seems like there are three top CMS for non-techies: Squarespace, Wix and Weebly. I compared Wix and Squarespace primarily and went with Wix because Squarespace has no backup/restore capability. I'd consider backup to be essential for non tech users.
> Squarespace has no backup/restore capability
At all? Even if you contact support because you accidentally deleted a lot of stuff?
At all? Even if you contact support because you accidentally deleted a lot of stuff?
Hire someone who is technical? Most people don’t install the electrical or plumbing on their house, why are they trying to make a website?
For a business web application, yeah. For someone trying to get a small marketing page / blog online, DIY solutions almost always make more business sense than paying hundreds or thousands of dollars (and then having to self-maintain or pay a retainer).
Is there a good alternative to WordPress?
Are you planning on self hosting? If not, you could give https://www.dynablogger.com a try - there's a free plan so it's easy. It's a fully managed, no-bloat, easy to use blogging plarform. (I'm the founder)
Kirby is great. "loved by developers and editors alike": https://getkirby.com/
It's sad that the only options given to people nowadays are either JAMstack hype nonsense or the WordPress poop monolith.
It's sad that the only options given to people nowadays are either JAMstack hype nonsense or the WordPress poop monolith.
Craft CMS : https://craftcms.com/
the big alternative is static content - if you are just publishing a webpage, you can use something like Jekyll to manage your content and then it is "compiled to HTML".
For simple static content there really is no need for a database or anything at all, people just want the convenience of writing content dynamically and the database is a necessary evil in wordpress to make that happen.
If you need to handle a certain amount of user submissions (that can't be handled by forms/etc) you use JAM stack - javascript + API behind it.
For simple static content there really is no need for a database or anything at all, people just want the convenience of writing content dynamically and the database is a necessary evil in wordpress to make that happen.
If you need to handle a certain amount of user submissions (that can't be handled by forms/etc) you use JAM stack - javascript + API behind it.
If you are a developer, a static site generator is the way to go. However, the point that so many developers seem to completely miss when they decide not to choose WordPress is the end user. There might be plenty of alternatives, but there are none (in my opinion) that even come close to WordPress' publishing experience. The admin panel is a refined UI, the publishing experience is really easy for people to grasp, it's the most user-friendly CMS around.
What so many developers get wrong is that a lot of average users are used to writing in WYSIWYG environments like Microsoft Word. And despite Markdown being easy, once again, you lose the visual publishing experience in a lot of these static options. Markdown is easy for developers, but average users will struggle (especially with complex markup like tables or even images).
What so many developers get wrong is that a lot of average users are used to writing in WYSIWYG environments like Microsoft Word. And despite Markdown being easy, once again, you lose the visual publishing experience in a lot of these static options. Markdown is easy for developers, but average users will struggle (especially with complex markup like tables or even images).
October CMS: https://octobercms.com/
There are a lot of other complex sites and business running Wordpress. Why is it a big deal when there's a new one???
Wordpress makes it very easy for users to manage website content for the end users. But for developers, simplicity depends upon personal preference.
I like the the whole project to follow a same set coding standards irrespective of whether it's a procedural paradigm or OOP or any other. But, if you look into the wordpress core, you will several sets of standards which makes it harder to follow through whenever you try to understand the core. For simpler plugins, one might not need to dive into the core but I have had a fare share of projects and plugin development where I had to go through the core. And, it still takes me some time to understand whenever I have to do so. Maybe, I might be using Wordpress for wrong reasons and wrong project (because that particular task can be easily achieved using other technologies or even if I start coding from scratch without wordpress), but clients are always right and I have to use the technologies they prefer.
Wordpress makes it very easy for users to manage website content for the end users. But for developers, simplicity depends upon personal preference.
I like the the whole project to follow a same set coding standards irrespective of whether it's a procedural paradigm or OOP or any other. But, if you look into the wordpress core, you will several sets of standards which makes it harder to follow through whenever you try to understand the core. For simpler plugins, one might not need to dive into the core but I have had a fare share of projects and plugin development where I had to go through the core. And, it still takes me some time to understand whenever I have to do so. Maybe, I might be using Wordpress for wrong reasons and wrong project (because that particular task can be easily achieved using other technologies or even if I start coding from scratch without wordpress), but clients are always right and I have to use the technologies they prefer.
> Dave Amirault, Pagely’s Director of Marketing, and Jeff Matson, Minister of Propaganda, have had a few moments to gather their first impressions of the site.
I had to google that because for a split second I thought the US had a minister of Propaganda. It's a job title at Pagely.
I had to google that because for a split second I thought the US had a minister of Propaganda. It's a job title at Pagely.
Related read: https://ma.tt/2021/01/new-whitehouse-gov/
[deleted]
Does it really need to be so dynamic? Plenty of static site generators that could be used as alternatives? What features of Wordpress do they use?
[deleted]
When I read there are over 55,000 plugins available, someone on reddit manage to find 16,000+ plugins, the rest could be outdated?
The rest are probably on the various marketplaces and websites around the internet, not the official plugin directory.
Probably, we can only get the actual figures of less than 55,000 from sitemap:
https://wordpress.org/plugins/sitemap.xml
https://wordpress.org/plugins/sitemap.xml
[deleted]
Good. Wordpress is battle tested, open source and in the right hands, secure. Twitter recently tried to dunk on the last administration's use of Wordpress at the State Dept, claiming they were hacked to show Trump had resigned, but it was just a disgruntled employee and was it never hacked.
[deleted]
I wonder why?
Can't they just use the Gov't CMS
Can't they just use the Gov't CMS
Heh. When did CL-HTTP get phased out?
Is it 2010 Again?
So much for the Biden administration's renewed focus on cyber security.
ogre_codes(1)
Seriously? The most powerful tech country in the world choses bloated system, created for 'regular folks'. What can go wrong?
Little warning for anyone reading these comments:
100% of the criticism will be by devs with little or no experience with WordPress.
It's almost an in-joke to hate on WordPress at this point.
100% of the criticism will be by devs with little or no experience with WordPress.
It's almost an in-joke to hate on WordPress at this point.
For the sake of security and scale I hope they're serving pre-generated static pages. That is, WP is strictly a backend CMS, with frontend responsibility being delegated elsewhere.
At that point it's not full WP per se.
At that point it's not full WP per se.
I predict they'll move to Jamstack soon. I've really been impressed by the things I've seen moved to Next.js in the last couple of years.
I am not sure. A major problem with Jamstack is that article writers need to learn git and markdown, to do the job.
While wordpress gives you a GUI editor, and you are good to go
While wordpress gives you a GUI editor, and you are good to go
FWIW I’m seeing people conflating Jamstack and headless CMS (eg Contentful) a lot lately. The latter provides an infinitely better editing experience for non-tech users. But the non-free tier can start as high as $500 / mo (the amount of shit you could tack on a WP site for that money...) and as one of the top commenters has said I think that even for a best-in-class headless CMS, the non-techie UX starts crumbling as soon as you start adding typical features outside of content editing (forms, analytics, etc)
Gutenberg sucks donkey dick. Matt should remove it asap before people switch in masses to another cms. Last I checked reviews are still sucking.
https://wordpress.org/plugins/gutenberg/#reviews
This is an example where the words chosen to express a valuable criticism completely undoes it because noone wants to engage with someone using such words. (Wish this was a spoken conversation because you'd hear this said in a very sad voice and not as a high and mighty I-look-down-upon-to-you. Trust me, I know how much it matters how you express yourself. It cost me nearly everything that I valued in my life.)
Lately most of the modern marketing websites I see is built using gatsby and next.js. Having been talking to different content/marketing teams, they hate it so much because of the complexity it brings. Editing content? Sign in to this headless CRM app, want a form? Go sign in to another app. It might be a fun project for devs but the actual users if these systems will almost always have a hard time using it.