WordPress code evolution – OCP for the rescue?

Diagram that shows the personal code evolution
1 The personal evolution when learning to code and using WordPress

The big picture

Everybody who codes has to find solutions to complex problems multiple times every day. And every time we do so, we learn something new. The personal code evolution is a rocketing curve. But only to a certain point as there’re as well tasks that we repeat from day to day: Loading files, hooking callbacks to their appropriate hooks, fetching translation files and adding textdomains and so on. And as WordPress has something like an API that is meant to be used we suddenly find ourselves in the situation where we repeat similar tasks again and again. And the only real problems we get into is our copypasta as we’re fed up by writing the same lines into each single piece of code. Then we start to think about what parts all our codes got in common – the most obvious is forms: users, posts, taxonomies etc. all need additional data. And then we start summing up all those common things and stuff them into a base class that we can extend upon. Eureka! we did it! The next step obviously is to abstract things further. We build one class to handle saving to the database, another one to handle different UI tasks… we know the story.

Evolution

And then, a half year and 30 plugins later, when coming back to our first piece of code that extends upon those classes, we realize that we already changed that many things that other plugins stopped working. So we go back, refactor the class, go through different cases and realize that we can simplify and abstract further. And we realize as well that we got too many edge cases. Label above, label below, label on the side, label in a different table cell, label with classes, … again: we know the story. So we do a rough calculation how long we’d need to refactor everything that extends upon it and give up. Let’s go back, realize that there’re so many edge cases that we’d have to work on the whole thing for another week. And no one would pay that. So what are we doing now? Let’s just ship it! and write exactly what we need for this single case.

(R)evolution

After we did write single case code pieces for quite some time, we get fed up by it again. Then we try to open source our base, hope for contribution and that everybody jumps on our train and helps to make the world a better place. And we fail. We fail because most developers got the exact same kind of base laying around and don’t want to drop their own code. Or they simply have been through this multiple times and have given up.

Solution? Anyone?

I don’t know at which point you are (I’d love to read it in the comments below), but I’ve started and given up multiple times by now. And my personal conclusion is that I’ll stick with OCP – or: One Case Plugins – and go down another route. If I can open source something and you want to contribute, I give you full access, like a triple A pass. This means two things for me and every participating developer:

  1. I loose full control, you get responsibility
  2. The project will live even if I stop participating

There’re – to stick with the forms API example – simply too many cases that need to be considered. From different MarkUp to different form types, advanced JavaScript, remote APIs and HTTP requests, etc. and there won’t ever be a one to rule them all-solution, but sticking with a specific task and writing OCP plugins for this that are maintained by a larger group of developers so far works extremely well. If you want to jump the shared OCP model, just take a look at either my repositories or those of WeCodeMore – WCM on GitHub. If you see something where you’d like to contribute: Open an issue or file a pull request and you’ll be rewarded with full push and pull access.

Way of the ronin

Did you ever try to build base plugins or shared plugin classes? How did it work out? Are you succeeding with it or have you already switched over to OCP plugins or themes? Would you rather contribute to someone else code or write your own?

9 comments:

  1. Too bloody right.

    IMHO, every plugin is an island unto itself. You build, you release, they use, you fix, they use, you fix, rinse, repeat. You learn. You build another, better.

    I like the idea of reusable code. I make good use of it in applications. I build plugins for applications.

    I also build plugins for release into the wild, where they get used in ways you just can’t dream up. Forget about reusable code for such plugins, just copy in good code and maybe patch later to bring it up to a better grade. The plugin is the reusable bit, and it needs to be stable.

    Similar with themes: we’ve built I-don’t-know-how-many WordPress websites for wineries now. Almost all based upon a single custom plugin for wineries, in two branches. You’d think that would mean we could create a base theme that we could customise *just a little* for each new one. Bollocks! Each new one brings new challenges, with lessons learnt from the previous one making it “better” this time. Forget about a parent/child theme thing, too much changes every single time. OCT.

    After 27 years of programming, I’m still waiting for that year when I spend more time just banging out code than I do learning new stuff. 2013 is it, I’m sure of it this time! :)

    1. Hi Ross, very true comment:

      Each new one brings new challenges, with lessons learnt from the previous one making it “better” this time.

      absolutely my experience.

  2. I have written an autoloader for my plugins. Currently I write two smaller plugins and did not use the autoloader. There are two or three classes and I use really every class in this plugins. In larger plugins I use the autoloader for sure.
    The art of writing good base classes is not to handle the edge cases. It is to avoid handling edge cases in the base class.

    1. Hey Ralf, good notes! So far I never stuffed an autoloader into a WordPress project, so I can only talk about outside WP projects: What I don’t understand is why one actually needs a custom autoloader. Normally you can just go with the default PHP SPL autoloader, as long as you stick to PSR-0 standards.
      About the edge cases: Maybe I should’ve written possible cases – hence the forms API example. In my experience there always was either to much to do for a base class, or simply too less so it wasn’t worth including it and running all the git submodule funk including maintenance.

      1. PSR-0 is fine and dandy if you can guarantee a minimum of PHP 5.3 — which is a client-by-client thing. There’s a lot of PHP 5.2 servers out there still, so any plugin that you want to offer to the public needs to avoid namespaces for now. As such, I still prefix class names with something identifying the plugin, and drive autoload with an associative array.

      2. PSR-0 is fine if you write your own project, in a WP-plugin it is very useless. And if you also want to autoload some WP-classes, you start to write your own autoloader.

        Base classes are very small. Look at my last blog post where I talk about a datacontainer. I use the simplest datacontainer as base class (setter, getter, one propperty). If I want to protect some vars, I extend this simpe datacontainer with another baseclass containing the protect method and a propperty. If I need autostoring, I extend again. I simply don’t put every edgecase in one class, I split them up in different classes.

        If you want to write a base class for forms, put the validation and sanitazion in diffrent classes and the templates in another class. So you can strip the edgecases from the common buisness. You got a class for sanitazion, one for validation and one for output. Than you extend the base class or use dependency injection.
        And that’s the point where you start to think about an autoloader.

        We can use base classes, but we always have to remember that we are already using a framework. And there is no need to write a framework for the framework.

  3. I’ve been there done that.

    If you ever build a plugin which does “a little bit more” then it quickly becomes too big and too specific to share bigger chunks of code with other plugins.

    I believe that there is no easy soluton for that, that maybe we expect too much from ourselves (we would like to handle everything by ourselves) and as WP is used for all types of websites there is no “one solution which fit everybody”.

    What I would like to see is a WP fork which abandons a lot of the old code ( “like lets support 1.x guys, there are somewhere in the Internets, we cannot let them down ” – omg omg who cares?!? ) and introduces new, more modular structure

    1. Kamil, thanks for your comment.

      What I would like to see is a WP fork which abandons a lot of the old code (…) and introduces new, more modular structure

      There have already been several talks and for-fun drafts about having a fork. Maybe after 3.6 as most of its goals were missed? :)

Comments are closed.