Let’s face it – there are some features in WordPress which are unloved and rarely used. Ever used Press This? I’d love to see WordPress cutting out some bloat to make core lighter, and as a consequence easier to use. Here are my thoughts on what should be killed.
Sometimes code needs to change; without doing so you can end up with a non-consistent, bloated mess. When changing things such as functions and hooks however, you do have to consider backwards compatibility so that code which relies on the old things doesn’t just stop breaking without explanation.
In WooCommerce major releases we often have to deal with this problem – in this post I’ll explain how to deprecate code, and how we dealt with it whilst developing 2.1.
Last week at WordSesh there was a session all about the WooCommerce ecosystem. If you missed it, you can view it below:
Coen Jacobs also voiced his thoughts after being disconnected (#fail).
Unfortunately, as a developer-hermit I didn’t take part in this session, but I would like to give my thoughts anyway so here goes 🙂
Up until 2.1, each order had to be shipped via a single method with a single price. 2.1 changes that and allows each package to be quoted and shipped individually.
By default, each order is a package, so to get this new functionality to kick in you must split it into multiple packages first.
Filtering the packages
Each package has cart items, a total cost, applied coupons, and the destination:
Once items are placed into this package, the package is then filtered through the
woocommerce_cart_shipping_packages hook. This is where you can manipulate the packages and create more if needed.
Lets say for this example we have a regular items and a bulky item in our cart:
The bulky item cannot ship with regular items, so we give it a shipping class called ‘Bulky’ and then filter the packages to separate it out via some code:
This code puts bulky items in one package, and regular items in another – once done, during cart and checkout you will get a shipping section per-package, and each can be chosen independently:
Limiting available methods for a package
Each package can now also be marked to ‘ship via’ a method of your choosing. This is useful if certain packages can only be shipped by certain methods.
For this example, lets ensure bulky items are only shipped via flat rate, and not shipped for free.
Notice the ‘ship_via’ row which has been added. Now during cart and checkout, only flat rate will be allowed for the bulky items:
After an order is placed, this is displayed in the backend like this:
So how can this new feature be used? Here are some example use cases:
- Shipping method restrictions
- Per product shipping with a different selectable method per product
- True per-product shipping costs
- Shipping per class
- Free shipping for qualifying products only, not the whole cart
Right now its obviously only do-able via code, but I plan on building some extra functionality into the per-product shipping plugin to use this at some point, and I’m sure someone will make a UI for this eventually 🙂
I think it’s great to see what tools other people in your industry use day to day. You can learn new techniques, discover new apps, and improve your own workflow by looking. Coen Jacobs recently shared his setup, so I thought it would be good to share mine too. Even though pretty much we do the same thing, we’re both pretty different when it comes to workflow.
Most developers agree the donation model isn’t great (giving the plugin away for free and requesting, not requiring, a small donation as a sign of support).
Arguably the best alternative is freemium model (where you have a free plugin and build premium functionality plugins around it) which is growing in popularity and is used by plugins such as WooCommerce and EDD.
Freemium may not be suitable for all plugins however, as some may not have many features which you can make premium, or you may just want to avoid the burden of supporting users who’ve purchased a premium product (who’s expectations for support may be far greater).
One of my plugins, Download Monitor, has always been donation based and free on WordPress.org. Although there is space for a few premium extensions, I’ve not had the capacity nor will to build them yet. When I rewrote the core plugin however, I did take out a feature I deemed to be bloat and made it separate – but not premium, as I thought users would react badly to a previously core feature being made paid-for after an update. Instead I made it “pay what you want”.
If you are building a complex plugin, or one which needs it’s own database tables, you’ll likely be installing all kinds of things during activation or first run. Uninstalling your data however may be an after thought.
In this post I’ll explain techniques you can use to install and remove your data to keep things tidy, should the user decide they no longer want your plugin.
WP Job Manager is one of my side projects which I’m having a lot of fun with at the moment.
This week the plugin passed 20,000 downloads which is a nice milestone to reach – so far I’ve done little marketing and just built it up slowly, so it’s great to see it growing in popularity naturally (which also allows me to keep up with support and feature requests).