inShare A sloppy mess is transforming into readable code by magic after reading the following Practically every Drupal site has a vast amount of contributed modules and even more of those in something large-scale. As an addition you may have written some of your modules and you may have been generating Features that are nothing but modules as well. What is the result? A hellishly large amount of modules to manage. What may your actions be? Sure one may simply grab them together and toss into the modules folder. But is it such a great decision? How will you be orienting between which modules are custom and which are contributed? It’s not even about that as you are bond to know which of your modules are custom but it may be a pain to simply browse through all that madness in order of locating one particular thing. That is why organizing all that into some relevant buckets is essential. Considering you will be adding more and more modules in the future I’d say this is the only way to go. Where is the module folder exactly? 1.|–sites 2.| |– all 3.| | |– modules 4.| | |– themes 5.| |– our example.com 6.| | |– modules 7.| | |– themes This here is how your setup is likely to look if you are running a multi-site install. Which means your module directory may be located in sites – all or sites – our example.com. This setup means all the themes as well as modules are of potential use to every site reside in sites – all. If a module is site-specific it will be stored in a relevant side older as our example.com. Here is one option that may assist you with maintaining things in order Let us call it Custom inside Contrib. This means that contributed modules will be inside the appropriate modules directory. The directory that goes by the name of custom is located in the very same folder and that is the place where custom modules are stored. 1.|– sites 2.| |– all 3.| | |– modules 4.| | | |– antispam 5.| | | |– custom 6.| | | |– cck This is fairly better than simply having all the modules in simply sites – all. Although this is quite clever, but is still not perfect enough. But, knowing the idea you may try something like 1.|– sites 2.| |– all 3.| | |– modules 4.| | | |– contrib 5.| | | |– custom 6.| | | |– dev-tools 7.| | | |– patches 8.| | | |– migration Or 1.|– sites 2.| |– all 3.| | |– modules 4.| | | |– contrib 5.| | | |– custom 6.| | | |– dev-tools 7.| | | |– features 8.| | | |– patches 9.| | | |– migration Or whatever approach that will satisfy your needs.