Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.This documentation describes a best practices process for Community Media module co-maintainers to make changes to modules. Because the Community Media Starter Kits are used as a base for building websites the serve the needs of group with varying sizes and workflows, it is important to understand how other people are using these modules and keep changes from negatively impacting other users.
It is important to give both the individuals and organizations actively contributing credit and well as recognize that...
- station staff play an important role... great modules don't come from just a developer
- these modules are part of a larger package/project
- there is a community already committed to contributing and new users should follow their lead
To do that, every project that a station staff member is willing to help maintain should give that user credit with a statement similar to this...
<hr>
<em><strong>This module is co-maintained by [REAL NAME] (<a href="https://drupal.org/u/[DRUPAL USERNAME]">[DRUPAL USERNAME]</a>) of <a href="[ORGANIZATION SITE]">[ORGANIZATION NAME]</a> in [ORGANIZATION LOCATION] as part of the <a href="http://www.cmdrupal.org">CMDrupal project</a>. It is designed to be used with other modules included in the Community Media Start Kit ([LINK TO APPROPRIATE DISTRIBUTION... <a href="http://drupal.org/project/cm_starterkit_easy">Easy</a> and <a href="http://drupal.org/project/cm_starterkit_moderate">Moderate</a>). Consider joining the growing community who have <a href="https://drupal.org/node/1860560">made a commitment to contribute</a>.</strong></em>
<hr>
Things All Maintainers Should Do
1) SUBSCRIBE TO EMAIL ALERTS FOR THE PROJECT
One way we keep updates working for everyone is to discuss potential changes openly using the module issue queues on Drupal.org. Every change should start with a problem someone has reported or a feature request. If you are interested in any changes to a module, subscribe to All issues added to the queue via email.
2) LEARN DRUPAL.ORG SPECIFIC MARKUP AND PROTOCOLS FOR WORKING ISSUES IN THE QUEUE
Drupal.org automatically links issues color coding based on the status if you use this format in body of an issue or on the project page...
[#12345]
Make sure there is an item in the issue queue for the problem. When making a commit using git use the node number without the brackets. Just #12345
Once you have successfully tested a patch and determined that it fixes your problem don't just set the issue to Closed, instead set it to RTBC. This will signal the maintainer that the patch or fix can be rolled into the latest release. Only after the patch or fix is included and a new release rolled should the status be set to Fixed. This final step will trigger drupal.org to automatically close the issue after 2 weeks without further activity.
3) CREATE A TEST SITE
All code changes should be created and tested on the development version of the site, and not on the live site.
4) LEARN THE BASICS OF GIT AND APPLYING PATCHES (advanced/optional)
Make sure you are working with the latest version of the code
Clone your live site to the development site before making any code changes and make sure that the module version being changed is the same as the latest module on drupal.org.
After you have tested and are satisfied with the code changes to the module on the development site, copy the entire module directory to you local machine where you have git and/or SmartGit installed.
The command line git instructions can be found for every module using the Version Control tab on the project page or going to https://www.drupal.org/project/[PROJECT]/git-instructions
Installing Git
Drupal.org maintains excellent instructions for installing Git on most operating systems as does GitHub/
Installing SmartGit
If you don't have SmartGit, it is free to use for non-profit work. SmartGit still requires git be installed (see above).
In SmartGit navigate to Project > Open Working Tree enter the path to the edited module directory and enter Continue and then Finish
Click on the Changes icon to inspect and verify the changes between your edited version and the most recent commit.
When satisfied with this changes, click on Commit. In the comment area enter the issue number #12345 (the issue number will automatically be linked in the commit message on Drupal.org).
Then click on Push and enter your Drupal username and password. When this process is completed, you should see the commit recorded on the module page on Drupal.org
The next step is to upgrade your live site with the latest dev snapshot of the module. It can take up to 4 hours for Drupal to package a new dev snapshot, but it often happens in < 30 minutes.
5) BE ABLE TO PACKAGE A NEW RELEASE OF A MODULE (advanced/optional)
Once the dev snapshot of a module is working well, it's time to package a new version.
The command line steps for adding a tag with git for a new release of a module can also be found using the Version Control tab on the project page or going to https://www.drupal.org/project/[PROJECT]/git-instructions. They are at the bottom of the page.
Using the command line, navigate into the module directory. Then type...
git tag 7.x-[VERSION]
git push origin tag 7.x-[VERSION]The [VERSION] are restricted to release naming conventions, but in most cases you will be incrementing the previous release. So if the current supported release is version 1.1, the tag would be 7.x-1.1. If you are still indicating that the module is in alpha or beta release, you might be moving from 7.x-1.0-beta1 to 7.x-1.0-beta2.
SmartGit
NEED TO ADD STEPS
Once the tag is pushed, you must tell Drupal.org to package a new release. To do that, go to the project page. If you are a co-maintainer with permission to create releases, you will see a link to "Add Release" under the downloads. Clicking that will show a list of tags that have been committed and pushed to git that do not yet have a packaged download.
Select the tag you added.
Next you will be given the option of adding a description of what's in the release. Best practice is to use the [#123] where 123 is the node number of an issue that has been resolved.
Most releases will either be a Bug fix and/or New Features. DO NOT use Security release unless specifically told to do so!
Once you save the release form, Drupal.org will package the release and update the project page with the latest version. Sites using the Update module will then be altered of the update.
