Posted by ben.on7 on November 27, 2012 at 1:18am
Greetings,
I was wondering if there would be any particular issues with just running some code as an include, and using a few custom queries and functions to interact with Drupal tables.
I like to use modules, but I would prefer to use Drupal for permissions, publishing, and user management, and then just create my own queries and functionality without creating a module. I like views, and a lot of the modules, but some of them are too cumbersome for my purpose.
Any thoughts?
Comments
Drupal is a Content
Drupal is a Content Management Framework (CMS). This in contrast to a Content Management System (CMS), such as Wordpress. The difference is that Drupal has an underlying framework, on which functionality is built. People take advantage of this framework, develop modules, and post them on Drupal.org as contributed modules. There are (currently) about 10000 modules on Drupal.org, meaning that site builders can make extremely flexible sites using these modules. Using modules this way is using Drupal as a CMS. The modules are built on the underlying framework, but the site itself is built using modules.
There is no requirement to use contributed modules however. It's possible to use Drupal as a framework, and develop your own code entirely off that. There are many, many APIs provided by core that can be used to do pretty much whatever you want.
Drupal itself however is modular, meaning it works off a series of modules. So even if you are using Drupal as a framework, you will still be using modules, they will just be your own modules, not contributed modules.
Personally, I mostly use Drupal as a framework. That said, I still use a number of contributed modules on each site. But where a developer using Drupal as a CMS may need to download four modules to get some functionality out of a fifth module that depends on those four, I will develop the functionality that fifth module would give myself, so that I don't have to use four modules, none of which I may need for anything else.
For the systems I build, I generally have the following:
1) Core
2) A few contributed modules
3) A site-specific module that I develop, in which I put all custom code relating to that site
4) A theme, containing theme specific code that doesn't need to persist when I switch to a new theme
For #2, I balance the time it would take to develop a piece of functionality with the availability of existing modules that could provide the same functionality, the state of development of said modules, and the weight they would add to the system (compared the weight of developing the functionality myself).
By keeping all site specific code in #3, it limits the number of modules needed for the site, which keeps the overall page-load weight down.
The above list is not actually complete. I should add:
5) Modules I develop that are site-agnostic
I develop multiple Drupal sites, so if I am building code that I know I will use on another project at some point in the future, sometimes I create a separate module, making it portable. For example, I develop sites in Japan, so I built a module that creates a field, using the Field API, allowing for an AJAX based hierarchical selection of a location in Japan. It drills down from prefecture to city to ward. I knew I would need this on multiple sites, so when I built it, rather than including the code in my site-specific code, I created a separate module to provide the field.
So to summarize, Drupal is a framework, with many contributed modules which are very beneficial. It is also a framework, and can speed up your development process when using it's APIs. You can build a site on Drupal entirely using contributed modules, or you can build a site entirely using the APIs, or you can use a combination of both.
Jaypan We build websites
Just a minor note: #3 is ok
Just a minor note:
#3 is ok for small sites that won't grow. The moment you got several pieces of functionality completely unrelated to one another (eg. one is a form with its page callback and validation + submit handlers, the other one is a "follow this user" button block thing), or if the site has the possibility of requiring more features or features that change, it's best practice to create a module per functionality. In the example given above, it means one module for that form + callbacks + handlers, and another module for the "follow this user" button block thing. It makes maintenance a whole lot easier. But yeah, for small business card-like sites, one single module with all the custom code in it, will definitely do.
I disagree. I maintain a few
I disagree. I maintain a few complex sites under that exact model. For a developer who knows Drupal hooks, with commented code, it's not particularly difficult to maintain. If everything is split up into separate modules, it adds weight to each page load, and for particularly high traffic sites, it's best to keep each page load as light as possible. Adding more modules for simpler maintenance is prioritizing the developer over the user.
But, as always with Drupal, there are 10 ways to do any single thing, so each developer will prioritize in their own manner.
Jaypan We build websites
.
If I'd keep all my custom modules for one of my biggest sites in one module, that module'd easily reach 10K lines of code. The overhead of that on each page load is bigger than the overhead of several modules ;) Each case is different, which is why I said that your #3 can in some cases be better as several modules.
Well, 10,000 lines of code is
Well, 10,000 lines of code is 10,000 lines of code, whether it's in 1 file or 10. Each .module file is included on every page load, so spreading it out between multiple .module files just means including more .module files, the amount of code will still be the same.
But, this is what include files were made for. For the most part, I only keep hooks and regularly called API functions in the .module files, with everything else being in files that are included on relevant page loads. This is more important than splitting it up into multiple modules.
Jaypan We build websites
.
Didn't really think of it including it every page, so... ya got me there ;)
Indeed about splitting the files up. I even split the hooks up into separate files, so the .module file holds only the most necessary stuff (like callbacks where I'd otherwise have to pull some stunts to get the include file). I find it the easiest (and lightest) to have the .module file as a point of entry, so even without reading the documentation, others looking into my code should be able to find out where to start and follow from there. Too bad I learned doing this the hard way :P There are more than enough tutorials about PHP, SQL, the Drupal API, performance, security and what not, but never about properly organizing your code, so the hard way is, sadly enough, the only way.
I'm with you there. I learned
I'm with you there. I learned the hard way on most of this stuff myself!
Jaypan We build websites