Saturday, September 3, 2011

How to Configure CAS (Central Authentication Service) for Drupal?

I have had a long time to learn how to set up CAS (Central Authentication Service) to be used with Drupal. Obviously you need drupal's contrib module 'cas' and phpCAS library but there are some initial settings that needs to be configured in many places. I had a tough time to try out these but finally I am happy to share these information with all the drupal guys who believes in the capability of Drupal CMS.

Just follow the step by step guide to configure java sdk, apache tomcat, maven, cas , jdbc mysql connector and other configuration files. Here we go...

I would like you people use linux platform to use these steps.

First you need to prepare your CAS server up and running with SSL enabled.

#To install java 6 sdk in linux
1. Check /usr/lib/jvm for already installed java
2. Type: “apt-get update”
3. Type: “apt-get install sun-java6-jdk”

#To install Apache Tomcat
1. sudo wget
2. tar xvzf apache-tomcat-6.0.33.tar.gz
3. sudo mv apache-tomcat-6.0.3 /usr/local/tomcat
4. vi ~/.bashrc
5. Add this line at the end ==> export JAVA_HOME=/usr/lib/jvm/java-6-sun
6. sh /usr/local/tomcat/bin/   ,  sh /usr/local/tomcat/bin/

#To install Maven
1. sudo apt-get install maven2
2. sudo apt-get install ant
3. sudo apt-get install maven-ant-helper

#To install jConnector
1. wget
2. tar xvzf mysql-connector-java-5.0.8.tar.gz

#To install CAS server software
1. wget
2. tar xvzf cas-server-3.3.3-release.tar.gz
3. cd cas-server-3.3.3
4. cd cas-server-webapp
5. Edit pom.xml and add the following lines before ending '' tag:




6. [Dont change the current directory!]

a) mvn install:install-file -DgroupId=mysql -DartifactId=mysql-connector-java -Dversion=5.0.8-bin -Dpackaging=jar -Dfile=/home//mysql-connector-java-5.0.8/mysql-connector-java-5.0.8-bin.jar

b) mvn package install  

7. cp target/cas.war /usr/local/tomcat/webapps/
8. sudo /usr/local/tomcat/bin/
9. Go : http://servername:8080/cas/  to check whether server is running or not.

10. cp ~/mysql-connector-java-5.0.8/mysql-connector-java-5.0.8-bin.jar /usr/local/tomcat/webapps/cas/WEB-INF/lib/

11. Create table

CREATE TABLE users (username char(20) PRIMARY KEY NOT NULL, password char(64));
INSERT INTO users(username, password) VALUES ('test',MD5('test'));

12. cd /usr/local/tomcat/webapps/cas/WEB-INF/
13. Open file deployerConfigContext.xml and

Search for the following line:

Replace it with :






14. In deployerConfigContext.xml, just before ending of the
tag, add the following:






15. Restart Tomcat server and recheck.

16. Use CAS library phpCAS version 1.1.0 for proper functionality
17. check whether the CAS server has https enabled or not.(Redirects to https page.)

#To install SSL on tomcat

1. $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA         [Specify a password value of "changeit"]
it will generate a .keystore file at the home of the server /home//.keystore

2. Open /usr/local/tomcat/server.xml and do the followings:

    Find a connector having port="8443";
Now uncomment the section and make the line as following:

           scheme="https" secure="true" SSLEnabled="true"
           keystoreFile="/home/anish/.keystore" keystorePass="changeit"
           clientAuth="false" sslProtocol="TLS"/>

    Also comment this line: ''

3. Edit /usr/local/tomcat/conf/tomcat-users.xml to add users to manage tomcat server

Finally VVV Important ==> In CAS settings page, Set CAS version to 1.0, If you put 2.0 or higher , it will throw error.

Wednesday, May 18, 2011

Sample Interview Questions for Drupal Themer

General questions

1. What is a theme override?
2. What's the difference between a theme override and a template file?
3. Where is the place for placing a theme override?
4. Where is the place for placing a template file? What are the differences in template files on D5 and D6?
5. What are the template files involved in theming an Ubercart invoice?
6. Have you worked with 960gs before? If not, have you worked with any kind of grid layout framework? Even if you have no experience with this, you should take a quick look at both the drupal theme and the 960gs framework and comment how you see working with 960gs can help you when developing a drupal theme.

Questions on theme development
A simple e-commerce site is needed - all the functionality has been coded. Regular static pages (about us, contact us, terms and conditions etc) plus a product with several fields (title, size, color, body, main image, additional images, price, SKU, etc.)

We assume you have knowledge of CCK & Views as those modules would be used both for creating the content types and working on different displays that will probably need to be themed. We are going to use imagefield module for the images and imagecache module for thumbs and other images sizes.

In your answers, we are looking for certain basics on drupal theme development, you don't need to provide any code, just brief answers that indicate how you would handle each point. Please explain the specifics involved in a proper drupal theme, such as template files that you might use, what alternatives around drupal (modules, etc.) you can suggest or what function (don't need the exact name) you think you would override.

1. How would you work with the main images and the additional images on the theme? What would you do and what templates file are you planning on changing?
2. How would you work on the the theme to selectively display certain fields of the product in a very specific way to match a design, something that's not configurable through the content type display administration section?
3. How would you display the main image with a normal size and additional images as thumbnails just below the main image, in a grid-like form displaying three per row. Also, what would you do if an image swap effect between the thumbnail and the main image is required?
4. If we need a block display up to 6 products in a 3 column scheme on top of the content, how would you do this?
5. How would you theme the checkout page of an Ubercart e-commerce site?

Sunday, May 15, 2011

Interview Questions for Drupal.

1. What is CMS?
A content management system (CMS) is a collection of procedures used to manage work flow in a collaborative environment. These procedures can be manual or computer-based. The procedures are designed to:
* Allow for a large number of people to contribute to and share stored data
* Control access to data, based on user roles. User roles define what information each user can view or edit
* Aid in easy storage and retrieval of data
* Reduce repetitive duplicate input
* Improve the ease of report writing
* Improve communication between users
In a CMS, data can be defined as almost anything – documents, movies, pictures, phone numbers, scientific data, etc. CMSs are frequently used for storing, controlling, revising, semantically enriching, and publishing documentation. Content that is controlled is industry-specific. For example, entertainment content differs from the design documents for a fighter jet. There are various terms for systems (related processes) that do this. Examples are web content management, digital asset management, digital records management and electronic content management. Synchronization of intermediate steps, and collation into a final product are common goals of each.
cms,drupal,drupal cms,interview questions,technical,joomla,joomla cms,drupal interview question,content management system

