I see a lot of plugins making use of object-oriented coding when there isn't really necessary.

But what's even worse is that theme developers are starting to do the same thing. Commercial themes and free popular themes like Suffusion, even my favorite theme - Hybrid, stuff all their functions inside a class, instantiate it once in functions.php and run its functions in a procedural manner :)

Wtf? What's the point of doing this? Obviously you won't be using two or more instances of the same theme, at the same time.

Let's assume that the plugins do this for the namespace (which is ridiculous), but what's the theme excuse? Am I missing something?

What's the advantage of coding a theme like this?

  • 5
    @Ambitious Amoeba - Can you explain why you believe that using classes for plugins to minimize namespace collisions is ridiculous? As for themes maybe it would be helpful too if you could give examples of what you consider good code in themes to be and what you are considering to be unnecessary. Discussing this in the abstract is not likely to achieve any insight for you or for others, especially others who are not familiar with what you are referring to. Dec 22, 2010 at 11:04
  • 1
    I use classes wherever i can personally, it's much easier for me to maintain, update and reuse. Personal preference aside, what good reasons are there for using a class?
    – t31os
    Dec 22, 2010 at 11:06
  • 1
    Odd, just lost my original comment(SE bug perhaps?).. i'll repeat it though, what good reasons are there for not using a class?
    – t31os
    Dec 22, 2010 at 11:08
  • 2
    @MikeSchinkel: you can do that by appending a prefix to the function name. I don't think it's worth the extra class overhead just to have nice function names. Anyway, I'm curious about why themes do this, not that much about plugins Dec 22, 2010 at 11:11
  • 4
    @Ambitious Amoeba - I'll certainly give that you have a right to your opinion, but my opinion differs. I believe that the clarity that classes bring to code by minimizing functions floating in the global namespace is worth what I believe to be an effectively immeasurable amount of additional overhead, especially when using a professional level IDE like PhpStorm. And classes create a self-contained unit so that the developer can know what code a module requires. And finally after evolving my WordPress plugin style to use classes, any other method just feels to me like sloppy coding. Dec 22, 2010 at 11:19

6 Answers 6


I can understand your confusion based on the example you provided. That's really a poor way to use a class ... and just because a class is used, doesn't make a system OOP.

In the case of Hybrid, they're just using a class to namespace their functions. Considering Hybrid is a theme framework, this is done so that child themes can re-use function names without the developer having to worry about name collision. In many cases, a theme framework (parent theme) is so complex, many child theme developers will never understand exactly what goes on under the hood.

If Hybrid didn't use a class structure, child theme developers would need to know what all of the existing function calls were so they could avoid re-using names. And yes, you could just prefix all of your functions with a unique slug, but that makes the code hard to read, hard to maintain, and inherently non-reusable should you develop further systems that want to make use of the same functionality.

To Answer Your Questions

Wtf? What's the point of doing this? Obviously you won't be using two or more instances of the same theme, at the same time.

No, you won't be using two or more instances of the same theme. But like I said, think of the class structure in this case as namespacing the functions, not creating a traditional object instance. Lumping everything together in a class and either instantiating it to call methods (myClass->method();) or calling methods directly (myClass::method();) is a very clean way to namespace things in a readable, reusable fashion.

Of course you could always use something like myClass_method(); instead, but if you want to re-use any of this code in another theme, in a plug-in, or in antoher framework you have to go back through and change all of your prefixes. Keeping everything in a class is cleaner and allows you to redevelop and redeploy much more quickly.

Let's assume that the plugins do this for the namespace (which is ridiculous), but what's the theme excuse? Am I missing something?

In the majority of situations I'd agree with you. However, that majority is quickly waning. I host several sites on a MultiSite installation that use variations of the same theme. Rather than re-create the same theme over and over again with minor differences, I have a single "class" for the parent theme and all of the child themes extend that class. This allows me to define custom functionality for each site while still maintaining a general sense of uniformity across the entire network.

