Join Jon Peck for an in-depth discussion in this video What are modules and why use them?, part of Drupal 7: Custom Module Development.
Before I describe what modules are, let's explore the Drupal architecture at a high level for some perspective. Drupal is referred to as a Content Management Framework or CMF. A CMF is an application programming interface that can be used to create and customize a Content Management System. What does this mean practically? Drupal out of the box, consists of a number of components that can be used to build a website, but assembly is definitely required. This is different than a straight Content Management System such as WordPress.
WordPress is extremely good at building blogs and minimal websites and has been optimized to do just that. As a result, you can get a blog up and running in WordPress very quickly. There is a cost though, while WordPress and the other similar blogging content management systems do have the ability to be extended, they are purpose-oriented. Often the technical needs of extending functionality outweigh the capabilities of the core system. In contrast, Drupal can be used to create websites in many different scales. From simple sites such as brochures, blogs and portfolios, Drupal can also be used to scale to full enterprise grade applications with hundreds of thousands of users.
This flexibility is a double-edged sword. A core Drupal 7 installation is kind of like opening a box of building blocks and dumping them on the floor. There may be some recognizable shapes and some instructions on how to build a simple structure, but as a whole, it can be intimidating. Then focusing, one can see that each building block can connect to one another and experimentation and construction begins. With a context of what Drupal is in its core, the purpose and use of a module becomes clear. A Drupal module refers to software components that extend the functionality of a Drupal installation in order to accomplish a particular task or goal.
According to the official Drupal module developer's guide, there are three distinct kinds of modules. Core modules, which are included with the Drupal distribution itself. Each core module is approved by core developers and the community. Core modules are already included within your site installation. Examples include, field, help, and user. Contributed modules which are written and maintained by members of the Drupal community and shared with the GNU Public License or GPL, as Drupal is. The official repository of contributed modules is found at drupal.org/project/ modules where close to 11,000 distinct projects are hosted.
Examples of contributed modules include views, pathauto, and backup, and migrate. And finally, custom modules which are created by individual developers. The licensing of custom modules can vary. Some are shared only within a company or group, while others are released freely on public repositories such as GitHub. Sometimes they can be a fork or a variation of an existing contributed module. Like Drupal itself, Drupal modules are written in PHP. For Drupal 7, PHP 5.2.5 or higher is required while PHP 5.3 is officially recommended.
Contributed and custom modules can optionally have external dependencies, such as a software library that needs to be installed separately from the module itself. For example, the Print module requires a PDF writing library such as TCPDF to be available. When there is an external dependency, the library or libraries in question are typically not included with the module itself. This is done for multiple reasons. Potential licensing issues can be avoided which is particularly important for GPO licensed modules found on drupal.org.
Additionally, it avoids duplication of effort and cluttered source control repositories by separating disparate components logically. To review: Drupal modules extend the functionality of the core Drupal installation. There are core, contributed, and custom modules. Modules can interact with third-party libraries, but are typically not distributed with the libraries themselves. Using modules, a developer can manipulate virtually every aspect of a Drupal system without needing to alter the source code of core itself.
One of the published Drupal best practices is never hack core. This cannot be stressed enough. Changing core yourself makes it virtually impossible to apply updates and upgrades that offer bug and security fixes along with performance enhancements. Second, it makes it harder for the next person. Maintenance of the site by others becomes difficult at best as they have to reverse engineer the hacks created by their predecessors. And third, it can introduce security holes. Security vulnerabilities can be introduced inadvertently, as a sole developer does not have the same oversight and peer review that core contributions receive.
There are thousands of contributed modules that are available under the GPL license. So before writing a custom module, one should use due diligence and check to see if a module with that functionality already exists. If it does, then leverage the existing model and don't waste time reinventing the wheel. If the solution does exist, but there are deficiencies or shortcomings, submit an issue through the project homepage on drupal.org describing the problem and ideas on resolving it. The Drupal community actively request that developers regardless of their affiliation, contribute code back.
So if there is an issue that you know how to resolve, please do contribute your code as a patch back to the project maintainer through an issue. Proper attribution will be given and the end product will be improved based on the collaborative effort. I will demonstrate how to build a custom module to solve a particular problem. Storing and rendering information about Wind Farms, then importing data from a public source to populate the system. Some contributed modules will be leveraged to save time and avoid duplication of effort. In practice, use freely available modules to get as close as possible to the necessary solution, then custom build the functionality needed to get the job done.
Let's start building a custom module.
- Creating your first module
- Interacting with hooks
- Working with permissions and roles
- Controlling access
- Adding a menu item to an admin interface
- Using the Form API (FAPI) to quickly create a form
- Creating custom form validation
- Manually creating a custom content type
- Validating user input
- Importing content using feeds
- Creating a block
- Understanding best practices and coding standards
Skill Level Advanced
Q: gmap3_tools is not working the way I expected it to. What version of gmap3_tools should I be using?
A: Use the free exercise file containing the version of gmap3_tools used for recording; the published version of the module on drupal.org has changed since recording and is not backwards compatible.
Q: I attempted to run the Drupal site root from the project files, but the site isn't loading. Why not?
A: The Drupal configuration file in sites/default/settings.php contains database configuration specific to the environment used to record the movie. This may be different than your environment. Edit the file and search for "windfarms" - you may need to change the database host, username, password, db name and port to match your specific environment.