3 ms·

Install woocommerce - you'll end up with 12-15 plugins off the bat. Would you like to force everything to be SSL? Another plugin. Do you want a contact form?

Install woocommerce - you'll end up with 12-15 plugins off the bat. Would you like to force everything to be SSL? Another plugin. Do you want a contact form? Another plugin. Do you want to disable the bizarre update messages from ignite woo that won't go away? Another plugin. Oh, you want some slider-carousel thing on some page? Another plugin. Caching? Another plugin. Image optimization? Another plugin. Some sort of 'maintenance mode' to deal with taking down the site for upgrades? Another plugin. Social sharing buttons? Another plugin. I could keep going, but perhaps you get the picture. And the argument could be made that 90% of these are not needed, and there's other ways to deal with the requirements. In my most recent excursion, I'd taken over a project from someone else, and this was it. Any changes to anything would require investigation, custom code, and still require some sort of UI to manage things, all of which cost time and money, which were in short supply, so this particular project kept going with dozens of plugins. You want to do an upgrade to WP core? You've got 30+ plugins to test. Or... just click 'update' and hope for the best. Or test each plugin and upgrade process on a separate server. Again, back to relatively large amounts of time and money expended just to keep up with wp core to avoid inevitable hacking attempts. I have another multisite install I was brought in on over the summer, with 165 plugins. It's just another version of 'crappy legacy software and undocumented crap with no documentation' which we've all seen, but it is also quantified by "number of wp plugins". No, not every site is using all 165. But there were/are > 40 sites, with various groups using various combinations - there's 0 good reasons for all of these to have been combined (over several years) in to one massive multisite mess, but it was, and it's taken many people far too long to unravel some of the mess to extricate some sites. Yes, some of this is just a 'bad code is bad code' rant, but given the mindshare that WP owns, it would seem to be incumbent on them to raise the bar with respect to tools for plugin management (as just one example), give developers better starting code and samples and guidance for what's acceptable and what's not. A paid certification program which would vet code for 'best practices' would be something I think would help improve the landscape in short order (and no doubt has been considered by some over the years).

g00gler 10y ago
So I think you're agreeing with me? I can't really tell. I agree that knowledge of best practices is really important, because why would you need to run a plugin on top of your site to force HTTPS? I use Apache to force HTTPS, Apache to handle error documents, etc. My themes each have their own cache manifest. It's common sense / best practice to have a second server to test updates on, that's what I do. Given I only have 12 plugins with a handful on active on each site, it doesn't take too long. I also add and develop plugins on the second server. IMO the shittiest thing about WordPress is the library so by and large I choose not to use it when it isn't necessary, so pretty much everything besides querying posts and accepting AJAX calls since they make it nearly impossible to otherwise. In general, I try to develop apps/plugins that run 100% independent of WordPress and just write a wrapper for the library that's used for administration on the WordPress dashboard. An example of this is a plugin that's more or less a long test, with some custom GUI and other requirements (save progress, download CSV, take notes, etc). I wrote it to WordPress standards and used a short code to add it to a page. It was slow, sooooo slow. So, I rewrote the entire front end to be an independent app that uses a custom DB table, propagated by a plugin on the WordPress dashboard. Result? 80% faster load times. Another example, I made a simple app that gets some data from another custom DB table and sends tweets, triggered by cron. It uses a SQLite DB to track a few settings and a list of users to mention. I wrote a wrapper for the library with a simple API to manage settings in the WordPress dashboard. Unless there is a drastic change to WordPress's plugin system these apps will always work. Even if there is a change, pretty much all the code that WordPress cares about is displaying the settings page and receiving AJAX requests. It might not be by the book but it's faster and in my opinion, pretty logical. This way apps are portable and can be transferred to other platforms easily, not necessarily other WordPress sites on shared hosts but they're custom so that isn't the point. * Edit to say, I wouldn't recommend any non technical user maintain a WordPress e-commerce site, anyways. Square makes it so easy, hosted secure and has tools for inventory and other things, too. All included in standard credit card processing fees. I'm sure they aren't the only ones but I was amazed at how simply someone could set up a site, as I know someone who has a store and uses square for payment processing already.
- mgkimsal 10y ago
  > It's common sense / best practice to have a second server to test updates on, that's what I do. Given I only have 12 plugins with a handful on active on each site, it doesn't take too long. I also add and develop plugins on the second server. WP specifically makes this non-trivial, because post and db data has hardcoded path info in it. Export/import a database? You have to make changes to it. For something that is 10 years old... an import/export system that acknowledges the reality of plugins and separation of data would be nice. SSL? When you're running wordpress, and you think "I want everything to be SSL"... you look for a plugin. I wouldn't and don't, but this particular system was something I inherited. 20+ plugins in WP systems seems to be something I run in to far more often than the "expert dev/ops guy who knows about SQL and can handwrite in 5 plugins what takes 15 by normal folks" systems. I think you're in the minority when it comes to being able to be 'good' with wordpress. As I was suggesting before, part of the appeal in wordpress is there's a low common denominator. Someone who came across your WP code that used custom tables, (instead of throwing EVERYTHING in to either wp_options or post_meta)... they'd be lost. Honestly. Really. I see it quite often. People writing plugins and themes and selling WP solutions not having the foggiest idea how to write or use SQL. "Square makes it so easy, hosted secure and has tools for inventory and other things, too. All included in standard credit card processing fees." This particular client was sold on "you can customize everything in woo/wp". There were a number of technical things they wanted to do which Square and others do not do, and they'd already tried with other hosted solutions as well (3dcart, for certain, and maybe another). What we inherited (and what I normally get in most projects that get referred) is an undocumented mess of stuff that is not in version control of any sort, a mishmash of various versions of libraries, etc. CAN you build 'decent' code in WP? Without a doubt, it's possible, but the defaults still go against commonly accepted dev practices. The more configs go in databases ("wp_options for everything by default"), the harder migrating between various environments is (I can't just pull code, for example, because db configs are required for everything to run correctly). That's not insurmountable, but you're working in an environment where these common tools and practices are a) not provided and b) not-understandable or accessible by the majority of the developers in that community.

