Add hooks to have modules define support in themselves
| Project: | RealName |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
I'm working on a module where I needed to have non-unique names and since usernames needs to be unigue I needed something like RealNames.
I'm fetching the names myself and the only thing I needed help with was to find where those names are to be shown - which RealNames can fix for me.
But - as RealNames is currently constructed I need to modify some of RealNames' files to add support for my module - which feels wrong to me and which I think isn't a very "drupal" way of doing it. I think my module should be able to implement the support for RealName by itself.
I've therefor refactored the RealNames module into using Drupals hooks to find modules supporting it as well as for talking to those modules.
I've also added a simplified approach for modules not wanting the fields control to give names to RealName - they can use hook_realname_make() to which only the user account is sent and which returns a name. I wanted my module to have complete control over which names is given for which users - that's why I added that hook.
I'm attaching a patch for this - although I also have the changes up in a git-repository at: http://github.com/voxpelli/drupal-realname/tree/master All adjustments of the patch should and will of course be posted here and not only in the git-repository :)
| Attachment | Size |
|---|---|
| realname_add_hooks.patch | 22.27 KB |
#1
New version of the patch - this time with a new option for a module to opt out of having the names cached.
The reason why I add this is that the module I'm currently implementing support for RealNames in has it's own cache and I don't want the overhead and potential conflict that comes with having two caches.
Such an option can of course also be useful if some module is using a really simple method of finding out the real name which isn't worth caching.
#2
While I haven't reviewed the (quite massive) patch, I can certainly vouch for its functionality. It works great!
#3
Couldn't the module just implement template_preprocess_username()?
#4
This is not a functionality that belongs in the preprocess - this is a refactoring of the current realname_supported_modules() function to behave more like Views and other established modules does when it comes to support cross-modules relations.
Currently realname_supported_modules() is hard coded - what this patch does is that it changes that to enable all module to itself tell whether it supports realname or not. This patch also changes the currently supported modules to use this new approach instead.
Currently only realname can implement support for realname - what this patch does is that it makes it possible for other modules to support realname as well without having to hack that support into realname.
#5
Here's a patch that's been updated against the latest version of the 6.1 branch...