Which are the files in a Typical Drupal theme and their Purpose

A drupal theme is a collection of files that define the presentation layer. You can also create one or more "sub-themes" or variations on a drupal theme. Only the .info file is required, but most themes and sub-themes will use other files as well. The following diagram illustrates the files that are found in a typical drupal theme and sub-theme.

DRUPAL 6

DRUPAL 7

.info (required)
All that is required for Drupal to see your theme is a ".info" file. Should the theme require them, meta data, style sheets, JavaScripts, block regions and more can be defined here. Everything else is optional in drupal theme.

The internal name of the theme is also derived from this file. For example, if it is named "drop.info", then Drupal will see the name of the theme as "drop". Drupal 5 and below used the name of the enclosing folder of the theme.

Info files for themes are new in Drupal 6. In version 5, .info files were used solely for drupal modules.

template files (.tpl.php)
These drupal templates are used for the (x)HTML markup and PHP variables. In some situations they may output other types of data --xml rss for example. Each .tpl.php file handles the output of a specific themable chunk of data, and in some situations it can handle multiple .tpl.php files through suggestions. They are optional, and if none exists in your drupal theme it will fall back to the default output. Refrain from having complex logic in these files. In most cases, it should be straight (x)HTML tags and PHP variables. A handful of these templates exist in directories where core and contributed modules exist. Copying them to your drupal theme folder will force Drupal to read your version.

Note: The theme registry caches information about the available theming data. You must reset it when adding or removing template files or theme functions from your theme.

template.php
For all the conditional logic and data processing of the output, there is the template.php file. It is not required, but to keep the .tpl.php files tidy it can be used to hold preprocessors for generating variables before they are merged with the markup inside .tpl.php files. Custom functions, overriding theme functions or any other customization of the raw output should also be done here. This file must start with a PHP opening tag "

Sub-themes
On the surface, sub-themes behave just like any other drupal theme. The only differences is that they inherit the resources from their parent themes. To create one, a "base theme" entry inside the .info file is needed. From there it will inherit the resources from its parent theme. There can be multiple levels of inheritance; i.e., a sub-theme can declare another sub-theme as its base. There are no hard set limits to this.

Drupal 5 and below required sub-themes to be in sub-directories of the parent theme. This is no longer the case.

Others
The logo and screen shot is not absolutely necessary for the theme to function, but it is recommended, especially if you are contributing your theme to the Drupal repository. Screenshots will show inside the theme administration page and the user account settings for selecting themes when the appropriate permissions are set. See the screenshot guidelines for more information.
To supply administrative UI settings or "features" beyond logo, search, mission, etc., a "theme-settings.php" file can be used. This is an advanced feature. More information can be found in the Advanced settings handbook page.
For color module support, a "color" directory with a "color.inc" file is needed along with various support files.
If you want to base your work on a core theme, use sub-theming or make a copy and rename the theme. Directly modifying Bartik, Garland or Minnelli is strongly discouraged, since they are used for the install and upgrade process.
All non-Core or modifications to Core themes should be installed under the "sites/all/themes" directory to keep them separate from core files. If you plan to run multiple sites from a single Drupal code base, you can make a theme available to a specific site rather than all sites; read about how to set this up in Multi-site installations.

Compare Joomla and Drupal Terminology

1. Joomla Template is called Theme in Drupal.
2. Component = Module.
3. Module = Block.
4. Mambot/Plugin = Input filter.
5. Menu-Horizontal = Primary Links
6. Menu-Vertical = Navigation
7. Dynamic Content Item = Story
8. Static Content = Page
9. Back-end = there is no back-end in Drupal,
10. SEF = Clean URLs (but some docs refer to SEF, too).
11. Section = Taxonomy Vocabulary/Term
12. Section Title = Taxonomy Term (master)
13. Category = Taxonomy Term (child)
14. Introtext = Teaser
15. Maintext = Body (see explanation below)
16. Pathway = Breadcrumb