2. What is a web content Management system ?
A Web content management system (WCM, WCMS or Web CMS) is content management system (CMS) software, implemented as a Web application, for creating and managing HTML content. It is used to manage and control a large, dynamic collection of Web material (HTML documents and their associated images). A WCMS facilitates content creation, content control, editing, and essential Web maintenance functions.
The software provides authoring (and other) tools designed to allow users with little knowledge of programming languages or markup languages to create and manage content with relative ease.
Most systems use a database to store content, metadata, or artifacts that might be needed by the system. Content is frequently, but not universally, stored as XML, to facilitate reuse and enable flexible presentation options.
A presentation layer displays the content to Web-site visitors based on a set of templates. The templates are sometimes XSLT files.
Most systems use server side caching boosting performance. This works best when the WCMS is not changed often but visits happen on a regular basis.
Administration is typically done through browser-based interfaces, but some systems require the use of a fat client.
Unlike Web-site builders, a WCMS allows non-technical users to make changes to a website with little training. A WCMS typically requires an experienced coder to set up and add features, but is primarily a Web-site maintenance tool for non-technical administrators.

3. Which are commonly used PHP based CMSs ?

4. What is Drupal ?
Drupal is an open-source platform and content management system for building dynamic web sites offering a broad range of features and services including user administration, publishing workflow, discussion capabilities, news aggregation, metadata functionalities using controlled vocabularies and XML publishing for content sharing purposes. Equipped with a powerful blend of features and configurability, Drupal can support a diverse range of web projects ranging from personal weblogs to large community-driven sites.

5. What is an Open source software ?
Open-source software (OSS) is computer software for which the source code and certain other rights normally reserved for copyright holders are provided under a software license that meets the Open Source Definition or that is in the public domain.This permits users to use, change, and improve the software, and to redistribute it in modified or unmodified forms. It is very often developed in a public, collaborative manner.
Open source doesn’t just mean access to the source code.
The distribution terms of open-source software must comply with the following criteria:

1. Free Redistribution
The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

2. Source Code
The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.

3. Derived Works
The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

4. Integrity of The Author’s Source Code
The license may restrict source-code from being distributed in modified form only if the license allows the distribution of “patch files” with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.

5. No Discrimination Against Persons or Groups
The license must not discriminate against any person or group of persons.

6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

7. Distribution of License
The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.

8. License Must Not Be Specific to a Product
The rights attached to the program must not depend on the program’s being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program’s license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.

9. License Must Not Restrict Other Software
The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.

10. License Must Be Technology-Neutral
No provision of the license may be predicated on any individual technology or style of interface.

6. What are GNU Licenses ?
Does free software mean using the GPL?
Not at all—there are many other free software licenses. We have an incomplete list. Any license that provides the user certain specific freedoms is a free software license.

7. Why are so many Drupal versions available – 4.x, 5.x …? Which one should I use?
It is recommended that you run the most current stable release. This can always be found at the Drupal Project page. However, if there are no compelling features in the latest version, a contrib module that is important to you isn’t ready or you don’t have time, there is no need to rush your upgrade as long as security updates are available for the version you are running.

8. Can I use Drupal on the command line?
Yes, you can use drush –
drush is a command line shell and Unix scripting interface for Drupal

9. What are hooks in Drupal ?
Allow modules to interact with the Drupal core.
Drupal’s module system is based on the concept of “hooks”. A hook is a PHP function that is named foo_bar(), where “foo” is the name of the module (whose filename is thus foo.module) and “bar” is the name of the hook. Each hook has a defined set of parameters and a specified result type.
To extend Drupal, a module need simply implement a hook. When Drupal wishes to allow intervention from modules, it determines which modules implement a hook and calls that hook in all enabled modules that implement it.

10 what is Database abstraction layer in Drupal ?
Allow the use of different database servers using the same code base.
Drupal provides a slim database abstraction layer to provide developers with the ability to support multiple database servers easily. The intent of this layer is to preserve the syntax and power of SQL as much as possible, while letting Drupal control the pieces of queries that need to be written differently for different servers and provide basic security checks.
Most Drupal database queries are performed by a call to db_query() or db_query_range(). Module authors should also consider using pager_query() for queries that return results that need to be presented on multiple pages, and tablesort_sql() for generating appropriate queries for sortable tables.

11. Explain the menu system in Drupal ? Purpose of menus ?
Define the navigation menus, and route page requests to code based on URLs.
The Drupal menu system drives both the navigation system from a user perspective and the callback system that Drupal uses to respond to URLs passed from the browser. For this reason, a good understanding of the menu system is fundamental to the creation of complex modules.
Drupal’s menu system follows a simple hierarchy defined by paths. Implementations of hook_menu() define menu items and assign them to paths (which should be unique). The menu system aggregates these items and determines the menu hierarchy from the paths. For example, if the paths defined were a, a/b, e, a/b/c/d, f/g, and a/b/h, the menu system would form the structure:
Note that the number of elements in the path does not necessarily determine the depth of the menu item in the tree.
When responding to a page request, the menu system looks to see if the path requested by the browser is registered as a menu item with a callback. If not, the system searches up the menu tree for the most complete match with a callback it can find. If the path a/b/i is requested in the tree above, the callback for a/b would be used.
The found callback function is called with any arguments specified in the “page arguments” attribute of its menu item. The attribute must be an array. After these arguments, any remaining components of the path are appended as further arguments. In this way, the callback for a/b above could respond to a request for a/b/i differently than a request for a/b/j.
For an illustration of this process, see page_example.module.
Access to the callback functions is also protected by the menu system. The “access callback” with an optional “access arguments” of each menu item is called before the page callback proceeds. If this returns TRUE, then access is granted; if FALSE, then access is denied. Menu items may omit this attribute to use the value provided by an ancestor item.
In the default Drupal interface, you will notice many links rendered as tabs. These are known in the menu system as “local tasks”, and they are rendered as tabs by default, though other presentations are possible. Local tasks function just as other menu items in most respects. It is convention that the names of these tasks should be short verbs if possible. In addition, a “default” local task should be provided for each set. When visiting a local task’s parent menu item, the default local task will be rendered as if it is selected; this provides for a normal tab user experience. This default task is special in that it links not to its provided path, but to its parent item’s path instead. The default task’s path is only used to place it appropriately in the menu hierarchy.
Everything described so far is stored in the menu_router table. The menu_links table holds the visible menu links. By default these are derived from the same hook_menu definitions, however you are free to add more with menu_link_save().

12. How to interact with Drupal search system ?
There are three ways to interact with the search system:
Specifically for searching nodes, you can implement nodeapi(‘update index’) and nodeapi(‘search result’). However, note that the search system already indexes all visible output of a node, i.e. everything displayed normally by hook_view() and hook_nodeapi(‘view’). This is usually sufficient. You should only use this mechanism if you want additional, non-visible data to be indexed.
Implement hook_search(). This will create a search tab for your module on the /search page with a simple keyword search form. You may optionally implement hook_search_item() to customize the display of your results.
Implement hook_update_index(). This allows your module to use Drupal’s HTML indexing mechanism for searching full text efficiently.
If your module needs to provide a more complicated search form, then you need to implement it yourself without hook_search(). In that case, you should define it as a local task (tab) under the /search page (e.g. /search/mymodule) so that users can easily find it.

