Drupal Interview Questions
1. 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. CMS 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.
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. 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 web logs to large community-driven sites.
4. 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.
5. 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 ().
6. 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.