Working with Drupal Code
I have no clue how to code -- I know how to hack into code and fix things the way I want them... But I attended a gentle introduction session at the start of DrupalCon in Washington, DC. We started out with terminology so I don't feel so stupid. Addison Berry presented the first session I attended. There are 1400 people attending this event!
First and foremost, Drupal is a content management system. It helps you manage a website built onto a framework. Drupal was made to be flexible to do what you want it to do. The CMS framework that makes it so flexible are constructed from APIs (Application Programming Interface). It does all kinds of bits of code that let you do tasks so you don't have to hand code your website. It's wrapped up in a nice little package for you. Drupal has a ton of APIs that are built as "modules."
Here's when the discussion gets deeply nerdy. If you aren't interested in code... Here's what I learned. There is a step by step process that helps Drupal function. It looks for all of the things you want to happen with the site and then it delivers that content to the site's look or theme. If you think through what you want, the code comes together for you. If you build it and then try to make changes on top of your structure, things break. Also, the theme is more powerful than the actual code. It can trump the code... or the theme can fight the code. I'm pretty sure that's another problem I found during my Smart Decision '08 experience.
The sites folder that comes with a Drupal install is what you would probably mess around with. But the includes folder is actually worth looking into. It gives you the lay of the land and tells you what you're working with. (http://api.drupal.org information is all in this file. It's your own reference to explain things for you.) You can learn about the common functions of Drupal code. These functions are a little machine.
Drupal has a concept called "hooks." It's a naming convention. hook_* where hook is replaced by your module name. It lets you create a system where a module defines the system and another hook can connect with another hook.
Hook example: Think of Drupal of a train. It looks for a hook_perm function (each is a train car) in your module file. The API tells you what needs to go into it. Drupal searches through the whole site and grabs the items that have a hook_perm. Drupal grabs all of the cars (module perm files) and then it goes to the themes where you can snag alter functions. It's a step by step process to get the site to do what you want it to do. Once it gets to the theme, that's when it gets pretty. So once the site has all of the "look" and it delivers the content to a web browser. The hook system is why Drupal works... but it's also why it can be challenging if you try to fight the hook process. If you work from the beginning to build a site following the hook process... then you won't get in big trouble> Most troubles hapeen when you try to hook on extra stuff after you've built the basics of site. Ugly things happen... and that's where I hit major snags with smartdecision08.com.
Menu function (in the includes folder as menu.inc) - Drupal needs the menu system functions that make it work. The menu system is not the menu module. The system works like a router - that's how Drupal knows how to produce anything on your site. The menu system maps URLs to take you to that site. Without the menu system, the site won't work. The menu module is not needed - it's just the UI for you to graphically create navigation for a site. (most people don't turn it off)
Form API (FAPI) - is a "thing of beauty" but most people get scared. The form API lets you build forms on your site. Drupal FAPI - form.inc has all of the functions in there. It handles the form, validation and submission. Instead of building it with HTML tags, it is just an element in the array - a big PHP array for every single thing. Drupal takes that array information and turns it into the HTML for you. Why would you let Drupal do it? It doesn't just create a form, it does the security and verification for you as well. The idea is FAPI takes care of all of the security stuff. You just list out what you want in the form and Drupal takes care of it for you. Drupal has your own default and submission process. You can change it to have required and non-required elements. You have complete control when you build your own form module. When you're trying to alter a form someone else built, you can go in it and tweak it (which is how I do anything in code). It's great when you know what you're doing... frustrating when you don't. But once you get it, it's a much easier way to build forms.
Databases - database.inc and database*.inc are in the includes folder. When you need a new table, insert new tables and take out tables, this will do it for you. This helps you securely pass and share information without a concern of breaking security holes (SQL stuff that I don't know). You can just pick all the items you want for a database, it will build it for you. Just tell it what fields and tables you want and Drupal will do it for you.
Theme layer - is the last step. There's an include files (theme.inc). It runs the entire theme system. It's how Drupal gets output. Information runs through the theme to output to the front side of the web world. Drupal has a system module that has default tpls files (template files). Drupal by default has block, box and page template files in the system module folder. Blocks are a module - but the system has a block section as well. The core html output goes into a tpl file inside modules folder. If you want to change the tpl file - go into the system module, it will automatically change everything you want. page.tpl is what is most often changed. Anytime you want to modify html, see if there's a template file to work on. Copy it, paste it and go.
In the end, themes rule. It controls everything in the end. Module output uses theme() The order of priority is theme_function_name() (is there a theme function?) phptemplate_function_name() (the engine of drupal) mytheme_function_name() (final item that trumps all - it gives you total control of everything) Copy and paste function into anything you want - change the logic, the wording... anything you want. It trumps anything the coders did for the site. Themers end up trumping the coders. When it comes to output the theme has control and this is probably where I've also hit snags. The code sometimes doesn't agree with a theme. If you keep the module code really generic, it allows the theme to give it control on a lower level and the module can be used multiple times.
Yikes. I think I kind of picked up on the way Drupal actually works!! Resources Developer/Theme handbooks Drupal source/api.drupal.org Dev/Theme mailing lists (drupal.com/mailing-lists) IRD:#drupal (#drupal-dev) #drupal-themes Issue queues Paper books: http://drupal.org/books
Those are my notes and I promise to go through that and improve what I'm trying to say. I promise.