Contrib Development Best Practices

Is there a standard for keyboard activation of drop-down menus? We are using multiple drop-down menus from various sources which behave differently from one another. Technically speaking, each individual jump menu is WCAG 2.0 AA accessible because it can be navigated keyboard-only, but the technique for opening the menu varies from menu to menu.

I can't imagine that to be a pleasant experience for site visitors, but I also can't seem to find documentation from an authoritative source for a standard menu-open behavior that could (theoretically) be applied across all drop-down menus.

Is there a standard? Where is it documented? If there is no standard, is there a way to force a single behavior across incompatible drop-downs or else enable forgiving actions? If not, is there a reasonable way, e.g., through appropriate ARIA labeling, to communicate the correct way to access a particular drop-down menu without forcing the site visitor to figure it out for themselves?

I despair of keyboard-only visitors being able to achieve mastery of drop-down menus on websites.

Details follow:

I noticed the following language in the hook documentation comment of a module hook-alter:

Function that fungates as last resort to alter the pre_render build.

/**
* Implements hook_field_group_pre_render().
* Function that fungates as last resort to alter the pre_render build.
*/

The only definitions I can find for "fungates" have to do with fungus, which I doubt is what is intended. But I get lots of search results if I search on Drupal and fungates, so it's apparently in common use.

Having reviewed a module recently within the Security Advisory Coverage application queue, a discussion came up of whether hook_help() must be used or should be used to comply with the module documentation guidelines.

The guidelines state

All but the most trivial modules should implement hook_help().

in bold letters.

I'm wondering what is the best practice for creating new releases of modules and deprecating the old version, in terms of maintaining security while the new version proceeds to release status. I'm asking this as a Drupal newbie.

This group looks defunct and will be merged or deleted in 1 week.

Especially with the availability of sandbox projects, and the frequent pushing of code to places like github this seems a solved problem.

I'm referencing the Drupal Markup Style Guide g.d.o wiki in the Definitive Guide to Drupal 7 and it hasn't been updated in a couple years so i wanted to give all interested parties, especially HTML5 folk, foreknowledge to update it (or link it to a d.o equivalent?).

Advice is sound and it's the most comprehensive take i've seen from a module developer's perspective, so that's why i'm providing the link: http://groups.drupal.org/node/6355

Hi Drupalfolk -

I documented a bunch of the ideas/discussion points from Dries' D8 core convo on a blog post:

http://affinitybridge.com/blog/drupal-8-git-sprints-efficient-smooth

I am considering making a page/section in the Initiatives section on d.o but would really like a bit more input first - I got a lot of positive tweets and a couple more detailed comments, but I still am not sure exactly how much support there would be for this, nor how much more detail would need to be hashed out for it to become a method that people would be comfortable experimenting with.

Modules are grouped on the module administration page (admin/modules in Drupal 7) by package, which is defined, optionally, in our module's .info file. Package, then, is the most visible way in which modules are categorized. This wiki page documents package names chosen by module maintainers, please edit it!

Modules are grouped on the module administration page (admin/modules in Drupal 7) by Package. Sensible grouping can greatly enhance site builders' Drupal experience. (Package is defined, optionally, in our module's .info file.) As developers of contrib modules, we can come to this wiki page before choosing our package name to see what other thoughtful module developers have chosen for their package.

A ping in #drupal-docs earlier has brought to my attention that the Docs style guide only applies to handbook and not explicitly to interface text in Drupal core/contrib.

I'd think it should apply so we get consistent text and grammar formatting Drupal-wide, but didn't want to make such a sweeping declaration without some consensus from the community at large.

I posted this question yesterday after seeing some contrib code (not yet submitted) which included HTML tags to track module installations.

I'd appreciate any pointers or feedback on the practice, and how we can educate contrib developers about what practices are and aren't acceptable in code hosted on Drupal.org.

I don't know of any specific security or privacy policy this practice would be forbidden by, even though to me it seems clear that the practice wouldn't be acceptable.

Thanks in advance!

http://twitter.com/grobot

hi,

usually the hook "hook_node_access_records($node)" gets called when you hit the save-button on the edit page of a node. I need to call this function outside the edit-form.

I'm building a custom content-privacy module and I need to call this function for all existing nodes filtered by content-type (for example all blog nodes).

The problem I have is that this hook needs a node-object as a parameter. When being on a node-edit page (node/[NID]/edit) this object will be available. But when I don't edit a node I have no node-object available.

I'd like to get some of you great people to give a panel discussion on best practices. Here's a proposal - edit it! Who would be willing to lead it? Who has something to offer?

Session Proposal: Best practices in Contrib development and support

Contributed modules and themes are fundamental to the Drupal experience, but the quality varies oh, so widely.

How can we improve our development process, keep modules maintained, help maintainers, and somehow harness the explosion of modules.

This forum will cover:

• What's expected of a module maintainer
• How to keep the modules you maintain from overwhelming you
• How to get help from others
• Finding maintainers, abandoning projects, dealing with abandoned projects
• Best practices in CVS, including when to branch, and how to maintain branches
• Best practices in patch issue workflow
• Best practices in the issue queue: How to enlist the community, deal with support, and deal with newbies.
• Avoiding duplication in contributed projects

So, I've got a question pointed by a services module discussion.. What should be the best practice for contributed module versioning when Drupal version is updated, keep current contrib versioning?

Here are some notes from a discussion with greggles that influenced me on managing commits and patches:

• Every commit should be matched with an issue that has a patchfile, just as would be done in core.
• Every commit should give credit to the contributor of the patch, and a link to the patch. This page gives a great summary

This can seem hard to do in a rapidly developing project, but it gives great discipline to the code.

There is a standard Drupal (and maybe everywhere) methodology for managing a project in CVS, but not all of us know about it.

• Always do new development on HEAD.
• When the time comes to leave a branch behind (as when beginning Drupal 7 development) branch off the old (like D6) stuff. Continue working on HEAD.
• You can apply patches from HEAD onto other branches, if you have other branches going.

This is the approach described in the fine Pro Drupal Development.

Please add to this.

Drupal Coding standards

Follow the [Drupal coding standards] (http://drupal.org/coding-standards). The coding standards provide information on code syntax, white space in code, and currently more development detail than this wiki page.

Required Files

When a module gets too long it is wisest to break up a custom module into the following files:

• MYMODULE.info - Module declaration file.
• MYMODULE.module - for Drupal hooks like hook_menu, hook_forms, etc.

Additional Files

HAHA, welcome everyone, been a while since I checked this group. So, here's the basic need to get us going. I'd really like to put our heads together and start to put a list of features that would be needed for this sort of thing, together. Let's get it started, and we'll see where it goes from there.

Obviously we need some serious taxonomy controls to help make code easier to find and categorize. I'd like to start off by asking what sort of scheme you all think might work best here.

Eclipse

So I'm at DrupalCamp UK and the topic of this site has come up again.
Lots of developers mention cool modules they've written in-house but aren't releasing because they're too specific to their projects or too raw for a release.

A space where these could be released without too much expectation would mean the next person who needs this feature doesn't reinvent the wheel, but instead can give some time to pushing the code a little more towards being generic and ready for release.

So let's think about use cases for the Wastelands and the spec we'd need.

I think there is a huge potential in this idea.

There are lot of modules on d.o that are not maintened, and lot more code never published.

A true "recycling drupal code factory" could have several benefits :

To allow the drupal community to better understand the general needs behind lots of "custom modules", reuse some code but also some conception work.

For the beginners users of d.o, a smaller list of contributed modules really maintened instead of a large list of 2000 modules with lot of weird modules would be a huge time saving.