Other terms are the same, such as: forum discussion, editor, search, region, comment, subject/title, preview, html tag, view, edit, advertising/banner, log in/log out, profile, avatar, access control, logs, cache, site maintenance, RSS feed, parent-child and snippets.

Name a few Good Drupal sites

http://www.economist.com/

http://www.howtodothings.com/

http://leadel.net/

http://www.cargoh.com/

http://www.symantec.com/connect/

For a comprehensive list of drupal success stories follow the below link on drupal.org
http://drupal.org/success-stories

What are the technical differences between Joomla and Drupal

1. Joomla only supports one Section and one Category for each content, while you can assign Drupal contents to several Sections/Categories.
2. Joomla does not support multi-site setups, whereas drupal supports multisite setups.
3. Drupal has built-in forum discussion, so you don't need to install additional modules.
4. The term Blog in Joomla is not same as blog in Internet dictionary. 'Blog' term in Joomla is actually a teaser view of contents containing: Title, Introduction and a Read More link. So, in short, 'Blog' in Joomla terminology is not 'Weblog'! If one is asking if Joomla supports a 'Blog' by default, then the answer is yes, but with a different meaning.
5. Comments on contents are not available in Joomla by default, but Drupal supports comments for all content-types by default.

How to migrate your joomla site to Drupal site

I went immagrate site from joomla to Drurpal

How to Install Themes in your drupal website

Download the theme.
You can download drupal themes from http://drupal.org/project/themes, as well as some external sites like http://topdrupalthemes.net/, http://drupalthemesdownload.com/ , http://drupal2u.com/ , http://www.sooperthemes.com/drupal-themes , http://www.rockettheme.com/drupal-themes , http://fusiondrupalthemes.com/. Make sure the version of the theme matches your version of Drupal. Note that themes labeled "DEV" are in a development stage. They may be written for a previous/current/future version of Drupal, and they are considered unstable and should be handled with care.

Extract the files.
When you first get the theme, it will appear in a compressed file format such as 'tar.gz'. On Windows, use a program like 7-Zip to extract it. On the Mac, you can use Stuffit Expander. To extract the file using the Unix command line:
tar -zxvf themename-drupalversionnumber.tar.gz
You should see a list of files extracted into a folder.

Upload the folder.
FTP/Copy/SCP your files to the desired themes folder in your Drupal installation. Since the themes folder at the top level of Drupal is typically reserved for Drupal core themes, you should create a sites/all/themes/ directory and put uploaded themes there. If you are running a multi-site installation of Drupal, you can create a themes folder under sites/my.site.folder and put themes there that are specific to a particular site in your installation. Themes that will be shared between all sites should be placed in sites/all/themes.

Read the directions.
If the theme has an installation file (usually INSTALL.txt and/or README.txt), read it for specific instructions. There are themes that require special treatment to function properly.

Enable the theme.
Go to administer > site building > themes. Check the 'Enabled' box next to the theme.

Optional: Make it the active, default theme.
Check the 'default' box to make this the chosen theme for your site. Enabled alone will allow users to select the theme, if you have allowed that permission.

Click the 'Save Configuration' button at the bottom.

If you run into problems, check the themes issue queue and search the forums. If your problem hasn't already been addressed, post a question and someone will try to help you out.

How to Create Content in Drupal ?

To create content

Administration >> Content >> Add Content

Select the content type you want to create. There are usually one or more fields within each content type. We are providing an example of a page.

