1) how to improve DRUPAL performance for anonymous and authenticated users ?
Lighter user, basic configuration and performance tuning should handle more use cases.
Heavier user, can lead to more complex configurations to handle load and performance.
Caching for Drupal Websites
so here are five of the most important caching solutions for a Drupal website:
Drupal’s built-in caching
There are other options, of course, but these five cover most of the ground. Let’s briefly go through them one at a time.
Drupal’s Built-in Caching
Most of a Drupal site is stored in the database – nodes, information about blocks, etc. – and enabling the default caching will store the results of these database queries so that they aren’t executed every time a page is requested. Enabling these settings alone can have a big impact on performance, particularly if your pages use a lot of views. This one is kind of a no-brainer.
The Boost module is pretty great. It works very well in tandem with Drupal caching, but it requires some additional configuration. What you end up with after you have the module installed and configured is a caching system that stores the output of your Drupal site as static HTML pages. This takes PHP processing out of the equation, leading to another nice bump in performance.
Memcached can speed up dynamic applications (like Drupal) by storing objects in memory. With Boost and Drupal caching, the data being cached is stored on the server’s hard drive. With memcached, it’s being stored in memory instead of on the drive, something that can greatly speed up the response time for a page request.
Memcached works great in conjunction with both Boost and Drupal caching. For most folks, however, it’s something a server administrator will have to help install and configure.
Varnish is an HTTP accelerator that, similar to memcached, stores data in memory. It’s capable of serving pages much faster than Apache (the most common web server for Drupal sites).
It can also be used in conjunction with memcached, although it’s often the case that they are not used together and other advanced caching methods are instead implemented alongside Varnish. Most people will need a server admin to help set up Varnish on their server.
Another type of database caching is Views caching. Views is a very popular, but rather resource intensive, Drupal module. Implementing Views caching can give your site a nice additional performance boost by possibly removing a few database queries from the build process.
To set views caching, go to your view. On the right hand side, under Advanced > Other, you’ll see a link for Caching. Just go in and set a value – an hour is usually a good default – for each view on your site.
Performance and Scalability in Drupal 7
One of the most commonly mentioned performance issues in Drupal 5 and 6 was the number of queries executed per page, with most of these coming from path alias lookups. Path aliases allow a link to example.com/about to be converted to example.com/node/1 automatically in both directions. What is less known is that these queries were introduced in Drupal 4.7 to fix a scalability issue in earlier versions of Drupal.
Paths, round trips and mass transit
In Drupal 7 two large changes to the path system were introduced:
The path system maintains a white-list of which kinds of paths to look up aliases for, to avoid making round trips when there is nothing there to find – if there’s no aliases for user/*, it doesn’t bother looking for them.
Each page builds a cache of paths that were last requested, replaced every 24 hours or on cache clears. This allows those aliases to be queried in one go on the next request. If a path isn’t in the cache, it’s looked up individually until the next time the cache is refreshed.
The combination of these two optimizations means that on cache misses only a subset of paths are queried.
Entities on the wagon
In Drupal 7, introduced the Entity API and the concept of ‘multiple load’. The entity_load() function takes an array of entity IDs so database queries and hooks can all act on the list of entities at the same time. If a single node takes five database queries to build, it will only take five queries to build 30 nodes in Drupal 7, compared to 150 queries for the same objects in Drupal 6.
Big data, big queries
As Drupal has become more popular, the number of Drupal sites storing large amounts of data has increased. Drupal 7 introduces a number of measures to deal with this.
The new database layer and query builder allows drivers to specify case-insensitive operators. This allows MySQL to use LIKE() for auto-complete and user name lookups instead of LOWER(), allowing these queries to use indexes rather than doing a full table scan.
Forum, taxonomy and tracker modules now build de-normalized tables containing the data needed to build listings. Queries that used to require conditions and sorts across multiple tables can now be run against a single table, fully indexed.
InnoDB is enabled by default, providing much better safety and performance than MyISAM, particularly in situations with a large number of writes.
Fields and NoSQL
These de-normalized tables help with specific pain points encountered by Drupal 6 sites using those core features. However, a bigger issue facing Drupal sites is the combination of highly flexible storage via modules like CCK and Flag combined with the need to display that data in many different ways (often using the equally flexible Views module). This flexibility tends to lead to slow queries.
A plug for pluggability
In addition to the pluggable watchdog, cache and session backends in Drupal 6, Drupal 7 added pluggable lock and queue APIs. This means the storage for these systems can be moved out of SQL to MongoDB, Memcached, APC, Beanstalkd and other technologies better suited to handle these tasks at high volume.
Files and front end
Alongside swapping out SQL, Drupal 7 also allows you to swap out your local filesystem much easier, both for saving and serving files. Core file handling now uses PHP stream wrappers, meaning any file storage method supported by a stream wrapper can be used for file operations. Support already exists for Amazon S3 and the PHP hash wrapper in contributed modules. CDN support also got easier, with the CDN project providing drop-in support from contrib.
2) Explain panels and page layout ?
Features of Panels
- Panels supports styles, which can control how individual content panes, regions within a panel, and the entire panel will be rendered. While Panels ships with few styles, styles can be provided as plugins by modules, as well as by themes!
- The layout builder is nice for visually designing a layout, but a real HTML guru doesn’t want the somewhat weighty HTML that this will create. Modules and themes can provide custom layouts that can fit a designer’s exacting specifications, but still allow the site builder to place content wherever you like.
- Panels includes a pluggable caching mechanism. A single cache type is included, the ‘simple’ cache which is time-based. Since most sites have very specific caching needs based upon the content and traffic patterns, this system was designed to let sites that need to devise their own triggers for cache clearing and implement plugins that will work with Panels. Panels can be cached as a whole, meaning the entire output of the panel can be cached, or individual content panes that are heavy can be cached.
- Panels can be integrated with Organic Groups through the og_panels module to allow individual groups to have their own customized layouts.
- Panels integrates with Views to allow administrators to add any view as content. Or, for uses where the layout editor needs more tightly controlled content, Views can be given custom displays to provide only what the site administrator wants the panels builder to use.
Panels module is a User Interface on top of theme() and hook_theme()
It’s very easy to get overwhelmed by the number of options, buttons and links. So let’s start simpler: a two column layout.
Explaining Panels blog post image
The code needed to declare that this two column layout exists at all is really small. Browse around the directory declaring it. There is not much there. An info array tells us most importantly that we have left and right regions.
‘regions’ => array(
‘left’ => t(‘Left side’),
‘right’ => t(‘Right side’)
And there’s a template file that prints the left and right regions.
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.
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
Functions and overrides defined in the template.php
A sub-theme will not inherit:
Logos and Favicons
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
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’).
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() 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:
You can also build new kinds of entity types where the options above don’t suit your needs.
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.
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.
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
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.
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)
Title (to translate the node titles)
Entity (required by Title)
To add some usability to the site, we’ll also use:
Variable (required by many of the translation modules)