Introducing Author Pane - A module born from uncooperation
Posted 12/21/2008 - 21:13 by Michelle
There are a lot of modules that make up a forum in Drupal. Advanced Forum attempts to make it easier for users by allowing many of those modules to have their stuff show up in the author section of the forum posts. It does this by making use of the preprocess system built into core of Drupal 6 (and backported into Drupal 5). For those not familiar with the preprocess system, it's a wonderful thing. For any template file on your site, any module out there can add variables to it just by implementing the preprocess hook. In this case, I'm dealing with the "author pane" template which is used by both Advanced Forum and Advanced Profile Kit. So all those modules out there only need to implement one preprocess hook and, viola, both modules get their goods.
In theory, it's an excellent way for one module to add their stuff to another. In practice, it failed miserably. Two months ago, I filed issues in seven queues (and an eighth added a bit later) giving them the hook code in a file they only needed to drop into their directory and commit. I did everything but push the button for them. All they needed to do was add this hook and their users could get their stuff into the their forum posts and profiles with no effort. I expected the maintainers would be happy I made it so easy for them.
Instead, I was mostly ignored. Two of the modules weren't interested because they're an API, though one of them finally consented that the module implementing the hook should be the one holding the code, API or not. The other offered to put it in one of their sub modules, which I was fine with, but then they never followed through. I realize everyone is busy and wasn't expecting instant results but it's been two months of users being confused, trying to understand how to get the data from these other modules to show up in their forums. Two months of me telling them they need to add the file manually because the maintainers haven't done it yet.
Finally, I had enough. Because this needs to work with both Advanced Forum and Advanced Profile Kit, pulling the hooks back into AF wasn't an option. This would make APK dependent on AF, which was unacceptable. Trying to put them in both modules would result in namespace collisions and, even if I if tested around that, tons of duplicated code. So, grudgingly, I decided the only way out of this was to create a third module.
Enter Author Pane. This module exists just to be a dependency of AF & APK and hold the code the other maintainers wouldn't touch. It seems silly to create a module to implement hooks on behalf of other modules but it was the best I could come up with. As of the next releases I do, both AF and APK will depend on this module. It seems strange to be sad about releasing a new module, but it's a sad situation. I'm very disappointed that it came to this. So many people give lip service to wanting better forums and better profiles with Drupal and, when I try to make it easier, I'm met with silence and outright resistance. What ever happened to cooperation?
Site contents are licensed under a 
I've had *very* similar experiences as you. I now check out the issue queue and/or contributor(s) on a project before filing an issue/patch most of the time.
Realize that's not much offering much in the way of a better community-based solution (don't really know what to say for that), but I have been beating my head on the wall less and getting more done in lesser amounts of time. :p
In cases like that, can you simply request permission to make the desired commits yourself?
I think it is a common practice. First you create a submodule which implements all the necessary hooks for other modules to work nicely with your module. You solve it "inhouse" first, and when you think the code is perfect then you try to make a common goal with other module authors you try to work with..
here is an issue for example:
http://drupal.org/node/286336
The module works with 3 other contrib modules (and there are some patches for other module integrations in the issue queue). The code works nicely, but I would not push the code to other module maintainers yet..
@Caleb - Wanting to just get it done is how I ended up with this module. That gives me control over the code at the expense of me having to chase the code changes in 8 modules I don't maintain with more sure to come.
@Christopher - While I have the access to do that, that would quickly get it removed. Adding things to another project without the maintainer's permission is just not done. Unless the maintainer abandons the module, they are the final authority on it outside of security issues.
@Pasqualle - In this case the function is different for each module. And there's really not much too the code. It's just a small preprocess hook that generally assigns the results of one of their functions to a variable. That's it. Not worth making a module out of each one. So I've got one module that has hook implementations for a bunch of other modules which is crazy but gets the job done.
Michelle
@Christopher - While I have the access to do that, that would quickly get it removed. Adding things to another project without the maintainer's permission is just not done. Unless the maintainer abandons the module, they are the final authority on it outside of security issues.
Wrong. If you are added as a co-mainter of the module by the module author then you have cvs access and can therefore can commit updates to head. Then you can obviously release a new version of the module on the project homepage. Done.
Wrong. If you are added as a co-mainter of the module by the module author then you have cvs access and can therefore can commit updates to head. Then you can obviously release a new version of the module on the project homepage. Done.
I think you've misunderstood. A co-maintainer is a maintainer. Obviously she is not a co-maintainer of these other modules, so there is nothing wrong about what she said. She is not a maintainer (co- or otherwise) but technically has the access to arbitrarily add code to a project because of permissions on drupal.org in general. She, quite rightly IMO, feels that it would be an abuse of those privileges to add code to someone else's project without their consent.
At least, that is how I understood it.
I'm sorry to hear of your frustration, Michelle. Although I'm not a forum user (of any sort) on the sites I maintain, I've heard nothing but good things about your work. Sometimes things don't work as well as we imagine them in open source communities. Keep your chin up; most folks appreciate your efforts.
Hi Michelle,
After reading your reply and re-reading my original comment I realized that I didn't do a very good job at all of making it clear that I actually agree with, and also use the basic approach that you outlined here! (e.g., roll your own module and be done with wasting a lot of time and energy on uncooperative people) :-)
Michelle, have you considered the other side of it? If someone came along and demanded I implement a patch so that their module would work with my module, I would be a bit hesitant. I don't know the specifics of your case, but it could be that the other developers did not see the value in increasing their codebase just to allow their module to work with yours. I don't think it's fair to call other coders uncooperative just because they don't do what you want them to.
Besides, Drupal allows code to be cooperative even if coders aren't - as evidenced by the fact that you solved the problem without them committing your patches anyway.
@drawk - Yes, that's what I meant. I have access to add myself to cvs for any project but that would be a serious breech of trust and I would never do that.
@Chris - Thanks. :)
@Caleb - Yes, it's just unfortunate that I needed to do it. I really thought this would be a no brainer. I'm all about making modules work together so I was really stunned by the response I got.
@Garrett - Yes, I have thought about it. I maintain two (now 3) modules and if someone came along and asked me to add just a tiny bit of code to make life easier for our joint users, I would do it. We're not talking huge chunks of code here. And the code is all function calls to the module that I wanted to add it.
I'm trying to avoid naming names here so let me give an example. Module foo calculates a user's foo status. It's a nice module that a lot of people use but showing the user's foo status requires the site admin to add this to their node template:
<?php$uid = $node->author;
$account = user_load(array('uid' => $uid);
print foo_get_status($account);
?>
That may not seem like much but it's scary to non programmer admins. So I come along and say to the foo maintainer, hey, just add this to your module:
<?phpfunction foo_preprocess_author_pane(&$variables) {
$variables['foo_status'] = foo_get_status($variables['account');
}
?>
That's it. Just a tiny little bit of code that is all about the foo module. For my part, I add the printing of the $foo_status variable right into the template I provide so the user doesn't even need to add that.
Sure, I could put the code I wrote to begin with in both of my modules but then when the foo maintainer comes along and decides it really should be foo_get_statuses and return multiple statuses, I need to go change both my modules. Whereas the foo maintainer, having put this code in thier module, could simply do:
<?phpfunction foo_preprocess_author_pane(&$variables) {
$statuses = foo_get_statuses($variables['account');
$variables['foo_status'] = implode(',', $statuses)
}
?>
Then neither I nor the end users need to change anything. That's maybe not the best example because the end user might not be thrilled suddenly having a list of statuses shown there but it was what came to me off the top of my head.
At any rate, the point is that the foo_* functions are all in the foo module and all I need to do is print out the variable they create. Maybe I'm alone in this but I think that's a much better system than me having to track the APIs of every module that wants to add data to AF & APK.
Michelle
It occurred to me that some might say that I could change what I call my function as well. And that's true, but there's a big difference. If foo_status() no longer exists and I call it, the site crashes with an error. If author_pane becomes author_polka_dots, there's no crashing. foo_preprocess_author_pane() simply never gets called. The users would lose their foo statuses and scream at me and it would be up to me to fix it since I broke it, which is fair. If their sites crash because the API I'm using changes, who's fault is that?
Michelle
This has happened to me once or twice with my own module (dhtml_menu).
I was going to write a reply here, but it grew out of proportion so much that eventually I put it into a separate post on my own blog.
To summarize: The lack of cooperation between module authors is in my opinion a result of the "module ownership" system where every developer is personally responsible for what happens in their module. No developer wants to take on the responsibility of implementing and maintaining compatibility with a "foreign" API.
This could perhaps be solved by giving all projects "contrib" sub-folders that are universally open to all (like "translations"), so that developers can extend a module without having access to the code itself...
Not sure I wouldn't have done the same thing, actually.
I've added code to modules I maintain to act as "bridge" code before at the other module maintainers' insistence. The inevitable result is that my queue starts getting filled with support requests for this piece which I am not able to address, since I don't use the other piece myself. And when the time comes to upgrade the module to the next Drupal version, that original supplier of that code never comes back to upgrade their piece, so everything gets stuck in limbo.
Yes, the piece is "simple" for now, until someone logs a feature request to add an additional variable here, or format the results slightly differently there, or wants to know how to get it to work with $some_other_module there. If these requests were spread out over 7-8 issue queues, it would be a complete nightmare.
So basically, I'm not sure why this approach wasn't taken in the first place, since it's the most logical thing to do, imo.
I give up. If even webchick thinks me writing a module that declares functions on behalf of modules not under my control is the "most logical thing to do" then so be it. Personally, I think it's silly and will continue to do so. I don't know what more to say on it.
Michelle
Michelle,
You are one of the most importnat members of the Drupal community!!!
I just wanted to THANK YOU for all your effort.
Please keep up your excellent work and don't desist.
We selected Drupal thanks to YOUR modules.
THANKS
Thanks, Rod. Don't worry, I'm not giving up Drupal. This situation made me sad, but I made the best of it. And I think Author Pane might be a useful little module on its own. So it all worked out in the end.
Michelle
Hi Michelle!
Thanks for your reply!
I am glad you're still putting all the energy into Drupal.
I wasn't overstating what I said in the last mail that we actually choose Drupal because of your modules.
One of the developers that works with me (we actually started learning Drupal together), even placed a "Thank you Michelle" on our development site, as you were our guide for most of our development. When we were selecting between different technologies, and we were stuck between the comparisons, we even worked with the "rule" : 'if Michelle has used that solution..". We're really couldnt have done everything we achived without your Advanced Profile, and Advanced Forum.
THANK YOU and please keep up the great work.
I hope you can finish the final versions of AP, AF very soon.
Best,
Rod
Awwww. :) Thanks so much. Posts like this are wonderful to wake up to.
I'm getting closer to the final versions. I had hoped to have them out by the end of the month but won't make that. Definitely in February, though.
Michelle
I'm sorry to hear of your frustration, Michelle. Although I'm not a forum user (of any sort) on the sites I maintain, I've heard nothing but good things about your work. Sometimes things don't work as well as we imagine them in open source communities. Keep your chin up; most folks appreciate your efforts.
Thanks. :) It's worked out ok in the end. AP is turning into a nice little module that can be used alone even. It's still a pain having to keep on top of other peoples' APIs but what can you do?
Michelle