• Title and Body fields are found in most content types.
• Body is where you put the text for the page. "Input format" controls what code can go in the Body field. There are three (core) options: filtered HTML, PHP code, and full HTML. CCK allows you to change the name of this field; for example, you might call it "Product description."
• Use the log message to provide information that might be useful to other authors who may edit your document later, or provide your rationale for making edits to your own or other people's content. The log message is not visible to users without the appropriate content editing rights.
• Menu settings are used only if you are making this piece of content an item in one of your menus. It's the most efficient way to create menus. Another handbook section you may find useful is Working with the Menu.
• Comment settings are probably best set at the site level (click Content management > Comments > Settings), but can be specified for an individual piece of content.
• You can attach files to many content types. The "Upload" module must be enabled, and then the content type has to be set to allow this.
• If you enabled the Path core module or added PathAuto, you'll have URL path settings next. You can enter a "normal" name here rather than being required to use "node/2" when you refer to it later on. PathAuto will automatically create a URL based on your page title.
• Authoring sets the time stamp and creator information. The other use for this section is to control the page or story order when they are based on the time and date it was created.
• Publishing options: only "Published" items show up on the website. You can also promote content to the front page and make the content item sticky to the top of lists.

The final step is to preview your content and to Submit your page.

How URL Aliases works in Drupal ?

Drupal has a feature called "URL Alias" that allows you to provide a more understandable name to the content. As far as browsers, servers, and search engines go, it is totally unnecessary. But for humans, it is nearly mandatory. This is why most consultants tell people to always turn on the Path core module, which supports URL aliasing.

You can administer the URL Aliases directly on the node edit or add forms, or by doing the following:

First, visit the page you created. In your browser's address field, you'll see its URL. On the end it will probably say "node/xxx" where xxx is some number. Write down that number. Now go to Administer > Site building > URL Aliases. There's an "Add Alias" tab at the top. In the top box, enter "node/xxx" from above. In the second box, enter "Newurl".

Automatic Alias Generation
If your site is going to have lots of content, particularly user-submitted content, you might want to look at the PathAuto module. Not only will this module automatically generate URL aliases for new content (according to rules you can set up), but can even go back and change aliases in bulk.

Permissions
After you enable the Path module, you need to give the appropriate roles permission to use it in admin/user/permissions. Scroll down to the Path module to enable "administer url aliases" and/or "create url aliases" permissions.

Drupal Features / Drupal Benefits / Why Use Drupal ?

1. Administer
2. Build
3. Collaborate
4. Connect
5. Create
6. Design & Display
7. Extend
8. Organize & Find

Explain Briefly Drupal ?

Drupal
Come for the software, stay for the community
Drupal is an open source content management platform powering millions of websites and applications. It’s built, used, and supported by an active and diverse community of people around the world.

Drupal Home page : http://drupal.org/



Why choose Drupal ?

Drupal is a free software package that allows you to easily organize, manage and publish your content, with an endless variety of customization.

Reasons are many,

Drupal is Open Source | Community Support | Commercial Services |Who's Using Drupal |Drupal CMS Features

Drupal Downloads
http://drupal.org/download


Drupal Groups

http://groups.drupal.org/


Drupal tutorials
http://www.siteground.com/tutorials/drupal-tutorial/


Drupal Wikipedia Page
http://en.wikipedia.org/wiki/Drupal

What is Content Construction Kit (CCK) in Drupal

The Content Construction Kit allows you to add custom fields to custom content types using a web interface. In Drupal 5.x, custom content types can be created in Drupal core, and the Content Construction Kit allows you to add custom fields to any content type. In Drupal 7 and later, most of the functionality of CCK has been absorbed into Drupal core.

Summary and purpose of CCK?

Drupal comes with core content types like story and blog. For such a content type, go to 'Create content' and submit a new story or blog. That's sufficient for pages of pure text and with or without attachments.

But what if your users want to be able to submit reviews of their favorite aardvark? That would be a new content type, but I want to be able to display other stuff as well as a chunk of text for every node of that type, and I don't want it to be just attached file links.

My options: I could hack the story.module, OR I could see if someone has already created an aardvark.module for the exact type of content I want, OR using CCK I could create a new content type called Aardvark Review.

Using CCK, I can create a content type that has exactly the fields I need, no more or less. My Aardvark Review for instance might have:

