9 ms·

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

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.

ceejayoz 6y ago
> 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.
- falcolas 6y ago
  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.
  - ceejayoz 6y ago
    > 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.
    - falcolas 6y ago
      > 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.
      - kortilla 6y ago
        > 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.
      - hluska 6y ago
        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.
splatzone 6y ago
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: define('DISABLE_WP_CRON', true); Again this is a decision I imagine was made to support shared hosting environments. They've made it easy for 99% of users, which is why it's so popular. We the remaining 1% who prefer to use real cron can edit the config. > 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/ https://wp-cli.org/ [1] https://www.siteground.co.uk/tutorials/wordpress/real-cron-job/ https://www.siteground.co.uk/tutorials/wordpress/real-cron-j... [2] https://en-gb.wordpress.org/plugins/w3-total-cache/ https://en-gb.wordpress.org/plugins/w3-total-cache/ [3] https://kinsta.com/ https://kinsta.com/
- falcolas 6y ago
  > 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.
winrid 6y ago
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...
- falcolas 6y ago
  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.
  - AlchemistCamp 6y ago
    My site has also hit #2 on HN multiple times and never broken 10RPS during any of those times, AFIK.
- 1123581321 6y ago
  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.
  - winrid 6y ago
    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 http://imgur.com/gallery/IQk2kun
    - 1123581321 6y ago
      Ah, sorry. I expected Apache. Nice numbers.
- photomatt 6y ago
  Thank you for sharing. :)
deleted 6y ago
[deleted]
toast0 6y ago
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.
- photomatt 6y ago
  This is the plugin we use to run WP databases across many servers and geographic locations: https://wordpress.org/plugins/hyperdb/ https://wordpress.org/plugins/hyperdb/
coldtea 6y ago
>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.
- captn3m0 6y ago
  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_.
  - thg 6y ago
    Typo3 can do that too.
  - Kimitri 6y ago
    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.
    - 6y ago
melomal 6y ago
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.
achairapart 6y ago
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.
donatj 6y ago
> 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.
- watermelon0 6y ago
  > 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.
_the_inflator 6y ago
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.
neurostimulant 6y ago
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.
- marc_io 6y ago
  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.
  - tolstoyswager 6y ago
    When is it scheduled to arrive?
    - 6y ago
dvfjsdhgfv 6y ago
> 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.
xorcist 6y ago
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.
lhorie 6y ago
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.
snowwrestler 6y ago
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.
uberswe 6y ago
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.
alicorn 6y ago
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.

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~~

ceejayoz 6y ago

> 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.

falcolas 6y ago
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.
- ceejayoz 6y ago
  > 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.
  - falcolas 6y ago
    > 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.
    - kortilla 6y ago
      > 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.
    - hluska 6y ago
      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.

splatzone 6y ago

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: define('DISABLE_WP_CRON', true); Again this is a decision I imagine was made to support shared hosting environments. They've made it easy for 99% of users, which is why it's so popular. We the remaining 1% who prefer to use real cron can edit the config. > 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/ https://wp-cli.org/ [1] https://www.siteground.co.uk/tutorials/wordpress/real-cron-job/ https://www.siteground.co.uk/tutorials/wordpress/real-cron-j... [2] https://en-gb.wordpress.org/plugins/w3-total-cache/ https://en-gb.wordpress.org/plugins/w3-total-cache/ [3] https://kinsta.com/ https://kinsta.com/

falcolas 6y ago
> 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.

winrid 6y ago

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...

falcolas 6y ago
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.
- AlchemistCamp 6y ago
  My site has also hit #2 on HN multiple times and never broken 10RPS during any of those times, AFIK.
1123581321 6y ago
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.
- winrid 6y ago
  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 http://imgur.com/gallery/IQk2kun
  - 1123581321 6y ago
    Ah, sorry. I expected Apache. Nice numbers.
photomatt 6y ago
Thank you for sharing. :)

deleted 6y ago

[deleted]

toast0 6y ago

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.

photomatt 6y ago
This is the plugin we use to run WP databases across many servers and geographic locations: https://wordpress.org/plugins/hyperdb/ https://wordpress.org/plugins/hyperdb/

coldtea 6y ago

>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.

captn3m0 6y ago
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_.
- thg 6y ago
  Typo3 can do that too.
- Kimitri 6y ago
  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.
  - 6y ago

melomal 6y ago

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.

achairapart 6y ago

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.

donatj 6y ago

> 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.

watermelon0 6y ago
> 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.

_the_inflator 6y ago

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.

neurostimulant 6y ago

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.

marc_io 6y ago
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.
- tolstoyswager 6y ago
  When is it scheduled to arrive?
  - 6y ago

dvfjsdhgfv 6y ago

> 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.

xorcist 6y ago

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.

lhorie 6y ago

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.

snowwrestler 6y ago

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.

uberswe 6y ago

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.

alicorn 6y ago

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.