On the one hand, theme developers may choose a class-based approach to namespace their functionality (which isn't ridiculous if you work in an environment where you re-use chunks of the same code over and again). On the other hand, theme developers may choose a class-based approach for easy extensibility by child themes.

What's the advantage of coding a theme like this?

If you're only using Hybrid on your site, there's little to know advantage for you as the end user. If you're building a child theme for Hybrid there are advantages from namespacing and extensibility. If you work for ThemeHybrid, the advantage lies in quick, efficient code reuse across your other projects (Prototype, Leviathan, etc).

And if you're a theme developer who likes a specific feature of Hybrid but not the entire theme, the advantage lies in quick, efficient code reuse in your non-Hybrid project (assuming it's also GPL).

  • I don't agree with the "extensibility" part. You have the same level of control over the parent theme as you would if you used actions and your typical functions. Why? You said it yourself, this is not true OOP. I don't agree with namespacing either - this is why I started this question in the 1st place - Try redefining any function from Hybrid in any plugin and you'll see that the functions will collide. Why do you think they still added the prefixes? :) You just can't wrap the entire theme in a class, it just doesn't make any sense... Dec 22, 2010 at 16:53
  • I'm not saying to not use OOP in themes, like some people here might have understood, on the contrary (see 2.8 widgets for eg., walkers etc), but not like this. Dec 22, 2010 at 17:01
  • 1
    It seems like you have a problem with Hybrid's specific implementation, not with the practice of using OOP in themes or even using a class to namespace the functions defined in a theme. I was trying to answer your broader questions re:why do this? and re:what are the advantages of doing this? I'm not going to spend any time defending what appears to be a halfhearted implementation or arguing against your obvious animosity towards a specific theme framework's structure. Bottom line, if you don't like the way Hybrid's built, use something else.
    – EAMann
    Dec 22, 2010 at 18:34
  • 1
    not at all, I like Hybrid (but not the class thing of course). Hybrid insipired me to create my own theme framework. Take another example, Suffusion, same type of practice. Again, namespaces in this case don't work with themes, all functions within the wrapper class will always conflict with plugins, because plugins are loaded by WP "within" themes. Dec 22, 2010 at 19:33
  • 1
    Fair enough. Just try to keep in mind that most WP work isn't OOP to begin with (since WP isn't), but putting theme methods in a class to mimic how it's done in a plug-in is at least a step in the right direction ... even if it is a half-conceived and poorly implemented class. I definitely agree that just wrapping everything in a class and calling things procedurally is a bit odd (and not useful from the POV of a 3rd party developer trying to use the system). But if done correctly (and in Hybrid it's apparently not), class-ifying your code in functions.php can be very powerful.
    – EAMann
    Dec 23, 2010 at 15:15


My current base theme has 13 classes. When I build a new theme, I either use these classes as they are or I extend them. That system makes the process of building a new theme very, very fast.

Tight scopes

I rarely need global variables, because everything my code has to know is hidden in class members. So I’m able to share a variable between two very different filters or actions without the risk of collision with poorly written plugins.


Each class is one file. If I need to update a client’s theme, I just update some files. Whatever happens inside the classes is up to me as long as I offer the same API.

An example: above the comment_form(); call, I use a simple action:

do_action( 'load_comment_class' );

Which comment class will be loaded decides my controller. What exactly happens inside the comment class decides the individual class.

Try this with a pure procedural approach and you’re going nuts. :)


It is so much easier to reread and understand your own code some months later if you have separated everything by its task.