text field (comments on the aardvark)
dropdown menu (aardvark color)
audio file (recording of the aardvark's grunting)
image (photo of aardvark)
The CCK admin interface for creating these new content types is nice and easy: just create your new type and then click through, adding the type of fields you want it to have and what their parameters will be (how much text for the review? which colors in the dropdown menu?). There are many add-ons available in the downloads section under CCK that add new kinds of fields to your options (video field, audio field, calculated values and vastly more complicated ones).

From the users' perspective, they'll just click on Create content > Aardvark Review and get a form that asks them to submit their review, the aardvark's color, a recording, and picture.

The Drupal flow

If you want to go deeper with Drupal, you should understand how information flows between the system's layers. There are five main layers to consider:

At the base of the system is the collection of nodes—the data pool. Before anything can be displayed on the site, it must be input as data. The next layer up is where modules live. Modules are functional plugins that are either part of the Drupal core (they ship with Drupal) or they are contributed items that have been created by members of the Drupal community. Modules build on Drupal's core functionality, allowing you to customize the data items (fields) on your node types; set up e-commerce; programmatically sorting and display of content (custom output controlled by filters you define); and more. There are thousands of different options within the fast-growing repository of contributed Drupal modules. They represent the innovation and collaborative effort of everyone from individuals to large corporations. At the next layer, we find blocks and menus. Blocks often provide the output from a module or can be created to display whatever you want, and then can be placed in various spots in your template (theme) layout. Blocks can be configured to output in various ways, as well as only showing on certain defined pages, or only for certain defined users. Next are user permissions. This is where settings are configured to determine what different kinds of users are allow to do and see. Permissions are defined for various roles, and in turn, users are assigned to these roles in order to grant them the defined permissions. On the top layer is the site theme (the "skin"). This is made up predominantly of XHTML and CSS, with some PHP variables intermixed, so Drupal-generated content can go in the appropriate spots. Also included with each theme is a set of functions that can be used to override standard functions in the modules in order to provide complete control over how the modules generate their markup at output time. Templates can also be assigned on-the-fly based on user permissions. This directional flow from bottom to top controls how Drupal works. Is some new functionality you want not showing up? Perhaps you uploaded the module into the system but have not activated it yet, and this is making everything downstream non-functional (as in "A" in the diagram above). Maybe the module is installed and activated, but you still don’t see what you want on your site. Did you forget to place the block, as in "B"? Or are your user permission settings conflicting with what you want and your users are not set to see the output as in "C"? Additionally—as mentioned earlier—getting the kind of granular control you want over the details of the XHTML module outputs requires understanding this flow. Are you using a module that does exactly what you want, only you wish the markup was just a little bit different? Maybe you’d like it to use different tags, or you’d like to assign a CSS class to something? You accomplish this by copying the output function from the module and pushing it up to the functions document in your theme. Modify the code there, and when the system goes to output, it will see your customized function and use that instead.

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.

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.

source: http://ostatic.com/blog/interview-john-vandyk-author-of-pro-drupal-development

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: forum.info,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 = 7.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, 7.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.

Writing module .info files (Drupal 7.x)

Overview
Drupal uses .info files to store metadata about themes and modules.

For modules, the .info file is used for:

rendering information on the Drupal Web GUI administration pages;
providing criteria to control module activation and deactivation;
notifying Drupal about the existence of a module;
general administrative purposes in other contexts.
This .info file is required for the system to recognize the presence of a module.

Example
The following is a sample .info file:

name = Really Neat Widget
description = Provides a really neat widget for your site's sidebar.
core = 7.x
package = Views
dependencies[] = views
dependencies[] = panels
files[] = tests/example.test
configure = admin/config/content/example
The .info file should have the same name as the .module file and reside in the same directory. For example, if your module is named example.module then your .info file should be named example.info.

This file is in standard .ini file format, which defines properties in key/value pairs separated by an equals sign (key = value). You may use quotation marks to wrap the value. Quoted values may contain newlines.

.info files may contain comments. A semi-colon [;] placed at the beginning of a line makes that line a comment, and that line will not be parsed.

Note: Whenever you create or change your .info file, you will need to clear your site's cache for your changes to take effect.

Properties
The .info file can contain the following properties:

Contents

name required
description recommended
core required
stylesheets
scripts
files
dependencies
package
php
version discouraged
configure
required
hidden
project Discouraged, packaging use only
project status url Only used for custom modules not submitted to drupal.org
name (Required)
This displays the name of your module, which will appear on the Modules page. Since module names are proper names, it should be capitalized as a proper name (e.g., "Really Neat Widget", not "really neat widget" or "Really neat widget"), and it should be a human-readable name (not really_neat_widget). If your module name includes an acronym (CSS, WYSIWYG, UI, etc.) or a third-party trade name (jQuery, JavaScript), of course follow the standard capitalization for those.
name = Really Neat Widget
description (Recommended)
A short, preferably one-line description that will tell the administrator what this module does on the module administration page. Remember, overly long descriptions can make this page difficult to work with, so please try to be concise. This field is limited to 255 characters.
description = Provides a really neat widget for your site's sidebar.
Descriptions can contain links to documentation and sources. The following example shows a link to the author. It could be a link to a documentation node on Drupal.org. This is useful when the online documentation is better than the readme file and when you want to read about a module before switching it on.
description = Domain manager by <a href="http://petermoulding.com">Peter Moulding .com</a>.

core (Required)
The version of Drupal that your module is for. For Drupal 7 this would be 7.x, etc. Note that modules cannot specify the minor version of a branch of Drupal. 6.x is correct; 6.2 is not.
core = 7.x
stylesheets (Optional)
Drupal 7 allows you to add CSS files in the module's .info file if it should be added on every page, just like theme .info files do. Here is an example from the node module's .info file:
stylesheets[all][] = node.css
scripts (Optional)
You can add Javascript in the module's .info file if it should be added on every page. This allows Javascript to be aggregated in an optimal way, and is the preferred method of adding Javascript that most visitors will need on a typical site visit:
scripts[] = somescript.js
For more information see Managing JavaScript in Drupal 7.

files (Optional)
Drupal supports a dynamic-loading code registry. To support it, all modules must declare any code files containing class or interface declarations in the .info file, like so:
name = Really Neat Widget
...
files[] = tests/example.test
When a module is enabled, Drupal will rescan all declared files and index all the classes and interfaces that it finds. Classes will be loaded automatically by PHP when they are first accessed.

dependencies (Optional)
An array of other modules that your module requires. If these modules are not present, your module cannot be enabled. If these modules are present but not enabled, the administrator will be prompted with a list of additional modules to enable and may choose to enable the required modules as well, or cancel at that point.

The string value of each dependency must be the module filename (excluding ".module") and should be written in lowercase like the examples below. Spaces are not allowed.
dependencies[] = taxonomy
dependencies[] = comment
In addition, test_dependencies[] can be used to indicate dependencies which are optional but recommended. At this writing they are supported only by Drupal.org's automated testing system. They cause the testbots to check out the projects suggested. Generally any modules that you have listed in the 'dependencies' array in the getInfo() function of your module's tests should be added as test_dependencies[].

test_dependencies[] = autoload
If you need to specify that a certain module's version number is required Drupal 7 provides a way for this in the dependencies[] field. Version numbers are optional and only necessary if the module absolutely requires another module's specific version or branch.

The syntax for the dependencies[] field(s) is:

dependencies[] = modulename (major.minor)
Where major is the numeric major version number and minor is the numeric or alphanumeric minor version number. x can be used to denote any minor version. Some examples follow.

name = Really Neat Widget
description = An example module
dependencies[] = exampleapi (1.x)
test_dependencies[] = autoload (>7.x-1.5)
...

In the above .info code, the "Example" module requires an "Example API" module with the major version of 1 and any minor version.

dependencies[] = exampleapi (1.0)
This means that the module requires the 1.0 (and only the 1.0) version of the Example API module.

dependencies[] = exampleapi (1.x)
The above module requires any minor version of the module in the 1.x branch (1.0, 1.1, 1.2-beta4, etc.)

The dependencies[] property in the .info file can also optionally specify versions:

= or == equals (optional: equals is the default)
> greater than
< lesser than
>= greater than or equal to
<= lesser than or equal to
!= not equal to
dependencies[] = exampleapi (>1.0)
The above module requires any version greater than version 1.0.

You can optionally specify the core version number as well:

dependencies[] = exampleapi (>7.x-1.5)
The above module requires a 7.x version compatible version of the module and a version greater than 1.5.

Additionally, multiple version dependencies can be specified as comma-separated values within the parentheses:

dependencies[] = exampleapi (>1.0, <=3.2, !=3.0)
This facility can be used to specify a minimal core version by using system as the module name:

dependencies[] = system (>=7.53)
This makes the module require at least Drupal 7.53.

package (Optional)
If your module comes with other modules or is meant to be used exclusively with other modules, enter the name of the package here. If left blank, the module will be listed as 'Other'. In general, this property should only be used by large multi-module packages, or by modules meant to extend these packages, such as Fields, Views, Commerce, Organic Groups, and the like. All other modules should leave this blank. As a guideline, four or more modules that depend on each other (or all on a single module) make a good candidate for a package. Fewer probably do not. An exception to this rule is the "Development" package, which should be used for any modules which are code development tool modules.

If present, the package string groups modules together on the module administration page (admin/modules); the string should therefore be the heading you would like your modules to appear under, and it needs to be consistent (in spelling and capitalization) in all .info files in which it appears. It should not use punctuation and it should follow the Drupal capitalization standard as noted above.

Capitalization is important because package string is case sensitive, and using package = fields in one module and package = Fields in another would yield two different packages on the module administration page. This can be highly confusing as Seven (the default administrative theme) capitalizes fieldset legends, making fields and Fields indistinguishable. Using package = Fields is the correct way.
package = Views
Suggested examples of appropriate items for the package field:

Administration
Commerce
Development
Fields
Media
User interface
Views
Voting (if it uses/requires VotingAPI)
The Package names for contributed modules wiki tries to track current package names; this does not mean they are recommended.

php (Optional)
As of version 6.x, module and themes may specify a minimum PHP version that they require. They may do so by adding a line similar to the following to their .info file:
php = 5.3
That specifies that the module/theme will not work with a version of PHP earlier than 5.3. That is useful if the module makes use of features added in later versions of PHP (improved XML handling, object iterators, JSON, etc.). If no version is specified, it is assumed to be the same as the required PHP version for Drupal core. Modules should generally not specify a required version unless they specifically need a higher later version of PHP than is required by core. See the PHP Manual for further details on PHP version strings.

version (Discouraged)
The version string will be added by drupal.org when a release is created and a tarball packaged. However, if your module is not being hosted on the drupal.org infrastructure, you can give your module whatever version string makes sense (eg. see Release naming conventions).

Users getting their modules directly from git will not have a version string, since the .info files checked into git do not define a version. These users are encouraged to use the git deploy module to provide accurate version strings for the admin/build/modules page for modules in directories checked out directly from git.

Because Drupal core uses a slightly different packaging process than contributed modules, the core modules have a version line predefined. This is an exception to the rule, not the model for contributed modules.
configure (Optional)
As of version 7.x, the path of the module's (main) configuration page.
If a module is enabled, a "Configure" and "Permissions" link appear. This will be the path of the "Configure" link for this particular module on the modules overview page.
configure = admin/config/content/example
required (Optional)
As of version 7.x, modules and themes may specify that they are absolutely required and should never be disabled by adding required = TRUE. These modules will be enabled automatically during install. In most cases it should only be used with the Drupal core required modules (e.g. Node, User, etc.).
hidden (Optional)
As of version 7.x, modules and themes may specify that they should not be visible on the modules page by adding hidden = TRUE. This is commonly used with testing modules used with SimpleTest where end-users should never enable the testing modules.
project (Discouraged, packaging use only)
Module maintainers should not use this at all. The packaging script on drupal.org will automatically place a string here to identify what project the module came from. This is primarily for the Update status module, so that Drupal installations can monitor versions of installed packages and notify administrators when new versions are available.
project status url (Only used for custom modules not submitted to drupal.org)
Allows module maintainers to define a URL to check for updates to their module using the Update status module. No module released on drupal.org should define this parameter. URL should point to an XML feed that accepts requests in the form of http://my.domain.com/projects/{project}/{core}. In that example, project status url should be set to http://my.domain.com/projects.
For more information on info file formatting, see the drupal_parse_info_file() documentation.

Troubleshooting
I added the core = 7.x line, but my module still says "This version is incompatible with the 7.x version of Drupal core" on the modules page. What gives?

Be aware that the "dependencies" format changed between Drupal 5.x and 6.x.

Wrong:

name = Really Neat Widget
...
dependencies = foo bar   ; 5.x dependency format.
core = 6.x
Correct:

name = Really Neat Widget
...
; Note the [], and that each of the dependencies is on its own line:
dependencies[] = foo
dependencies[] = bar
core = 7.x
Description and Non-ASCII Characters

Note that if you want to use accented characters or other non-ASCII characters in your .info file's description field, you should include the HTML escaped notation, e.g., &ouml; for the "ö" character or &copy; for the "©" character.

Is it possible to disable the core required modules through Drupal admin ?

No, it is not possible to disable the core required modules.

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.

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.

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).

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.

