4 ms·

Agreed. Plugins make it flexible and extensible, and if you use too many of them you're an idiot. Attack surface is a problem everything has, so that's not even

by burnte 7y ago

Agreed. Plugins make it flexible and extensible, and if you use too many of them you're an idiot. Attack surface is a problem everything has, so that's not even valid, and considering you can only use the plugins you need, WP has a smaller attack surface. Live changes? I'm sorry, it's Wordpress's fault you don't have a dev environment? Themes, yes, that's valid, they can be constraining. So is buying the wrong type of automobile. Deal with it.

viraptor 7y ago
Dev environment for WordPress is really hard to achieve. Or more precisely, testing changes on one deployment and then pushing them to another instance without wiping all the other state.
- burnte 7y ago
  As someone who has been developing for WP for over ten years, no, it's not difficult at all. It's just a very minor about of planning, and working with a process.
  - viraptor 7y ago
    I believe the point in the article was about changes to the website itself. So what's the process here? Let's say you want to move some boxes around on the site, while another person writes a new post. You've got the change in dev and a new post queued in production - how do you merge that? Custom, partial db sync?
    - burnte 7y ago
      Theme changes don't affect the content DB. You'd make your change in dev, verify it, then change the prod theme without worrying about content. Wordpress is PHP (and html/css/js/etc)and SQL. WP does not inherently do staging, so you set up a dev environment. You sync content from prod to dev, make code tests on dev, then copy them to prod. It's not hard.
      - viraptor 7y ago
        No, I get it, but that's not what I meant. I meant changes to page layout/design which is in the db.
        burnte 7y ago
        Unless you have people making multiple layout changes at the same time you shouldn't have collisions. It's 2019, you don't need to lock an entire DB to make changes to tables. You can sync those changes while content changes are being made if you so choose.

by burnte 7y ago

viraptor 7y ago

Dev environment for WordPress is really hard to achieve. Or more precisely, testing changes on one deployment and then pushing them to another instance without wiping all the other state.

burnte 7y ago
As someone who has been developing for WP for over ten years, no, it's not difficult at all. It's just a very minor about of planning, and working with a process.
- viraptor 7y ago
  I believe the point in the article was about changes to the website itself. So what's the process here? Let's say you want to move some boxes around on the site, while another person writes a new post. You've got the change in dev and a new post queued in production - how do you merge that? Custom, partial db sync?
  - burnte 7y ago
    Theme changes don't affect the content DB. You'd make your change in dev, verify it, then change the prod theme without worrying about content. Wordpress is PHP (and html/css/js/etc)and SQL. WP does not inherently do staging, so you set up a dev environment. You sync content from prod to dev, make code tests on dev, then copy them to prod. It's not hard.
    - viraptor 7y ago
      No, I get it, but that's not what I meant. I meant changes to page layout/design which is in the db.
      - burnte 7y ago
        Unless you have people making multiple layout changes at the same time you shouldn't have collisions. It's 2019, you don't need to lock an entire DB to make changes to tables. You can sync those changes while content changes are being made if you so choose.