Before you release your plugin on WordPress.org it’s always good to spend a little time polishing the final product; not only does this make your job easier in the long run (so you don’t have to fix it later), it gives a better first impression to new users.
With 2013 drawing to an end, it’s time to start thinking about the upcoming year and what I hope to accomplish. I didn’t set any resolutions for 2013, but this year I want to set myself some goals so I have something to work towards. Here are my four new year resolutions.
This month I’ve been blogging like a champ, every day. Not from WordPress admin though – I’m a markdown lover and I prefer dedicated apps.
I’ve been experiementing with 3 apps in particular this month; Byword, MarkDrop, and the one I’ve used the longest; iAWriter. In this post I’ll review each and give my verdict on my favourite solution overall.
Something I get asked a fair bit with regards to my plugins is how to send an alert during an event, for example, “when a job expires in WP Job Manager, how can I notify the user?”
Plugins which use custom post types, like WP Job Manager, are likely to use custom/standard post statuses too – it’s pretty common. Using these statuses you can easily hook-in a custom function and trigger and email.
This is a quick tutorial for hooking into a status change and sending an email for WP Job Manager.
Yesterday I was taken off guard with a comment/concern from an anonymous WooCommerce developer named “Jonathan”. Jonathan was annoyed at upcoming changes in the core WC plugin:
Mike, one thing that strikes me about WC as compared to WP is stability of maintstay features and code structures. Notice that WP rarely breaks a site.
He went on to compare WordPress to WooCommerce:
This is something all the devs of WC should take careful note of. As a glaring example, WC 2.1 will break a lot of plugins. I know this to be fact our company has developed dozens upon dozens of custom plugins for WC for our customers.
Jonathan’s personal feeling was that plugins should avoid change. His main gripe was our ‘restructuring’ of core classes.
But it’s simply an ideological / philosophical tree structure decision that makes no difference in the overall operation of the software
Yes, we could have left them as they were and not much would change operationally. But the old structure was a mess and inflexible.
To explain a little, we had a classes folder, function files willy nilly, a separate admin folder with more classes inside etc. Anyone coming into WC development would see this and think “WTF are these jokers doing?”.
So yes, whilst we could have left them alone, we changed them – this will improve the plugin structure long-term, even if that means breaking some things short-term (note however: we didn’t envision this particular change could break anything).
I put the question to twitter:
— Mike Jolley (@mikejolley) December 22, 2013
There were some interesting replies, and the decision was unanimous from both plugin developers like Pippin, and freelancers like Sean; Improve and Change > Supporting legacy.
— Pippinsplugins (@pippinsplugins) December 22, 2013
You can view the full conversation here if you wish: https://twitter.com/mikejolley/status/414837248572796928
WordPress isn’t perfect
Jonathan’s argument stemmed from the fact WordPress doesn’t break things often. But remember it still does.
Take MP6 for example; 3.8 changed the look and feel of WordPress admin, as a result styling in many plugins has been “broken”, including menu icons. Now, albeit not a site-breaking change, it means all < 3.8 plugins will need to make some visual alterations.
And what about the major updates 1.0 -> 2.0, 2.0 -> 3.0 – I’m certain plugins built for 2.0 would fail for 3.0, so why would WooCommerce 1.0 to 2.0 be any different? You shouldn’t expect your code to work forever.
Why changes are important
Whether they be features, refactors, or file structure changes, changes are important. Without making these decisions your plugin cannot evolve – you don’t want to be stuck with a v1.0 forever. It’s natural for things to crop up after the first release and after some real-world usage. Users will find bugs, oversights, or simply won’t be able to work with the plugin as they want to. Thats why you need to make the hard decisions for the greater good.
I can give you an example of a plugin-breaking change in WooCommerce. The order system in WooCommerce 1.0.x used post meta to store line items. This worked perfectly fine but with real-world usage it meant:
- queries of line items were extremely heavy
- serialisation of data was slow
- the system was inflexible
- a slight error in line item data would break all lines
So we created a custom table in 2.0 to store line items and the system is now way more stable. This change would have broken any plugin using those old meta fields directly, but it was necessary.
If you don’t improve, someone else will
You need to keep up to date with new features and enhancements. If you don’t someone else will, either with a fork or with a new competing plugin. Let us take an eCommmerce plugin example.
WordPress 3.0 “Thelonious Monk”, was released June 17, 2010 with the revolutionary new ‘custom post types’ feature.
Shopp, one of the biggest eCommerce plugins at the time, up to then was using its own custom tables and UI for products simply because no other core alternative was available.
It took 2 years for Shopp to support custom post types (Feb, 2012) and in that time countless new eCommerce plugins were released; WooCommerce, Jigoshop, eShop, Marketpress to name a few. Shopp had to lose many users over this, an example in their comments:
Too late for me. I wish you guys all the luck as you were there when I needed you years ago, but I’ve been seeing other shopping carts and they are getting all the future love.
See my point? I’m sure a large factor in this delay was the fear of change and backwards compatibility, but sometimes you’ve just got to say “screw it” and get the ball rolling before its too late.
What plugin developers should do
Keep backwards compatibility if possible
If its possible to keep backwards compatibility, even for a few releases, you should. Use deprecated functions, fallbacks, and output warnings. Production sites shouldn’t break and shouldn’t show these, but development sites will and developers will be able to get their customisations updated before the site falls over.
Only make major changes in major releases
Don’t make site-breaking changes in minor releases – that would would be irresponsible. If you have to change a fundamental part of your plugin, ensure its a major release with an obvious major version update.
It’s no good changing something un-announced and watching the havoc unfold; notify your users.
— Sean Johnson (@seanuk) December 22, 2013
Blog posts, dedicated development blogs, in-plugin warnings and notifications, an ‘upgrade notice’ in your readme – all good ways of notifying your users. As long as developers utilising your plugin are listening, they’ll be able to act accordingly.
What client developers should do
If you’ve built something for a client, or a product on top of a plugin, you are ultimately responsible for its functionality.
Stay up to date with plugin developments, listen to announcements and ensure major updates don’t crop up without you knowing first.
Plan for maintenance
Understand it won’t be a build once, ignore forever chunk of code. You will need to plan updates and maintenance into your proposal, otherwise your clients will be stuck with old versions. Charge more, as Brian so bluntly puts it:
— Brian Krogsgard (@Krogsgard) December 22, 2013
You wouldn’t sell a car and then fix it for free for life, so when you sell a plugin don’t do the same. Create a plan to deal with updates and do them as required.
Test your code with major updates before running them. If you need to do this on behalf of your client, ensure they are aware of these costs up front.
Follow best practice
If developers tell you how you should be doing something, follow their guidance. In Jonathan’s case he has been including core classes:
We probably have to modify about 40 of them, simply because you guys decide to move files around in the core tree and no other reason. This is seriously bad practice and really ought to stop now.
We’ve never recommended this practice, nor provided any code, snippet or plugin which does this and whilst I cannot comment on whether or not he was right to do what he did, but it doesn’t feel right. We always recommend using the many filters provided, but if they weren’t suitable this leads me to my next point.
If something is wrong, make your case before it is too late
If you spot a problem in the plugin you are developing for, perhaps one you cannot work around, let the developer know. Otherwise, how can they help you?
In the case of WooCommerce we have both a development blog and github issues setup – tell us, suggest an alternative, get involved. If you do nothing you only have yourself to blame.
I know updates can be frustrating and appreciate your situation, but we’re working towards building a better solution overall. If that means breaking some custom code along the way, I honestly believe it’s well worth it in the end.
Please don’t give up, and by all means get involved – thats the beauty of open source, anyone can contribute their ideas, code and guidance.
Thanks for reading.
As we approach the end of 2013, I’d like to reflect a little on the past year’s events and my achievements.
My highlights for this year included releasing WooCommerce 2.0 and hitting both 1 and 2 million download milestones, releasing my jobs plugin, and the WooTrip to Leiden and WordCamp EU.
WooCommerce 2.1 has a new dashboard widget which replaces the previous version’s “Right now”, sales, and recent order widgets. Some users will like this change, others may ‘miss’ the old widgets. In this post I’ll explain the reasoning behind the changes.
I was asked about WooCommerce’s session handling at WCEU (where I seized up; darn social phobia) so I thought it would be good to give a brief history of our handling of sessions, and how things are changing in 2.1.
Cart sessions have been a long standing source of frustration in WooCommerce. To clarify, the session is the part which tracks a particular user’s cart object – without this the user wouldn’t be able to use the cart nor checkout.
The most obvious solution would be to use PHP’s built in sessions and
session_start(). This was the first thing we used (obviously) and you’d expect this to work perfectly fine…but it doesn’t for the following reasons.
Back in January we had several shipping methods for WooCommerce for getting quotes from APIs such as UPS, USPS and FedEx. Because these APIs expected ‘packages’ to quote on, it was necessary for items to be ‘packed’ into packages with a weight and dimensions.
The original extensions attempted to pack items by attempting to stack items to see how many items would fit into a box. This was not well received, and had several flaws:
- Stacked items left ‘gaps’ in the box
- Only one box size was supported – the box just grew to envelop all items..
- ..or was pre-defined which lacked flexibility (any sized item would be shipped in that box)
Both the developer and I looked into solutions and this lead us to read about the BIN packing problem.
Wow, what a milestone. WooCommerce has today hit 2 million downloads, just 6 months after hitting a million.
How did we get here? Team WooCommerce has grown from 2 to 11 employees over the past 2 years, we’ve made 63 releases, closed 3735 Github issues (out of 3779), and solved over 30k support tickets.
Since the creation of the WooCommerce repository on Github, there have been a massive **6,284 commits*. Personally I’ve made 3,134 commits of those, with 1,187,191 line additions and 887,313 lines removed.
WooCommerce is by far the biggest and most successful thing I’ve worked on and I’m so happy to see it flourishing, especially this quickly into it’s existence.
Google trends shows the increasing interest in searches related to WooCommerce which really demonstrates its popularity:
This dwarfs other WordPress eCommerce plugins. Other platforms such as Magento do still have more interest average, but WooCommerce is catching up fast (given it’s age, and that its not a dedicated eCommerce solution this is pretty impressive).
BuiltWith has even more promising stats, suggesting WooCommerce powers 9% of eCommerce sites (thats 154 463 stores!). the below chart shows it’s popularity amongst the top 100k, 10k and 1 million sites. and suggests at present it is more popular with smaller sites, but that popularity is growing.
BuiltWith also has stats about platform usage showing just what the stores they track are using. WooCommerce takes a large chunk of that pie. Interestingly many use custom carts. I would expect custom carts to be a lot more work over time for the companies involved, so perhaps those will start moving to other solutions (including WC) in the near future?
It’s good to see WooCommerce beating other WordPress eCommerce plugins, and even many dedicated eCommerce platforms, by a substantial margin.
We’ll continue to improve core (2.1 is coming out soon) build and evolve surrounding plugins, and hopefully continue with the impressive growth we’ve seen so far. As the platform evolves I imagine WooCommerce will appeal more and more to users of WordPress, and WordPress + WooCommerce will become a more serious alternative to dedicated eCommmerce platforms like Magento.
Bring on 3 million!