What are Systems Requirements for Drupal Installation ?

Disk space
A minimum installation requires 15 Megabytes. 60 MB is needed for a website with many contributed modules and themes installed. Keep in mind you need much more for the database, files uploaded by the users, media, backups and other files.

Web server
Apache, Nginx, or Microsoft IIS
More details about web server requirements.

Database
Drupal 6: MySQL 4.1 or higher, PostgreSQL 7.1,
Drupal 7: MySQL 5.0.15 or higher with PDO, PostgreSQL 8.3 or higher with PDO, SQLite 3.3.7 or higher
Microsoft SQL Server and Oracle are supported by additional modules.
More details about database requirements.

PHP
Drupal 6: PHP 5.2.x only. Warning: support for PHP 4.x has been dropped. PHP 5.3 and later may produce errors or unexpected behaviour.
Drupal 7: PHP 5.2.5 or higher (5.3 recommended).
Drupal 8: PHP 5.4 or higher.

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.

How to Port a Joomla template to Drupal ?

I was browsing through the Drupal Handbook looking for some tutorial on using CVS with Drupal and came over this great little tutorial on converting a Joomla template to Drupal. I thought i'll share this with some Joomla users that maybe be interested if they hadn't seen it yet.

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)

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.

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.

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 :

1. Mailhandler
2. Mailssave
3. Mediamover
4. SWFTools
5. FFMPEG_wrapper
6. cck
7. filefield
8. imagefield

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

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

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.

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 themename.info 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.

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.

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 (drupal.org) is (of course) built with Drupal. The page you are now viewing is http://drupal.org/node/19828, 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=".

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.

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.

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.

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.

