Lessons Learned From Maintaining a WordPress Plug-In: Joost de Valk’s list of seven lessons learned from writing and maintaining a WordPress plugin. I was nodding my head all the while I was reading through them. Some of these are applicable to the general WordPress plugin developer while others are more particular to the individual project that Joost was working on but almost all of them are good advice. All in all, I think this is a good read for both seasoned as well as newbie WordPress plugin developers.
Great tips! 😀
1) It’s hard to pretend how other ppl config their environment when we’re distributing free software under GPL. It’s their duty to help us… reporting bugs, with bugfix, offering code to enhance the software, etc. We can’t just give everything ready, even more when all our needs are already satisfied.
2) I add version to my configs 🙂 I don’t relember exactally how it’s done because I developed a framework and it deals with everything for me, but it always check if version is different and when it is it calls a function where I can make proper changes.
4) Are u sure about that? I always thougth it was useless. It’s boring to update version in many places everytime a new version is done, and if I fogot it will break all its purpose. There’s a way to get plugin version from WP, but I still don’t use it.
Again, it’s our users responsibility to keep updated, WP already has features to inform about it. If they wanna remain in old versions, it’s better to report the reason and help us satisfy them in latest version then stay stuck in the outdated world.
5) Always use site_url() and children and u’ll be good.
WordPress is a CMS, and nothing is static in it. We’re lucky it almost always offers functions to deal with dynamic resources, so always use its API functions to refer to its resources, instead of assuming every site puts its files in the same place you do.
6) content_url() or some function like that, and for upload folder use upload_dir(), or some name like that 😛
7) Better yet, leave your filter function publicly available! That way they can add ur filter anywhere they want, even in custom or other plugins hooks.
And add to that: add hooks everywhere you want, and make everything possible to allow your users to customize your plugin and filter your content without needing to edit your files!
Those were really good tips!
I could probably write out a list of my own, with some overlap and some odd situations I’ve run across.
Being available to support a release is why I haven’t done much plugin releasing lately either. Writing the code is fairly easy, testing a bit boring, but not too hard. Being available to fix bugs when a release goes way bad for someone, that’s a tough one!
Ozh has an excellent list from last year’s plugin competition.
I’d love to see a web-based seminar on plugin “best practices.” I couldn’t teach, but I could certainly add a lot of questions.
Thanks for sharing this. It’s really a good read. I really like the last part which says never assume. Assumptions sometimes lead to problems, it’s best to work on hard facts.
I can’t get enough of plugins – props to Joost for his 7 steps, and props to you for the article 🙂
I guess a lot of non techies don’t appreciate how much work goes into developing and maintaining plugins, and how something as normal as having one site in your Google Analytics account can cause a plugin to break.
The life of a plugin developer must sometimes be hard and stressful, but kudos to you all for putting in the effort.