Contrib developers often need some help figuring out the best way to maintain their modules, both strategically and tactically.
This can include (but is not limited to)
- git best practices in contrib (branch naming? How to commit patches? How to commit my own work?)
- How to manage the issue queue
- How to deal with difficult people in the issue queue.
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.Read more
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:
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.Read more
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!Read more
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.Read more
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.Read more
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.
Thanks in advance!
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.Read more
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
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.
Last updated by Chris Charlton on Wed, 2010-01-06 19:01
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.
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 FilesRead more
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.
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.Read more
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.Read more
So I came here expecting a list of a bunch of modules that has been tossed out as incomplete/un-generalized. Found nothing but a poll. Hrm.
So the thought then is, how do I get a list of modules that are categorized in a way that I know that they either a) need work or b) are specific to a private company's needs but released for other to at least peruse/hack/learn from/or throw away?
I don't think we can actually just list them here...
I don't think that we should really just throw them up on d.o (read: http://drupal.org/node/307211)...