Added Further ::

Nodes: The secret to Drupal's flexibility

We don't talk about "nodes" every day, but since they are at the heart of Drupal's design, they deserve further investigation. At its most basic, a node is a set of related information. When you create a new blog post, you are not only defining its body text, but also its title, content, author link, creation date, taxonomy (tags), etc. Some of these elements will be shown by the theme layer when the node is displayed. Others are meta-data that control when the node will show up at all - such as taxonomy or publishing status.

Since each item of content is stored as a node, and contains the same basic information, each can be handled in a standard way by both Drupal core and contributed modules. This allows site builders to choose exactly where they want content to show up, and exactly how they want it to look in each case. Most of a Drupal site builder's time is spent defining what kinds of information you want to store in your nodes, and configuring the structures (menus, taxonomy trees, views, panels) in which to display them.

As suggested before, you aren't limited to a single way of presenting your site's content. You can define as many navigation schemes, custom themes ("skins" for the site), blocks (small bits of content, such as the five most recent blog articles described earlier), and feature sets as there are distinct audiences for your site.

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.

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 drupal.org, 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.

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.

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:

a
a/b
a/b/c/d
a/b/h
e
f/g

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().

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.

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.

The string "hook" is used as a placeholder for the module name in the hook definitions. For example, if the module file is called example.module, then hook_help() as implemented by that module would be defined as example_help().

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

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.

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.

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.