Some examples for useful class hierarchies

  • Meta_Box -> extended by Shortdesc_Meta_Box and Simple_Checkbox_Meta_Box -> extended by Sidebar_Switch
  • User_Profile_Addon -> extended by User_Profile_Checkbox (see Question 3255)
  • Comment_Form -> extended by {$theme_name}_Comment_Form
  • 2
    Any chance to get your 'theme' classes? I want to write my own and I'd like to know how you do it.
    – Horttcore
    Dec 22, 2010 at 12:05
  • 1
    I haven’t decided this yet. Maybe I’m realsing a new base theme together with @bueltge next year which uses some of these classes. Very likely not before march, I’m afraid.
    – fuxia
    Dec 22, 2010 at 12:31
  • 5
    Especially for your cases, free themes and frameworks, OOP is the way to go. Other people have to work with these codes. The authors should make this process as easy and flexible as possible. Replacing a class is easier than replacing 20 functions, because a well written class has a clearly defined API.
    – fuxia
    Dec 22, 2010 at 13:19
  • 2
    I can’t say anything about Hybrid; i have never used it. But, yes, a controller which organizes everything behind the curtains, offers good filters and inserts some MVC pattern into the usual theme mess – is A Good Thing. Don’t trust me. Try it. :)
    – fuxia
    Dec 22, 2010 at 14:12
  • 3
    It is time, WordPress needs a OOP theme for developers; i hope we fount the time to work for our goal. This small excerpt here and the benefits show the great possibilities with oop for customer themes; a fast way to realize a new themes ans also great for maintenance.
    – bueltge
    Jan 2, 2011 at 10:20

Another point to consider: Speed.

if ( !class_exists('cccYourClassName') )  
if ( !function_exists('ccc_your_function_name') )

After a short look/print out i found ~1.700 internal functions and ~1.400 user functions = ~3.100/3.200 functions VS. ~250 Classes. I guess this says the most about how much a look up would need. If you call for !function_exists('') on about 50-100 functions in your theme... just set a timer for one and then start doing some math. Even if it's not OOP it's a good way to make code

1) reuseable
2) maintainable
3) exchangeable
4) little faster

When you take a look at different classes floating around in the web that help you doing meta boxes, widgets, etc. fast, then it's good to use a controller like @toscho mentioned, because you can just plug classes out and in and just replace some lines in the controller that handles your classes.


Some argue that encapsulation is the only (or at least primary) benefit that OOP offers, and that inheritance and state are somewhere between boring and evil:


The author's talking more about using classes/objects as structs than as containers for static functions, but it's interesting to read a completely different take on the question, from someone who's squarely outside of the OOP camp.

I may write my next WordPress Plugin in Haskell.

  • 1
    Blog open to "invited" users only, unfortunately. Just another reminder why we should never post our information on a free service and, instead, should host our own blogs. Facebook is much the same in this regard. An updated resource link would be nice. FWIW I've seen the dark side of OOP and will never use it again unless it's absolutely necessary within the context, as higher-order functions can usually do extend functionality and help reduce boilerplate and misuse of the class keyword.
    – vhs
    May 19, 2017 at 8:17

Oh quite the discussion! I have to admit as well that I use classes for encapsulation far more often than not. The idea being here that in my plugins, I can wrap my functions in a class, and within that class use very simple, meaningful method names that are generic even among other plugins I write. In that instance, classes are a substitute for namespaces, which I am forced to avoid for 5.2.x environments.

While there are few instances that OOP is useful for modularity, the simple act of wrapping your functions also creates the added bonus of cross-plugin extendability. For example, I recently extended an invoicing solution that was class based, and being such I could extend the main class, add extra code to various functions (w/ parent::calls) or even replace functions, all without internalizing the extended plugin.

Allas though, class wrapping for the most part is just a substitute for namespaces.


What's the point of complaining about code you didn't write?

If you don't like the code, write your own!

Simple. Problem solved.

Programmers like to do stuff their way. So don't presume you can tell them how to write code, what kind of whiskey to drink, what brand of cigarette to smoke, or what religion to follow. They'll just debug such diatribe and keep right on doing what they want. ;-)

Code is not poetry. Code is a variation of the Sinatra song "My Way" ...

  • 10
    This question isn't complaining about the code, it's asking for a clear explanation of why code would be written in a particular way. Much of WP core is procedural, with a few newer features using an OOP approach. Many modern plug-ins also use OOP to encapsulate functionality. But most themes don't. The OP was asking why a pseudo-OOP approach would be used and gave Hybrid as an example. You're not answering the question, you're ranting.
    – EAMann
    Dec 23, 2010 at 15:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.