Drupal's theme registry maintains cached data on the available theming hooks and how to handle them.
For most theme developers, the registry does not have to be dealt with directly. Just remember to clear it when adding or removing theme functions and templates. Editing existing functions and templates does not require a registry rebuild.
To clear the theme registry, do one of the following things:
1. On the "Administer > Site configuration > Performance" page, click on the "Clear cached data" button.
2. With devel block enabled (comes with devel module), click the "Empty cache" link.
3. The API function drupal_rebuild_theme_registry.
The theme registry is cached data instructing Drupal on the available theming hooks and how to handle it by indicating its type. In previous versions all theming calls were handled on the fly. Since a lot more work is being done under the hood, the cached instructions speeds up the process especially for templates. The theme engine your theme is running under should automatically register all the theming hooks for you.
There are special cases where you may need to work with the registry directly. When your theme requires a new hook to be registered that was not already implemented on the layers below it (core, modules, engine). This includes some forms when they are not explicitly themed by core or modules but instead rely on the default form presentation.
* More details can be found in the sub-page, The theme registry for special cases.
* Do not confuse the theme registry with the theme's .info file which is also cached. Points 1 and 2 on clearing the registry will clear both.
* Your theme must be using phptemplate engine for the for its templates and functions to be discovered. Other engines should behave the same way. For engineless themes, it must be done manually. See phptemplate_theme to see how it is done.
Thursday, January 8, 2009
Wednesday, January 7, 2009
Theming Drupal primary links with child sub-menus
Using 'Primary links' for your Drupal site's main navigation menu is a great idea. However, most themes by default display primary links in such a way that if the menu has sub-child menus, they will not be displayed. Fortunately, the solution is much easier that you'd think.
First off, the way that most themes generate primary links is like so:
theme('links', $primary_links);
As mentioned, this will only output the top-level menu items, like so:
That's not very useful for sites with a robust navigation tree.
To get around this, the simplest way is to remove the original theme() function outputing the primary links, and create a new region in your template where you'd like your navigation menu to show up. Then, you can assign the 'Primary links' block to that region, and the entire menu tree will be displayed there.
To create a region in Drupal 5:
You'll need to modify your theme's template.php file. If it doesn't yet have one, create it, and enter the following:
function name_of_theme_regions() {
return array(
'name_of_new_region' => t('name of new region'),
);
}
To create a region in Drupal 6:
In your theme's '.info' file, you'll need to define your new region. Put something like this:
regions[name_of_new_region] = name of new region
Be sure to replace 'name_of_theme' with the name of your theme, and 'name_of_new_region' with the name of your new region.
Outputting content of the new region
The key of the array item (or value in between brackets for Drupal 6) will be used as the variable name in your theme files, like '$name_of_new_region'.
The value of the array item (or value to the right of the equals sign for Drupal 6) will be used as the title of the region on the '/admin/build/block' page.
In your page.tpl.php file, output the content of the region like so:
Then, head over to '/admin/build/block' and set the 'Primary links' block to the region you just created.
First off, the way that most themes generate primary links is like so:
theme('links', $primary_links);
As mentioned, this will only output the top-level menu items, like so:
- Menu Item 1
- Menu Item 2
- Menu Item 3
That's not very useful for sites with a robust navigation tree.
To get around this, the simplest way is to remove the original theme() function outputing the primary links, and create a new region in your template where you'd like your navigation menu to show up. Then, you can assign the 'Primary links' block to that region, and the entire menu tree will be displayed there.
To create a region in Drupal 5:
You'll need to modify your theme's template.php file. If it doesn't yet have one, create it, and enter the following:
function name_of_theme_regions() {
return array(
'name_of_new_region' => t('name of new region'),
);
}
To create a region in Drupal 6:
In your theme's '.info' file, you'll need to define your new region. Put something like this:
regions[name_of_new_region] = name of new region
Be sure to replace 'name_of_theme' with the name of your theme, and 'name_of_new_region' with the name of your new region.
Outputting content of the new region
The key of the array item (or value in between brackets for Drupal 6) will be used as the variable name in your theme files, like '$name_of_new_region'.
The value of the array item (or value to the right of the equals sign for Drupal 6) will be used as the title of the region on the '/admin/build/block' page.
In your page.tpl.php file, output the content of the region like so:
Then, head over to '/admin/build/block' and set the 'Primary links' block to the region you just created.
Tuesday, January 6, 2009
Best Practices - Drupal 6
If you are going to invest the time to set up a CMS, then you should protect your investment by following some simple best practices. These guidelines are only suggestions. It is up to you to decide what is appropriate for your site.
The following list contains some quick pointers (for more detailed information, see the list of articles at the bottom of this page):
* Plan your site. Drupal provides a good toolset to help you build your site but you still need to plan. Good wireframes and proper planning can avoid significant misunderstandings and problems later.
* Plan for the future. You should revisit and reevaluate your site each time there is a major version release of Drupal. This does not mean you have to upgrade it, but you should evaluate and plan for an upgrade approximately each 12-24 months.
* Get involved in the community. This will help you follow development trends and, while helping others, you may just come across a cool idea that solves your own problem.
* Back up your site. Back up both the database and the files on the web server. Test your backups! If you don't test them, you have no idea if you are doing it right.
* Test your PHP snippets. Drupal gives you a great deal of power and flexibility when using PHP code in blocks. Unfortunately, a stray character or a missing semi-colon breaks PHP. Drupal then attempts to evaluate this broken code on any requested page, the PHP interpreter chokes on it and therefore your whole site is broken. Fortunately, there is a very simple and easy solution. Instead of writing and testing your code inside the administer > blocks page, go to create content and create a new story or page node. Use PHP input format, write the code, and the Preview to debug your code. When you are satisfied that your code is working, copy and paste the code into the block.
The following list contains some quick pointers (for more detailed information, see the list of articles at the bottom of this page):
* Plan your site. Drupal provides a good toolset to help you build your site but you still need to plan. Good wireframes and proper planning can avoid significant misunderstandings and problems later.
* Plan for the future. You should revisit and reevaluate your site each time there is a major version release of Drupal. This does not mean you have to upgrade it, but you should evaluate and plan for an upgrade approximately each 12-24 months.
* Get involved in the community. This will help you follow development trends and, while helping others, you may just come across a cool idea that solves your own problem.
* Back up your site. Back up both the database and the files on the web server. Test your backups! If you don't test them, you have no idea if you are doing it right.
* Test your PHP snippets. Drupal gives you a great deal of power and flexibility when using PHP code in blocks. Unfortunately, a stray character or a missing semi-colon breaks PHP. Drupal then attempts to evaluate this broken code on any requested page, the PHP interpreter chokes on it and therefore your whole site is broken. Fortunately, there is a very simple and easy solution. Instead of writing and testing your code inside the administer > blocks page, go to create content and create a new story or page node. Use PHP input format, write the code, and the Preview to debug your code. When you are satisfied that your code is working, copy and paste the code into the block.
mktime in PHP
mktime -- Get Unix timestamp for a date
Note the strange order of arguments, which differs from the order of arguments in a regular Unix mktime() call and which does not lend itself well to leaving out parameters from right to left (see below). It is a common error to mix these values up in a script.
Returns the Unix timestamp corresponding to the arguments given. This timestamp is a long integer containing the number of seconds between the Unix Epoch (January 1 1970) and the time specified.
Arguments may be left out in order from right to left; any arguments thus omitted will be set to the current value according to the local date and time.
is_dst can be set to 1 if the time is during daylight savings time, 0 if it is not, or -1 (the default) if it is unknown whether the time is within daylight savings time or not. If it's unknown, PHP tries to figure it out itself. This can cause unexpected (but not incorrect) results.
Note: is_dst was added in 3.0.10.
mktime() is useful for doing date arithmetic and validation, as it will automatically calculate the correct value for out-of-range input. For example, each of the following lines produces the string "Jan-01-1998".
Example: mktime() example
echo date("M-d-Y", mktime(0, 0, 0, 12, 32, 1997));
echo date("M-d-Y", mktime(0, 0, 0, 13, 1, 1997));
echo date("M-d-Y", mktime(0, 0, 0, 1, 1, 1998));
echo date("M-d-Y", mktime(0, 0, 0, 1, 1, 98));
?>
Year may be a two or four digit value, with values between 0-69 mapping to 2000-2069 and 70-99 to 1970-1999 (on systems where time_t is a 32bit signed integer, as most common today, the valid range for year is somewhere between 1901 and 2038).
Windows: Negative timestamps are not supported under any known version of Windows. Therefore the range of valid years includes only 1970 through 2038.
The last day of any given month can be expressed as the "0" day of the next month, not the -1 day. Both of the following examples will produce the string "The last day in Feb 2000 is: 29".
Note the strange order of arguments, which differs from the order of arguments in a regular Unix mktime() call and which does not lend itself well to leaving out parameters from right to left (see below). It is a common error to mix these values up in a script.
Returns the Unix timestamp corresponding to the arguments given. This timestamp is a long integer containing the number of seconds between the Unix Epoch (January 1 1970) and the time specified.
Arguments may be left out in order from right to left; any arguments thus omitted will be set to the current value according to the local date and time.
is_dst can be set to 1 if the time is during daylight savings time, 0 if it is not, or -1 (the default) if it is unknown whether the time is within daylight savings time or not. If it's unknown, PHP tries to figure it out itself. This can cause unexpected (but not incorrect) results.
Note: is_dst was added in 3.0.10.
mktime() is useful for doing date arithmetic and validation, as it will automatically calculate the correct value for out-of-range input. For example, each of the following lines produces the string "Jan-01-1998".
Example: mktime() example
echo date("M-d-Y", mktime(0, 0, 0, 12, 32, 1997));
echo date("M-d-Y", mktime(0, 0, 0, 13, 1, 1997));
echo date("M-d-Y", mktime(0, 0, 0, 1, 1, 1998));
echo date("M-d-Y", mktime(0, 0, 0, 1, 1, 98));
?>
Year may be a two or four digit value, with values between 0-69 mapping to 2000-2069 and 70-99 to 1970-1999 (on systems where time_t is a 32bit signed integer, as most common today, the valid range for year is somewhere between 1901 and 2038).
Windows: Negative timestamps are not supported under any known version of Windows. Therefore the range of valid years includes only 1970 through 2038.
The last day of any given month can be expressed as the "0" day of the next month, not the -1 day. Both of the following examples will produce the string "The last day in Feb 2000 is: 29".
Monday, January 5, 2009
Drupal and CVS
CVS is how Drupal developers manage code. It is a tool for managing the revisions and releases of a software project that is being developed by multiple people. In such a project, each developer will create one (or more) separate copies of the code, then make local modifications to fix bugs or add features. After debugging this modified code, the developer uploads it to a server, where it is merged with the other developers' modified code to create the next release of the software. Often, two or more developers will modify the same module at the same time, which creates a big problem when they try to combine their work. It is very easy for one of them to unintentionally overwrite the other's changes.
CVS helps to manage this problem by maintaining a central code repository -- a directory on the CVS server that contains the definitive archive of a project's code, as well as a complete history of that code's development. You can use CVS to download a local copy of the code -- either the very latest version (which is often called HEAD, and is typically very unstable), or one of the earlier, stable versions (which are labelled with tags to identify them). When other developers change the code, CVS can download those changes and update your local copy.
When project maintainers make changes they wish to share, CVS is used to upload and commit them. If your changes threaten to overwrite those of another developer, CVS will warn you and give you a chance to resolve the conflict. And when you make a mistake, CVS can help you recover: you can read a complete log of all the changes to the code since the project began, retrieve versions of files from any time in the past, and generate patch files that summarize the difference between any two versions of the code.
In addition, CVS helps developers stay up to date on the state of the project. For example, the Drupal CVS server will email all CVS commits to all maintainers, automatically informing them of the work you have done.
CVS helps to manage this problem by maintaining a central code repository -- a directory on the CVS server that contains the definitive archive of a project's code, as well as a complete history of that code's development. You can use CVS to download a local copy of the code -- either the very latest version (which is often called HEAD, and is typically very unstable), or one of the earlier, stable versions (which are labelled with tags to identify them). When other developers change the code, CVS can download those changes and update your local copy.
When project maintainers make changes they wish to share, CVS is used to upload and commit them. If your changes threaten to overwrite those of another developer, CVS will warn you and give you a chance to resolve the conflict. And when you make a mistake, CVS can help you recover: you can read a complete log of all the changes to the code since the project began, retrieve versions of files from any time in the past, and generate patch files that summarize the difference between any two versions of the code.
In addition, CVS helps developers stay up to date on the state of the project. For example, the Drupal CVS server will email all CVS commits to all maintainers, automatically informing them of the work you have done.
Drupal and PHP
Drupal 7 and PHP 5.2
Drupal has long prided itself for staying ahead of the curve technologically. In order to be able to write the best quality Drupal software, Drupal developers need the best programming tools available. Today, the best PHP available is PHP 5.
PHP 5 has been deployed and tested in production environments for three years. Unfortunately, web hosts have been slow to adopt PHP 5, which has made it difficult for Drupal and many other PHP projects to fully embrace PHP 5's features.
Now a growing consortium of PHP projects have joined together and push for wider PHP 5 adoption. By all embracing PHP 5 together, the projects involved in the GoPHP 5 effort are sending a message to web hosts that it is time to embrace PHP's future.
Drupal is now part of that movement.
After much deliberation, the Drupal project is committed to the following path:
* As of Drupal 7, changes to Drupal which use language features found exclusively in PHP 5.2 will be considered for acceptance into Drupal core.
* This policy effectively means that Drupal 7 will be incompatible with PHP 4.
The Drupal developer community agrees that this change is best for the future of Drupal. We are excited by the potential that PHP 5 brings, and we look forward to building better software for the community.
Drupal 6 and PHP 4
The upcoming Drupal 6 and all current Drupal releases will remain PHP 4-compatible for as long as they are supported.
In Drupal 6, contributed Drupal modules and themes may declare their PHP version compatibility. Contributed modules can only be installed on systems that support the required PHP version. This change will allow developers to leverage PHP 5 features without breaking existing Drupal sites. This feature will let Drupal users evaluate the advantages of moving their sites to PHP 5.
Drupal has long prided itself for staying ahead of the curve technologically. In order to be able to write the best quality Drupal software, Drupal developers need the best programming tools available. Today, the best PHP available is PHP 5.
PHP 5 has been deployed and tested in production environments for three years. Unfortunately, web hosts have been slow to adopt PHP 5, which has made it difficult for Drupal and many other PHP projects to fully embrace PHP 5's features.
Now a growing consortium of PHP projects have joined together and push for wider PHP 5 adoption. By all embracing PHP 5 together, the projects involved in the GoPHP 5 effort are sending a message to web hosts that it is time to embrace PHP's future.
Drupal is now part of that movement.
After much deliberation, the Drupal project is committed to the following path:
* As of Drupal 7, changes to Drupal which use language features found exclusively in PHP 5.2 will be considered for acceptance into Drupal core.
* This policy effectively means that Drupal 7 will be incompatible with PHP 4.
The Drupal developer community agrees that this change is best for the future of Drupal. We are excited by the potential that PHP 5 brings, and we look forward to building better software for the community.
Drupal 6 and PHP 4
The upcoming Drupal 6 and all current Drupal releases will remain PHP 4-compatible for as long as they are supported.
In Drupal 6, contributed Drupal modules and themes may declare their PHP version compatibility. Contributed modules can only be installed on systems that support the required PHP version. This change will allow developers to leverage PHP 5 features without breaking existing Drupal sites. This feature will let Drupal users evaluate the advantages of moving their sites to PHP 5.
Tuesday, December 30, 2008
Drupal 6 Theming Views
Views 2 provides a well structured theming environment allowing presentation control for each element of your view. And in my humble opinion, it rocks!
Those with no past experience with Views 1 will find Views 2 uses standard PHPTemplate theming techniques. All of your experience theming Drupal can be used with Views.
Views 1 themers starting with Views 2 might be a bit confused at first. I was. The single callback in template.php where everything happened is gone, refactored into a consistent framework of template files. All of the freedom that existed in the single function still exists with the added benefit of a well defined structure.
Overview
Views handles querying the database and organizing the information for display. It creates the output display by converting retrieved data into variables and passing them through a series of templates. Each template handles a different "level" of output creation. The number of templates used to create a view's output depends on the view's type and style, as well as the number of fields involved. These templates exist as files (with a .tpl.php extension), in either the module's or the theme's directory, and follow PHPTemplate's theming conventions.
Generally speaking, the template levels are:
Field: When fields are used in the view ("Row style" = Fields), each field can be themed with a field specific template file. If "Row style" = Node, the node's .tpl.php file is used.
Row: Controls how the individual fields are assembled together into a row. This template isn't used for table styles
Style: Controls how the rows are assembled into the output. For example, in a list view a foreach loop places each row entry into the list entry (li) of an unordered list (ul).
Display: Controls the other information making up the view such as title, header and footer.
Each level becomes input variables for the next level up. The output of field templates are input variables for the row template, the output for the row template becomes input variables for the style template, and so on. There are also level specific variables available, such as row number. A diagram is available at http://views-help.doc.logrus.com/help/views/analyze-theme.
A template file naming convention is used to make the template highly specific or highly general. Through appropriate naming, a template file can apply to all views, a view of a specific type, or a specific display of a specific view. Where multiple files might apply to a view, the one with the most specific name is used.
Those with no past experience with Views 1 will find Views 2 uses standard PHPTemplate theming techniques. All of your experience theming Drupal can be used with Views.
Views 1 themers starting with Views 2 might be a bit confused at first. I was. The single callback in template.php where everything happened is gone, refactored into a consistent framework of template files. All of the freedom that existed in the single function still exists with the added benefit of a well defined structure.
Overview
Views handles querying the database and organizing the information for display. It creates the output display by converting retrieved data into variables and passing them through a series of templates. Each template handles a different "level" of output creation. The number of templates used to create a view's output depends on the view's type and style, as well as the number of fields involved. These templates exist as files (with a .tpl.php extension), in either the module's or the theme's directory, and follow PHPTemplate's theming conventions.
Generally speaking, the template levels are:
Field: When fields are used in the view ("Row style" = Fields), each field can be themed with a field specific template file. If "Row style" = Node, the node's .tpl.php file is used.
Row: Controls how the individual fields are assembled together into a row. This template isn't used for table styles
Style: Controls how the rows are assembled into the output. For example, in a list view a foreach loop places each row entry into the list entry (li) of an unordered list (ul).
Display: Controls the other information making up the view such as title, header and footer.
Each level becomes input variables for the next level up. The output of field templates are input variables for the row template, the output for the row template becomes input variables for the style template, and so on. There are also level specific variables available, such as row number. A diagram is available at http://views-help.doc.logrus.com/help/views/analyze-theme.
A template file naming convention is used to make the template highly specific or highly general. Through appropriate naming, a template file can apply to all views, a view of a specific type, or a specific display of a specific view. Where multiple files might apply to a view, the one with the most specific name is used.
Landmarks to see in Chennai
Chennai, being the gateway to south India is a very culturally rich city and offers something for everyone, with a south Indian flair. From Christian churches to Hindu temples, from military forts to motorcycle factories, there is something for everyone here.
If you are a history or a culture buff, then welcome to the melting pot of south India, for Chennai is its capital, and over the centuries has attracted people from not only over South India, but also from all over the world. A must visit place is Mylapore, with its numerous Temples depicting the classical architecture of South India over the centuries.
Chennai is more or less divided into 3 sections: George Town, Egmore and Central Chennai, and South Chennai. George Town, named in honor of King George V being crowned emperor of India, is reminiscent of Chennai's colonial past, where as the other parts of Chennai have a more ethnic feel.
Places to see in Chennai
George Town
1. High Court Building
2. Fort St. George
3. St. Mary's Church
If you are a history or a culture buff, then welcome to the melting pot of south India, for Chennai is its capital, and over the centuries has attracted people from not only over South India, but also from all over the world. A must visit place is Mylapore, with its numerous Temples depicting the classical architecture of South India over the centuries.
Chennai is more or less divided into 3 sections: George Town, Egmore and Central Chennai, and South Chennai. George Town, named in honor of King George V being crowned emperor of India, is reminiscent of Chennai's colonial past, where as the other parts of Chennai have a more ethnic feel.
Places to see in Chennai
George Town
1. High Court Building
2. Fort St. George
3. St. Mary's Church
Sending Mail with the hook_mail in Drupal 6
The Drupal 6 Mail API is used to provide mail-sending services to Drupal modules.
In most cases, using the Mail API is a two-step process:
1. Implement hook_mail() in your module.
2. Elsewhere in your module, use the drupal_mail() function to invoke
your hook_mail() implementation and also do additional formatting
and sending.
In the previous section, we briefly glanced at the drupal_mail() function. Here, we
will start by looking at the function in more detail. Inside emailusers_compose_
form_submit(), we called drupal_mail() with the following parameters:
drupal_mail(
'emailusers',
'composemessage',
$account->mail,
user_preferred_language($account),
$form_values,
variable_get('site_mail', null),
true // Automatically send
);
Seven parameters! To get an idea as to what is going on here, let's look at each
in turn.
The first parameter (emailusers) is the name of the module that contains an
implementation of hook_mail(). Later, we will look at the emailusers_mail()
hook that will be called when this drupal_mail() function is executed.
The second parameter, composemessage, is used as a key and passed on to the
hook_mail() implementation. As we will see shortly, the mail hook can then
determine how to treat the message based on the key. In other words, you can
use one mail hook to handle various different mail-sending tasks simply by using
different keys.
The third parameter should contain the destination address. In this case, an
administrator will be sending the message to the email address for the account he or
she is examining. This is stored in $account->mail.
The fourth parameter is the language that should be used by t() and other
translation facilities when translating the message. Why is it necessary to specify
this? Since the user receiving the message may prefer a different language than that
of the system administrator who is sending the message.Fortunately, the user_preferred_language() function, which takes an account
object (like the one returned from load_user()), can return the appropriate
locale information.
The fifth parameter holds an associative array of data that might be used when
generating the message. This data is passed on to the hook_mail() implementation,
and we will make use of it in a few moments. In this case, though, the data we want
happens to be the values submitted through our form. So we pass $form_values
here.
Moving to the sixth parameter, we need to specify a delivery address. Who is
this message from? One of the values in Drupal's site-wide configuration is the
administration email address. We can use this address by retrieving the setting:
variable_get('site_mail', null). This will attempt to get the 'site_mail'
setting. If no such setting is found, this will return the default value null (in which
case the mailing library will attempt to assign an appropriate from address).
The last of the seven parameters is a Boolean flag to indicate whether or not the
message should be sent. When drupal_mail() is executed, it will return a specially
structured array, which can be passed to drupal_mail_send(). However, if this last
parameter is set to true, then the drupal_mail() function will send the mail before
returning. In that case, there is no need to call the drupal_mail_send() function or
even capture the data returned from drupal_mail().When drupal_mail() is called, it goes through a series of steps to take the data
passed in the seven parameters and create a suitable mail message. For example, it
sets default RFC 2822 mail headers and makes sure that certain values (like a from
address) are set.
Then it executes the hook_mail() implementation (if found).
After that, it proceeds through a few other steps, like executing any hook_mail_
alter() implementations before it (optionally) sends the email and returns a
formatted message.So the mail hook is executed right in the middle of this process. What does it do? In
a nutshell, it is responsible for setting appropriate fields (like the subject, CC, or BCC
fields) as well as creating a formatted body for the message.
In most cases, using the Mail API is a two-step process:
1. Implement hook_mail() in your module.
2. Elsewhere in your module, use the drupal_mail() function to invoke
your hook_mail() implementation and also do additional formatting
and sending.
In the previous section, we briefly glanced at the drupal_mail() function. Here, we
will start by looking at the function in more detail. Inside emailusers_compose_
form_submit(), we called drupal_mail() with the following parameters:
drupal_mail(
'emailusers',
'composemessage',
$account->mail,
user_preferred_language($account),
$form_values,
variable_get('site_mail', null),
true // Automatically send
);
Seven parameters! To get an idea as to what is going on here, let's look at each
in turn.
The first parameter (emailusers) is the name of the module that contains an
implementation of hook_mail(). Later, we will look at the emailusers_mail()
hook that will be called when this drupal_mail() function is executed.
The second parameter, composemessage, is used as a key and passed on to the
hook_mail() implementation. As we will see shortly, the mail hook can then
determine how to treat the message based on the key. In other words, you can
use one mail hook to handle various different mail-sending tasks simply by using
different keys.
The third parameter should contain the destination address. In this case, an
administrator will be sending the message to the email address for the account he or
she is examining. This is stored in $account->mail.
The fourth parameter is the language that should be used by t() and other
translation facilities when translating the message. Why is it necessary to specify
this? Since the user receiving the message may prefer a different language than that
of the system administrator who is sending the message.Fortunately, the user_preferred_language() function, which takes an account
object (like the one returned from load_user()), can return the appropriate
locale information.
The fifth parameter holds an associative array of data that might be used when
generating the message. This data is passed on to the hook_mail() implementation,
and we will make use of it in a few moments. In this case, though, the data we want
happens to be the values submitted through our form. So we pass $form_values
here.
Moving to the sixth parameter, we need to specify a delivery address. Who is
this message from? One of the values in Drupal's site-wide configuration is the
administration email address. We can use this address by retrieving the setting:
variable_get('site_mail', null). This will attempt to get the 'site_mail'
setting. If no such setting is found, this will return the default value null (in which
case the mailing library will attempt to assign an appropriate from address).
The last of the seven parameters is a Boolean flag to indicate whether or not the
message should be sent. When drupal_mail() is executed, it will return a specially
structured array, which can be passed to drupal_mail_send(). However, if this last
parameter is set to true, then the drupal_mail() function will send the mail before
returning. In that case, there is no need to call the drupal_mail_send() function or
even capture the data returned from drupal_mail().When drupal_mail() is called, it goes through a series of steps to take the data
passed in the seven parameters and create a suitable mail message. For example, it
sets default RFC 2822 mail headers and makes sure that certain values (like a from
address) are set.
Then it executes the hook_mail() implementation (if found).
After that, it proceeds through a few other steps, like executing any hook_mail_
alter() implementations before it (optionally) sends the email and returns a
formatted message.So the mail hook is executed right in the middle of this process. What does it do? In
a nutshell, it is responsible for setting appropriate fields (like the subject, CC, or BCC
fields) as well as creating a formatted body for the message.
Drupal core caching and content caching modules
Drupal core caching
Caching stores "elements" in a cache table in the database, so the data can be retrieved by a single query, rather that constructing the page from individual elements.
Drupal's core cache has two parts, stuff that gets caches no matter what, and stuff that is optional via an administrator defined settings.
The always on cache is for the menu (the hierarchy of callbacks/urls, with access information), the variable table (all the various settings and configuration), and filters (all processed texts).
The optional cache is the page cache, and it only applies for anonymous users.
For Drupal 4.7 and earlier, the cache table was a single table storing all of the above. As of Drupal 5.x, the cache table is split into cache_menu, cache_filter, cache_variable and cache_page to decrease contention. Also new in Drupal 5.x is aggressive caching mode.
Cache contention
On a large site, if you are using MyISAM, contention occurs in the database tables when the cache is forced to clear after a node or a comment is added. With tens of thousands of filter text snippets needing to be deleted, the table will be locked for a long period, and any accesses to it will be queued pending the purge of the data in it. The same is true for the page cache as well.
This often causes a "site hang" for a minute or two. During that time new requests keep piling up, and if you do not have the MaxClients parameter in Apache setup correctly, the system can go into thrashing because of excessive swapping.
Example of such cases exist here, and here.
If you change your database tables to InnoDB, you can avoid the table level locking, since it supports row level locking. However, you have to be careful of some InnoDB pitfalls that can cause other queries on the site to be slow, as well as eliminate the table locks as described in that same article.
Eliminating cache contention
To get rid of this contention, you have to first disable the page cache, which requires no code change. This is only possible if you have the CPU horsepower to generate the pages and filters for every page view. This means that you are on a dedicated server (which you need anyway if you have a large site), and that you have enabled one of the PHP op-code caches/accelerators.
Do disable the filter cache, you have to manually edit code in Drupal 4.7 (and remember to change it when you get a new release).
In filter.module, find the function check_markup(), then delete or comment out the following lines:
if ($cached = cache_get($id, 'cache_filter')) {
return $cached->data;
}
and
if ($cache) {
cache_set($id, 'cache_filter', $text, time() + (60 * 60 * 24));
}
With these lines removed/commented, you no longer have to worry about contention for the filter cache.
In Drupal 5.x, there is a nifty feature that allows you to create your own caching strategy, by replacing includes/cache.inc with a file you define.
Copy the includes/cache.inc file to sites/modules/cache_no_filter/cache_no_filter.inc, and then modify the file you just created like so:
In the cache_get() function, put the following at the start of the function:
if ($table == 'cache_filter') {
return 0;
}
And this in cache_set(), put this at the start of the function:
if ($table == 'cache_filter') {
return;
}
Then, in your settings.php file, you do the following:
$conf = array(
'cache_inc' => './sites/all/modules/cache_no_filter/cache_no_filter.inc',
);
A pre-patched version for Drupal 5.2 can be downloaded below towards the end of this article. Just rename the file to remove the .txt extension.
The beauty of this is that you do not modify Drupal core, yet hook into your custom cache.
Contributed caching modules
There are quite a few contributed modules that help with caching.
For example, there is a block cache module avoids the overhead of generating blocks for every page load.
Taking it a step further, there is an API module by the name pressflow preempt that allows other modules to cache any function.
Avoiding the database altogether is the ultimate in caching: if the pages are stored in HTML static files, they can be served faster.
Taking this approach, there is the fastpath fscache module, as well as the boost module.
Caching stores "elements" in a cache table in the database, so the data can be retrieved by a single query, rather that constructing the page from individual elements.
Drupal's core cache has two parts, stuff that gets caches no matter what, and stuff that is optional via an administrator defined settings.
The always on cache is for the menu (the hierarchy of callbacks/urls, with access information), the variable table (all the various settings and configuration), and filters (all processed texts).
The optional cache is the page cache, and it only applies for anonymous users.
For Drupal 4.7 and earlier, the cache table was a single table storing all of the above. As of Drupal 5.x, the cache table is split into cache_menu, cache_filter, cache_variable and cache_page to decrease contention. Also new in Drupal 5.x is aggressive caching mode.
Cache contention
On a large site, if you are using MyISAM, contention occurs in the database tables when the cache is forced to clear after a node or a comment is added. With tens of thousands of filter text snippets needing to be deleted, the table will be locked for a long period, and any accesses to it will be queued pending the purge of the data in it. The same is true for the page cache as well.
This often causes a "site hang" for a minute or two. During that time new requests keep piling up, and if you do not have the MaxClients parameter in Apache setup correctly, the system can go into thrashing because of excessive swapping.
Example of such cases exist here, and here.
If you change your database tables to InnoDB, you can avoid the table level locking, since it supports row level locking. However, you have to be careful of some InnoDB pitfalls that can cause other queries on the site to be slow, as well as eliminate the table locks as described in that same article.
Eliminating cache contention
To get rid of this contention, you have to first disable the page cache, which requires no code change. This is only possible if you have the CPU horsepower to generate the pages and filters for every page view. This means that you are on a dedicated server (which you need anyway if you have a large site), and that you have enabled one of the PHP op-code caches/accelerators.
Do disable the filter cache, you have to manually edit code in Drupal 4.7 (and remember to change it when you get a new release).
In filter.module, find the function check_markup(), then delete or comment out the following lines:
if ($cached = cache_get($id, 'cache_filter')) {
return $cached->data;
}
and
if ($cache) {
cache_set($id, 'cache_filter', $text, time() + (60 * 60 * 24));
}
With these lines removed/commented, you no longer have to worry about contention for the filter cache.
In Drupal 5.x, there is a nifty feature that allows you to create your own caching strategy, by replacing includes/cache.inc with a file you define.
Copy the includes/cache.inc file to sites/modules/cache_no_filter/cache_no_filter.inc, and then modify the file you just created like so:
In the cache_get() function, put the following at the start of the function:
if ($table == 'cache_filter') {
return 0;
}
And this in cache_set(), put this at the start of the function:
if ($table == 'cache_filter') {
return;
}
Then, in your settings.php file, you do the following:
$conf = array(
'cache_inc' => './sites/all/modules/cache_no_filter/cache_no_filter.inc',
);
A pre-patched version for Drupal 5.2 can be downloaded below towards the end of this article. Just rename the file to remove the .txt extension.
The beauty of this is that you do not modify Drupal core, yet hook into your custom cache.
Contributed caching modules
There are quite a few contributed modules that help with caching.
For example, there is a block cache module avoids the overhead of generating blocks for every page load.
Taking it a step further, there is an API module by the name pressflow preempt that allows other modules to cache any function.
Avoiding the database altogether is the ultimate in caching: if the pages are stored in HTML static files, they can be served faster.
Taking this approach, there is the fastpath fscache module, as well as the boost module.
Subscribe to:
Posts (Atom)