Introduction

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.

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.

Which are commonly used PHP based CMSs ?

Commonly used PHP based CMSs

1. Drupal
2. Joomla
3. Wordpress
4. TYPO3

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.

What is a 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.

100 [UPDATED] DRUPAL Interview Questions and Answers pdf

DRUPAL Interview Questions and Answers pdf :-

1.What is a CMS ?

2.What is a web content Management system ?

3.Which are commonly used PHP based CMSs ?

4.What is Drupal ?

5.What is an Open source software ?

6.What are GNU Licenses ?

7.Why are so many Drupal versions available - 4.x, 5.x ...? Which one should I use?

8.Can I use Drupal on the command line?

9.What are Hooks in Drupal ?

10.what is Database abstraction layer in Drupal ?

DRUPAL Interview Questions and Answers

11.Explain the menu system in Drupal ? Purpose of menus ?

12.How to interact with Drupal search system ?

13.What is a Module in Drupal ?

14.Explain User, Permission, Role in drupal

15.Explain the concept of Node in Drupal

16.Concept of Comment in Drupal

17.Explain Taxonomy in Drupal

18.How Database System of Drupal Works ?

19.Explain the path system of Drupal ?

20.Explain Region, Block, Menu in Drupal

21.How To Define New Regions in Drupal

22.Explain the function and working of Dashboard module ?

