Once you have a working site setup, you are ready to start creating modules. You should make sure that your text editor of choice is correctly configured for Drupal development using Drupal Coding Standards as a guide.
A Drupal module needs at least a .info file and a .module file. At minimum your .info file needs:
name = Module Name description = A description of what your module does. core = 7.x
For the WCMS, the naming conventions for modules typically include the type of module and the name. Not all modules will have a type. If you are developing for your own site, you can generally follow the uw_<area>_<module name> format. For example, a module from the Library might be named uw_lib_biblio_search.
Here is a link for creating a Drupal 7 module from Drupal.org: https://www.drupal.org/node/1074360
Once you have a module created you will want to upload it to your server. Depending on the code editor you are using you may be able to use that, otherwise, you can use file transfer software such as Filezilla.
Connect to your server and upload the module files to your site folder, for example:
$ /var/www/drupal7/sites/d7.fdsu1/modules/<your module>
You can then either go to https://d7/fdsu1/admin/modules and find your module on the list and enable it, or use a Drush command (if you are logged into your local server using putty, and are located in your site folder).
$ drush en <your module name>
Once your module is enabled, go to your Drupal site and make sure that it is functioning the way you expect and it isn’t causing any unexpected behavior.
In Drupal, numerous configuration settings are stored in the database which can make it hard to share something you’ve created on your site with other sites. Luckily there is the Features module that allows you to take a setting you have created on your site and “featurize” it, so you are then able to put it in Git so the WCMS team can test it and add it to your production site.
To featurize a module, go to: https://<servername>/<sitename>/admin/structure/features/create
You will give your feature a name, because the name box it will show a machine name with “edit” beside it. Click on “edit” and that will bring up a machine name box. The machine name would follow the same format of naming a wcms module (e.g. uw_mymodule or uw_cfg_mymodule ). You should give a short description so users (and WCMS devs) know what to expect when enabling the module. Package allows you to group your modules on the features page so you can easily find similar modules. The default is Features but you should change it to uWaterloo <mydepartment> or use one of the pre-existing uWaterloo groups that makes sense for your module. Leave the version number blank. You shouldn’t need to worry about any of the “Advanced Options”.
On the right of the page are a series of closed dropdowns that will contain all the available items that you can featurize. You need to select all the ones that pertain to what you are trying to do. So, if you created mymodule and had a mymodule permission, under permissions you would look to check off the mymodule permissions. Once you feel you have captured all the necessary items you can featurize your module by clicking “Download Feature”, which will then download the feature to your local computer.
Once you are happy that your module is ready for review by the WCMS team you should run it through the Coder module within your Drupal site. To do that, on the Module page make sure that Coder is enabled, then beside your module you should see a button that says Code Review. If you click that button it will give you a list of any coding standard issues with the module. Once those have been taken care of it is time to commit your code to a Git repository (if you haven’t already done so). Next you will need to upload your module to git.uwaterloo.ca in a publicly accessible repository. Once you have it committed, you can submit an RT to have someone on the WCMS team review the module.
Sometimes there are numerous ways to do the same thing in Drupal and the WCMS will sometimes use a specific method as a standard for our sites. For example, within the WCMS blocks are placed using the Context module instead of the Blocks module.