overriding drupal hooks

The point is only one override function is allowed. There's no logic in having two modules implementing overrides, which override will "win"? If two modules implement an override, then they're most likely doing conflicting things and only one should be enabled. This feature is not implemented to be liberally used but only when a code change inside a module hook can't be avoided for cleaner implementation.

Name conflicts are as likely as name conflicts with the current hooks which must be avoided by convention. Same case applies here, override functions should be avoided by convention. I looked at the coding standards but didn't notice anything wrong (actually I just skimmed over it heh)

I'm not really aware of chx's patch, could you point me to that?

ahhh, a module called override. ok, that's different.

umm... I still can't see where a naming conflict could occur even if there's a module called override, but if a conflict could actually occur, could you provide a sample? Override was really an arbitrary name, so anything else should do.

RobRoy, could you advise on some other naming scheme here?

I've given an example of a case where an override is a must, if there's an alternative implementation please share it here. Either that or hacking the module itself which is definitely wrong.

Only one override is allowed, so it's not really a feature that should be used by contributed modules at all, but by custom modules that are not contributed. NOT IMPLEMENTING it could even be a requirement for contributed modules. Without this, we would promote hacking contributed modules on live sites when an override can do. When the required functionality can only be achieved by an override, then better implement it separately than hack the module itself even if it's a non contributed module. In the least, this would ease porting of real live sites that use custom modules to later drupal versions.

I'm open for different implementation suggestions or naming conventions, but as I see it, this feature is a must to prevent the -currently unavoidable- massive module hacking that's hindering many sites from porting to new drupal versions.

I just stumbled on yet another case where hook overriding is needed. A contributed module, let's call it abc implements nodeapi op "rss item" and returns an array with additional RSS fields. In my custom site, I don't want this module to add these fields. How can I prevent it from doing that without modifying the module itself?

If hook overriding is allowed, then all I have to do is implement a custom module that contains something like this :

function override_abc_nodeapi($node, $op, $arg)
{
  if ($op != 'rss item')
    module_invoke('abc', 'nodeapi', $node, $op, $arg);
}

I really haven't tested this specific case, but I'm simply trying to show that hook overriding can indeed be useful and would avoid hacking the module itself. This simply isolates all overrides in one module and greatly eases the operation of updating to next drupal versions. Compare this to what needs to be done if modules were hacked to add the functionality that would otherwise be impossible to implement!

The workaround using nodeapi and weight manipulation above would work on the condition that another patch be submitted that would change how nodeapi handles the "rss item" op. Even if it were to be created, it is clearly going to be more complex and add a considerable overhead compared to overriding.

Moreover, this may work with op='rss item', but let's assume (from what I actually saw firsthand) that a module implements a number of permissions but you need more granular control in your custom site. You could create a module with your own granular permissions, but then you'd need to hack the module's code to check for these new permissions. If overriding is allowed, then you can override the implementation in an external module like so:

function override_abc_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL)
{
  if ($op == 'submit')
  {
    if (user_access('custom_module_granular_permission'))
      module_invoke('abc', 'nodeapi', $node, $op, $a3, $a4);
    else
      drupal_access_denied();
  }
  else
    module_invoke('abc', 'nodeapi', $node, $op, $a3, $a4);
}

Another scenario would be a module that adds a file upload field to another node's form, then saves that file in nodeapi's submit op. If you need a reference to the newly created file from a custom module you can't get it. But if you override the submit op you'll have full control.

I'm not proposing that this feature be widely used or allowed to be used at all in contributed modules, but having it will prevent a whole lot of module hacking in custom drupal sites that can't upgrade because there are hundreds of hacks distributed over a large number of modules. This would make upgrading to new drupal versions a whole lot easier. Also, hook overriding is an emulation of a sound OO approach called inheritance, we can't simply keep complicating things to avoid using a very legitimate OO approach when it is genuinely needed.

The ability to override some functionality to provide custom ones while being able to utilize the original functionality is inheritance. I'm not saying this *makes* drupal an OO system, I'm only saying this capability is very useful in an OO environment or any other.

whatever