23.List the Modules Required for Building a Social Networking Website in Drupal

24.List the SEO modules available in Drupal

25.How to post videos from mobile to Drupal website ?

26.What is a patch?

27.What is difference between Diff and Patch

28.List the Features of Drupal

29.How to Port a Joomla template to Drupal ?

30.Explain the Capabilities of Views Module

31.What are Systems Requirements for Drupal Installation ?

32.What are the browser requirements for Drupal ?

33.What is PDO?

34.How to enable clean urls in Drupal ?

35.Which are the core required modules in Drupal 6.x ?

36.Is it possible to disable the core required modules through Drupal admin ?

37.Writing module .info files (Drupal 7.x)

38.what a module is in Drupal and what the process of writing one involves?

39.Drupal is flexible at handling events automatically and employing triggers. How do developers make use of these features?

40.The search features in Drupal are excellent, as compared to search in other content management systems. What makes these so good?

41.The Drupal flow

42.What is Content Construction Kit (CCK) in Drupal

43.Explain Briefly Drupal ?

44.Drupal Features / Drupal Benefits / Why Use Drupal ?

45.How URL Aliases works in Drupal ?

46.How to Create Content in Drupal ?

47.How to Install Themes in your drupal website

48.How to migrate your joomla site to Drupal site

49.What are the technical differences between Joomla and Drupal

50.Name a few Good Drupal sites

51.Compare Joomla and Drupal Terminology

52.Which are the files in a Typical Drupal theme and their Purpose