(Dreaded) Hooks in Moodle :)

Re: (Dreaded) Hooks in Moodle :)

by Chris Weber -
Number of replies: 0

Hi everybody,  it's been years since I've come into this development forum.  But I thought I'd chime in here because I have a lot of experience with one of the open source projects that Dan mentioned (Drupal, 10 years exp):

The hook system in Drupal has served it well in the past 13 or so years, but it's not a system that Drupal developers seek to expand at this point.  If you like nerd words you can think of a hook system as a Global Event Dispatcher that allows custom code to register code that will execute when a specific event is executed.  You can write custom code that says, "Find anything that implements this hook, and let it run now".

Since the release of Drupal 8 last November, Drupal has included within it's core platform an actual Event Dispatcher.  As a result many of the new "hook" that plugin developers would introduce are created as a events / event listeners / even dispatchers.

If you're looking to introduce a hook system into Moodle, I would recommend looking at Event Dispatchers instead.  For several reasons:

  1. It's a solved problem: There is a good chance you could look around to existing PHP Frameworks (Drupal uses Symfony2) to reuse their Event Dispatcher.  You could just drop a library in (as long as the rest of the code can work with composer / autoloading code).  I hear that someone made it possible to get Moodle installed with Composer, so you might already have that level of support.
  2. 3rd Party code means less work for you (sort of): EVENTUALLY it will mean less work for you.  But, as Drupal discovered, having the ability to load a library of code to do a critical part of your platform will kick off a lot of work modernize your code (meaning working with a service container / Dependency Injection and finding ways to make your own code into libraries that code be independently loaded, etc.)  But once you do that you'll have a mechanism to update your platform code and its dependencies (which is basically Composer)
  3. It eventually causes you to participate in the development of 3rd party code so that it can work better with your own code.  Drupal is an excellent example of this.  Drupal initially wanted to bring in libraries to provide a Web Service out of the box, eventually that meat adopting sever libraries from the Symfony Framework and we contributed a lot of code to those libraries to ensure we could use them.

Drupal also worked with CKEditor to ensure we could deliver a text editor out of the box.  


It ultimately took about 4.5 years for Drupal to rewrite what we needed to rewrite in order to use all the Symfony libraries we wanted to use but that doesn't have to be your story.  If you just start by loading in an event dispatcher, then initializing / using it as you need to you'll start the project down the road of adopting modern PHP practices and libraries.  


Edit: sorry for the wall of text, but here's an excellent book that basically describes the process Drupal has gone through be able to use 3rd party code effectively:

Modernizing Legacy Applications in PHP: https://leanpub.com/mlaphp

Average of ratings: Useful (8)