Display Cache provides a simple way to cache the html of a specific entity endered in a specific view mode.
The idea is to let each entity handle its own cache independent of external caching strategies. So the cache only refreshes if the displayed entity is actually changed in any way.
Caching the display may have a huge impact on performance issues. See #1996842: Profiling for this module for benchmarks.
Comparision to other caching methods
Panels and Views
Panels and views provide a time-based caching mechanism. You can configure the time to elapse before the cache is rebuilt.
Panels
If a cached pane in Panels is used to display an entity and something is changed on this entity, the user has to wait until the configured caching time is elapsed before he gets the results displayed.
Views
If a cached view is used to display serveral entities and a new entity is added, which should be displayed within the view, the user has to wait also, before he gets the new Views results.
External caching mechanisms
External caching mechanisms like Varnish provide a good caching method unless the project works with logged in users. The request will not be cached bacause of the cookies sent within the call.
Usage
Call the display configuration page, with the display which shall be cached. For example admin/structure/types/manage/article/display/teaser. Enter the display cache section, enable Display Cache and configure the cache granularity.
Project Page: http://drupal.org/sandbox/Caseledde/1970904
Git: git clone http://git.drupal.org/sandbox/Caseledde/1970904.git display_cache
application reviews:
http://drupal.org/node/2000698#comment-7447794
http://drupal.org/node/1970152#comment-7443848
http://drupal.org/node/2001730#comment-7447862
application reviews second run:
http://drupal.org/node/1977172#comment-7467488
http://drupal.org/node/1994016#comment-7467596
http://drupal.org/node/2006076#comment-7472338
application reviews third run:
https://drupal.org/node/2004728#comment-7472520
https://drupal.org/node/2006668#comment-7472626
https://drupal.org/node/2001548#comment-7472750
Comments
Comment #1
PA robot CreditAttribution: PA robot commentedWe are currently quite busy with all the project applications and we prefer projects with a review bonus. Please help reviewing and put yourself on the high priority list, then we will take a look at your project right away :-)
Also, you should get your friends, colleagues or other community members involved to review this application. Let them go through the review checklist and post a comment that sets this issue to "needs work" (they found some problems with the project) or "reviewed & tested by the community" (they found no major flaws).
I'm a robot and this is an automated message from Project Applications Scraper.
Comment #2
InternetDevels CreditAttribution: InternetDevels commentedHi,
Found some issue:
You have some Error in Codes Sniffer, because name of API file must be .api.php (not .api.inc).
Comment #3
Caseledde CreditAttribution: Caseledde commentedThank you. Fixed.
Comment #4
fmizzell CreditAttribution: fmizzell commentedI have looked in d.o for a solution to this problem before without luck, so I am fairly certain that there isn't any duplicate modules out there.
I did not run the module through coder (but InternetDevels ran it through Codes Sniffer), but I have been playing with the code for a couple of weeks now, and it is well organized and easy to follow.
The solution itself shows a pretty good understanding of Drupal APIs, and how to work with them (specially entity and field APIs).
I did not do a full functional review of the module, but the basic functionality of the module is working correctly: I went to the manage display tab for one of my content types, set up caching for one of my view modes, and the render array started being cached.
After going through the review checklist, I feel that, if no one else sees any security issues with the code, this project is ready to be promoted to full status.
Comment #5
Caseledde CreditAttribution: Caseledde commentedAdded review bonus tag.
Comment #6
klausimanual review:
Otherwise looks pretty good! Removing review bonus tag, you can add it again if you have done another 3 reviews of other projects.
Comment #7
Caseledde CreditAttribution: Caseledde commentedHi Klausi,
thanks for your review.
1. I can't use hook_module_implements_alter() to alter the weight of hook_module_implements_alter() itself, because of
in module_implements().
See #1997458: It doesn't work!! for more informations why I have to increase the modules weight with hook_install().
2. Working on.
3. You are right with vulnerable to CSRF. But: In my opinion, this is how flush cache via admin_menu works. There are no flush cache callbacks provided by admin_menu with confirmation forms. So this should be a security issue for admin_menu too, shouldn't it?. Now we have three options:
So we have "act as usual" within admin_menu vs. we are aware of CSRF. I really curious about your opinion.
EDIT:
To point 3)
It seems, there are other functions within admin_menu to avoid CSRF. I have to dig a little deeper into admin_menu to get a solution.
Comment #8
Caseledde CreditAttribution: Caseledde commentedOkay,
I am back,
everything done.
Comment #8.0
Caseledde CreditAttribution: Caseledde commentedAdd application reviews
Comment #9
Caseledde CreditAttribution: Caseledde commentedSet to needs review.
Comment #10
Caseledde CreditAttribution: Caseledde commentedAdded review bonus tag.
Comment #11
klausiComment #12
klausiReview of the 7.x-1.x branch:
This automated report was generated with PAReview.sh, your friendly project application review script. You can also use the online version to check your project. You have to get a review bonus to get a review from me.
manual review:
watchdog('display cache', 'The entity type <em>@entity_type</em> s...
: use the "%" placeholder instead of "@" which will add the em tags for you.But otherwise looks RTBC to me. Removing review bonus tag, you can add it again if you have done another 3 reviews of other projects.
Comment #12.0
klausiAdd new application reviews.
Comment #13
Caseledde CreditAttribution: Caseledde commented0) $form_states renamed to $form_state. -> Fixed
1) The tokens by admin_menu are already in use. -> Fixed
2) The function was legacy. -> Removed
3) Uses t() now. -> Fixed
4) Uses '%' placeholder. -> Fixed
Comment #14
Caseledde CreditAttribution: Caseledde commentedAdded review bonus tag.
Comment #15
patrickd CreditAttribution: patrickd commentedComment #16
patrickd CreditAttribution: patrickd commenteddefine('DISPLAY_CACHE_DISABLED', '0');
why using a string ('0') instead of the actual integer (0)? (just nitpicking)
'title' => 'Administer Display Cache',
user readable text should always be piped through t() (except within hook_menu() implementations, watchdog() calls or database schemas)
Beside that I really liked what I saw,
Thanks for your contribution!
I updated your account so you can promote this to a full project and also create new projects as either a sandbox or a "full" project.
Here are some recommended readings to help with excellent maintainership:
You can find lots more contributors chatting on IRC in #drupal-contribute. So, come hang out and stay involved!
Thanks, also, for your patience with the review process. Anyone is welcome to participate in the review process. Please consider reviewing other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.
Thanks to the dedicated reviewer(s) as well.
Comment #17
Caseledde CreditAttribution: Caseledde commentedThanks a lot for all reviewers.
I just prepare the release.
2. t() is added.
3. I overlooked it. Fixed now.
Comment #18.0
(not verified) CreditAttribution: commentedUpdate application reviews.