galliCache for Elgg 1.8.X v1.3

Release Notes

1.3 (13/11/2013):

  • Better cache creation and compatibility with third party themes
  • Tested only with Elgg 1.8.16
  • To upgrade > Please disable current plugin > remove it from mod directory and install this.
  • i just tested this update.. and found that the background css issue was resolved.

    now though i have 2 other issues:

    1. the images that would be loaded by the lazy_load plugin are now dead lazy and do not load at all.
    2. the homepage produced a fatal crash:
      Fatal error: Call to undefined function apache_request_headers() in /mysite/mod/galliCache/start.php on line 87 Call Stack: 0.0001 238368 1. {main}() /mysite/index.php:0 0.2097 7444512 2. elgg_trigger_plugin_hook() /mysite/index.php:17 0.2097 7445824 3. call_user_func_array() /mysite/engine/lib/elgglib.php:989 0.2097 7446480 4. galliCache_route_hook() /mysite/engine/lib/elgglib.php:989 0.2107 7451032 5. galliCache_read_cache() /vmysite/mod/galliCache/start.php:130

    the fatal error relates to apache and i am using nginx.. so that may be why

  • @Ura : thanks for the report. Please add the following to the start.php of the plugin

    /* Helpers */
    // See
    if( !function_exists('apache_request_headers') ) {
    function apache_request_headers() {
    $arh = array();
    $rx_http = '/\AHTTP_/';
    foreach($_SERVER as $key => $val) {
    if( preg_match($rx_http, $key) ) {
    $arh_key = preg_replace($rx_http, '', $key);
    $rx_matches = array();
    // do some nasty string manipulations to restore the original letter case
    // this should work in most cases
    $rx_matches = explode('_', $arh_key);
    if( count($rx_matches) > 0 and strlen($arh_key) > 2 ) {
    foreach($rx_matches as $ak_key => $ak_val){
    $rx_matches[$ak_key] = ucfirst($ak_val);
    $arh_key = implode('-', $rx_matches);
    $arh[$arh_key] = $val;
    return( $arh );


    Regarding the lazyload : Sorry, conflict with a non-core plugin is difficult to address. 

  • thanks, there are no issue now. :)
    the pages are loading at around 1 second when logged out.. never seen them load that fast.

    lazy_load on top might be amazing too..
    i'll continue to test.

  • ah, got a glitch here..

    the following page is being rendered twice, the same data is repeated.. in firefox (linux):

  • this is occurring for all 'pages' created by the pages mod.

  • Page speed is awesome !!  But I cannot login anymore :-(  It says "You cannot login from a different domain"

    Which context should be excluded for that ?

  • i have just seen the same issue.. i set the plugin to exclude 'pages' to workaround the previous 'double page' issue.. and then when i logged out i couldn't log back in again..
    i deleted the plugin from the server as a way to login.

  • @ura : on a clean 1.8.16 install, this duplication error is not happening. Make sure that the page handlers for "reference" and "pages" plugin are returning true at the end.

    @gerard and @ura : Try this fix.

    The error may be because the login form is cached with (without) "www" when your actual domain maynot (may) have it.

  • I already have that fix. Also rewrite for https.

    RewriteEngine on
    RewriteCond %{HTTP_HOST} !^$
    RewriteCond %{HTTP_HOST} !^www\. [NC]
    RewriteCond %{HTTPS}s ^on(s)|
    RewriteRule ^ http%1://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

    Another issue I face is caching of language files. Pages appear in different languages depending on which version has been cached. Is there a way to exclude language caching ?

    I have the same thing as Ura with pages that render twice. I thing we have the same plugin that does not play by the rules. I'll look into that.

  • the 'reference' handler is pointing to the pages plugin - i am using pagehandler_hijack to change 'pages' to 'reference'.. are you using pagehandler_hijack or changing the pagehandler in another way there @gerard?

    i am not seeing any token mismatch error messages when the login fails - instead the page just reloads back to the login screen with no error message.

  • I do use pagehandler_hijack but not for rewriting pages. Token mismatch are gone if you move up the plugin, just below the core plugins. But I still have problems logging in some times (like you) I now have a page reload with no error.

    I have excluded the contexts: index, login, register and pages but there are still problems with languages and logging in. Language is determined based on user browser settings and that means that a cached page keeps the language format of the first visitor that opens that particular page. This could be fixed similar to the javascript handling the security tokens

    I hope Team WebGalli will fix it, because I love the speed it gives but cannot use it in its current form.

  • i thought that using varnish cache would provide a similar type of benefit.. i haven't learned enough about it to say more than that presently.
    an elgg tailored solution would be great if it equals or surpasses what varnish and other cache solutions do.

  • The trouble with logging in seems to be that the security token value and name are cached in the login form of a static cached page from the previous user.


  • So it can be due to a conflict with pagehandler_hijack. 

    i am not seeing any token mismatch error messages when the login fails - instead the page just reloads back to the login screen with no error message.

    Since the pages are cached and reloaded, new system messages wont show up. This limitation, can be overcome by using ajax submissions of the forms through elgg.action(). 

    The trouble with logging in seems to be that the security token value and name are cached in the login form of a static cached page from the previous user.

    The plugin will auto update all the security token values. This will fail, if you have any js errors. Look in your js console.

    None of this errors are happening in our installation, for the client who sponsored this plugin.So, we wont be able to release another revised version soon. But your own PR are welcomed.

  • So I was only invited by you as beta tester for your client ? If I knew that I would not have spent so much time on a plugin that never worked for me and still does not !

  • @Gerard : never feel offensed. The last two revisions(V 1.2 and 1.3) where exclusively for both of you people and for @Romans (To fix the widget issues. In our sites, we were not even using any widgets and the V1.1 was stable). 

  • Not offended. I feel misused ! But never mind, I'll fix it myself so you can work on a paid job.

  • i found the source of the login issue for me.. i looked in the javascript error log and saw that a syntax error was being thrown out due to the structure of the html and javascript comments that were being introduced at the top of one of the cache files when the elgg core developer tools plugin is activated and so too is the 'wrap views' option. the error relates to the position of the /* comment. i thought this could be resolved by adding an extra line at the start of the initiate_elgg view.. but that didn't fix it. if i disable 'wrap views' the errors stop and i can log-in ok.

    <!-- developers:begin galliCache/initiate_elgg -->/** * Don't want to cache these -- they could change for every request */


    i am also now noticing another javascript glitch with the WOAH-bar plugin that i am using (site notification messages).. i will locate the source of that issue now. and look into the double page issue too.

  • @ura : was just going to post the conflict with the developer tools plugin, when you posted this. This error is because of the extra html the developer plugin adds when you enable the wrap view option.

    Similar may be your conflict with the other plugin, please look in the js console.

  • there are no other js errors listed when these 2 remaining issues are encountered.

    i entered 'pages' as a context in the cache admin panel to exclude the reference 'pages' from the caching, though that did not stop the page duplication glitch from occurring.

    i have seen this type of error before (pages being rendered twice), as i recall it was caused by an html syntax error that wasn't being identified.. possibly a " symbol that was missing.

  • so gerard just let me know that the plugin: pages_tools contains the cause of the page duplication issue.

    so i disabled that and now there are no obvious errors. :)
    i am wondering, if i want to exclude a specific widget on the homepage from being cached, am i able to apply a custom context to that widget and exclude that context/widget from the cache via the admin panel?

    this way the homepage would mostly be cached, except for the 'recent activity' widget.


  • i notice that the cache is not reset when the main elgg cache's are flushed.. adding that feature might be a useful enhancement so that changes made by admins/coders can be immediately propogated to the whole site when necessary.

  • i notice that my own status messages (as admin) are rendered on other pcs for other visitors!
    so when i log out, that logged-out message is also seen by other visitors to the site who never logged in.. ;(

  • @ura : the caches are cleared when you flush the elgg cache.

  • oh ok, perhaps there is a delay between flushing and the changes being rendered since i did not see the effects of the flush immediately, but did 2-3 minutes later.

Team Webgalli

Leading Elgg developers India. We provide Elgg development, consultation and optimizations. To know more about our Elgg services and for cool elgg stuffs visit us


  • Category: Site admin
  • License: GNU General Public License (GPL) version 2
  • Updated: 2014-11-17
  • Downloads: 2680
  • Recommendations: 13

Other Projects

View Team Webgalli's plugins