I want to state very clearly that this does not intend to revive the discussion about functional/procedural programming versus object-oriented programming. There is plenty said about that, on WPSE and all over the net.

But a while ago I'm reading over some of the discussions about the programming foundations of Wordpress and I read something - I have to rephrase because unfortunately I didn't bookmarked it at the time - roughly like this:

One of the appealing things about using Wordpress is that they are additionally working based on the event-driven paradigm of programming.

From what I understand event-driven programming in this context is pretty much synonym to signal or dataflow programming. Furthermore - most likely oversimplifying it a lot - maybe the main apparent characteristic is the use of hooks - actions and filters - as linchpin for the method.

So far so good. Seems easy enough, but I'm not coming from a computer science background, so I'm pretty sure there is more to be said. I'm really interested in some input, like: What is it really about or is the above said pretty much it? Is it an extra paradigm? How does it relate to the other ones? Is it a core principle or just an addition?

Those are just off the top of my head, clearly breaching the rules, by not asking one singular question that has one distinct answer, but maybe this will be forgiven for once.

4 Answers 4


First of all lets clarify what paradigm word means in the programming. It means that we come to an agreement that we will handle certain cases/issues/situations in a certain way.

For instance, we come to agreements that foot-passenger should cross a road on a green light in our country. This is our green light paradigm. In another country could be an agreement to cross a road on a raised hand. That is their raised hand paradigm. They are not related to each other, they just exists and foot passenger could use either paradigm or create his own cross a road whenever I want paradigm.

The same situation is in the programming. Paradigm is just a set of rules or agreements to develop an application in a certain way or use a certain approach. Nothing more.

Ok, get back to WordPress and event driven paradigm. This paradigm is only one part of whole WordPress system. This paradigm sets a bunch of rules/agreements how to extend the core by 3rd party extensions, where hooks for actions and filters are linchpin approach. Pay attention that this paradigm covers only expansibility cases/issues/situations and this is not only paradigm used by WordPress, but is one of the core ones.

That's all. Of course you can use your own write a plugin/theme how I want paradigm and be happy with it :)

  • 2
    Thanks, I love the insight into the paradigm term! Personally I'm well aware of that, as I have written my master thesis about the field theory of knowledge, epistemology, history of science and so forth. Believe me, what I wrote wasn't as catchy as your explanation. I'm sure what you wrote will help people to a better understanding. Commented Oct 10, 2013 at 15:29
  • You are welcome. I hope that it will help too. Commented Oct 10, 2013 at 15:35
  • Just to break it down, as part of the Wordpress System the aspect of event-driven programming can be interpreted as paradigm of expansibility. I'd say first and foremost to let others make use of the wordpress core. And if one is not going to write a plugin with "how I want"-paradigm, but is instead going to follow the paradigm of expansibility, then it can be used as set of basic rules of making plugins/themes expansible too. Commented Oct 10, 2013 at 15:40

I think that with event driven paradigm, who write article intends Observer Pattern.

And that in WordPress is handled via the Plugins Api. I don't think there's much more to say.

  • Your first sentence is kind of hard to understand, but with the article you linked I'm getting what are you aiming for. I'm well aware of the Plugins API, in this context it might be noteworthy to point to the difference between Filters and Actions. Commented Oct 10, 2013 at 15:31
  • Just to clarify, while the observer is event driven it is not completely congruent with the even driven nature of Wordpress. Mainly because using the observer pattern the two objects - observer and subject - know of and communicate with each other. This isn't the case when using hooks to make use of event driven paradigm like wordpress implemented it, in this case only interception takes place and no reciprocal communication is happening. Commented Oct 17, 2013 at 12:06
  • 2
    @ialocin Observer it's just an abstract pattern that can be implemented is different ways. Abstractly spoken, the Subject notify Observers, and is not required that Observers communicate with Subject. After that WP, not really implement that pattern, just mimics it: in WP don't exist any Subject object, nor any Observer object: everything is handled using global variables...
    – gmazzap
    Commented Oct 17, 2013 at 12:57
  • @ialocin Regarding your 1st comment, in this specific case, there's no difference between actions and filters, both trigger events: try to add_filter('the_title', 'test'); function test($t) { error_log('foo'); return $t; }. It perfectly legal and the event is triggered even using a filter.
    – gmazzap
    Commented Oct 17, 2013 at 12:58
  • Thanks for clarifying the Observer Pattern further. I wasn't trying to say it's the only way to implement it. I merely tried to explain that the common ground event driven doesn't mean that it's implemented the same way in wordpress, but your comment clears that up very good. About the first comment, thanks for making that clear too. You are right - of course. I was more thinking about people who don't know anything about the Plugins API and how to make the point in your answer more plausible and/or accessible to them. Commented Oct 17, 2013 at 13:19

@nicolai: Wordpress follows Publisher Subscriber variant of The Observer pattern (Event Driven Architecture).


Wordpress is event driven because of the limitations of the language it is written in, not because it is in any way designed to be such.

The most popular web servers are event driven and PHP out of the box has very little utilities (none ?) to behave in any other way. Since wordpress depends on PHP, it just can not be anything else.

The PHP part of WordPress plugins and themes OTOH should be designed to be event driven by "events" "sent" by core. JS code is also event driven, but the events are almost only those triggered by an actual users (although some of the wordpress JS code will abstract it as well and raise events of its own).

  • Even with PHP it is possible to implement different patterns and designs, so it's not all about WordPress being based on PHP, but of course there are coming basic rules with the basis. Commented Mar 8, 2018 at 21:44
  • @Nicolai ok, maybe it is possible,and I was not fully accurate, but apache + PHP are geared toward event and its response. If the script is not "always run", lets say like java based web servers, it is going to be harder to implement anything else. Commented Mar 9, 2018 at 2:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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