13. What is a Module in drupal ?
A module is software (code) that extends Drupal features and/or functionality. Core modules are those included with the main download of Drupal, and you can turn on their functionality without installing additional software. Contributed modules are downloaded from the Modules download section of, and installed within your Drupal installation. You can also create your own modules; this requires a thorough understanding of Drupal, PHP programming, and Drupal’s module API.

14. Explain User, Permission, Role in drupal.
Every visitor to your site, whether they have an account and log in or visit the site anonymously, is considered a user to Drupal. Each user has a numeric user ID, and non-anonymous users also have a user name and an email address. Other information can also be associated with users by modules; for instance, if you use the core Profile module, you can define user profile fields to be associated with each user.
Anonymous users have a user ID of zero (0). The user with user ID one (1), which is the user account you create when you install Drupal, is special: that user has permission to do absolutely eveything on the site.
Other users on your site can be assigned permissions via roles. To do this, you first need to create a role, which you might call “Content editor” or “Member”. Next, you will assign permissions to that role, to tell Drupal what that role can and can’t do on the site. Finally, you will grant certain users on your site your new role, which will mean that when those users are logged in, Drupal will let them do the actions you gave that role permission to do.
You can also assign permissions for the special built-in roles of “anonymous user” (a user who is not logged in) and “authenticated user” (a user who is logged in, with no special role assignments). Drupal permissions are quite flexible — you are allowed to assign permission for any task to any role, depending on the needs of your site.

15. Explain the concept of node in drupal.
A node in Drupal is the generic term for a piece of content on your web site. (Note that the choice of the word “node” is not meant in the mathematical sense as part of a network.) Some examples of nodes:
• Pages in books
• Discussion topics in forums
• Entries in blogs
• News article stories
Each node on your site has a Content Type. It also has a Node ID, a Title, a creation date, an author (a user on the site), a Body (which may be ignored/omitted for some content types), and some other properties. By using modules such as the contributed Content Construction Kit (CCK) module, the core Taxonomy module, and the contributed Location module, you can add fields and other properties to your nodes.

16. Concept of Comment in Drupal .
Comments are another type of content you can have on your site (if you have enabled the core Comment module). Each comment is a typically small piece of content that a user submits, attached to a particular node. For example, each piece of discussion attached to a particular forum topic node is a comment.

17 explain Taxonomy in drupal .
Drupal has a system for classifying content, which is known as taxonomy and implemented in the core Taxonomy module. You can define your own vocabularies (groups of taxonomy terms), and add terms to each vocabulary. Vocabularies can be flat or hierarchical, can allow single or multiple selection, and can also be “free tagging” (meaning that when creating or editing content, you can add new terms on the fly). Each vocabulary can then be attached to one or more content types, and in this way, nodes on your site can be grouped into categories, tagged, or classified in any way you choose.

18 . How database system of drupal works ?
Drupal stores information in a database; each type of information has its own database table. For instance, the basic information about the nodes of your site are stored in the Node table, and if you use the CCK module to add fields to your nodes, the field information is stored in separate tables. Comments and Users also have their own database tables, and roles, permissions, and other settings are also stored in database tables.

