Textpattern Support Forum

And this only happens with Firefox 1.5 and not with Firefox 1.0.7? Very strange.

I guess I’ll have to start playing with 1.5 then. It might take me a few days…

I think I have found something else:

the bug is triggered (= you get a blank page) in this situation:

• if you save a form without making any change.
• if you modify a form but that modification doesn’t have any “impact” over the content of the refreshed page. Deep explanation: I have a form with some conditionals thay may have “impact” on the content layout of a page. If I make a change (add a simple comma) outside the conditional that is related to the output for the content layout of the refreshed page, then the blank page is triggered.

The but is not triggered (you can succesfully refresh the content with just an F5 hit):

• if you modify a form and the modification has impact over the content of the refreshed page. This is the “countercase” (dont know if that word exists) of the above point.
  Deep explanation: I have a form with some conditionals thay may have “impact” on the content layout of a page. If I make a change (add a simple comma) inside the conditional that is related to the output for the content layout of the refreshed page, then the blank page is triggered.
• if, for example, I add an excerpt to an article.

I will try to do some more testing.

> Sencer wrote:
> is it possible that you are running PHP as (F)CGI?

Yes. My hosting provider has changed to PHP as CGI in the last week.

> Sencer wrote:
> For a temporary fix: In jpcache-main.php find: header("HTTP/1.0 304"); and replace with header("Status: 304 Not Modified"); if this does help, I should have an updated version ready soon.

You are a magician!
I made the change you suggested and, at least by now, this is working good in FF 1.5.

Thanks, Sencer!

Just a note: people not running on (F)CGI will worsen the situation by changing the code as described above.

Your error is not related to my plugin, soulship. There is exactly one occurence of $_SERVER['HTTP_REFERER'] in my code, and that is preceded by a check with isset(), precisely so it won’t throw errors like that.

ETag: "jpd-1730008019.6157" is used by the plugin to do caching stuff, like 304s. The jp is short for jpcache, which this plugin is based on.

Wow, I’ve been beaten by a long shot. I was just checking to see if anyone else was working on adding jpcache or a similar caching system to Textpattern – as I ended up modling jpcache for myself, I figured it’d be semi-trivial to add to Textpattern as well.. I forgot how static my system was.

I’ve taken a look at this and updated the admin side plugin, but I still can’t seem to get it to work, at all. Even with a few modifications to 0.9.8, I get the ‘X-Cache: asy_jpcache -’ header, and then it dies, not reporting a version number, or anything, observe:

HEAD / HTTP/1.1
Host: mysite.dur

HTTP/1.1 200 OK
Date: Tue, 07 Feb 2006 04:42:03 GMT
Server: Apache
X-Cache: asy_jpcache – Content-Type: text/html; charset=utf-8

Sencer: I added this to the very head of your cache plugin to ensure that it had both the globals, and the cache (from within index.php):

// Trivial modification by ssh to keep from hacking the root index.php if ( txpinterface == ‘public’ && !in_array ($_SERVER[“REQUEST_URI”], array(’/&’)) ) { include_once( $_SERVER["DOCUMENT_ROOT"]."/textpattern/config.php" ); include_once( $_SERVER[“DOCUMENT_ROOT”].”/jpcache/jpcache.php” ); }

// I stole plenty of code from zem. Don’t tell him! ;)
…

I’ll take another look into it, but I’m guessing that it’s still having problems loading it’s locals. Since I’m forcing it to have the globals available, I assume $path_to_site and other variables are exposed? (Yeah, it’ll take two seconds to find out, I know, I know..)