Blog

Drupal developers will always have their own style of coding, and module file structure conventions. On a project where there are two or more developers, it can be beneficial to have a unified way of structuring your custom modules.

One of the reasons why I prefer structuring custom modules is because it makes it easier to find functions or block of codes when debugging.

When all the team members’ are using the same file structure, it is easier for each of them to jump in and help each other debug things if needed.

If there are people on your team who don’t code the same way no worries. Simply having the same filename conventions, and placing functions in different files, in the same manner, makes your project more organized and easier to maintain in the long run.

Here's an example of a file structure that I have used on one of my projects:

module_name
-cck_content_types(exported content types, if necessary)
-js
-css
-images
-includes
-templates
--blocks
--views(overridden views template files)
--others

Note that there are folders for templates, java script, style sheets, and image files. When I develop a custom module, I try to make it as independent as possible, so I can reuse it in other projects if applicable.

Here's an example of a file naming convention and how to organize files, which I have used myself

module_name
-cck_content_types(exported content types, if necessary)
-js
[module_name.do_something.js]
-css
-includes
[module_name].helpers.inc (function that are called across multiple files/modules)
[module_name].forms.inc (form functions and submit handlers)
[module_name].ajax.inc (ajax callback functions, if applicable)
[module_name].ws_api.inc (web service functions, if applicable)
-templates
--blocks
--views(overridden views template files)
--others

Note that “private functions” are placed in the file in which they are invoked.

Different projects may require different styles of custom module organization. Having said that, using the same file structure, within the team, provides a greater benefit to the project, making it easier, organized, and all team members are on the same page.

You don’t have to follow my examples; however, it pays to keep my suggestions in mind before you start your next project. The more organized you are, the better it is for your project.

If there is an alternative example of how you can better organize your custom modules, feel free to share.