You are here

Home » API reference » Authenticated User Page Caching (Authcache) 7.2

README.txt in Authenticated User Page Caching (Authcache) 7.2

Same filename in this branch
  1. 7.2 README.txt
  2. 7.2 modules/authcache_varnish/README.txt
  3. 7.2 modules/authcache_form/README.txt
  4. 7.2 modules/authcache_forum/README.txt
  5. 7.2 modules/authcache_builtin/README.txt
  6. 7.2 modules/authcache_p13n/README.txt
  7. 7.2 modules/authcache_votingapi/README.txt
Authcache Personalization API
=============================

The personalization API provides means to simplify substitution of
personalized markup with placeholders as well as an alternative light weight
front controller capable of rendering and delivering personalized fragments of
a page without requiring a full Drupal bootstrap.


Installation
------------

Enable this module along with Authcache Ajax and/or Authcache ESI. Also enable
all the Authcache modules providing support for the following core/contrib
modules if you use them:
* Block
* Comment
* Contact
* Field
* Flag
* Form
* Forum
* Menu (Support for local tasks and local actions)
* Page Manager (Only if you use panels)
* Panels
* Poll
* Search
* Views

For production environments it is strongly recommended to use the safe front
controller script by following the instructions contained in
safe_frontcontroller/authcache.php

Reasons for installing the safe front controller are shorter URLs and reduced
likeliness of experiencing potential side effects due to the modification of
some $_SERVER keys, which is necessary when the front controller script lives
somewhere else than in the Drupal root directory.


Markup Substitution
-------------------

Three methods of markup substitution are supported by this module.
* fragment: Replace a fragment on a page by a placeholder. One request to the
  front controller is issued for each substituted fragment on a page. (e.g.
  form tokens by the Form module).
* setting: Load a Drupal.setting using the front controller and run the
  Drupal.attachBehaviors JavaScript function on the result. (e.g. contact
  details by the Contact module).
* assembly: Load multiple fragments in one request and inject them via
  JavaScript into the DOM (e.g. flags by the Flag module).

Rendering of the substitution markup is left to client-modules. Currently
Authcache ships with two of them, namely Authcache Ajax and Authcache ESI. The
former uses Ajax to call back to the front controller directly from the users
browser while the latter embeds ESI tags, such that markup substitution
already can take place on a reverse proxy server (e.g. Varnish).


Light Weight Front Controller
-----------------------------

The personalization front controller by default does not perform a full
bootstrap. This results in much quicker response times if only a selected
subset of functionality is required to render a fragment. For example in order
to generate the tokens necessary to protect forms against CSRF attacks, a
bootstrap level of DRUPAL_BOOTSTRAP_SESSION is sufficient.

Fragments delivered through the personalization front controller also may have
different cache lifetimes than the pages they are displayed on. E.g. on a
blog, the recent-comments block may have a cache-lifetime of 10 minutes while
an article page can be setup with a cache lifetime of 24 hours.

File

modules/authcache_p13n/README.txt
View source 
  1. Authcache Personalization API

  2. =============================

  3. 

  4. The personalization API provides means to simplify substitution of

  5. personalized markup with placeholders as well as an alternative light weight

  6. front controller capable of rendering and delivering personalized fragments of

  7. a page without requiring a full Drupal bootstrap.

  8. 

  9. 

  10. Installation

  11. ------------

  12. 

  13. Enable this module along with Authcache Ajax and/or Authcache ESI. Also enable

  14. all the Authcache modules providing support for the following core/contrib

  15. modules if you use them:

  16. * Block

  17. * Comment

  18. * Contact

  19. * Field

  20. * Flag

  21. * Form

  22. * Forum

  23. * Menu (Support for local tasks and local actions)

  24. * Page Manager (Only if you use panels)

  25. * Panels

  26. * Poll

  27. * Search

  28. * Views

  29. 

  30. For production environments it is strongly recommended to use the safe front

  31. controller script by following the instructions contained in

  32. safe_frontcontroller/authcache.php

  33. 

  34. Reasons for installing the safe front controller are shorter URLs and reduced

  35. likeliness of experiencing potential side effects due to the modification of

  36. some $_SERVER keys, which is necessary when the front controller script lives

  37. somewhere else than in the Drupal root directory.

  38. 

  39. 

  40. Markup Substitution

  41. -------------------

  42. 

  43. Three methods of markup substitution are supported by this module.

  44. * fragment: Replace a fragment on a page by a placeholder. One request to the

  45.   front controller is issued for each substituted fragment on a page. (e.g.

  46.   form tokens by the Form module).

  47. * setting: Load a Drupal.setting using the front controller and run the

  48.   Drupal.attachBehaviors JavaScript function on the result. (e.g. contact

  49.   details by the Contact module).

  50. * assembly: Load multiple fragments in one request and inject them via

  51.   JavaScript into the DOM (e.g. flags by the Flag module).

  52. 

  53. Rendering of the substitution markup is left to client-modules. Currently

  54. Authcache ships with two of them, namely Authcache Ajax and Authcache ESI. The

  55. former uses Ajax to call back to the front controller directly from the users

  56. browser while the latter embeds ESI tags, such that markup substitution

  57. already can take place on a reverse proxy server (e.g. Varnish).

  58. 

  59. 

  60. Light Weight Front Controller

  61. -----------------------------

  62. 

  63. The personalization front controller by default does not perform a full

  64. bootstrap. This results in much quicker response times if only a selected

  65. subset of functionality is required to render a fragment. For example in order

  66. to generate the tokens necessary to protect forms against CSRF attacks, a

  67. bootstrap level of DRUPAL_BOOTSTRAP_SESSION is sufficient.

  68. 

  69. Fragments delivered through the personalization front controller also may have

  70. different cache lifetimes than the pages they are displayed on. E.g. on a

  71. blog, the recent-comments block may have a cache-lifetime of 10 minutes while

  72. an article page can be setup with a cache lifetime of 24 hours.