Drupal Sessions

2009 June 25
Posted by bharatsharma83@gmail.com

Drupal sessions:

How Sessions works on drupal:

The page request send by the browser includes a 32-character ID known as PHPSESSID under set- cookie tag, which is used as the key to the session information that drupal stores about session.

  • The settings for session management are done in three files i.e. .htaccess, settings.php nad bootstarp.inc

  • By default drupal uses the cookie based session management instead of URL base session management. If the browser doesn’t accept cookies , a session cannot be established

      • The PHP directive ’sessions.use_only_cookies’ is set to 1 in settings.php to accept cookie based sessions.

      • The PHP directive ’sessions.use_trans_sid’ is set to 0 in settings.php to reject URL based sessions.

  • At the installation time Drupal turns off the PHP’s ’session.auto_start’ functionality in .htaccess file to take full control over sessions.

Why Drupal need sessions?

  • To handle the viewing preferences of the site content according to viewer status.

  • To remember the viewing preferences: Drupal stores sessions in ’sessions’ table, the session table is used to associate the sessions Ids with the user ids to retrieve the viewing preferences of a user. It applies a join query on session and user tables using session ids and user ids to know the user role. Session data of a user is viewable by $user->session of $user object.

      • To represent a session for anonymous user, the ’session’ table ‘uid’ column is set to 0.

      • To represent a session for login user, the ’session’ table ‘uid’ column is set to user Id with a new session Id such that the session does’nt get hijacked. If a user logs out, the row for that session is removed from the database immediately.

  • To remember the comments preferences: In comment.module session is used to store viewing preferences for users, i.e.

      • $_SESSIONS['comment_mode']=$mode

      • $_SESSIONS['comment_sort']=$order

      • $_SESSIONS['comment_comments_per_page']=$comments_per_page

  • To handle file uploads

Session Life time

  • Sessions lifetime related settings are located in settings.php, By default

      • ini_set(’session.cache_expire’, 200000); // 138.9 days

      • ini_set(’session.cookie_lifetime’, 2000000); // 23.1 days

      • ini_set(’session.gc_maxlifetime’, 200000); // 55 hours

Other Information

  • Writing session in the session table is the last task of drupal while serving pages.

  • Drupal does not store session information , the first time a user visits a site. This is to reduce the load on the sessions table generated by crawlers.

  • Drupal $user object is first built during the DRUPAL_BOOTSTRAP_SESSION phase of bootstrapping by sess_read().

  • While deploying drupal on multiple subdomains, you can create a unique session name for each site by adding ini_set(’session.name’, ‘my-site-unique-name_PHPSESSID’); in settings.php

  • If you need to store short term data for anonymous users, use the $_SESSION superglobal e.g.

      • $_SESSION['anonymous_data']=$anonymous_data;

  • If you want to store a permanent data to a user, save it in the $user object e.g.

      • $user->login_name=$login_name; user_save();

csmpqgbe7r

Add to Technorati Favorites

Drupal Cache

2009 July 2
Tags: , ,
Posted by bharatsharma83@gmail.com
  • Caching is required to prevent dynamic websites numerous trips to the database to retrieve information about saved content, user, setting and config. Caching is used to speed up a website performance and visibility.
  • Drupal uses its cache API to provide caching of modules, node and pages. The default table in which drupal stores the module settings is called ‘cache’. We can create our own cache tables for various modules. The only requisite of cache API for custom cache tables is that the structure must be identical to the default cache table.
  • Besides cache table drupal also ships with three other cache tables know as

cache_page (stores cache of anonymous pages)

cache_menu (stores cache for navigational menus)

cache_filter ( stores cache copy of node’s content)

  • The drupal_page_cache_header() prepares the cache data by setting HTTP headers.
  • Functions of cache API

Three important cache functions:

cache_set($cid, $table=’cache’, $data, $expire=CACHE_PERMANENT, $header=NULL)

where , $cid= Unique cache ID

$table= Name of the cache table to store the data, by default ‘cache’ table is used.

$data= data to store in the cache.

$expire=The cache data expire time. You can use CACHE_PERMANENT, CACHE_TEMPORARY or a Unix Timestamp. By default CACHE_PERMANENT is set.

$headers= The HTTP header passed to the browser.

cache_get($cid, $table=‘cache’ )

where $cid= The cahe id of the data to retrieve.

$table= The table name from which data retrieved. The cache table is used by Default.

cache_clear_all($cid=NULL,$table=NULL,$wildcard=NULL)

where $cid=if set,  clear only the given cache ID, otherwise delete all expire entries.

$table=the table to delete from.if not set entries from cache_block and cache_page table will be deleted.

$wildcard=if set to TRUE , all cache entries with ID contains a substring similar to $cid wil be deleted.

8yjebzxq9v

Drupal Forms API

2009 June 29
Posted by bharatsharma83@gmail.com

This post is about the Form API of drupal6, You may find this post written in a little bit of unimpressive way, this is bcoz i am running short of time these days nonetheless i would like your suggestions and comments at any time and will try to make them happening:

Forms API

  • The forms API abstracts forms into a nested array of properties and values.
  • $form_values is array which holds form elements values.
  • The form token (form unique id) is stored in the variables table as drupal_private_key.
  • drupal_get_form() function interact with drupal form.
  • hook_elements() function is used to define element type.
  • hook_element() can be used to define your own element types in your module.
  • element_info() hook collects all the properties for all form elements.

FORM PROPERTIES

  • #validate property is used to validate the form elements.
  • #base is used to apply same validator to several forms.
  • #submit handles form submission. If there is no property named #submit, drupal looks for function name “formID_submit()” or failing that drupal again search for “#basevalue_submit”.
  • #after_build property will call all functions of a form.
  • #theme is used to set a theme to an existing form.
  • #pre_render property used to call the functions just before the transformation of form from a data structure to HTML.
  • #prepend, #suffix properties are used to prepend and append text to  the form elements. drupal also uses these properties while rendering the form.
  • #method property is used to set the form method to post. By default it is set to post, Also get method is not supported by the form API.
  • #tree : Setting #tree to TRUE gives a nested array of fields with there values. While #tree is set to FALSE, we get a flattened representation of field name and values.

FLOW of form formation:

when a module contains a form code is called by drupal the form datastructure renders form into html in the following sequence:

call drupal_get_form() -> call hook_elements()['defining element types such as radio buttons, chekcboxes, textfiels'] -> call elements_info() [information about the related properties ,values and functions] -> #validate property -> #submit property

Bibliography: Apress Pro Drupal Devlopement (ycu73k6ath)