</div>
</div>
Page Manager is a UI on top of hook_menu() and hook_menu_alter()
The response you get when visiting a URL on a Drupal site is determined largely by hook_menu(). When you go to the user register page you see a registration form because the user module told hook_menu() that a registration form belonged there. Other stuff may appear in Blocks in sidebars, footer and headers that are outside the knowledge of hook_menu(). hook_menu() primarily controls the main response that shows up in the “content” region of page.tpl.php
Here the distinction between Panels and Page Manager becomes cloudy. Page Manager tells Drupal “I know taxonomy module told you how term pages look, but I am overriding that. Use this Panels configuration instead.” Page Manager changes the way Drupal responds to existing paths as well as telling Drupal about new ones.
Panels is not even necessary to use Page Manager. Out of the box, Page Manager gives you the option to override existing URL paths just to change the HTTP response code (for that rare case where you want node/%node to respond with a 403 for anonymous users but don’t want to use the node access system). There are even other modules like Contextual Adminstration https://www.drupal.org/project/context_admin which use Page Manager to add more administrative options.
To go over that Jazz use case one more time, Page Manager:
Overrides the normal ‘list all nodes’ behavior declared by Taxonomy module.
Replaces it with a package of Panels configuration which
Declares the layout it wants
Contains instructions for populating the regions of that layout based on the given “context” (the taxonomy term “Jazz”)
Panels Everywhere is a UI alternative to page.tpl.php and Blocks UI
I just mentioned above that Page Manager is the way to control the the “content” region inside page.tpl.php. Panels Everywhere is meant to entirely replace your typical page.tpl.php customizations and the Block configurations that feed that file.
This block will show up on every page except those the pages whose URL paths match a certain pattern. Blocks can also be restricted by user role.
Mini Panels is a UI on top of individual Blocks If Panels Everywhere is a way to replace Core’s mechanism for organizing and displaying existing Blocks, Mini Panels is a way to add more individual Blocks. If you are writing a new Block with Core you will need a few pieces. You will need a machine name like “online” for the user module’s “Who’s online” block that lists currently logged in users, and you might need a configuration form for something like the number of users to show
Mini Panels allows you to accomplish those same concepts with less new code or no code at all. Mini Panels is perhaps the purest implementation of Panels in that it contains just the base concepts of Panels. You pick a layout plugin which is how the Mini Panel will actually render.
Panelizer is a (replacement) UI on top of View Modes Panelizer became famous/infamous in the Drupal community for the way it allows editors to make per-node overrides to Page Manager variants (which again almost always contain Panels configurations). Forget about that part for a moment. Panelizer has expanded its scope and is now best understood as a UI on top of View Modes. When you enable Panelizer it will give you a giant grid of checkboxes.
If you Panelize an article teaser view mode and you use Page Manager plus Panels to control the article listing URL and Panels Everywhere to control the global level then you’ll have three layers of Panels. Yes, you can do that.
http://www.palantir.net/blog/explaining-panels-overview-drupal-developers
3) DRUPAL 7 – how to create Sub themes ?
Creating a sub-theme is really simple. A sub-theme inherits a lot of the design resources from its parent theme. We can have multiple sub-themes inheriting only one base theme.
It is important to know that what a sub-theme inherits from its parent theme.
A sub theme will inherit:
All style sheets
Template files
Functions and overrides defined in the template.php
A sub-theme will not inherit:
Logos and Favicons
Block regions
Advanced theme settings
Creating a sub theme
Theme Directory: Create a directory in your custom theme directory in the same way you create a theme. Give it a name. For example: mysubtheme.
.info file: Create an .info file in the directory mysubtheme as similar to the parent theme. The only difference will be the following line:
base theme = theme_name
Logo: Add the logo in the sub-theme directory.
Screenshot: Theme screenshot is inherited from the base’s theme. To override the same, just create a new screenshot.png in the sub theme directory.
Style Sheets: You must declare at least one stylesheet in your sub-theme for any of the parent theme’s stylesheets to be inherited. To override any particular css file (for instance, style.css), add the following line in your .info file and add a new css file with the same name in your sub-theme’s directory.
stylesheets[all][] = style.css
Javascripts: All the js files defined in the parent theme will be inherited. To override any particular js file, add the following line in your .info file and add a new js file (for instance, script.js), with the same name in your sub-theme’s directory.
scripts[] = script.js
Regions: You can declare a new set of regions in the sub-theme. To inherit the custom regions of the parent theme, the regions should be copied in the sub-theme’s .info file.
Template Files: You can add any template files in your sub theme. If the template file is found in your sub-theme’s directory, then Drupal will override the parent’s template files. Otherwise, it will use the parent’s template files.
Images: The images used in the theme can also be copied in the sub theme directory. If the image is found in your sub-theme’s directory then Drupal will override the parent theme’s image with the same name. Otherwise, it will use the parent’s image.
4) explain Hooks and give any example worked on ?
Hooks are how modules can interact with the core code of Drupal. They make it possible for a module to define new urls and pages within the site (hook_menu), to add content to pages (hook_block, hook_footer, etc.), to set up custom database tables (hook_schema), and more. This page lists the hooks provided in the core, but modules can define hooks of their own. For example the cck module defines hook_field_info, which can be used by modules that want to define a new type of content field. Most modules that define hooks will also provide documentation about them.
A hook is a PHP function that can be called from Drupal, or third-party modules, when necessary to do a task. Instead of having a prefixed list of functions to call, the list is build checking the enabled modules, and the functions they implement.
For example, Drupal uses hook_node_update(); when a node is being saved with node_save(), the following code is executed.
// Call the node specific callback (if any). This can be
// node_invoke($node, ‘insert’) or
// node_invoke($node, ‘update’).
node_invoke($node, $op);
What node_invoke() does is the following:
Getting the list of all the enabled modules
Checking if the enabled modules has a function whose name ends in “_node_update” and starts with the short name of the module
Calling that function, passing $node as parameter
Hooks can save their own data in a database, or alter the value returned from a function. The last case is, for example, what happens with hook_form_alter(), which alters the value of $form passed as reference to drupal_prepare_form().
Drupal hooks are generally invoked using three functions:
drupal_alter()
module_invoke()
module_invoke_all()
drupal_alter() is the function used to invoke specific hooks whose purpose is to alter the data passed them as reference, such as hook_form_alter(), hook_hook_info_alter(), and hook_tokens_alter().
There are other functions that are used to invoke hooks, such as node_invoke(), but those functions essentially use one of the functions I listed before.
5) Explain DRUPAL bootstrap ?
Bootstrap is the process during the which Drupal initializes itself; the process actually includes:
Setting the error, and the exception handlers
Initializing the value of some spec-global variables contained in $_SERVER
Initializing some variables with init_set()
Finding the cached version of the page to serve
Initializing the database
Setting the handlers that load files when a class, or an interface is not found
Initializing the Drupal variables
Initializing the PHP session
Initializing the language variable
Loading the enabled modules
6) explain features ? How do features work?
The features module enables the capture and management of features in Drupal. A feature is a collection of Drupal entities which taken together satisfy a certain use-case.
Features provides a UI and API for taking different site building components from modules with exportables and bundling them together in a single feature module. A feature module is like any other Drupal module except that it declares its components (e.g. views, contexts, CCK fields, etc.) in its .info file so that it can be checked, updated, or reverted programmatically.
The purpose of the Features module is to copy configuration setups from one drupal site to another. It creates “packages” of the settings that can be shared among different sites. Today it is used in almost every development workflow to deploy changes from one environment to the other.
Assume that the developer creates a new content type and he wants to copy it to the development server. Here is what he will do with features:
1. He adds the content type to an existing feature (or creates a new one). features will automatically detect any dependencies (eg modules implementing the fields)
2. He downloads the features and copies it to the custom modules folder. Then he pushes it to the version control system.
3. The features module is pulled to the development site
4. The feature is enabled and the content type is automatically created.
Now assume that he makes some changes to the content type. Here is how he copies to changes to the site:
1. Updates the feature using the features UI or using drush (this causes the feature to pick up the changes)
2. Pushes the feature to the live site
3. He reverts the feature in the live site so that the changes are activated.
7) what are entitles and entitiy types?
An entity type is a useful abstraction to group together fields. Let’s consider some examples of entity types:
Nodes (content)
Comments
Taxonomy terms
User profiles
You can also build new kinds of entity types where the options above don’t suit your needs.
Bundles
Bundles are an implementation of an entity type to which fields can be attached. You can consider bundles as subtypes of an entity type. With content nodes (an entity type), for example, you can generate bundles (subtypes) like articles, blog posts, or products. Not all entity types have bundles, however. For example, users do not have separate bundles (subtypes). For the entity types that do allow bundles, you can create as many bundles (subtypes) as you want. Then, using the Field system, you can add different fields to each bundle. Examples include a file download field on Basic Pages and a subtitle field on Articles.
Fields
A field is a reusable piece of content. In technical terms, each field is a primitive data type, with custom validators and widgets for editing and formatters for display.
Entity
An entity would be one instance of a particular entity type such as a comment, taxonomy term or user profile or a bundle such as a blog post, article or product.
You can use entity_load to load any entity. Note, however, that the core does not provide a save or delete function, but thanks to Entity API module the missing pieces are added (entity_create(), entity_save(), entity_delete(), entity_view() and entity_access()).
Entity API module
The project Entity API extends the entity API of Drupal core in order to provide a unified way to deal with entities and their properties. Additionally, it provides an entity CRUD controller, which helps in simplifying the creation of new entity types.
Putting this in Object-Oriented Design/Programming terms
An entity type is a base class
A bundle is an extended class
A field is a class member, property, variable or field instance (depending on your naming preference)
An entity is an object or instance of a base or extended class
8)Multi Language translation in DRUPAL ?
There are two basic components to the translation system, the translation of the interface and the translation of content.
Translating the interface has to do with the translation of miscellaneous text strings used all over the site (like the label used on Submit buttons). These are elements that are the same on all sites no matter what actual content it contains. Because these strings are standardized, Drupal is able to create a system to provide everyone with translated values for all these elements in various languages. To take advantage of this you enable the core Locale module, which will allow you to grab translated text from the Drupal Localizer site and import them into your site
Content Translation
in earlier versions of Drupal by creating a complete copy of each node that needs translation. So the French node would have all the French values of the content and the English node would have all the English values. Then they are organized together in translation sets.
it is still available in Drupal 7, if you enable the core Content Translation module.
Entity Translation
In Drupal 7, a new model for content translation was created. In this system each piece of content consists of a single node, but each field on the node can have multiple copies, in different languages, all attached to the same entity.
The API to get this system working went into core, but there was no time (and not enough agreement) to get a UI into core. So the Entity Translation module was created to provide a way for site administrators and translators to use the new field translation system.
Creating a Site Using Entity Translation
The minimum list of modules we will need include:
Locale (included in core)
Entity Translation
Title (to translate the node titles)
Entity (required by Title)
To add some usability to the site, we’ll also use:
Internationalization (i18n)
Variable (required by many of the translation modules)
Localization Update
Language Icons