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.
Tuesday, December 30, 2008
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.
Upgrade from Drupal 5 to Drupal 6
The module provides full upgrade scripts for a smooth transition to Drupal 6. However, due to some multilanguage features provided now by Drupal core and that the i18n package has been fully reworked, there are some special considerations. So please, read all this page before doing anything.
Drupal 6 upgrade notes
* To upgrade from 5.x, first upgrade to the latest 5.x stable release. To upgrade from 4.x, first upgrade to 5.x, then to 6.x
* Note that some old features and behaviors have been dropped and replaced by new Drupal 6 multilingual features. This module won't pretend to replace Drupal core available features but to build on them and provide extended ones.
* While the upgrade scripts already work for nodes and taxonomy, there's other data that is simply deleted by the main Drupal 6 core upgrade, like the menu items language.
* Other parts like the multilingual block system have been completely reworked and will need manual reconfiguration. Existing normal blocks won't be lost but the language settings will need manual reconfiguration.
* The module layout, dependencies and names have important changes, so it is advised to take your time, read the new modules descriptions, and decide on which ones you new enabled, that may be different from the Drupal 5 ones.
The upgrade process
1. As with any other upgrade, make a full back up of your database before and set the site in off-line mode.
2. Disable all i18n modules (Disabling all contributed modules is always recommended) before upgrading to Drupal 6.
3. Upgrade your codebase and run the Drupal 6 standard upgrade
4. First, enable Drupal 6 core Translation module. Internationalization now relies on it.
5. Go through the Inernationalization package module list and enable the ones you need.
6. Run the update script again (update.php) so i18n modules can update their data properly
7. Review *all* the language settings (Drupal 6 core settings have also changed), and reconfigure your multilingual menus, blocks and path aliases.
After upgrading
* If you are using multilingual variables, some variable names have changed in Drupal 6. Review and update your settings.
* Language prefixes in path aliases are not supported anymore. Instead use the new language setting for path aliases. You'll need to update them manually
Drupal 6 upgrade notes
* To upgrade from 5.x, first upgrade to the latest 5.x stable release. To upgrade from 4.x, first upgrade to 5.x, then to 6.x
* Note that some old features and behaviors have been dropped and replaced by new Drupal 6 multilingual features. This module won't pretend to replace Drupal core available features but to build on them and provide extended ones.
* While the upgrade scripts already work for nodes and taxonomy, there's other data that is simply deleted by the main Drupal 6 core upgrade, like the menu items language.
* Other parts like the multilingual block system have been completely reworked and will need manual reconfiguration. Existing normal blocks won't be lost but the language settings will need manual reconfiguration.
* The module layout, dependencies and names have important changes, so it is advised to take your time, read the new modules descriptions, and decide on which ones you new enabled, that may be different from the Drupal 5 ones.
The upgrade process
1. As with any other upgrade, make a full back up of your database before and set the site in off-line mode.
2. Disable all i18n modules (Disabling all contributed modules is always recommended) before upgrading to Drupal 6.
3. Upgrade your codebase and run the Drupal 6 standard upgrade
4. First, enable Drupal 6 core Translation module. Internationalization now relies on it.
5. Go through the Inernationalization package module list and enable the ones you need.
6. Run the update script again (update.php) so i18n modules can update their data properly
7. Review *all* the language settings (Drupal 6 core settings have also changed), and reconfigure your multilingual menus, blocks and path aliases.
After upgrading
* If you are using multilingual variables, some variable names have changed in Drupal 6. Review and update your settings.
* Language prefixes in path aliases are not supported anymore. Instead use the new language setting for path aliases. You'll need to update them manually
Monday, December 29, 2008
PHP Circle in Chennai
While many believe that the real action in the IT business happens in the large companies, there are very few who realise that there is life outside as well. There is a vast potential for Indian small-scale IT companies and the thousands of job-aspirant programmers/engineers who work with them.
A group of professionals and companies has joined hands to form Chennai’s first PHP professional forum, a free forum, called the ‘PHP Circle’.
While TCSes, Infosyses and Wipros are busy catering to the large US business segment for software development, there is a large, untapped segment viz., the US and European small online business market. This is one of the high growth markets today, especially in the US, as businesses built around strong revenue models are now emerging from the rubbles of the dot com bust.
Web applications market for small online business has its own characteristics. The size of each work is small, with low budgets (yet very viable for the Indian SSI IT market), and project management issues are more complex than the conventional software market. Still, Indian IT SSIs would do well to focus on these segments, as there is relatively less competition in this market from the established IT companies.
While Microsoft platforms and other higher-end tools are the preferred by medium of large-scale companies, small businesses prefer PHP and mySQL to develop their web applications in view of their being low-cost and being from the open source stable.
Due to the strong inroads that Microsoft ASP and .NET have made in providing easy tools to create web applications, and also due to the fact that India is favourably tilted towards Microsoft technology, there are not many trained programmers and solution-providers available to pursue PHP-based development. So, concerted efforts are required to develop manpower in PHP and mySQL. Companies willing to join these efforts are welcome to become members of this forum.
The activities proposed, all free of cost, include weekend classroom training for programmers, free tutorials, monthly forum meets with popular guest speakers, career-related contact opportunities, PHP Help Desk through bulletin boards, weekly newsletter with job postings by companies, sub-forums in engineering colleges and more.
Anyone with the required professional qualifications/programming experience and desirous of becoming a PHP programmer can become a free member of this circle. Since PHP is a fast expanding open source development tool, India can and must become the world leader in this widely used domain. And future prospects abound.
‘PHP Circle’ is a Chennai based non-profit forum. For More Information Click Here
A group of professionals and companies has joined hands to form Chennai’s first PHP professional forum, a free forum, called the ‘PHP Circle’.
While TCSes, Infosyses and Wipros are busy catering to the large US business segment for software development, there is a large, untapped segment viz., the US and European small online business market. This is one of the high growth markets today, especially in the US, as businesses built around strong revenue models are now emerging from the rubbles of the dot com bust.
Web applications market for small online business has its own characteristics. The size of each work is small, with low budgets (yet very viable for the Indian SSI IT market), and project management issues are more complex than the conventional software market. Still, Indian IT SSIs would do well to focus on these segments, as there is relatively less competition in this market from the established IT companies.
While Microsoft platforms and other higher-end tools are the preferred by medium of large-scale companies, small businesses prefer PHP and mySQL to develop their web applications in view of their being low-cost and being from the open source stable.
Due to the strong inroads that Microsoft ASP and .NET have made in providing easy tools to create web applications, and also due to the fact that India is favourably tilted towards Microsoft technology, there are not many trained programmers and solution-providers available to pursue PHP-based development. So, concerted efforts are required to develop manpower in PHP and mySQL. Companies willing to join these efforts are welcome to become members of this forum.
The activities proposed, all free of cost, include weekend classroom training for programmers, free tutorials, monthly forum meets with popular guest speakers, career-related contact opportunities, PHP Help Desk through bulletin boards, weekly newsletter with job postings by companies, sub-forums in engineering colleges and more.
Anyone with the required professional qualifications/programming experience and desirous of becoming a PHP programmer can become a free member of this circle. Since PHP is a fast expanding open source development tool, India can and must become the world leader in this widely used domain. And future prospects abound.
‘PHP Circle’ is a Chennai based non-profit forum. For More Information Click Here
Joomla 1.5 & Drupal 6.1 Performance Comparison
Alldrupalthemes.com did a performance comparision between Joomla 1.5 & Drupal 6.1. As the author of the post infers, the numbers collected may not mean much to the user in the "real world" and limitations in the test results should be noted. Nevertheless, numbers that compare Drupal and Joomla performance are always interesting.
The conclusions drawn from the results are:
1. Drupal is significantly faster than Joomla in all 4 setups
2. Drupal cuts down pageload time by ~74% when caching is enabled on the fresh install and ~86% with the more populated setup
3. Joomla cuts down pageload time by ~23% on the fresh install and ~20% on the more populated setup
These numbers are interesting and I bet the study pulls in a lot of visitors for All Drupal Themes. Not only are Drupal and Joomla users interested in these type of posts, but so are potential users shopping around the first time for a CMS. As always, you should judge a CMS by what it does for you and not what it does for others.
The conclusions drawn from the results are:
1. Drupal is significantly faster than Joomla in all 4 setups
2. Drupal cuts down pageload time by ~74% when caching is enabled on the fresh install and ~86% with the more populated setup
3. Joomla cuts down pageload time by ~23% on the fresh install and ~20% on the more populated setup
These numbers are interesting and I bet the study pulls in a lot of visitors for All Drupal Themes. Not only are Drupal and Joomla users interested in these type of posts, but so are potential users shopping around the first time for a CMS. As always, you should judge a CMS by what it does for you and not what it does for others.
Project usage overview
This page summarizes the usage of all projects on drupal.org. For each week beginning on the given date the figures show the number of sites that reported they are using (any version of) the project. Detailed usage information for each release of a project is available by clicking the project name.
These statistics are incomplete; only Drupal websites using the Update Status module are included in the data. As this module is now included with the download of Drupal since version 6.x, the data is heavily biased toward newer sites.For more information Click Here
These statistics are incomplete; only Drupal websites using the Update Status module are included in the data. As this module is now included with the download of Drupal since version 6.x, the data is heavily biased toward newer sites.For more information Click Here
Comparison Between Drupal And Joomla
Making comparisons between Joomla and Drupal are very common these days as they are currently considered the top two open source content management systems (CMS) out there. The forum post written by Steve Burge contains a link that takes you to a comparison table he did between Joomla and Drupal. While the table may not give the full picture of each CMS, I'm convinced that Burge tried to be as non-bias as he possibly could in his comparison.
There is something interesting about the table posted at Burge's site. Specifically, take a look at which elements according to Burge each CMS excels in and which elements each CMS fails. Did you notice a particular pattern in where each CMS is considered to have failed? If not, perhaps you didn't see the excerpt I posted earlier from Gadgetopia's Deane Barker, titled Architecture and Functionality in Content Management.
Let me be more specific. In the table Drupal fails on such elements as Shopping Carts, Event Calendars, Document Management, and Themes. The majority of these items are functions or features which are considered lacking in the Drupal CMS. Regarding the other CMS, Joomla fails to deliver in such elements as user permission, content management, multi-site management, and standard's compliance. Joomla fails in elements that are more architecture centric.
Taking the flip side, Joomla as a CMS appears to excel in elements that can be identified as functional, while Drupal succeeds in the architectural elements. Which element is more important in a CMS, architecture or function? According to Deane Barker he believes it is more important for a CMS to have better architecture.
As a developer with the capability to write code, I find myself much more concerned with architectural matters. Functionality can be programmed, but I’m at the mercy of architecture. Put another way, give me the right tools and materials, and I can build anything. But give me nothing but a pile of sand and a toothbrush, and I’m pretty much screwed.
In other words, if you agree with Barker that architecture is more important than function you're likely going to want to choose Drupal. However, if you need to make a quick sell where function, third party integration, and eye candy is important right out the box...Joomla still has the advantage.
What does the future hold in the post-Drupal 5 and post-Joomla 1.5 era? It's hard to say, but I'm betting Drupal will likely become very competitive in functions as it currently is in architecture. Then again Joomla may still pull a few punches as it continues to shed it's roots with Mambo. Interesting times ahead and I'll be quite interested how comparison tables such as the one we have been looking at will look like a couple more years down the road.
There is something interesting about the table posted at Burge's site. Specifically, take a look at which elements according to Burge each CMS excels in and which elements each CMS fails. Did you notice a particular pattern in where each CMS is considered to have failed? If not, perhaps you didn't see the excerpt I posted earlier from Gadgetopia's Deane Barker, titled Architecture and Functionality in Content Management.
Let me be more specific. In the table Drupal fails on such elements as Shopping Carts, Event Calendars, Document Management, and Themes. The majority of these items are functions or features which are considered lacking in the Drupal CMS. Regarding the other CMS, Joomla fails to deliver in such elements as user permission, content management, multi-site management, and standard's compliance. Joomla fails in elements that are more architecture centric.
Taking the flip side, Joomla as a CMS appears to excel in elements that can be identified as functional, while Drupal succeeds in the architectural elements. Which element is more important in a CMS, architecture or function? According to Deane Barker he believes it is more important for a CMS to have better architecture.
As a developer with the capability to write code, I find myself much more concerned with architectural matters. Functionality can be programmed, but I’m at the mercy of architecture. Put another way, give me the right tools and materials, and I can build anything. But give me nothing but a pile of sand and a toothbrush, and I’m pretty much screwed.
In other words, if you agree with Barker that architecture is more important than function you're likely going to want to choose Drupal. However, if you need to make a quick sell where function, third party integration, and eye candy is important right out the box...Joomla still has the advantage.
What does the future hold in the post-Drupal 5 and post-Joomla 1.5 era? It's hard to say, but I'm betting Drupal will likely become very competitive in functions as it currently is in architecture. Then again Joomla may still pull a few punches as it continues to shed it's roots with Mambo. Interesting times ahead and I'll be quite interested how comparison tables such as the one we have been looking at will look like a couple more years down the road.
Sunday, December 28, 2008
Chimop For Indesign
layout tool in InDesign that allows for semi-automatic page layouts. Chimp has little to do with Drupal per se, but it has a lot to do with making print media more accessible for low-budget organisations and newsrooms. The beta we're running locally has cut about a third off our layout time, and we're aiming at chopping a full half of our time spent layouting. It's different from PrintCasting in that it's intended for small newsrooms (locals, student newspapers, ...) that have a layout-staff and want to be more productive, rather than providing a fully-automatic solution for people who can't afford designers. It's different from other automatic layout systems (like DTI PageMagic, the ISI docuboxx, ...) in that it'll be free rather than unaffordable for us mere mortals.
Thursday, December 25, 2008
Overriding Theme Functions in Modules Instead of Template.php
Drupal's theming system offers developers and designers a flexible way to override default HTML output when specific portions of the page are rendered. Everything from the name of the currently logged in user to the HTML markup of the entire page can be customized by a plugin "theme".
Unfortunately, this system can be its own worst enemy. Themes are very powerful, but in many cases they're the only place where specific output can be changed without hacking core. Because of this, themes on highly customized production sites can easily turn into code-monsters, carrying the weight of making 'Drupal' look like 'My Awesome Site.'
This can make maintenance difficult, and it also makes sharing these tweaks with other Drupal developers tricky. In fact, some downloadable modules also come with instructions on how to modify a theme to 'complete' the module's work. Wouldn't it be great if certain re-usable theme overrides could be packaged up and distributed as part of any Drupal? As it turns out, that is possible. In this article, we'll be exploring two ways to do it: a tweaky, hacky approach for Drupal 5, and a clean and elegant approach that's only possible in Drupal 6.
Under the Hood
Before getting into the details, we'll look at how Drupal allows themes to override HTML rendering. This mechanism will be the key to our sneaky tricks.
Whenever 'themable' HTML is being generated, Drupal modules first assemble the basic data that should pre presented (an array of numbers, a content node...), then call the theme() function. For example:
$node = node_load(1); // Load node id 1 from the database
$output = theme('node', $node); // This generates themed HTML
print $output;
?>
The first paramater passed into the theme() function is the type of data being themed, while the second parameter is the 'thing' itself. When that function is called, Drupal walks through the following process:
1. Does the theme handle it?
The currently installed theme is first in line to render the object to HTML. Drupal checks for a function named theme-name_object-type(), and if it exists, calls it. For example, the Garland theme uses the function garland_breadcrumb() to control how the breadcrumb trail is displayed.
2. Does the theme engine handle it?
Next in line is the current 'theme engine.' In most cases, this is Drupal's default PHPTemplate theming engine. Smarty and PHPTal are other possibile engines. As with themes, Drupal checks for a function named theme-engine-name_object-type(), and if it exists, calls it. The PHPTemplate engine uses the function phptemplate_node() to control how nodes are displayed.
3. Let a module handle it.
Finally, if no overrides are found, Drupal checks for a function named theme_object-type() and calls it if it exists. These default theme functions are usually provided by modules to offer default HTML output for objects in case no one overrides them.
This approach is very flexible: it gives themes and the underlying theme engines a chance to override the HTML, lets modules provide a 'default' style of output, and it makes the complexities of the overriding process invisible to a developer who just wants to print out a node (or any other themable object) on a page. The only problem is that it doesn't provide a way for another module to jump in between steps 2 and 3, overriding the default HTML.
Drupal 5: Sneaky, Sneaky Hacks
In Drupal 5, there's no officially supported way to overcome this limitation, There is, however, a crafty trick you can use to override theme functions in your modules. Take a look back at step 2 in the explanation of Drupal's overriding process, again. Drupal checks to see whether a function named theme-engine-name_object-type() exists in order to see if a theme engine wants to override the rendering. If that function name exists, Drupal will use it -- even if it's implemented in your module, not the actual theme engine.
What does that mean? If your module implements the function phptemplate_username(), it will be treated as if it's the theme engine in step 2, overriding the default markup provided by Drupal core, without making any changes to the theme itself. Voila!
The downside, of course, is that if the theme engine you're using does provide its own override, no module can play this trick: the function name already exists, and trying to define it again in your module will cause PHP errors. It can still be a useful way to isolate site-specific chunks of theme code in a way that's easy to track, enable or disable, and so on.
Drupal 6: The Land of Milk and Honey
In Drupal 6, things are a bit different. The same basic hierarchy is still in place: first themes, then theme engines, then modules all get opportunities to render an object to HTML. However, Drupal now caches the information about what function should be used in an internal "theme registry." This saves Drupal the work of 'discovering' who's in charge each time the theme() function is called.
In addition to saving time, though, this cached "registry" of theme functions is something that modules can modify using the hook_theme_registry_alter() function. What does that mean? While a module can't insert itself between steps 2 and 3 in the discovery process, it can step in after the discovery process is complete, and replace the default function from step 1 with its own version -- even if it doesn't follow the naming conventions Drupal expects.
Let's take a quick look at how this works, stealing a snippet of code from the WordPress Comments module. It's a module that intercepts Drupal's default rendering of all form elements to tweak the appearance of labels and 'required' flags on certain forms.
function wp_comments_theme_registry_alter(&$theme_registry) {
if (!empty($theme_registry['form_element'])) {
$theme_registry['form_element']['function'] = 'wp_comments_form_element';
}
}
function wp_comments_form_element($element, $value) {
// Here, we provide our customized version of the
// theme_form_element function from theme.inc...
}
?>
The above code is pretty straightforward: in hook_theme_registry_alter(), it first checks to be sure that the form_element theme data is properly defined, then swaps in its own custom function (wp_comments_form_element) in place of the default one (theme_form_element).
The beautiful part of this system is that it continues to work cleanly with custom themes: if a theme overrides the form_element theming code as well, it will still take precedence over wp_comments' version. In addition, there's no chance of colliding function names, as it relies on the theme registry rather than 'magic' function names like phptemplate_form_element().
Unfortunately, this system can be its own worst enemy. Themes are very powerful, but in many cases they're the only place where specific output can be changed without hacking core. Because of this, themes on highly customized production sites can easily turn into code-monsters, carrying the weight of making 'Drupal' look like 'My Awesome Site.'
This can make maintenance difficult, and it also makes sharing these tweaks with other Drupal developers tricky. In fact, some downloadable modules also come with instructions on how to modify a theme to 'complete' the module's work. Wouldn't it be great if certain re-usable theme overrides could be packaged up and distributed as part of any Drupal? As it turns out, that is possible. In this article, we'll be exploring two ways to do it: a tweaky, hacky approach for Drupal 5, and a clean and elegant approach that's only possible in Drupal 6.
Under the Hood
Before getting into the details, we'll look at how Drupal allows themes to override HTML rendering. This mechanism will be the key to our sneaky tricks.
Whenever 'themable' HTML is being generated, Drupal modules first assemble the basic data that should pre presented (an array of numbers, a content node...), then call the theme() function. For example:
$node = node_load(1); // Load node id 1 from the database
$output = theme('node', $node); // This generates themed HTML
print $output;
?>
The first paramater passed into the theme() function is the type of data being themed, while the second parameter is the 'thing' itself. When that function is called, Drupal walks through the following process:
1. Does the theme handle it?
The currently installed theme is first in line to render the object to HTML. Drupal checks for a function named theme-name_object-type(), and if it exists, calls it. For example, the Garland theme uses the function garland_breadcrumb() to control how the breadcrumb trail is displayed.
2. Does the theme engine handle it?
Next in line is the current 'theme engine.' In most cases, this is Drupal's default PHPTemplate theming engine. Smarty and PHPTal are other possibile engines. As with themes, Drupal checks for a function named theme-engine-name_object-type(), and if it exists, calls it. The PHPTemplate engine uses the function phptemplate_node() to control how nodes are displayed.
3. Let a module handle it.
Finally, if no overrides are found, Drupal checks for a function named theme_object-type() and calls it if it exists. These default theme functions are usually provided by modules to offer default HTML output for objects in case no one overrides them.
This approach is very flexible: it gives themes and the underlying theme engines a chance to override the HTML, lets modules provide a 'default' style of output, and it makes the complexities of the overriding process invisible to a developer who just wants to print out a node (or any other themable object) on a page. The only problem is that it doesn't provide a way for another module to jump in between steps 2 and 3, overriding the default HTML.
Drupal 5: Sneaky, Sneaky Hacks
In Drupal 5, there's no officially supported way to overcome this limitation, There is, however, a crafty trick you can use to override theme functions in your modules. Take a look back at step 2 in the explanation of Drupal's overriding process, again. Drupal checks to see whether a function named theme-engine-name_object-type() exists in order to see if a theme engine wants to override the rendering. If that function name exists, Drupal will use it -- even if it's implemented in your module, not the actual theme engine.
What does that mean? If your module implements the function phptemplate_username(), it will be treated as if it's the theme engine in step 2, overriding the default markup provided by Drupal core, without making any changes to the theme itself. Voila!
The downside, of course, is that if the theme engine you're using does provide its own override, no module can play this trick: the function name already exists, and trying to define it again in your module will cause PHP errors. It can still be a useful way to isolate site-specific chunks of theme code in a way that's easy to track, enable or disable, and so on.
Drupal 6: The Land of Milk and Honey
In Drupal 6, things are a bit different. The same basic hierarchy is still in place: first themes, then theme engines, then modules all get opportunities to render an object to HTML. However, Drupal now caches the information about what function should be used in an internal "theme registry." This saves Drupal the work of 'discovering' who's in charge each time the theme() function is called.
In addition to saving time, though, this cached "registry" of theme functions is something that modules can modify using the hook_theme_registry_alter() function. What does that mean? While a module can't insert itself between steps 2 and 3 in the discovery process, it can step in after the discovery process is complete, and replace the default function from step 1 with its own version -- even if it doesn't follow the naming conventions Drupal expects.
Let's take a quick look at how this works, stealing a snippet of code from the WordPress Comments module. It's a module that intercepts Drupal's default rendering of all form elements to tweak the appearance of labels and 'required' flags on certain forms.
function wp_comments_theme_registry_alter(&$theme_registry) {
if (!empty($theme_registry['form_element'])) {
$theme_registry['form_element']['function'] = 'wp_comments_form_element';
}
}
function wp_comments_form_element($element, $value) {
// Here, we provide our customized version of the
// theme_form_element function from theme.inc...
}
?>
The above code is pretty straightforward: in hook_theme_registry_alter(), it first checks to be sure that the form_element theme data is properly defined, then swaps in its own custom function (wp_comments_form_element) in place of the default one (theme_form_element).
The beautiful part of this system is that it continues to work cleanly with custom themes: if a theme overrides the form_element theming code as well, it will still take precedence over wp_comments' version. In addition, there's no chance of colliding function names, as it relies on the theme registry rather than 'magic' function names like phptemplate_form_element().
Tuesday, December 23, 2008
Form Building in Drupal
It's the Form builder module: an AJAX, Drag and Drop interface for constructing forms in Drupal.The Form builder project reads and modifies Form API arrays. Using a well-known data-structure that most Drupal developers are familiar with should make for low barrier to entry for utilizing the new module.
The project uses a AJAX-based interface for updating form elements. As you modify properties such as "Title" or "Description", Form builder makes requests in the background to update the element through Drupal's internal FAPI system. The user gets a live preview of their changes without saving the form. This approach means that no additional JavaScript needs to be written by implementing modules, since the rendering is done in PHP and then sent to the client as needed. For Live Demo Click Here.This module is still very new, so it is not recommended using it on any production site.
The project uses a AJAX-based interface for updating form elements. As you modify properties such as "Title" or "Description", Form builder makes requests in the background to update the element through Drupal's internal FAPI system. The user gets a live preview of their changes without saving the form. This approach means that no additional JavaScript needs to be written by implementing modules, since the rendering is done in PHP and then sent to the client as needed. For Live Demo Click Here.This module is still very new, so it is not recommended using it on any production site.
Wednesday, November 26, 2008
Tuesday, November 25, 2008
Saturday, November 22, 2008
Five Good Features About Drupal 6 Than Previous Versions.
1.Performance. The Drupal core is much more efficient in Drupal 6 than in previous versions. Caching is employed much more in the theming process than formerly, so in serving a page time is not wasted looking for theme files and functions that don’t exist. The module system is much leaner, with files being loaded on demand rather than willy-nilly.
2.Schema module. There’s more abstraction available in the database layer, with the addition of the new Schema module which allows module developers to manipulate tables at a higher level.
3.AHAH Support. The forms API now includes AHAH support, which is either a subset of AJAX or a close cousin, depending on what book you read. Either way, it makes the creation of enhanced user interfaces much easier.
4.Improvements to CCK. The Content Construction Kit module has been greatly improved in Drupal 6, and the administration of fields and widgets is much easier as a result. One unfortunate effect however is that due to the API changes many CCK extensions developed for Drupal 5 have not been ported as yet at the time of writing. Another complaint is that the CCK API is still not well-documented or easy to write for.
5.Improvements to Views. The latest version of the Views module includes a new administration UI that - leaving aside a few idiosyncrasies - is a joy to work with. New views of data can be built and customized a lot more rapidly than formerly. If I have any complaint it is that field names in the data passed to row templates are still rather overlong and weird: the ability to give these short, sensible, aliases would be very helpful.
To summarise, Drupal 6 is in general a considerable improvement over its predecessors. However, the fact that a significant number of useful contributed modules are not yet available in usable form for production purposes is disappointing.
2.Schema module. There’s more abstraction available in the database layer, with the addition of the new Schema module which allows module developers to manipulate tables at a higher level.
3.AHAH Support. The forms API now includes AHAH support, which is either a subset of AJAX or a close cousin, depending on what book you read. Either way, it makes the creation of enhanced user interfaces much easier.
4.Improvements to CCK. The Content Construction Kit module has been greatly improved in Drupal 6, and the administration of fields and widgets is much easier as a result. One unfortunate effect however is that due to the API changes many CCK extensions developed for Drupal 5 have not been ported as yet at the time of writing. Another complaint is that the CCK API is still not well-documented or easy to write for.
5.Improvements to Views. The latest version of the Views module includes a new administration UI that - leaving aside a few idiosyncrasies - is a joy to work with. New views of data can be built and customized a lot more rapidly than formerly. If I have any complaint it is that field names in the data passed to row templates are still rather overlong and weird: the ability to give these short, sensible, aliases would be very helpful.
To summarise, Drupal 6 is in general a considerable improvement over its predecessors. However, the fact that a significant number of useful contributed modules are not yet available in usable form for production purposes is disappointing.
Monday, November 10, 2008
Tips for Mysql
1. use the explain command
Use multiple-row INSERT statements to store many rows with one SQL statement.
The explain command can tell you which indexes are used with the specified query and many other pieces of useful information that can help you choose a better index or query.
Example of usage: explain select * from table
explanation of row output:
* table—The name of the table.
* type—The join type, of which there are several.
* possible_keys—This column indicates which indexes MySQL could use to find the rows in this table. If the result is NULL, no indexes would help with this query. You should then take a look at your table structure and see whether there are any indexes that you could create that would increase the performance of this query.
* key—The key actually used in this query, or NULL if no index was used.
* key_len—The length of the key used, if any.
* ref—Any columns used with the key to retrieve a result.
* rows—The number of rows MySQL must examine to execute the query.
* extra—Additional information regarding how MySQL will execute the query. There are several options, such as Using index (an index was used) and Where (a WHERE clause was used).
2. use less complex permissions
The more complex your permissions setup, the more overhead you have. Using simpler permissions when you issue GRANT statements enables MySQL to reduce permission-checking overhead when clients execute statements.
3. specific mysql functions can be tested using the built-in “benchmark” command
If your problem is with a specific MySQL expression or function, you can perform a timing test by invoking the BENCHMARK() function using the mysql client program. Its syntax is BENCHMARK(loop_count,expression). The return value is always zero, but mysql prints a line displaying approximately how long the statement took to execute
4. optimize where clauses
* Remove unnecessary parentheses
* COUNT(*) on a single table without a WHERE is retrieved directly from the table information for MyISAM and MEMORY tables. This is also done for any NOT NULL expression when used with only one table.
* If you use the SQL_SMALL_RESULT option, MySQL uses an in-memory temporary table
5. Run optimize table
This command defragments a table after you have deleted a lot of rows from it.
6. avoid variable-length column types when necessary
For MyISAM tables that change frequently, you should try to avoid all variable-length columns (VARCHAR, BLOB, and TEXT). The table uses dynamic row format if it includes even a single variable-length column.
7. insert delayed
Use insert delayed when you do not need to know when your data is written. This reduces the overall insertion impact because many rows can be written with a single disk write.
8. use statement priorities
* Use INSERT LOW_PRIORITY when you want to give SELECT statements higher priority than your inserts.
* Use SELECT HIGH_PRIORITY to get retrievals that jump the queue. That is, the SELECT is executed even if there is another client waiting.
9. use multiple-row inserts
Use multiple-row INSERT statements to store many rows with one SQL statement.
10. synchronize data-types
Columns with identical information in different tables should be declared to have identical data types so that joins based on the corresponding columns will be faster.
Use multiple-row INSERT statements to store many rows with one SQL statement.
The explain command can tell you which indexes are used with the specified query and many other pieces of useful information that can help you choose a better index or query.
Example of usage: explain select * from table
explanation of row output:
* table—The name of the table.
* type—The join type, of which there are several.
* possible_keys—This column indicates which indexes MySQL could use to find the rows in this table. If the result is NULL, no indexes would help with this query. You should then take a look at your table structure and see whether there are any indexes that you could create that would increase the performance of this query.
* key—The key actually used in this query, or NULL if no index was used.
* key_len—The length of the key used, if any.
* ref—Any columns used with the key to retrieve a result.
* rows—The number of rows MySQL must examine to execute the query.
* extra—Additional information regarding how MySQL will execute the query. There are several options, such as Using index (an index was used) and Where (a WHERE clause was used).
2. use less complex permissions
The more complex your permissions setup, the more overhead you have. Using simpler permissions when you issue GRANT statements enables MySQL to reduce permission-checking overhead when clients execute statements.
3. specific mysql functions can be tested using the built-in “benchmark” command
If your problem is with a specific MySQL expression or function, you can perform a timing test by invoking the BENCHMARK() function using the mysql client program. Its syntax is BENCHMARK(loop_count,expression). The return value is always zero, but mysql prints a line displaying approximately how long the statement took to execute
4. optimize where clauses
* Remove unnecessary parentheses
* COUNT(*) on a single table without a WHERE is retrieved directly from the table information for MyISAM and MEMORY tables. This is also done for any NOT NULL expression when used with only one table.
* If you use the SQL_SMALL_RESULT option, MySQL uses an in-memory temporary table
5. Run optimize table
This command defragments a table after you have deleted a lot of rows from it.
6. avoid variable-length column types when necessary
For MyISAM tables that change frequently, you should try to avoid all variable-length columns (VARCHAR, BLOB, and TEXT). The table uses dynamic row format if it includes even a single variable-length column.
7. insert delayed
Use insert delayed when you do not need to know when your data is written. This reduces the overall insertion impact because many rows can be written with a single disk write.
8. use statement priorities
* Use INSERT LOW_PRIORITY when you want to give SELECT statements higher priority than your inserts.
* Use SELECT HIGH_PRIORITY to get retrievals that jump the queue. That is, the SELECT is executed even if there is another client waiting.
9. use multiple-row inserts
Use multiple-row INSERT statements to store many rows with one SQL statement.
10. synchronize data-types
Columns with identical information in different tables should be declared to have identical data types so that joins based on the corresponding columns will be faster.
Wednesday, November 5, 2008
CakePHP - For robust web applications
CakePHP is a framework for PHP that provides an extensible architecture for developing, maintaining, and deploying applications. Through which it will create forms by itself based on the columns we specify in database. Live Demo where cakePHP integrated with modal dialog box. For futher information please visit CakePHP.
Tuesday, November 4, 2008
Steps For Installing & Configuring Apache PHP and MySQL
Installing Apache
Installing apache is easy if you download the Microsoft Installer ( .msi ) package. Just double click on the icon to run the installation wizard. Click next until you see the Server Information window. You can enter localhost for both the Network Domain and Server Name. As for the administrator's email address you can enter anything you want.I'm using Windows XP and installed Apache as Service so everytime I start Windows Apache is automatically started.
Click the Next button and choose Typical installation. Click Next one more time and choose where you want to install Apache ( I installed it in the default location C:\Program Files\Apache Group ). Click the Next button and then the Install button to complete the installation process.To see if you Apache installation was successful open up you browser and type "http://localhost" in the address bar. You should see something like this :
By default Apache's document root is set to htdocs directory. The document root is where you must put all your PHP or HTML files so it will be process by Apache ( and can be seen through a web browser ). Of course you can change it to point to any directory you want. The configuration file for Apache is stored in C:\Program Files\Apache Group\Apache2\conf\httpd.conf ( assuming you installed Apache in C:\Program Files\Apache Group ) . It's just a plain text file so you can use Notepad to edit it.
For example, if you want to put all your PHP or HTML files in C:\www just find this line in the httpd.conf :
DocumentRoot "C:/Program Files/Apache Group/Apache2/htdocs"
and change it to :
DocumentRoot "C:/www"
After making changes to the configuration file you have to restart Apache ( Start > Programs > Apache HTTP Server 2.0.50 > Control Apache Server > Restart ) to see the effect.
Another configuration you may want to change is the directory index. This is the file that Apache will show when you request a directory. As an example if you type http://www.php-mysql-tutorial.com/ without specifying any file the index.php file will be automatically shown.
Suppose you want apache to use index.html, index.php or main.php as the directory index you can modify the DirectoryIndex value like this :
DirectoryIndex index.html index.php main.php
Now whenever you request a directory such as http://localhost/ Apache will try to find the index.html file or if it's not found Apache will use index.php. In case index.php is also not found then main.php will be used.
Installing PHP
First, extract the PHP package ( php-4.3.10-Win32.zip ). I extracted the package in the directory where Apache was installed ( C:\Program Files\Apache Group\Apache2 ). Change the new created directory name to php ( just to make it shorter ). Then copy the file php.ini-dist in PHP directory to you windows directory ( C:\Windows or C:\Winnt depends on where you installed Windows ) and rename the file to php.ini. This is the PHP configuration file and we'll take a look what's in it later on.
Next, move the php4ts.dll file from the newly created php directory into the sapi subdirectory. Quoting from php installation file you can also place php4ts.dll in other places such as :
* In the directory where apache.exe is start from ( C:\Program Files\Apache Group\Apache2 \bin)
* In your %SYSTEMROOT%\System32, %SYSTEMROOT%\system and %SYSTEMROOT% directory.
Note: %SYSTEMROOT%\System32 only applies to Windows NT/2000/XP)
* In your whole %PATH%
Modifying Apache Configuration
Apache doesn't know that you just install PHP. We need to tell Apache about PHP and where to find it. Open the Apache configuration file in C:\Program Files\Apache Group\Apache2\conf\httpd.conf and add the following three lines :
LoadModule php4_module php/sapi/php4apache2.dll
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
The first line tells Apache where to load the dll required to execute PHP and the second line means that every file that ends with .php should be processed as a PHP file. You can actually change it to anything you want like .html or even .asp! The third line is added so that you can view your php file source code in the browser window. You will see what this mean when you browse this tutorial and click the link to the example's source code like this one.
Now restart Apache for the changes to take effect ( Start > Programs > Apache HTTP Server 2.0.50 > Control Apache Server > Restart ) . To check if everything is okay create a new file, name it as test.php and put it in document root directory ( C:\Program Files\Apache Group\Apache2\htdocs ). The content of this file is shown below.
phpinfo();
?>
phpinfo() is the infamous PHP function which will spit out all kinds of stuff about PHP and your server configuration.
Installing MySQL
First extract the package ( mysql-4.0.18-win.zip ) to a temporary directory, then run setup.exe. Keep clicking the next button to complete the installation. By default MySQL will be installed in C:\mysql.
Open a DOS window and go to C:\mysql\bin and then run mysqld-nt --console , you should see some messages like these :
C:\mysql\bin>mysqld-nt --console
InnoDB: The first specified data file .\ibdata1 did not exist:
InnoDB: a new database to be created!
040807 10:54:09 InnoDB: Setting file .\ibdata1 size to 10 MB
InnoDB: Database physically writes the file full: wait...
040807 10:54:11 InnoDB: Log file .\ib_logfile0 did not exist: new to be created
InnoDB: Setting log file .\ib_logfile0 size to 5 MB
InnoDB: Database physically writes the file full: wait...
040807 10:54:12 InnoDB: Log file .\ib_logfile1 did not exist: new to be created
InnoDB: Setting log file .\ib_logfile1 size to 5 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Doublewrite buffer not found: creating new
InnoDB: Doublewrite buffer created
InnoDB: Creating foreign key constraint system tables
InnoDB: Foreign key constraint system tables created
040807 10:54:31 InnoDB: Started
mysqld-nt: ready for connections.
Version: '4.0.18-nt' socket: '' port: 3306
Now open another DOS window and type C:\mysql\bin\mysql
if your installation is successful you will see the MySQL client running :
C:\mysql\bin>mysql
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 4.0.18-nt
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql>
Type exit on the mysql> prompt to quit the MySQL client.
Now let's install MySQL as a Service. The process is simple just type mysqld-nt --install to install the service and net start mysql to run the service. But make sure to shutdown the server first using mysqladmin -u root shutdown
C:\mysql\bin>mysqladmin -u root shutdown
C:\mysql\bin>mysqld-nt --install
Service successfully installed.
C:\mysql\bin>net start mysql
The MySQL service was started successfully.
C:\mysql\bin>mysql
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 4.0.18-nt
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql>.
Installing apache is easy if you download the Microsoft Installer ( .msi ) package. Just double click on the icon to run the installation wizard. Click next until you see the Server Information window. You can enter localhost for both the Network Domain and Server Name. As for the administrator's email address you can enter anything you want.I'm using Windows XP and installed Apache as Service so everytime I start Windows Apache is automatically started.
Click the Next button and choose Typical installation. Click Next one more time and choose where you want to install Apache ( I installed it in the default location C:\Program Files\Apache Group ). Click the Next button and then the Install button to complete the installation process.To see if you Apache installation was successful open up you browser and type "http://localhost" in the address bar. You should see something like this :
By default Apache's document root is set to htdocs directory. The document root is where you must put all your PHP or HTML files so it will be process by Apache ( and can be seen through a web browser ). Of course you can change it to point to any directory you want. The configuration file for Apache is stored in C:\Program Files\Apache Group\Apache2\conf\httpd.conf ( assuming you installed Apache in C:\Program Files\Apache Group ) . It's just a plain text file so you can use Notepad to edit it.For example, if you want to put all your PHP or HTML files in C:\www just find this line in the httpd.conf :
DocumentRoot "C:/Program Files/Apache Group/Apache2/htdocs"
and change it to :
DocumentRoot "C:/www"
After making changes to the configuration file you have to restart Apache ( Start > Programs > Apache HTTP Server 2.0.50 > Control Apache Server > Restart ) to see the effect.
Another configuration you may want to change is the directory index. This is the file that Apache will show when you request a directory. As an example if you type http://www.php-mysql-tutorial.com/ without specifying any file the index.php file will be automatically shown.
Suppose you want apache to use index.html, index.php or main.php as the directory index you can modify the DirectoryIndex value like this :
DirectoryIndex index.html index.php main.php
Now whenever you request a directory such as http://localhost/ Apache will try to find the index.html file or if it's not found Apache will use index.php. In case index.php is also not found then main.php will be used.
Installing PHP
First, extract the PHP package ( php-4.3.10-Win32.zip ). I extracted the package in the directory where Apache was installed ( C:\Program Files\Apache Group\Apache2 ). Change the new created directory name to php ( just to make it shorter ). Then copy the file php.ini-dist in PHP directory to you windows directory ( C:\Windows or C:\Winnt depends on where you installed Windows ) and rename the file to php.ini. This is the PHP configuration file and we'll take a look what's in it later on.
Next, move the php4ts.dll file from the newly created php directory into the sapi subdirectory. Quoting from php installation file you can also place php4ts.dll in other places such as :
* In the directory where apache.exe is start from ( C:\Program Files\Apache Group\Apache2 \bin)
* In your %SYSTEMROOT%\System32, %SYSTEMROOT%\system and %SYSTEMROOT% directory.
Note: %SYSTEMROOT%\System32 only applies to Windows NT/2000/XP)
* In your whole %PATH%
Modifying Apache Configuration
Apache doesn't know that you just install PHP. We need to tell Apache about PHP and where to find it. Open the Apache configuration file in C:\Program Files\Apache Group\Apache2\conf\httpd.conf and add the following three lines :
LoadModule php4_module php/sapi/php4apache2.dll
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
The first line tells Apache where to load the dll required to execute PHP and the second line means that every file that ends with .php should be processed as a PHP file. You can actually change it to anything you want like .html or even .asp! The third line is added so that you can view your php file source code in the browser window. You will see what this mean when you browse this tutorial and click the link to the example's source code like this one.
Now restart Apache for the changes to take effect ( Start > Programs > Apache HTTP Server 2.0.50 > Control Apache Server > Restart ) . To check if everything is okay create a new file, name it as test.php and put it in document root directory ( C:\Program Files\Apache Group\Apache2\htdocs ). The content of this file is shown below.
phpinfo();
?>
phpinfo() is the infamous PHP function which will spit out all kinds of stuff about PHP and your server configuration.
Installing MySQL
First extract the package ( mysql-4.0.18-win.zip ) to a temporary directory, then run setup.exe. Keep clicking the next button to complete the installation. By default MySQL will be installed in C:\mysql.
Open a DOS window and go to C:\mysql\bin and then run mysqld-nt --console , you should see some messages like these :
C:\mysql\bin>mysqld-nt --console
InnoDB: The first specified data file .\ibdata1 did not exist:
InnoDB: a new database to be created!
040807 10:54:09 InnoDB: Setting file .\ibdata1 size to 10 MB
InnoDB: Database physically writes the file full: wait...
040807 10:54:11 InnoDB: Log file .\ib_logfile0 did not exist: new to be created
InnoDB: Setting log file .\ib_logfile0 size to 5 MB
InnoDB: Database physically writes the file full: wait...
040807 10:54:12 InnoDB: Log file .\ib_logfile1 did not exist: new to be created
InnoDB: Setting log file .\ib_logfile1 size to 5 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Doublewrite buffer not found: creating new
InnoDB: Doublewrite buffer created
InnoDB: Creating foreign key constraint system tables
InnoDB: Foreign key constraint system tables created
040807 10:54:31 InnoDB: Started
mysqld-nt: ready for connections.
Version: '4.0.18-nt' socket: '' port: 3306
Now open another DOS window and type C:\mysql\bin\mysql
if your installation is successful you will see the MySQL client running :
C:\mysql\bin>mysql
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 4.0.18-nt
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql>
Type exit on the mysql> prompt to quit the MySQL client.
Now let's install MySQL as a Service. The process is simple just type mysqld-nt --install to install the service and net start mysql to run the service. But make sure to shutdown the server first using mysqladmin -u root shutdown
C:\mysql\bin>mysqladmin -u root shutdown
C:\mysql\bin>mysqld-nt --install
Service successfully installed.
C:\mysql\bin>net start mysql
The MySQL service was started successfully.
C:\mysql\bin>mysql
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 4.0.18-nt
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql>.
Sunday, November 2, 2008
Drupal Uses OOPS Concepts Or Not ?
“Drupal” - One of the most popular open sources content management system and framework built with PHP language, summary is - Drupal doesn’t use a single Class in its code base. Whole Drupal code base is based on just functions. As PHP, with which programming language Drupal itself is built, is also implementing many powerful OPP features, but Drupal is not using these features.Actually, the OOP concept is not based on uses of data structures like CLASS. It is based on the fundamentals of features like Objects, Abstraction, Encapsulation, Polymorphism, Inheritance etc.
If these fundamental features are included in programming then it can be considered in OOP.There is no keyword ‘class’ in Drupal code. Drupal is as non-OOP as many programmers do. But that is not true. Drupal doesn’t contain any class like data structure; still it is still Object Oriented.Drupal covers all these features without classes. Power of Drupal is hardly depends on this programming structure only. The way, how the hook system has been implemented in Drupal would never been possible with the use of Classes.See more details about how Drupal implements Object Oriented Programming (OOP) without using Classes, visit:http://api.drupal.org
If these fundamental features are included in programming then it can be considered in OOP.There is no keyword ‘class’ in Drupal code. Drupal is as non-OOP as many programmers do. But that is not true. Drupal doesn’t contain any class like data structure; still it is still Object Oriented.Drupal covers all these features without classes. Power of Drupal is hardly depends on this programming structure only. The way, how the hook system has been implemented in Drupal would never been possible with the use of Classes.See more details about how Drupal implements Object Oriented Programming (OOP) without using Classes, visit:http://api.drupal.org
Saturday, November 1, 2008
Useful & Quick CSS Injector Module - Drupal 6
This CSS Injector module allows administrators to inject CSS into the page output based on configurable rules.It's useful for adding simple CSS tweaks without modifying a site's official theme -- for example, a 'nighttime' color scheme could be added during certain hours. The CSS is added using Drupal's standard drupal_add_css() function and respects page caching.For downloading this module please visit CSS Injector
Thursday, October 30, 2008
Speed up a Drupal web site by using a simpler theme
A Drupal theme controls the look of a web site by setting text colors, fonts, and decorative images. Speed up a web site by selecting a theme that has fewer and smaller images and CSS files. This will make your web pages smaller, faster to send to your site's visitors, and easier for their web browsers to draw.The CSS and image files of Drupal's default "Garland" theme account for up to 50% of the page size. Other themes are much larger with more CSS, images, and JavaScript. Speed up a site by using a simpler theme with fewer files to download on every page.A wide variety of free themes are available in the Themes section of the Drupal web site. The themes vary a lot in size and complexity. To know more about size of common themes visit Speed up a Drupal web site by using a simpler theme.
Sunday, October 26, 2008
Drupal Con * DC
Drupal conference is going to be held on march 4-7 2009. It is the event for drupal developers.It's where decisions are made, clients and talent are found, and new stuff is unveiled. For more information visit
.
.
Drupal 6.6 released
The newer verson Drupal 6.6 has been released.Drupal 6.6 maintenance releases fixing problems reported using the bug tracking system, as well as critical security vulnerabilities, are now available for download.There are no new features in these releases. For more information about the Drupal 6.x release series, consult the Drupal 6.0 release announcement.
Friday, October 24, 2008
Contributing our modules in Drupal.org
Recently myself and my project lead abdu rahim along with help of our DCC(drupal competency center) team created our own custom module "email_blast" where we can send bulk emails and also we can track in database when the users has read the email. we are also tracking the number of times the user has read the mail. we are sure there is not such module in drupal.org. After making it to drupal coding standars we are planning to put it in drupal.org site after getting prior permission from our company.
Friday, October 17, 2008
Upcoming Ruby On Rail
Ruby on Rails is MVC framework with powerful oop concept than java. Many leading companies have started using it.So it's a great fit for practically any type of web application let be a software for collaboration, community, e-commerce, content management, statistics, management.
Thursday, October 16, 2008
Article Writing
I am going to start writing article about various new technologies like iphones,xbox. For this article writing i have contacted one writer where he will specify the product and rate for each article.
Tuesday, October 14, 2008
LightBox Effect for websites
Most of the websites are using ajax and lightbox for opening an innerform or to show a n informative message. Similarly through drupal 6 "popups" module we can customize in our custom forms to give that lightbox effect. We are planning to incorprate these things in our upcoming projects.
Sunday, October 12, 2008
PHPFree Chat Customization
In drupal there is a module called "Phpfreechat" which customizes free source of PHPFreechat. But it has lot of bugs in it. I have integrated the the free source of PHPfreechat and customized to use it in drupal.
Subscribe to:
Posts (Atom)