Development

Download

development@drupal.org

June 2007

123 participants
112 discussions

Modules up for adoption
by Jeff Eaton 01 Jun '07

01 Jun '07

With the work going into Drupal 6 development, work, and a number of other modules, I've been looking over my list of contrib projects and admitting that I simply don't have enough hours in the day to maintain all of them effectively. I'm actively seeking maintainers and co-maintainers for the following modules. Drop me a line if you're interested in any of them and we can chat. If you're familiar with Drupal code and want to make a splash, a number of them offer some cool opportunities. Maintainers sought * Akismet -- The Wordpress anti-spam API. Insert Block -- Inserts blocks in node bodies using [this] syntax Insert View -- Inserts blocks in node bodies using [this] syntax Latest and greatest -- Cast votes on aggregator items. Loves and Hates -- Cast votes on taxonomy terms * Node Moderation -- Complex role-weighted voting for nodes Related Nodes -- Taxonomy-based 'similar nodes' block Co-maintainers sought Custom Breadcrumbs -- Create customized breadcrumb trails for each node type Custom Links -- Add links to nodes without code * Custom Pagers -- Forum/Book/Gallery style pagers for nodes in views * VotingAPI -- A backend API for voting and rating modules Most of these modules would need someone with moderate Drupal familiarity, but aren't particularly huge or complex as modules go. Starred modules are more complex and/or tricky, and would need someone with experience working on other modules and solid familiarity with Drupal's APIs and code standards. Most of the modules in the 'Maintainers sought' category (Akismet is one exception) haven't been upgraded to Drupal 5, or are in progress; I just haven't had time or had the need to. Most of them (Akismet excepted, probably) will become unmaintained after the Drupal 6 release unless someone else wants to pick them up. Modules in the 'Co-maintainers sought' category are all running smooth on Drupal 5, but my attention is divided enough that patches, fixes, and new features only get sporadic attention. I'm hoping to find other folks who share a similar vision for their future directions. If anyone is interested, drop me a line. Thanks! --Jeff

1 0

$node namespace woes -- can we fix this in D6?
by Derek Wright 01 Jun '07

01 Jun '07

hello world, i've had a series of bugs in the project* issue queues[1] caused by the fact that the project* modules use $node->pid just like "pid" always means in the project* codebase: the project id, or the nid of the project node that the (release|issue|...) belongs to. however, book.module thinks $node->pid is the nid of the parent page in the book hierarchy. :( so, all hell breaks loose when you try to put a release node into a book outline. certainly other contribs might use $node->pid to mean all sorts of things, too, which would conflict with both project* and book.module. i could always just hack project* to always prefix everything it tries to stuff into or read from $node with some kind of custom variable name prefix, like calling this "$node->project_issue_pid" instead of just "$node->pid". however, given that the API isn't quite frozen for D6 yet, i'm wondering if there's anything smarter and better we could do via the core API, instead of relying on convention and luck to avoid this problem... 1) what's the right way to handle variable namespaces in the $node object? can/should we change hook_nodeapi('load') to force people to use a namespace of some kind when populating $node? maybe $node should be a nested array instead of an object, so that everyone touches: $node[$module_name][$variable_name] instead of just: $node->variable_name ?? that probably sucks for all sorts of reasons, i'm just quickly brainstorming here... 2) presumably this has come up before? anyone have pointers to relevant old issues or threads? i don't remember seeing anything like this come up before, but i've been known to miss the occasional thread on this list. ;) 3) anyone else interested in making a little push to try to do this for D6? 4) would the D6 core maintainers be willing to commit a patch if it materialized and was properly reviewed/tested/RTBC'ed? thanks, -derek (dww) [1] for the interested reader: http://drupal.org/node/98278 http://drupal.org/node/124846 http://drupal.org/node/145782

12 19