Search

CacheLite updated to version 1.0.9 on 21st of September 2010

  • Added 304 header support

Hi, I am using Content Type Mappings extension to serve an XSLT-generated CSS snippet and some JS as well. I just installed CacheLite, and CSS/JS pages are being served as text/html type, which breaks CSS in Firefox. Aside from excluding those pages from the caching, is this something you’ve thought about addressing?

I guess it’s a use case that hasn’t been considered. CacheLite seems to make the assumption that all pages will be served as HTML. Depending on the order of the extensions working (CacheLite vs. Content Type Mappings) could CacheLite look to see whether an alternative header has already been set by Content Type Mappings, and only set its own text/html when no other header is present?

@tmslnz: CacheLite actually used to deal with this problem elegantly. I used to reconstruct the headers on the page object before output, but I ended up changing the extension to use the FrontendPageResolved delegate because it executes before the FrontendPreRenderHeaders and thus doesn’t build the page at all. The downside is that we no longer have access to the headers so I can’t reconstruct them.

I’d happily hook the Content Type mappings ext. into CacheLite if there were an easy way… not sure there is though. Otherwise I can certainly add more defaults for content types, I’d just replicated the Symphony defaults for consistency. Thoughts?

CacheLite updated to version 1.0.10 on 23rd of September 2010

  • Added support additional content types via the Content Type Mappings extension

I’ve managed to add in support for custom content types. Usage is via the Content Type Mappings extension, just install both extensions and CacheLite will interpret the page types (included 404 and 403 errors now) and serve the correct headers based on your configuration.

Hi Guys, I am running into (the same?) issues as bd_creations and icek.

First a little context: my config.php file has:

###### TRANSIP: DEBUG: show errors ######
ini_set('display_errors', "on");

###### TRANSIP: REMOVE SESSID FROM URL ######
ini_set('session.use_trans_sid', 0);
ini_set('session.use_only_cookies', 1);

.. Because I wanted to remove the seesion ID from the url…

After enabling the Cachelite extension I suddenly got this error:

ini_set() [function.ini-set]: A session is active. You cannot change the session module's ini settings at this time
An error occurred in /sites/arvoo.com/www/manifest/config.php around line 7

.. This happens only(?!) when trying to access the Symphony Preferences page.

The problem seems to be with my ini_set() statements, but when I disable those another error occurs:

"Cannot request a page callback without first specifying the page."

This seems to be the exact error described at http://getsymphony.com/discuss/thread/748/5/#position-91

I am using Sub Section Manager but do not think this bug still applies since I have the latest version with the patch applied.

I hope these issues can be resolved but according to icek not much seems to have happened :-(

For now, the only solution seems to be to disable the Cachelite extension.

Any ideas?

PS: I also noticed a strange (persistent?) sym-|a:0:{} session_data entry in my Symphony Sessions table.

I’ve found that my problem is with extension Quick Preview created by… me. Shame on me. I’ll repair my extension in the next few days.

Hahaha… love those moments.

icek I also use your extension. Could you explain how you found out it was the cause and what actually causes the error?

I have also found the same problem with other extensions (ones I’ve written on a per-project basis. The problem has been having a reference to getPageCallback() within a delegate callback, and presumably that callback being executed on a page where there is a problem calling getPageCallback().

For example, if I subscribe to a delegate:

public function getSubscribedDelegates(){
    return array(
        array(
            'page' => '/administration/',
            'delegate' => 'AdminPagePreGenerate',
            'callback' => '__appendAssets'
        ),
    );
}

and in my __appendAssets callback function I choose to call the aforementioned function:

$callback = Administration::instance()->getPageCallback();

This is fine on “publish” pages (i.e. /symphony/publish/*) but seems to error on /symphony/system/preferences/. I have no idea why. My solution was to wrap a condition around so that this code only executes when I want it to, e.g.

$page = $context['oPage'];
if ($page instanceOf contentPublish){
    $callback = Administration::instance()->getPageCallback();
    ...
}

This seemed to prevent the error.

I suppose someone more inclined should dive into the core and work out why it occurs, rather than just patching up when it occurs.

Thanks Nick, I’m afraid I’m not really that person, but your notes should be a great starting-point for someone more versed in Symphony/PHP.

If I understand you correctly, chance is that this issue will popup with quite a few extensions. Strangely it only occured when I activated CacheLite, so the real issue for me seems to be with this particular extension.

Hopefully Makenosound (or someone else) is able/willing to patch CacheLite quickly, I’d love to use it.

Symphony has become very fast, so if you don’t have to handle monster traffic you shouldn’t need that sort of caching.

I’m still getting the “Cannot request a page callback without first specifying the page”-error. Is there any news on how to fix this? I’ve got the latest version of subsectionmanager but I don’t know what other extensions might be causing this error. :-S

Is there any news on how to fix this?

See my comment above, have you tried this?

@kanduvisla: I can’t replicate this issue with the current version of CacheLite. Can you tell me which extensions you’re using and what versions they’re at?

It’s an odd error to pin down, there’s no call to getPageCallback() in CacheLite, and the delegates that are called on the preferences page only deal with, unsurprisingly, building and saving the CacheLite preferences.

I think perhaps it’s some freaky combination of CacheLite and Subsection Manager. Perhaps CacheLite subscribing to the append_preferences delegate (or any extension for that matter) does something.

If you see the error, search through all your extensions and see if my fix above works. I can’t recall which extensions I added it to. I think it was Mediathek and Subsection Manager, and the problem ceased.

I think perhaps it’s some freaky combination of CacheLite and Subsection Manager.

It was, yeah, and then Nils made a little change to Subsection Manager that fixed the conflict. I’m running the latest CacheLite and SSM on a site without conflict, so perhaps it’s another extension?

Hi all,

I have copied the extension CacheLite to the extensions folder. When I enable the extension I get this error. (see below) Could it be that FILEIGNORENEWLINES | FILESKIPEMPTYLINES) is not supported in php 4?

Symphony Warning Show Markdown for copy/paste file(/var/www/html/web-custom/manifest/cachelite-excluded-pages) [function.file]: failed to open stream: No such file or directory An error occurred in /var/www/html/web-fx/extensions/cachelite/extension.driver.php around line 451 • 446: foreach($segments as $key => $segment) { • 447: if(inarray($segment, $domain) || empty($segment)) unset($segments[$key]); • 448: } • 449: $path = "/" . implode("/", $segments); • 450:
• 451: $rules = file(MANIFEST . '/cachelite-excluded-pages', FILE
IGNORENEWLINES | FILESKIPEMPTYLINES); • 452: $rules = arraymap('trim', $rules); • 453: if(count($rules) > 0) { • 454: foreach($rules as $r) { • 455: $r = str_replace('http://', NULL, $r);

Thanks as always

Chris

Looks like the file that stores the list of excluded pages hasn’t been created. Try creating it manually, it’s just an empty file that should be at /manifest/cachelite-excluded-pages.

Could it be that FILEIGNORENEWLINES | FILESKIPEMPTYLINES) is not supported in php 4?

It could be, but then Symphony currently requires PHP 5.2 so you may run into more problems than just this if you’re running it on PHP 4.

Thanks alot! Yeah ur right. It seems the file had to be created.

Thank you very much

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details