Friday, October 12, 2012

Drupal Interview Questions - IV

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.

No comments:

Post a Comment

only show translated menu items into current language (Drupal 8)

function MY_THEME_preprocess_menu(&$variables) {   if ($variables['menu_name'] == 'brancott-header-menu') {    $langu...