Extend and customize Drupal functionality with contributed modules.
If a module doesn't quite do what you want it to do, if you find a bug or have a suggestion, then join forces and help the module maintainer. Or, share your own by starting a new module.
This module defines the "hierarchical_select" form element, which is a greatly enhanced way for letting the user select items in a hierarchy.
Hierarchical Select has the ability to save the entire lineage of a selection or only the "deepest" selection. You can configure it to force the user to make a selection as deep as possible in the tree, or allow the user to select an item anywhere in the tree. Levels can be labeled, you can configure limit the number of items that can be selected, configure a title for the dropbox, choose a site-wide animation delay, and so on. You can even create new items and levels through Hierarchical Select!
For a good overview of what Hierarchical Select can do, look at this demo!
Boost provides static page caching for Drupal enabling a very significant performance and scalability boost for sites that receive mostly anonymous traffic. For shared hosting this is your best option in terms of improving performance. On dedicated servers, you may want to consider Varnish instead.
This module provides configurable actions upon events that will expire URLs from caches like reverse proxy caches, internal page caches, etc.This module make more sense when Minimum Cache Lifetime setting is set to a value other than none.
There is now integration with the following modules:
Boost - deletes expired pages (files) from the file system.
Varnish - integrates over an administrative socket.
Summary (7.x & 8.x)
AdvAgg allows you to improve the frontend performance of your site. Be sure to do a before and after comparison by using Google's PageSpeed Insights and WebPagetest.org. The performance benefits are achieved by using some of the features found in AdvAgg and its sub modules. Out of the box AdvAgg's frontend performance will be similar to cores.
!NEW Release 2.0 is finally out, with D7 support, code & performance improvements and a lot of new features!
Elysia Cron extends Drupal standard cron, allowing a fine grain control over each task and several ways to add custom cron jobs to your site.
[NEW IN 2.0] Set the timings and frequencies of each cron task (you can run some jobs every day at a specified hour, other only monthly and so on...). For each task you can simply choose between some frequently used options ("once a day", "once a month" ...), or use a powerful "linux crontab"-like syntax to set the accurate timings. You can even define your frequently used options to speed up site configuration.
Parallel execution of cron task: you can group jobs in channels and execute then simultaneously: so a task that takes a lot of time to execute won't block other tasks that need to be executed every 5 minutes...
You can disable all tasks, an entire channel or a single task.
Change the priority/order of task execution.
Manual force the execution of a cron tasks.
Detailed overview of cron status with time statistics for single tasks and channels.
[NEW IN 2.0] powerful API for module developers: you can define extra cron tasks for your modules, each one with own default timings (site administrators can override them by configuration, other modules via hook_alter). Elysia Cron 2.0 gives a brand new API support (compatible with 1.0 version) with a lot of features.
Administrators can define custom jobs (call to functions with parameters), via the "script" option.
Several optimization for frequent cron calls and error handling.
Protection from external cron calling by cron_key or allowed host list.
Elysia has no dependencies with contributed modules, and doesn't need to patch the core: it can be used in minimal Drupal installation with only core modules.
It also can be used in a Drupal install profile.
3rd party integration:
[NEW IN 2.0] Ping feature, for external tracking services like host-tracker to tell whether cron is functioning properly on your site.
[NEW IN 2.0] Drush support: you can call "drush elysia-cron" to manually run extended cron.
[NEW IN 2.0] CTools support for exports/backup of task settings.
This module provides integration between your Drupal site and Varnish cache, an advanced and very fast reverse-proxy system. Basically, Varnish handles serving static files and anonymous page-views for your site much faster and at higher volumes than Apache, in the neighborhood of 3000 requests per second.
This module provides admin-socket integration which allows Drupal to dynamically invalidate cache entries, and also lets you query the Varnish admin interface for status, etc.
This is a library module. It provides no out of the box functionality other then providing an API that other modules/code can use. Other projects might require/recommend this module. Install HTTPRL only if other modules recommend or require it.
What does httprl do?
Using stream_select() it will send http requests out in parallel. These requests can be made in a blocking or non-blocking way. Blocking will wait for the http response; Non-Blocking will close the connection not waiting for the response back. The API for httprl is similar to the Drupal 7 version of drupal_http_request().
As a bonus, a simple threading library is built on top of the parallel http requests functionality. This allows you to split a job and have multiple http "workers" running this split job in parallel. Anything that takes a long time to do can greatly benefit from using threads.
Drupal has expensive 404 errors. On an 'average' site with an 'average' module load, you can be looking at 60-100MB of memory being consumed on your server to deliver a 404. Consider a page with a bad .gif link and a missing .css file. That page will generate 2 404s along with the actual load of the page. You are most likely looking at 180MB of memory to server that page rather than the 60MB it should take.
That's where Fast 404 comes in. This module combines a very common method of handling missing image/file 404 errors (discussed here and planned for Drupal 8) with a method created by dpardo (a co-maintainer of this project) to deliver super fast 404 error pages for both missing images and bad paths. Depending on which method of implementation you choose (aggressive or super aggressive) you can deliver 404 errors using less than 1MB of memory on your server.
Drupal 7 Core Updates
Drupal 7 core has updated to add a rudimentary version of what this module implements. It allows you to set an excluded set of paths, a list of extensions to Fast 404 on, as well as the plain HTML that is delivered.
Modernizr tests which native CSS3 and HTML5 features are available in each browser and makes the results available to you in two ways: as properties on a global Modernizr object, and as classes on the <html> element. This information allows you to progressively enhance your pages with a granular level of control over the experience.
This Drupal module provides deep integration with the Modernizr JS library, allowing other modules or themes to register tests, load additional assets as needed, and even create new copies of the Modernizr library when a website's requirements change. Read more below.
Minify is designed to improve the website performance.
How Minify help
Minify removes the comments and whitespace which will help to reduce the file size. Smaller HTML and file size reduces the page load time and improve the website performance.
This module provides easy Content Delivery Network integration for Drupal sites. It changes file URLs, so that files (CSS, JS, images, fonts, videos …) are downloaded from a CDN instead of your web server.
An API for browsing next/previous nodes without overloading your database server.
This module allows you to know the previous or next nodes for any given node. This is very useful for providing navigational links to the user without the expensive queries required to dynamically deduce such information on the fly.
The use case is two fold:
For example, on a site with a gallery of images, you want to show a next/previous link with a thumbnail under each image. Your site's visitor click on the link to show new content or browse it.
Although the previous and next nodes can be deduced with some SQL work, the queries to do so are very heavy on the database, and can bring a site to its knees. This module solves this problem by storing the previous/next node in a table so lookups are fast. Once the module is installed, it will build this index backwards via cron until all nodes have been indexed. See the "More Info" section below for a detailed post on the positive scalability impacts of implementing this module.
The module can be restricted to certain content types to be included in the previous/next indexing. For example, you want the site's visitors to browse through video and image nodes only, but not blogs and regular pages.
All Drupal sites need some magic, so give yours some! Magic is a set of tools for front-end best practices and general front-end goodies to make your life as a front-end developer happier. Features include:
The Alternative PHP Cache (APC) is a free and open opcode cache for PHP. Its goal is to provide a free, open, and robust framework for caching and optimizing PHP intermediate code. Besides a opcode cache it provides a user cache for storing application data. This module uses the APC user cache as a cache backend for Drupal.
The acquia_purge module invalidates your Varnish caches on your Acquia Cloud site. When this is combined by setting Drupal's time to live (TTL) extremely high, your stack requires less servers, becomes much more resilient against DDOS attacks and performance dramatically improves!
Permits to load some blocks by additional AJAX request after loading the whole cached page when the page is viewed by anonymous user. It is suitable for sites which are mostly static, and the page caching for anonymous users is a great benefit, but there are some pieces of information that have to be dynamic.
Alter cache settings per block. Cache settings per block are now set in code, but if you don't like the default - usually none - you can now easily change this. Install this to speed up block rendering for authenticated users.
Alter cache settings per block. Cache settings per block are now set in code,
but if you don't like the default - usually none - you can now easily change this
per block on the block configuration page in a fieldset called 'Cache settings'.
Install this to speed up block rendering for authenticated users.
This is a small helper module which will automatically lazyload all images for sites with multiple images, which will make the site load faster.
All images will only load when it's visible to the browser window.
2) Distance - image distance from the viewable browser window before the actual image loads
3) Placeholder Image - stand-in image
4) Loader Icon - animating icon (shamelessly borrowed from ajaxblocks module)
5) Excluded Pages - page paths to be excluded from image lazyload
For other images:
You can also manually lazyload your other images not processed by Drupal image module by formatting your img markup to this:
1) src = path to placeholder image
2) data-src = path to actual image
3) width = add width for best result
4) height = add height for best result
5) Add a container block
The Speedy module is designed to help speed up front end performance in a site.
The Authcache module offers page caching for both anonymous users and logged-in authenticated users. This allows Drupal/PHP to only spend 1-2 milliseconds serving pages, greatly reducing server resources.
Please note that enabling authenticated user caching will require modifying how your user-customized content displays on your pages. You should be an experienced Drupal developer if you choose to implement the full functionality of this module.
How does it work?
Authcache saves the final rendered HTML of a page to serve visitors. A separate cache is created for each user role as defined by the administrator, so some roles can be excluded if necessary.
Authcache places priority on serving pages to the visitor as fast as possible. After a page is loaded by the browser, a second HTTP request may be performed via Ajax. This initiates a lightweight DRUPAL_BOOTSTRAP_SESSION that allows SQL queries to be executed (such as updating the user "history" table or node "statistics" table), and returns any user-customized data to the page (such as form tokens or default values on a contact form).