Tuesday 2 October 2012

About Drupal 7 Hook, Form API, Token, Triggers, Cache, Performance optimization

  • About Drupal Hook.
    In programming, a hook is a place and usually an interface provided in packaged code that allows a programmer to insert customized programming. Allow modules to interact with the Drupal core.

    Drupal’s module system is based on the concept of “hooks”. A hook is a PHP function that is named foo_bar(), where “foo” is the name of the module (whose filename is thus foo.module) and “bar” is the name of the hook. Each hook has a defined set of parameters and a specified result type.

    For example, if the module file is called example.module, then hook_help() as implemented by that module would be defined as example_help().
  • About Drupal Form API.
    Drupal's Form API is a powerful tool allowing developers to create forms and handle form submissions quickly and easily. This is done by defining arrays of form elements and creating validation and submit callbacks for the form.

    function form_example_tutorial_1($form, &$form_state) {
      $form['description'] = array(
        '#type' => 'item',
        '#title' => t('A form with nothing but a textfield'),
      );
      // This is the first form element. It's a textfield with a label, "Name"
      $form['name'] = array(
        '#type' => 'textfield',
        '#title' => t('Name'),
      );
      return $form;
    }
  • About Drupal Token.
    A token is a small piece of text that can be placed into a piece of text via the use of a placeholder. When the text is passed through the function token_replace(), then the tokens are replaced with the appropriate information. Tokens allow users to include data that could change in text blocks, without having to go back and change it everywhere they're referenced.

    A sample token is [site:name]. When text containing this token is passed through token_replace(), it is replaced with your site's name as defined in Home | Administer | Configuration | Site information.
  • About Drupal Triggers.
    The Trigger module provides the ability to take a particular action when a trigger occurs.

    Actions include functional tasks that are defined by Drupal core modules, and advanced actions that can be defined by the system administrator. Contributed modules can introduce new actions. Some examples of actions are sending an email, publishing a node, banning a user or promoting a node to the front page of a website.

    The Trigger module allows you to perform useful tasks by associating actions with specific triggers, such as e-mailing an administrator (the action) when a user account is deleted (the trigger), or automatically unpublishing a comment (the action) if the added comment (the trigger) contains certain words. The Trigger module is included in the core Drupal installation. The module must be enabled to use it.
  • About Drupal Cache.
    A collection of data duplicating original values stored elsewhere on a computer Drupal's APIs provide three key functions you'll need to be familiar with: cache_get(), cache_set(), and cache_clear_all().

    cache_get($cid, $bin = 'cache') Data may be stored as either plain text or as serialized data. cache_get will automatically return unserialized objects and arrays.

    Parameters
    $cid: The cache ID of the data to retrieve.

    $bin: The cache bin to store the data in. Valid core values are 'cache_block', 'cache_bootstrap', 'cache_field', 'cache_filter', 'cache_form', 'cache_menu', 'cache_page', 'cache_path', 'cache_update' or 'cache' for the default cache.

    cache_set($cid, $data, $bin = 'cache', $expire = CACHE_PERMANENT)
    Stores data in the persistent cache.

    The persistent cache is split up into several cache bins. In the default cache implementation, each cache bin corresponds to a database table by the same name. Other implementations might want to store several bins in data structures that get flushed together. While it is not a problem for most cache bins if the entries in them are flushed before their expire time, some might break functionality or are extremely expensive to recalculate. These will be marked with a (*). The other bins expired automatically by core. Contributed modules can add additional bins and get them expired automatically by implementing hook_flush_caches().

    Cache: Generic cache storage bin (used for variables, theme registry,
    locale date, list of simpletest tests etc).

    cache_block: Stores the content of various blocks.
    cache field: Stores the field data belonging to a given object.
    cache_filter: Stores filtered pieces of content.
    cache_form(*): Stores multistep forms. Flushing this bin means that some
    forms displayed to users lose their state and the data already submitted to them.

    cache_menu: Stores the structure of visible navigation menus per page.
    cache_page: Stores generated pages for anonymous users. It is flushed
    very often, whenever a page changes, at least for every ode and comment submission. This is the only bin affected by the page cache setting on the administrator panel.

    cache path: Stores the system paths that have an alias.
    cache update(*): Stores available releases. The update server (for
    example, drupal.org) needs to produce the relevant XML for every project installed on the current site. As this is different for (almost) every site, it's very expensive to recalculate for the update server.

    The reasons for having several bins are as follows:
    Smaller bins mean smaller database tables and allow for faster selects and inserts we try to put fast changing cache items and rather static ones into different bins. The effect is that only the fast changing bins will need a lot of writes to disk. The more static bins will also be better cacheable with MySQL's query cache.
    Parameters

    $cid: The cache ID of the data to store.

    $data: The data to store in the cache. Complex data types will be automatically serialized before insertion. Strings will be stored as plain text and not serialized.

    $bin: The cache bin to store the data in. Valid core values are 'cache_block', 'cache_bootstrap', 'cache_field', 'cache_filter', 'cache_form', 'cache_menu', 'cache_page', 'cache_update' or 'cache' for the default cache.

    $expire: One of the following values:

    CACHE_PERMANENT: Indicates that the item should never be removed unless explicitly told to using cache_clear_all() with a cache ID.
    CACHE_TEMPORARY: Indicates that the item should be removed at the next general cache wipe.
    A Unix timestamp: Indicates that the item should be kept at least until the given time, after which it behaves like CACHE_TEMPORARY.

    cache_clear_all($cid = NULL, $bin = NULL, $wildcard = FALSE)
    Expires data from the cache.

    If called without arguments, expirable entries will be cleared from the cache_page and cache_block bins.

    Parameters

    $cid: If set, the cache ID to delete. Otherwise, all cache entries that can expire are deleted.

    $bin: If set, the cache bin to delete from. Mandatory argument if $cid is set.

    $wildcard: If TRUE, cache IDs starting with $cid are deleted in addition to the exact cache ID specified by $cid. If $wildcard is TRUE and $cid is '*', the entire cache bin is emptied.
  • About Performance optimization of Drupal Website.
    The first step is to consider what part of your site is experiencing problems. A particular page or View.
    Another issue to consider is whether it's the backend that's slow, or the frontend.

    Secondly, Take a look at the load on your CPU when you notice poor performance as serving complex PHP applications can be quite taxing.

    On every production Drupal site I'll take the following steps:
    (1)   Enable CSS/JS compression
    (2)   Make sure APC is enabled and properly configured
    (3)   Disable unnecessary modules
    (4)   Clean up as many PHP errors as possible, especially if we're logging with the dblog or syslog modules
    (5)   Make sure the MySQL query cache is enabled and properly configured
    (6)   Sprite images where possible for frontend performance benefits

    We can go further to attempt to address outstanding issues:

    (1)   Cache expensive or time consuming operations, for example, requesting data from a web service. Drupal makes this simple with cache_set() / cache_get().
    (2)   Turn on additional caching, such as Views or Block, if possible
    (3)   Use the MySQL slow query log and run EXPLAIN on the logged queries. Look for queries which have joins using filesort or temporary tables and determine whether          these could be rewritten or sped up with an index.
    (4)   Analyze the traffic pattern. A site with a largely anonymous user base can see a significant benefits from implementing the Boost module or Varnish in to the         server stack.
    (5)   Change cache backends. Drupal reads and writes a lot of data from its caches (as it should) so you can see some great speed improvements storing this data                in memory (fast!) rather than the database (on the disk, slow!).


    While many things can contribute to a slowed-down site, there are some common issues that affect many customized Drupal setups. These common issues are :-

    Server Configuration
    User Types, Browsing Habits and Connections
    Using External Resources
    Database Configuration
    Image Handling
    Know Your Cache

    Helpful Drupal Modules
    Once you've completed the simple "do it yourself" steps, there are some modules offered by Drupal's community to help boost performance. Be sure to read through each module's documentation carefully, though - these are not simple plug-n-play modules. They require some configuration to get installed correctly.

    1. Memcache API and Integration

    The Memcache API and Integration module serves as, you guessed it, an integration between Drupal and Memcached.

    Memcached works to improve dynamic web applications by alleviating database load. It helps to optimize your site's use of available memory for caching. The installation looks scary, so be sure to read through every thing carefully to make sure that you've got it set correctly. However, once set, you'll see that it's totally worth the effort. Make sure your webhost supports memcache before trying this module.

    2. APC - Alternative PHP Cache

    The APC - Alternative PHP Cache module works to provide a reliable framework for caching and optimizing PHP intermediate code. It is best suited for caches which are not expected to change often or grow beyond a certain size.

    3. Boost

    The Boost module is another module that requires a little extra effort to get installed and working correctly. But, once it's up and running, you'll be glad you put in that extra effort.

    Unlike some other caching modules, Boost has been tested and works well on all sorts of server types - Shared, VPS, Dedicated. This module provides static page caching, which will have significant impact on your site's performance if your site's visitors are primarily anonymous visitors. If your site's traffic is mostly logged in / authenticated users, then Boost won't help you all that much.

    4. Varnish HTTP Accelerator Integration

    The Varnsh HTTP Accelerator Integration module works as a stack above Apache, helping to serve up cached files and page views faster for anonymous visitors.

    And My Personal Favorite Is...

    Personally, I use either Boost or Memcache depending on a particular site's needs. Boost if the traffic is mostly anonymous, and Memcache if the traffic is mostly registered members. Seems fairly cut and dry, right?

    But, in recent years, I have been working with more and more clients where it hasn't been quite so cut and dry. Their traffic has been almost equal between anonymous and logged in / authenticated users. So, you may like to know that these two modules play nicely together when installed on the same site - without any more work or configuration beyond their normal installation.