hooks

While searching for how to integrate drupal with a "light" webserver called Hiawatha, I find this comment intriguing:

http://www.hiawatha-webserver.org/forum/topic/222

In one of the comments, Hugo Leisink says that he doesn't recommend drupal because of the "ugly" code.
He says "On a simple page that showed a list of 15 items, Drupal needed more that 400 database queries."

I know drupal does these queries so it can do logging and for other status information, but I think you can disable these logging features.

Hi Guys,

I was doing a review on the hooks provided by drupal 5 and drupal 6. Most of the hooks are same, except a few which i tried to put down in a document. I needed this to be able to port my custom modules to drupal 6 [i'm still using drupal 5]. So, I thought why not make a document of this and share with everyone else :) I have attached the document. The document contains only those hooks which are in either of the drupal installations and not both.

The major differences that i see in drupal 6 are:

1. Actions is integrated with the core.

I would like to implement extra functionality on specific CCK fields operations. For example, I have a link CCK field in some content type. When a value, eg a website link, is entered in that field, I automatically want to set up a feed using that link. To do this, I am now altering the entire node form using hook_nodeapi(), filtering out the correct content type and then reading the field value. I thought it would be nicer to hook up my custom action (creating the feed from the link) directly to the CCK field.

Image Enhanced Scaling is dead – long live ImageMagick Advanced Options! Yes, the Long Module Names Movement is back with longer names than ever before!

As of Octover 10, Image module comes with a new contributed module: ImageMagick Advanced Options. This is good news for anyone who needs fine-grained control over their images in Drupal, such as photographers or managers of image archives – regardless of wheter they use Image module or not. This post describes how it came into existence and why you should use it.

So, we have a few modules that we are running for a new client. We're running drupal on about 60K worth of hardware, not including the Oracle database sitting on it's own nice slice of hardware (about 4 tearbytes of data).

So we get data once a week, millions of rows of data (60 million+). The module that we made for the client has a cron job that runs through and makes some updates (this is along with a Database-side PL\SQL script, and a sprinkle of java. A nice orchestra of apps that work beautifully togather). Well, this takes days to do. Literally days, and we noticed a problem when the "aggregator" failed because it through an error trying to read a certain RSS feed. We were not aware of this for about a week. This cost us and our customer prescious time because since aggregator had filed, the clients custom module never got to run!!! Futher more, I concluded that if I put the custom module first, it would eat up all the cron run time. On top of than, we were seriously "under" utilizing our hardware. This was just totally unaccepatble. Thus comes "Mutli-Threaded Cron" runs.

What this does bascially is fire each modules cron run in it's own "sandbox" if you will. So that each modules cron run has the FULL use of PHP's time out, and does not have to worry about another modules cron run failing. The multi-threaded cron also gives more detailed information about each modules cron run. This will better help site admins control the PHP time out variable (which can now also be set dynamically), and see what modules are taking hte most time to run, the least time, and which ones are currently failing.

I believe this is a BIG improvment over the current cron implementation.
Some items I would like to implement next:

• Emailing the admin if these is a "cron run fail" escalation (say in a 20 min. period, there are 10 failure, email me), etc.
• Being able to set each modules individual PHP execution time variable. (be nice to give search.module more time than aggregator module)
• "Throttle" the cron runs. Meaning, I only want to have 5 cron "threads" running at any given time. So it needs to wait until a few have finished before running more cron threads.

You can review the patch and a detailed discussion of it here: http://drupal.org/node/87528
I'll be discussing more options for mutli-threaded cron runs on my blog: http://www.eb3it.com

Below is a snipped from my blog:

<br/><br/><br/>

So, I have started an ambitous patch. For those who do not want to read the explination, and just gain knowledge by reading the patch:

Right now, SimpleVote is the best example of how an external module can hook into VotingAPI's action functionality. I'm writing up more detailed docs on how it works internally, but for now let's take a quick tour. First, there's hook_votingapi_action_sets(), a hook that any module can implement to return a collection of 'action sets' for consideration whenever a vote result is processed.

Each action set includes some key information:

1. Meta-data, like name and description
2. Some behavioral data, like whether ALL of its conditions must be true or only ONE,
3. A set of 'condition' records that are evaluated
4. A set of 'actions' that are executed if the conditions are satisfied