I agree with some of the comments by the author. Yes, it’s not the easiest to configure and maintain. If you ignore some best practices you’re really screwed. If this configuration problem refers to specific module configurations, yes, I’ve seen numerous people gripe about that.

3rd party modules are there so that the core can be clean and simple. This extensibility, IMO a very good thing. Coding a custom CMS in Rails doesn’t seem sexy to me. It’s a really boring thing to code a CMS these days regardless of the language. There are enough free CMSes out there that work 95% of the time. The remaining 5% is not worth coding a new CMS from scratch.

Yes, Drupal views are stored in the database. For me, that’s the easiest and logical place to store this. I think if the file system was used, this feature would’ve been much slower given its dynamic nature.

Again, I agree with that the usability sucks. It can be improved.

The comment about the use of structured programming instead of OOP is nonsense. Drupal framework implement a hooks system that you can hook up a user defined function practically anywhere. For the programmer that’s sufficient to get the job done. Dissing the whole framework because of OOP fanboyism is stupid.

A particular software tool might not be able to do everything that we dream of doing. However, compared with a proprietary program, the user has a choice of choosing something which matches closely with his requirements. As Paul puts it, it’s like an arranged marriage vs. dating. Cool thing is, if you need a particular feature so badly you can pay someone and get it done the way you want it. Reality has it, even if it’s arranged vs. dated for couple of years, after getting married you can’t live together if you’re not able to make compromises. So I’ve been told.

Coming back to Drupal, this issue of having the freedom to modify anything ‘cos it’s all PHP should really not be an issue but experience suggest otherwise. Having restricted access to Drupal core files is also of limited success. Remember, I’m not talking from an outsiders perspective where you worry about world readable files and whatnot, this is from the developer perspective who has full control over making a code level change. A set of people maintaining the site doing continuous modifications.

If you’re just running Drupal as a blog and you’re the only one who makes changes to it, then there are no issues. In a team environment sometimes you assume that something like a change to a core file should not be done unless you have 1) googled 2) RTFM (thrice) and there’s no other way to do it, but surprisingly people overlook this fact and do change the stuff that should not be changed. Usually these kind of shit happens when you cut your software engineering lectures and go collecting meadow muffins on perfectly bright and sunny days.

Close examination suggest legitimate reasons such as,

1. It’s easy to customize, say, include/common.inc rather than reading the API doc, which is comparatively harder and takes more time
2. Naming conventions. common.inc. “I need to display the top most blah blah blah nodes on these set of pages, it’s a common feature to all these so common.inc is the right place to do it”.
3. You do need to get something displayed, quickly, you know it’s not the right way to do it but since time is more important you decide to change a line in a core module which is trivial.

All goes well for a couple of years until someone else takes over and use the universal language to communicate with your entire genealogy.

Those 10 second hack jobs will stack up with time and by the time shit hits the fan, no amount of version control could save you. Problems arise when you have to update your CMS. Files such as common.inc belongs to the Drupal core and will be updated. So if you have modifications in those files you now have to get those to the system. If you’re really unlucky and the API has changed now you have to substitute the new functions. This will become tedious when you have to go through each and every file to see what has been added/modified. Things get more vexing if you have nodes embedded with PHP code. These are nodes with Input type PHP. If the API has changed now you have to go through those pages and see what breaks.

So what are the possible solutions for this mussed up state of affairs?

1. Making it hard to modify the core files which will be replaced during an upgrade.
2. Enforce an internal policy regarding the modifications so that changes happen in either the theme used or in a separate module.

Making everyone aware of the extension mechanisms available and doing changes in a disciplined manner will save you when you have to upgrade. Also this will make the life of the maintenance programmer easier. This does have one drawback. Turnaround times for features/changes will now take a bit more time than earlier but the big upside is the whole thing could be rapidly updated (if there’s a security vulnerability or a newer version have a killer feature, makes it faster etc…) and someone else could take over without much effort.

Forms are defined as PHP arrays,

$form['noreg'] = array(
    '#type' => 'checkboxes',
    '#title' => "Reason not to register",
    '#options' => $reasons,
    '#default_value' => 0,
    '#validate' => array('fizzed_up_validator' => array())
);

When the above code fragment gets rendered into HTML it’ll be a list of checkboxes with the items in $reasons. Also note that we’re passing a custom validation function. Inside your custom validation function you could perform all the checking and if there’s an error condition you could say,

form_set_error($form, $message);

which will display an error message and redirects users back to the form. $form is a parameter your validation function takes. Forms API is well documented with examples.

There’s this need to add the user to a particular role depending on from where the user come to the download page. This should be done in the registration phase. That’s trivial to do with Drupal. You could get this “event” where the user submitted details has passed all the validation logic and about to be inserted into the database, at that time you have to fetch the role info from the DB and insert stuff to users_roles table. Oh, and the redirection part. When the form is successfully submitted (meaning user got registered) you could redirect the user to anywhere. All the API and the things you could do with it is extremely well thought out and nice to play with. To get this registration form, all I had to do was hide some attributes before the form gets rendered. For example look at the standard registration page. Embedded registration form of the newly designed page had to contain only the mandatory fields. There was no need to display rest of the stuff. So, what I had to do was in hook_form_alter unset the relevant $form['elems']. Had to define a session variable to detect we’re coming from the right page, otherwise the all the registration form instances will be changed. After that display the form,

drupal_get_form('user_register');

voila! Now you have a customized registration form. The cool thing is all the validation stuff defined for the registration form will work and you don’t have to do anything extra.

A slightly less documented API call that we use is user_external_load. This’ll load a given user’s details into the current session so that the user will be logged into the system. To pull this off successfully there needs to be an entry in the authmap table as the function implementation shows. I’ve not been able to find a way one could insert a record to this table via the admin screens.