8 ms·

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 ea

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.
- rapind 6y ago
  > 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).
  - falcolas 6y ago
    > 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.
    - yurishimo 6y ago
      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.
    - rapind 6y ago
      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-performance-with-nginx/#wp-super-cache 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.
trog 6y ago
> 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?
- yurishimo 6y ago
  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.
  - trog 6y ago
    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.
- splatzone 6y ago
  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.
  - ellyagg 6y ago
nsomaru 6y ago
> 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?
- ehnto 6y ago
  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.
- sleavey 6y ago
  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.
sixothree 6y ago
The pricing alone of wordpress hosting supports the counter argument that it is indeed too complicated.
- uberswe 6y ago
  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.
  - sixothree 6y ago
    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. `
    - photomatt 6y ago
      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.
apple4ever 6y ago
> 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.

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.

rapind 6y ago
> 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).
- falcolas 6y ago
  > 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.
  - yurishimo 6y ago
    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.
  - rapind 6y ago
    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-performance-with-nginx/#wp-super-cache 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.

trog 6y ago

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

yurishimo 6y ago
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.
- trog 6y ago
  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.
splatzone 6y ago
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.
- ellyagg 6y ago

nsomaru 6y ago

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

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

sixothree 6y ago

The pricing alone of wordpress hosting supports the counter argument that it is indeed too complicated.

uberswe 6y ago
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.
- sixothree 6y ago
  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. `
  - photomatt 6y ago
    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.

apple4ever 6y ago

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