g00gler 10y ago

So I think you're agreeing with me? I can't really tell. I agree that knowledge of best practices is really important, because why would you need to run a plugin on top of your site to force HTTPS? I use Apache to force HTTPS, Apache to handle error documents, etc. My themes each have their own cache manifest. It's common sense / best practice to have a second server to test updates on, that's what I do. Given I only have 12 plugins with a handful on active on each site, it doesn't take too long. I also add and develop plugins on the second server. IMO the shittiest thing about WordPress is the library so by and large I choose not to use it when it isn't necessary, so pretty much everything besides querying posts and accepting AJAX calls since they make it nearly impossible to otherwise. In general, I try to develop apps/plugins that run 100% independent of WordPress and just write a wrapper for the library that's used for administration on the WordPress dashboard. An example of this is a plugin that's more or less a long test, with some custom GUI and other requirements (save progress, download CSV, take notes, etc). I wrote it to WordPress standards and used a short code to add it to a page. It was slow, sooooo slow. So, I rewrote the entire front end to be an independent app that uses a custom DB table, propagated by a plugin on the WordPress dashboard. Result? 80% faster load times. Another example, I made a simple app that gets some data from another custom DB table and sends tweets, triggered by cron. It uses a SQLite DB to track a few settings and a list of users to mention. I wrote a wrapper for the library with a simple API to manage settings in the WordPress dashboard. Unless there is a drastic change to WordPress's plugin system these apps will always work. Even if there is a change, pretty much all the code that WordPress cares about is displaying the settings page and receiving AJAX requests. It might not be by the book but it's faster and in my opinion, pretty logical. This way apps are portable and can be transferred to other platforms easily, not necessarily other WordPress sites on shared hosts but they're custom so that isn't the point. * Edit to say, I wouldn't recommend any non technical user maintain a WordPress e-commerce site, anyways. Square makes it so easy, hosted secure and has tools for inventory and other things, too. All included in standard credit card processing fees. I'm sure they aren't the only ones but I was amazed at how simply someone could set up a site, as I know someone who has a store and uses square for payment processing already.

mgkimsal 10y ago
> It's common sense / best practice to have a second server to test updates on, that's what I do. Given I only have 12 plugins with a handful on active on each site, it doesn't take too long. I also add and develop plugins on the second server. WP specifically makes this non-trivial, because post and db data has hardcoded path info in it. Export/import a database? You have to make changes to it. For something that is 10 years old... an import/export system that acknowledges the reality of plugins and separation of data would be nice. SSL? When you're running wordpress, and you think "I want everything to be SSL"... you look for a plugin. I wouldn't and don't, but this particular system was something I inherited. 20+ plugins in WP systems seems to be something I run in to far more often than the "expert dev/ops guy who knows about SQL and can handwrite in 5 plugins what takes 15 by normal folks" systems. I think you're in the minority when it comes to being able to be 'good' with wordpress. As I was suggesting before, part of the appeal in wordpress is there's a low common denominator. Someone who came across your WP code that used custom tables, (instead of throwing EVERYTHING in to either wp_options or post_meta)... they'd be lost. Honestly. Really. I see it quite often. People writing plugins and themes and selling WP solutions not having the foggiest idea how to write or use SQL. "Square makes it so easy, hosted secure and has tools for inventory and other things, too. All included in standard credit card processing fees." This particular client was sold on "you can customize everything in woo/wp". There were a number of technical things they wanted to do which Square and others do not do, and they'd already tried with other hosted solutions as well (3dcart, for certain, and maybe another). What we inherited (and what I normally get in most projects that get referred) is an undocumented mess of stuff that is not in version control of any sort, a mishmash of various versions of libraries, etc. CAN you build 'decent' code in WP? Without a doubt, it's possible, but the defaults still go against commonly accepted dev practices. The more configs go in databases ("wp_options for everything by default"), the harder migrating between various environments is (I can't just pull code, for example, because db configs are required for everything to run correctly). That's not insurmountable, but you're working in an environment where these common tools and practices are a) not provided and b) not-understandable or accessible by the majority of the developers in that community.