1. 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
2. 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.
PHP
Recommended: PHP 5.2.x
Required: PHP version 4.3.5 or higher (Contributed modules may not support this version of PHP)
3. 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).
4. 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.
5. 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.
6. Is it possible to disable the core required modules through drupal admin ?
No, it is not possible to disable the core required modules.
7. 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.
8. 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 = 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.
9. 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.
10. 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.