19. Explain the path system of drupal ?
When you visit a URL within your Drupal site, the part of the URL after your base site address is known as the path. When you visit a path in your Drupal site, Drupal figures out what information should be sent to your browser, via one or more database queries. Generally, Drupal allows each module you have enabled on your site to define paths that the module will be responsible for, and when you choose to visit a particular path, Drupal asks the module what should be displayed on the page.
For instance, this site ( is (of course) built with Drupal. The page you are now viewing is, whose path is “node/19828″. The module that is responsible for this path is the core Node module, so when you visit this page, Drupal lets the Node module determine what to display.
To determine the path to a particular page on your site, for purposes of creating a link, go to the page you want to link to and look at the URL in the address bar. By default the URL, after the base address of your site, will begin with ‘?q=’. When ‘Clean URLs’ are enabled you will see a directory structure in the URL. The “path” for use in a menu item is the part of the URL after the site’s base address and without the “?q=”.

20. Explain Region, Block, Menu in drupal ..
Pages on your Drupal site are laid out in regions, which can include the header, footer, sidebars, and main content section; your theme may define additional regions. Blocks are discrete chunks of information that are displayed in the regions of your site’s pages. Blocks can take the form of menus (which are concerned with site navigation), the output from modules (e.g., hot forum topics), or dynamic and static chunks of information that you’ve created yourself (e.g., a list of upcoming events).
There are three standard menus in Drupal: Primary Links, Secondary Links, and Navigation. Primary and Secondary links are built by site administrators, and displayed automatically in the page header of many themes (if not, you can enable their blocks to display them). Navigation is the catch-all menu that contains your administration menus, as well as links supplied by modules on your site. You can also create your own custom menus, and display them by enabling their blocks.
You can customise menus in several ways, such as reordering menu items by setting their “weight” or simply dragging into place, renaming menu items, and changing the link title (the tooltip that appears when you mouse over a menu item). You can move a menu item into a different menu by editing the Parent property of the menu item.
You can also add custom menu items to a menu, from the Add menu item tab of the Menu administration screen. To create a menu item, you will need to provide the path to the content (see above).
In all cases a menu item will only be shown to a visitor if they have the rights to view the page it links to; e.g., the admin menu item is not shown to visitors who are not logged in.

21. How To Define New Regions in Drupal
To add regions for Drupal 5.x
ADD this code in its entirety to the bottom of your template.php file:
/** Define the regions **/
function framework_regions() {
return array(
‘left’ => t(‘left sidebar’),
‘right’ => t(‘right sidebar’),
‘content’ => t(‘content’),
‘header’ => t(‘header’),
‘footer’ => t(‘footer’),
‘newregion’ => t(‘new region’),
Replace “newregion” with what you would like to call that region instead. Note that the name on the left before the = is the machine readable format, and cannot have spaces. the name after the = is the human readable format, and can have spaces, capital letters etc. You may add as many regions as you like in the same manner that “newregion” has been added in the example above.
Then, in your page.tpl.php file, define where you would like you regions to be using a print call like so:
You need to replace “newregion” with what you named your region. The id, class and any other html can be changed to anything.
To add regions for Drupal 6.x
ADD the following code to you file:
regions[left] = Left sidebar
regions[right] = Right sidebar
regions[content] = Content
regions[header] = Header
regions[footer] = Footer
regions[newregion] = New Region
The internal “machine” readable name in square brackets and the human readable name as the value, e.g., regions[theRegion] = The region label.
The contents of the .info file is cached in the database so altering it will not be noticed by Drupal. To clear it, do ONE of the following:
1. Clear button located at “Administer > Site configuration > Performance”.
2. With devel block enabled (comes with devel module), click the “Empty cache” link.
3. Simply visit the theme select page at “Administer > Site building > Themes”.
Then, in your page.tpl.php file, define where you would like you regions to be using a print call like so:
You need to replace “newregion” with what you named your region. The id, class and any other html can be changed to anything.

22. Explain the function and working of Dashboard module ?
The Dashboard module provides a Dashboard page in the administration menu. The intention of the Dashboard page is to give administrators a quick overview of important information on the website.

23. List the modules required for building a social networking website in Drupal.
• Activity
• Advanced Forum
• Advanced Profile Kit
• Application Toolbar (Appbar)
• Author Pane
• Buddylist2 Package
• Buddylist: list your social network
• CiviCRM: manage community contacts, relationships, and activities
• CiviNode and CiviNode CCK: Tools For Integrating CiviCRM Contacts Into Drupal Content
• Comment Notify
• FOAF: friends of a friend
• Facebook-style Statuses
• Family: Record, display, and analyze genealogical data.
• Flag Friend
• Friend
• FriendList
• Front: Show group membership and events
• Gigya Socialize Module
• Invite: send invitations to join your site
• Notice Feed
• Organic Group
• Profile Setup
• Radioactivity
• Sports Pickem
• Tellafriend Node
• User Invite
• User Relationships
• UserTag:Tag users with taxonomy terms
• meetü: The Social Networking Game from the OPL @ RIT

24. List the SEO modules available in Drupal.
1. Pathauto
2. Nodewords/ Meta tags
3. Service links
4. Google analytics
5. Related Links
6. Search 404
7. Site map
8. Url list

25. How to post videos from mobile to Drupal website ?
Posting video from mobile phone to drupal website via email requests from user to configure a mobile phone with smtp settings and reasonable Internet connection (3g). Costs depends from your mobile phone provider: at some networks you pay only for transfer volume, at others you might pay for “event” of establishing connection.
On server side you will probably need to setup smtp server and provide access to it to users of your website. Transcoding of posted video employs ffmpeg, its standard software on proper hosting server.
Process Overview
1. Email with video attachment from mobile phone is sent to a defined mailbox
2. Drupal website downloads Mail on cron (mailhandler module)
3. Emails are turned into nodes with videos as attachments
4. Media Mover runs on cron, trans-coding mobile video formats and creating thumbnails
5. Transcoded flash video files are added to cck file field
6. Thumbnail added to file field
7. Nodes are themed using swftools to display video using “JWplayer”

Modules used
• Mailhandler
• Mailssave
• Mediamover
• SWFTools
• FFMPEG_wrapper
• cck
• filefield
• imagefield

26. What is a patch?
A patch is a file that consists of a list of differences between one set of files and another. All code changes, additions, or deletions to Drupal core and contributed modules/themes between developers are done through patches.
The differences are presented in a structured, standard way, which means that a program (also named patch) can be used to apply the changes to another copy of the original file.

27. What is difference between Diff and Patch ?
diff creates patch
In simple terms, the diff command is used to compare differences between two versions of a file. The resulting file is called a patch, and typically is given (by the user) a “.patch” suffix.
This patch file then can be used on other copies of the “old” file by using the patch command, thus updating their “old” file(s) to match the “new” file(s).
Why you would use diff
When might one use diff to create a patch file? Let’s say you are customizing a module to fix a bug, and have saved a new version of the module. How will you pass on your bug fix to others? Simply passing on your version of the module may not work, because it’s quite possible someone else has modified some other aspect of the code at the same time and you both would be overwriting each others’ changes.
So instead, what you do is run diff between the two files, and then upload the resulting patch — which others can then apply to their files using the patch command. (And you can apply other people’s patches against your files, without losing your own changes.)
The added benefit of this type of workflow is that changes to the code can easily be tracked — and undone, if necessary — which is essential in a community-developed project such as Drupal.

28. List the features of Drupal ?
1. Rock solid & high quality platform
2. Powerful templating system. Any XHTML or CSS template can be easily converted to Drupal
3. Real multi-site-feature (only one installation for several sites)
4. Any Kind of user groups & user permissions, OpenId compliant in Version 6
5. Can run membership and community sites, not only CMS etc
6. Clear, high quality code and API (easy to integrate with other solutions etc)

29. How to port a joomla template to drupal ?
For explanation please visit

30. Explain the capabilities of views module.
The Views module provides a flexible method for Drupal site designers to control how lists and tables of content (nodes in Views 1, almost anything in Views 2) are presented. Traditionally, Drupal has hard-coded most of this, particularly in how taxonomy and tracker lists are formatted.
This tool is essentially a smart query builder that, given enough information, can build the proper query, execute it, and display the results. It has four modes, plus a special mode, and provides an impressive amount of functionality from these modes.
Among other things, Views can be used to generate reports, create summaries, and display collections of images and other content.

31. What are systems requirements for drupal installation ?
- 3MB of disk space
- If you install many contributed modules and contributed themes, the actual disk space for your installation could easily be 40 MB or more (exclusive of database content, media, backups and other files).
Web Server
Drupal has been deployed successfully on both Apache and IIS.
Drupal is being developed to be web server independent, but we have limited or no reports of successful use on web servers not listed here.
Database server
Recommended: MySQL 4.1 or MySQL 5.0
PostgreSQL 7.4 or higher

32. What are the browser requirements for Drupal ?
Websites built using just Drupal core (i.e. with no additional, contributed modules) are compatible with, and fully functional, in all modern browsers that support CSS and JavaScript. However, browsers have varying levels of compliance with Internet standards such as CSS 2, so there may be minor variations in appearance.
Here is an incomplete list of browsers that are known to work well with Drupal core and support all of its features:
• Internet Explorer 6.x and later
• Firefox 2.x and later
• Opera 7 and later
• Safari 1.x and later
• Camino 1.x and later
• Google Chrome
It’s worth mentioning here that IE6 has an problem with loading more than 30 stylesheets, and it’s fairly easy to run into this problem once you start adding contrib modules.
Recommended: PHP 5.2.x
Required: PHP version 4.3.5 or higher (Contributed modules may not support this version of PHP)

33. What is PDO?
PDO is an acronym for PHP Data Objects. PDO is a lean, consistent way to access databases. This means developers can write portable code much easier. PDO is not an abstraction layer like PearDB. PDO is a more like a data access layer which uses a unified API (Application Programming Interface).

34. How to enable clean urls in drupal ?
The standard Drupal installation contains a sample .htaccess file which supports clean URLs. It is easy to miss copying this file, because of the leading “dot”. So before trying to enable Clean URLs, make sure this file exists in your Drupal installation.
Drupal 6.x
In Drupal 6, the installer tests for compatibility with Clean URLs as a part of the installation process.
Drupal 5.x
Goto the administer >> site configuration >> clean urls section of the administrative interface.
Clean urls can be enabled by following the above two options in respective versions of drupal website.

35. Which are the core required modules in drupal 6.x ?
1. Block — Controls the boxes that are displayed around the main content.
2. Filter — Handles the filtering of content in preparation for display.
3. Node — Allows content to be submitted to the site and displayed on pages.
4. System — Handles general site configuration for administrators.
5. User — Manages the user registration and login system.

36. Is it possible to disable the core required modules through drupal admin ?
No, it is not possible to disable the core required modules.

37. Which are the core optional modules in drupal 6.x ?
1. Aggregator Aggregates syndicated content (RSS, RDF, and Atom feeds).
2. Blog Enables keeping easily and regularly updated user web pages or blogs.
3. Blog API Allows users to post content using applications that support XML-RPC blog APIs.
4. Book Allows users to structure site pages in a hierarchy or outline.
5. Color Allows the user to change the color scheme of certain themes.
6. Comment Allows users to comment on and discuss published content.
7. Contact Enables the use of both personal and site-wide contact forms.
8. Content translation Allows content to be translated into different languages.
9. Database logging Logs and records system events to the database.
10. Forum Enables threaded discussions about general topics.
11. Help Manages the display of online help.
12. Locale Adds language handling functionality and enables the translation of the user interface to languages other than English.
13. Menu Allows administrators to customize the site navigation menu.
14. OpenID Allows users to log into your site using OpenID.
15. Path Allows users to rename URLs.
16. PHP filter Allows embedded PHP code/snippets to be evaluated.
17. Ping Alerts other sites when your site has been updated.
18. Poll Allows your site to capture votes on different topics in the form of multiple choice questions.
19. Profile Supports configurable user profiles.
20. Search Enables site-wide keyword searching.
21. Statistics Logs access statistics for your site.
22. Syslog Logs and records system events to syslog.
23. Taxonomy Enables the categorization of content.
24. Throttle Handles the auto-throttling mechanism, to control site congestion.
25. Tracker Enables tracking of recent posts for users.
26. Trigger Enables actions to be fired on certain system events, such as when new content is created.
27. Update status Checks the status of available updates for Drupal and your installed modules and themes.
28. Upload Allows users to upload and attach files to content.

38. what a module is in Drupal and what the process of writing one involves?
When developers learn that modifying Drupal’s core code is a no-no, they often have a panic moment. “How, then will I bend Drupal to do my will?,” they ask. Easy: by writing a module. The first part of writing a module is writing a .info file, where you describe your module to Drupal. Here’s an example from the Forum Module:
; $Id:,v 1.6 2007/06/08 05:50:54 dries Exp $
name = Forum
description = Enables threaded discussions about general topics.
dependencies[] = taxonomy
dependencies[] = comment
package = Core – optional
core = 6.x
This gives Drupalenough information to list the module on the modules administration page, and to tell whether the module is compatible with the version of Drupal being run (in this case, 6.x). Drupal will also make sure the dependent modules are present.
A module may have a .install file containing code that runs when the module is first installed. For example, some database tables may be needed, or some values may need to be initialized in Drupal’s persistent variable system.
Finally, the .module file itself contains the code that does whatever it is that your module will do. And that’s just about anything. There were 3,430 modules in the repository last time I checked, so it’s a good idea to check if the module you’re thinking about writing is already written. Drupal Modules is a good place to do that.
New Drupal developers are also often stymied by the question “When does my code run? I put it in a module, but when does the module run?” Answering that question requires understanding of the Inversion of Control design pattern that Drupal uses, often called “hooks” or “callbacks”. You name your functions in a certain way, and Drupal will automatically call your code at the appropriate time, depending on how you’ve named the functions.

39. Drupal is flexible at handling events automatically and employing triggers. How do developers make use of these features?
There are really two answers here. At the code level, that’s always what Drupal has been about: having your code run when a certain event happens. For example, the following code would send a tweet to my Twitter account every time someone logs in to the Drupal site (it requires the third-party Twitter Module to be installed to do the dirty work).
function mymodulename_user($op, &$edit, &$account) {
if ($op == ‘login’) {
// Bring twitter-related functions into scope.
module_load_include(‘inc’, ‘twitter’);
// Use t() for proper localization.
$text = t(‘@username logged in’, array(‘@username’ => $account->name));
// Post to twitter using the twitter module.
twitter_set_status(‘clouseau’, ‘secret’, $text);
That’s fine if you are a programmer. But what if we took the whole idea of “Send a message to Twitter” and abstracted it? Then we could use a nice user interface to associate the action “Send a message to Twitter” with one of Drupal’s common events, such as when a user logs in, or posts content, or creates a new account. That is what the new features in Drupal 6 provide: the user interface for doing such associations between actions and events. A trigger is an event that has been exposed in the user interface.
You can also create your own triggers. Perhaps you want to go the other way: you want actions to happen in Drupal when a new tweet is posted to your Twitter account! Chapter 3 of the book tells you how to make your own triggers.

40. The search features in Drupal are excellent, as compared to search in other content management systems. What makes these so good?
Drupal’s search is so good because Drupal doesn’t treat its content as a big bucket of text; rather, all of the fine-grained semantic information that Drupal knows about can be used to fine-tune search results. That includes the type of content, any classification information from the taxonomy system, and the usual content metadata. Inside the search engine is an extensible indexer that can accept pretty much anything. In the book, one of the examples uses Drupal to index an external non-Drupal database.
And as usual, you can tweak and override the search system to adjust the user interface, the way content is ranked, and the way results are displayed. That said, Drupal integrates well with external search engines such as Apache Solr, Xapian, and Sphinx if the built-in Drupal search does not meet your needs.

Saturday, May 7, 2011

How Drupal's Menu System Work?

The Drupal menu system drives both the navigation system from a user perspective and the callback system that Drupal uses to respond to URLs passed from the browser. For this reason, a good understanding of the menu system is fundamental to the creation of complex modules.
Drupal's menu system follows a simple hierarchy defined by paths. Implementations of hook_menu() define menu items and assign them to paths (which should be unique). The menu system aggregates these items and determines the menu hierarchy from the paths. For example, if the paths defined were a, a/b, e, a/b/c/d, f/g, and a/b/h, the menu system would form the structure:


Note that the number of elements in the path does not necessarily determine the depth of the menu item in the tree.

When responding to a page request, the menu system looks to see if the path requested by the browser is registered as a menu item with a callback. If not, the system searches up the menu tree for the most complete match with a callback it can find. If the path a/b/i is requested in the tree above, the callback for a/b would be used.

The found callback function is called with any arguments specified in the "page arguments" attribute of its menu item. The attribute must be an array. After these arguments, any remaining components of the path are appended as further arguments. In this way, the callback for a/b above could respond to a request for a/b/i differently than a request for a/b/j.

For an illustration of this process, see page_example.module.
Access to the callback functions is also protected by the menu system. The "access callback" with an optional "access arguments" of each menu item is called before the page callback proceeds. If this returns TRUE, then access is granted; if FALSE, then access is denied. Menu items may omit this attribute to use the value provided by an ancestor item.

In the default Drupal interface, you will notice many links rendered as tabs. These are known in the menu system as "local tasks", and they are rendered as tabs by default, though other presentations are possible. Local tasks function just as other menu items in most respects. It is convention that the names of these tasks should be short verbs if possible. In addition, a "default" local task should be provided for each set. When visiting a local task's parent menu item, the default local task will be rendered as if it is selected; this provides for a normal tab user experience. This default task is special in that it links not to its provided path, but to its parent item's path instead. The default task's path is only used to place it appropriately in the menu hierarchy.

Everything described so far is stored in the menu_router table. The menu_links table holds the visible menu links. By default these are derived from the same hook_menu definitions, however you are free to add more with menu_link_save().

Sunday, May 1, 2011

How to Set Up a Multisite Drupal Installation?

Multisite 10 minute Install:
  • Server: LAMP
  • SSH (telnet) Client: ssh (PuTTY if you are using Windows to access your LAMP host)
  • Must have root access to your server.
If website in question is an addon domain, i.e.,, then substitute "addon" for "www" in steps below.
For list of Linux commands visit: or
Here we go:
[login via ssh / PuTTY]

Debian (Ubuntu)

Debian and offshoot distributions (e.g. Ubuntu) make installation and configuration very easy. This was done on a Debian distribution, Ubuntu should work identically.


Assumption: apache2 and mysql are already installed. If not, use apt-get install to install and configure them.
# apt-get install drupal6
Answer the questions. This will install everything necessary to run drupal and do the basic configuration, including creating an empty database for drupal.
  • Configure database for drupal6 with dbconfig-common? [YES]
  • Database type to be used by drupal6: [mysql]
  • Password of your database's administrative user: [enter mysql root password]
  • MySQL application password for drupal6: [create a password for your drupal6 db]
  • (enter the password again for verification)
You now have a basic unconfigured Drupal6 installation using the database drupal6 and accessible at Do not use it. This is the "prototype" installation that we will use to create the sites we really want to use.


Create Site Databases

The easiest way to create databases for your sites is to use dpkg-reconfigure and answer the questions.
# dpkg-reconfigure drupal6
  • Re-install database for drupal6? [YES]
  • Database type to be used by drupal6: [mysql]
  • Connection method for MySQL database of drupal6: [unix socket]
  • Name of your database's administrative user: [root]
  • Password of your database's administrative user: [enter mysql root password]
  • username for drupal6: [ENTER YOUR DB SITE *USERNAME* HERE (e.g. mysite)]
  • database name for drupal6: [ENTER YOUR DB *SITE* NAME HERE (e.g. mysite)]
  1. Repeat the above for each site you want to support.
  2. I used the same name for the database and the site. KISS.
  3. Don't use periods (e.g. is a bad choice). If you want to spell out the whole name, use underscores instead of periods (e.g. mysite_com).
  4. The above method ends up using the same site database password for all the sites you create. Advice: use mysql-admin (or mysql) to use different passwords for each site. 

    Configure Apache2 for Sites

    Before you jump to configure your virtual hosts do not forget to add host names in /etc/hosts file.

    Apache2 needs to be configured to support vhost access to your new sites.
    Create vhost site configuration files in /etc/apache2/sites-available/
    # Virtual hosting configuration for Drupal

    ServerAdmin [your email address]

    DocumentRoot /usr/share/drupal6/
    ServerName [your vhost#1 name]
    ServerAlias [if you want to support and]
    RewriteEngine On
    RewriteOptions inherit

    ServerAdmin [your email address]

    DocumentRoot /usr/share/drupal6/
    ServerName [your vhost#2 name]
    ServerAlias [if you want to support and]
    RewriteEngine On
    RewriteOptions inherit

    [...repeat for all your vhosts]
    • Modify the above items that are in [square brackets].
    • You likely will want to support port 443 (https) as well. See Apache documentation for detailed instructions.
    • I've chosen to put all the vhosts in one file named drupal. You may want to use one file per vhost.
    Sym-link the drupal file in the sites-enabled directory to enable it in your site:
    # cd /etc/apache2/sites-enabled
    # ln -s ../sites-available/drupal .

    ...and reload Apache2 to pick up your configuration changes...
    # /etc/init.d/apache2 reload

    Create Drupal Site Configurations

    We need to create Drupal configurations for each site by copying the default configuration to the Drupal site subdirectory.
    # cd /etc/drupal/6/sites/
    # cp -a default []
    # cp -a default []

    ...and edit the configurations to use the right database, MySQL user name, and password...
    # vi
    # vi
    • Modify the above items that are in [square brackets].


    Run Drupal and Configure Your Sites

    Browse to your sites, running install.php (e.g. to configure them.



    Get to location where Drupal core will be located:
    [/]# cd /var/www
    Upload Drupal core:
    "x.x" should be replaced with the version of Drupal you're installing, e.g. "5.2"
    [/var/www]# wget
    Unpack Drupal core:
    [/var/www]# tar -zxvf drupal-5.2.tar.gz
    Move contents of Drupal core (including .htaccess) to html:
    [/var/www]# mv drupal-x.x/* drupal-x.x/.htaccess /var/www/html
    [/var/www]# rm drupal-x.x.tar.gz

    [/var/www]# rm drupal-5.2
    Create the files directory per Drupal instructions and change permissions (will change permission again after install):
    [/var/www]# cd html

    [/var/www/html]# mkdir files

    [/var/www/html]# chmod 777 files
    Make directories that will hold custom and contributes modules and themes:
    [/var/www/html]# cd sites/all

    [/var/www/html/sites/all]# mkdir modules

    [/var/www/html/sites/all]# mkdir themes

    [/var/www/html/sites/all]# cd modules

    [/var/www/html/sites/all/modules]# mkdir custom

    [/var/www/html/sites/all/modules]# mkdir contrib

    [/var/www/html/sites/all/modules]# cd ../

    [/var/www/html/sites/all]# cd themes

    [/var/www/html/sites/all/themes]# mkdir custom

    [/var/www/html/sites/all/themes]# mkdir contrib
    Create directory "":
    [/var/www/html/sites/all/themes]# cd ../

    [/var/www/html/sites/all]# cd ../

    [/var/www/html/sites]# mkdir
    Change permission of "settings.php" per Drupal instructions and copy "settings.php" in default to
    [/var/www/html/sites]# cd default

    [/var/www/html/sites/default]# chmod 777 settings.php

    [/var/www/html/sites/default]# cd ../

    [/var/www/html/sites]# cp -a default
    Create database and user with permissions:
    [/var/www/html/sites]# mysql

    mysql> CREATE DATABASE wwwexamplecom_drupal;

    mysql> GRANT ALL PRIVILEGES ON wwwwexamplecom_drupal_drupal.* TO 'wwwexamplecom_drupal_myusername'@'localhost' IDENTIFIED BY 'mypassword';
    mysql> \q
    Go back to PuTTY to chmod on settings.php in
    [/var/www/html/sites]# cd

    [/var/www/html/sites/]# chmod 755 settings.php

    [/var/www/html/sites/]# logout
    What next?:
    • Make changes to "settings.php" in I've read that it's not necessary to make changes to setting.php.
    • Make changes to "httpd.conf" in /usr/local/apache/conf?
    I've been using WHM to create accounts, putting Drupal in public_html and having no problems. But when it comes to parting from the WHM abstraction and getting multisite set-up correctly this is the end of the proverbial road for me.
    Could use help...:
    1. Help making improvements to steps articulated above
    2. Help with next steps so that I/we can get on to grander things, like creating modules, custom themes, profiles, (and maybe - just maybe - spend some time working on business strategy :-)

    Now that we have successfully setup both our multisite installations (1 & 2), we can proceed to test our installation to see how this will benefit us in the future for accomplishing tasks much quicker between sites that rely on the same code base or share similar modules & themes.
    1. Download the latest version of your favorite drupal 6 module. Here we will be using "Views".
    2. Place the "Views" module inside of your main sites drupal modules folder: multisite-main/sites/all/modules/views, this module will now be shared across all multisite installations. Same goes for any themes you setup in the /sites/all/themes folder. You may now enable it for individual sites by visiting your sites "admin/build/modules" page. (ie. http://multisite-1/multisite-main/admin/build/modules).
    3. Likewise, if you do not want to share modules/themes across sites you would create a "modules" or "themes" folder inside of your multisite-1 or multisite-2 folder, and place your site specific modules inside of them.

      Monday, April 25, 2011

      Drupal 7 Views 2.0 Tutorial

      Finally here is a good screencast about Drupal 7 Views 3.0 . Views 3 has lot of new functionalities as compared to its previous version. I will gather more good tutorials on views and will publish them on this blog. There are other related videos regarding this video in youtube. However I post them here if I found them useful. So , see the video , do some experiments and enjoy!

      Sunday, April 24, 2011

      Drupal Forms API Reference

      The Drupal forms API is a powerful leap forward. It also allows for almost unlimited possibilities for custom theming, validation, and execution of forms. Even better, ANY form (even those in core) can be altered in almost any way imaginable--elements can be removed, added, and rearranged. This page is certainly not a comprehensive guide to this functionality, but should provide a good working foundation with which to do the most basic form creation, theming, validation, and execution. For programming details on form elements and their properties, please see the Forms API Reference.

      Creating Forms

      Form elements are now declared in array fashion, with the hierarchical structure of the form elements themselves as array elements (which can be nested), and each form elements properties/attributes listed as array elements in key/value pairs--the key being the name of the property/attribute, and the value being the value of the property/attribute. For example, here's how to go about constructing a textfield form element:
      $form['foo'] = array(
        '#type' => 'textfield',
      => t('bar'),
      '#default_value' => $object['foo'],
      '#size' => 60,
      '#maxlength' => 64,
      => t('baz'),
      and a submit button:
      $form['submit'] = array(
      => 'submit',
      '#value' => t('Save'),
      a few things to note:
      1. The element's name property is declared in the $form array, at the very end of the array tree. For example, if an element in the form tree was structured like this:


        ...then that element's name property is 'username'--this is the key it will be available under in $form_state['values'], in your validation and submission functions, as the form code flattens the array in this fashion before it passes the key/value pairs. NOTE: if you wish to have the full tree structure passed to $form_state['values'], this is possible, and will be discussed later.
      2. The type of form element is declared as an attribute with the '#type' property.
      3. Properties/attributes keys are declared with surrounding quotes, beginning with a # sign. Values are strings.
      4. The order of the properties/attributes doesn't matter, and any attributes that you don't need don't need to be declared. Many properties/attributes also have a default fallback value if not explicitly declared.
      5. Don't use the '#value' attribute for any form elements that can be changed by the user. Use the '#default_value' attribute instead. Don't put values from $form_state['values'] (or $_POST) here! FormsAPI will deal with that for you; only put the original value of the field here.
      One great advantages of this system is that the explicitly named keys make deciphering the form element much easier.
      Let's take a look at a working piece of code using the API:
      function test_form($form_state) {
      // Access log settings:
      $options = array('1' => t('Enabled'), '0' => t('Disabled'));
      $form['access'] = array(
      => 'fieldset',
      => t('Access log settings'),
      => TRUE,
      $form['access']['log'] = array(
      => 'radios',
      => t('Log'),
      =>  variable_get('log', 0),
      => $options,
      => t('The log.'),
      $period = drupal_map_assoc(array(3600, 10800, 21600, 32400, 43200, 86400, 172800, 259200, 604800, 1209600, 2419200, 4838400, 9676800), 'format_interval');
      $form['access']['timer'] = array(
      '#type' => 'select',
      => t('Discard logs older than'),
      => variable_get('timer', 259200),
      => $period,
      => t('The timer.'),
      // Description
      $form['details'] = array(
      '#type' => 'fieldset',
      => t('Details'),
      => TRUE,
      => TRUE,
      $form['details']['description'] = array(
      '#type' => 'textarea',
      => t('Describe it'),
      =>  variable_get('description', ''),
      => 60,
      => 5,
      => t('Log description.'),
      $form['details']['admin'] = array(
      => 'checkbox',
      => t('Only admin can view'),
      => variable_get('admin', 0),
      $form['name'] = array(
      => 'textfield',
      => t('Name'),
      => 30,
      => 64,
      => t('Enter the name for this group of settings'),
      $form['hidden'] = array('#type' => 'value', '#value' => 'is_it_here');
      $form['submit'] = array('#type' => 'submit', '#value' => t('Save'));

      function test_page() {
      This example demonstrates how form elements can be built in a hierarchical fashion by expanding and layering the form array. There are two functions involved - the function that builds the form, and another that renders the form using drupal_get_form(). Note that the form builder function always takes $form_state as its first argument, though for basic usage (as here) it is not used. Also note that the test_page() function that renders the form is returning the rendered HTML output, which is what you would need to do if test_page() is the page callback from a hook_menu() implementation, for example.
      Notice that the first layer is made up of two form groups, 'access', and 'details', and that inside each of these groups, one layer down, are some individual form elements. Order of construction is important here, as the form building code will default to the constructed order of the $form array when it builds the form (this can be overridden, and will be discussed later in the custom theming section).
      For form groups, the '#type' parameter is set to 'fieldset', and notice how the 'details' form group is made into a collapsed form group with the addition of a few attributes.
      All groups/elements are been built into the master $form array by the builder function.
      The drupal_get_form function is the "key" function in the Forms API. Note that in its basic usage, it takes just one argument, a string which is both the form ID and also the name of the function that builds the $form array. Because the form ID is generally also the name of a function, it must be a valid PHP variable name. It should start with a letter or underscore, followed by any number of letters, numbers, or underscores; spaces and hyphens are not allowed. drupal_get_form can take optional additional arguments, which will be simply passed on to the $form builder function.
      drupal_get_form does the following:
      • Starts the entire form-building process by getting the $form from the builder function
      • Translates the $form['name'] items into actual form elements
      • Performs any validation and "clean-up" that needs to be done, and calls custom validation functions if declared
      • Submits the form if a submit function is declared, and the form has been submitted
      • Calls any custom theming functions that have been declared
      • Returns an HTML string which contains the actual form.
      For more detailed information, also see the API page for drupal_get_form()
      An important thing to note: notice that $form['access'] has a '#tree' => TRUE attribute. this setting retains the full tree structure for all elements under it when it is passed to $form_state['values']. you must explicitly declare this anywhere you wish to retain an array's full hierarchy when it is passed.

      Theming Forms

      The API makes custom theming of all forms (including those found in core) possible. This custom theming becomes possible when all hard coded theming elements have been abstracted, so that they can be overridden at time of form generation. The abstraction is accomplished using one of the following methods:
      1. Adding '#theme' attributes to the form and/or elements. This allows you to specify which theme function will be used to render the form or elements, overriding the default theming function.
      2. Including any markup directly as an element in the $form array:
        • There are '#prefix' and '#suffix' attributes, and these will place the declared markup either before or after the form element in question. for example:
          $form['access'] = array(
          => 'fieldset',
          => t('Access log settings'),
          => '
          => '
          ...will place the div tags before and after the entire form group (meaning the form elements of the group will also be enclosed in the div). if you were to put those attributes in one of the form elements inside that form group, then they would only wrap that particular element, etc.
        • There is a '#markup' type which you can place anywhere in the form, and its value will be output directly in its specified location in the forms hierarchy when the form is rendered. example:

          $form['div_tag'] = array('#type' => 'markup', '#value' => '
          This markup form element can then be accessed/altered through its name in the array, 'div_tag'
          NOTE: it's not necessary to explicitly declare the type as markup, since type will default to markup if none is declared.
      3. Break out any markup into a separate theme function. This is the preferred method if the markup has any degree of complication. it is accomplished by creating a theme function with theme_ prepended to the name of the form ID that is to be themed. in cases where you want to use the same theming function for more than one form, you can include the optional callback arg in drupal_get_form--in which case the third arg of drupal_get_form will be a string containing the name of the callback function which the form building code will call, and the theming function will be theme_ prepended to the name of the callback. example:
        For our above form, we could create a custom theming function as follows:
        function theme_test_form($form) {
        $output = '';
        $output .= drupal_render($form['name']);
        $output .= '
        $output .= drupal_render($form['access']);
        $output .= '
        $output .= drupal_render($form['details']);
        $output .= '
        $output .= drupal_render($form);
        A few things to note:
        1. The theme function has one argument, which is the form array that it will theme
        2. You build and return an output string just as you would do in a regular theming function
        3. Form elements are rendered using the drupal_render function
        4. If you call drupal_render and pass it an array of elements (as in a fieldset), it will render all the elements in the passed array, in the order in which they were built in the form array.
        5. While the default order of rendering for a form is the order in which it was built, you can override that in the theme function by calling drupal_render for any element in the place where you would like it to be rendered. In the above example, this was done with $form['name'].
        6. The rendering code keeps track of which elements have been rendered, and will only allow them to be rendered once. Notice that drupal_render is called for the entire form array at the very end of the theming function, but it will only render the remaining unrendered element, which in this case is the submit button. calling drupal_render($form) is a common way to end a theming function, as it will then render any submit buttons and/or hidden fields that have been declared in the form in a single call.

      Validating Forms

      The form API has general form validation which it performs on all submitted forms. If there is additional validation you wish to perform on a submitted form, you can create a validation function. the name of the validation function is the form ID with _validate appended to it. the function has two args: $form and $form_state. $form is the form array of the executed form, and $form_state['values'] contains the form values which you may perform validation on. (Note - in more advanced usage, several forms may share a _validate or _submit function - so if the form's ID is needed, it can be retrieved from $form['form_id']['#value'], or $form_state['values']['form_id'].)
      Here's an example validation function for our example code:
      function test_form_validate($form, &$form_state) {
        if (
      $form_state['values']['name'] == '') {
      form_set_error('', t('You must select a name for this group of settings.'));

      Submitting Forms

      The normal method of submitting forms with the API is through the use of a form submit function. This has the same naming convention and arguments as the validation function, except _submit is appended instead. Any forms which are submitted from a button of type => 'submit' will be passed to their corresponding submit function if it is available.
      function test_form_submit($form, &$form_state) {
      db_query("INSERT INTO {table} (name, log, hidden) VALUES ('%s', %d, '%s')", $form_state['values']['name'], $form_state['values']['access']['log'],  $form_state['values']['hidden']);
      drupal_set_message(t('Your form has been saved.'));
      a few things to note:
      1. A submit function is called only if a submit button was present and exists in the $_POST, and validation did not fail.
      2. The $form_state['values'] array will not usually have the same hierarchical structure as the constructed $form array (due to the flattening discussed previously), so be aware of what arrays have been flattened, and what arrays have retained their hierarchy by use of the tree => TRUE attribute. notice above that 'statistics_enable_access_log' belongs to a tree'd array, and the full array structure must be used to access the value.
      3. If a form has a submit function, then hidden form values are not needed. Instead, any values that you need to pass to $form_state['values'] can be declared in the $form array as such:

        $form['foo'] = array('#type' => 'value', '#value' => 'bar')
        This is accessed in $form_state['values']['foo'], with a value of bar. This method is preferred because the values are not sent to the browser.
      4. To determine where the user should be sent after the form is processed, the _submit function can place a path or URL in $form_state['redirect'] which will be the target of a drupal_goto; every form is redirected after a submit. If you store nothing in $form_state['redirect'], the form will simply be redirected to itself after a submit. It is polite to use drupal_set_message() to explain to the user that the submission was successful.

      Understanding the Flow

      An important concept with Forms API compared to using raw HTML forms (as in Drupal 4.6 and before) is that the drupal_get_form() function handles both presenting and responding to the form. What this means is that the $form array you construct in your function will be built first when the form is presented, and again when the form is submitted.
      The practical upshot to this is that many developers immediately find themselves asking the question of "where does my data get stored?". The answer is simply that it doesn't. You put your $form data together, perhaps loading your object from the database and filling in #default_values, the form builder then checks this against what was posted. What you gain from this, however, is that the FormsAPI can deal with your data securely. Faking a POST is much harder since it won't let values that weren't actually on the form come through to the $form_state['values'] in your submit function, and in your 'select' types, it will check to ensure that the value actually existed in the select and reject the form if it was not. In addition, Drupal adds, by default, a security token to each form that will protect against cross-site forgery.