After time "x" a call lands on an unknown site template

[EmEiBee]

Hello everyone,

First of all, thank you very much for the nice, easy to install and easy to use blog system. It's exactly what I was looking for!

I have, however, come across a problem that I cannot solve:
If I haven't been on the blog for a few hours (nobody else is using it anyway), the page appears in an unfamiliar look.

At the beginning, of course, I tried out a few different styles, but there were problems and despite deleting all caches (server and client), sometimes this style and sometimes that style was displayed when I called it up.

In the end, I decided on the "Timeline" frontend.

Although this is now the only themefront end, something always appears on the visitor page and in the admin area, but not "TimeLine". Then only a repeated refresh with the SHIFT key pressed helps (complete reload). Even a new installation (--forced) didn't change anything.
The same effect in FireFox, EDGE and Opera.

I don't know if this is a BUG or if I'm just too stupid.

Would anyone like to help me fix this?

Greetz
Micha

EDIT say:
There I can find many entries of frontends that I tried out in the past like t_clean-blog, t_next, t_bartleby, t_chocolate_fudge. Can that be right?
The frontend should be "TimeLine", the backend "2k11" (is there anything else?)

[fe-hicking]

The CSS files get cached by the browser, so in some scenarios you would really need to force-refresh the old CSS out of the browser.
If you use the templatechooser plugin in scenarios where you offen change styles, that should actually prevent such caching....?

[EmEiBee]

That's not true. As I said, I deleted all available caches, both on the server side and on the client side.
This also happens in all browsers and also with friends who have accessed the site for the very first time.
So, in my humble opinion, this can have nothing to do with a cache.

The "templatechooser" plugin I don't use due I like to have only one.

[garvinhicking]

Ah alright, I misread your statement then, I'm sorry.

There are two places where Serendipity puts things:

• templates_c (compiled templates)
• SimpleCache (which I think puts its files also into templates_c though)

I must admit I haven't looked at this into ages, but maybe it helps as a pointer :D

[EmEiBee]

Ty a lot. I will look at; just killing the entrys by hand?

[garvinhicking]

Every file in templates_c is a cache file that can be regenerated. Should be safe to delete all files (also in subdirs) of that directory. Make a backup for safety though. ;-)

[EmEiBee]

... but I'll make a backup first ;)
In templates_c there are also XML files as well as two folders with the name of the frontend and the backend... Can I delete everything?!
I will try AFTER an backup ;)

[EmEiBee]

Looks good so far. I'll keep an eye on it for a few days. If it works then, that's the solution.

First of all, thank you very much for your support; you've helped me a lot!

[EmEiBee]

NOPE :(
Same as before. Frontend is ok so far right now, but backend is broken as before. That don't help. The problem must lie somewhere else...

[fe-hicking]

For the backend, a used template might be stored in a PHP session variable IIRC. Did you try to delete cookies so that PHPSESSID gets reset and you might start fresh?

Can't research atm as I'm only on mobile. Unsure if serendipity_options DB table held some backend related caching. Maybe @onli remembers more of this? 😅

[onli]

Hi! Great that you could already solve the frontend template issue, though it'd be interesting to know what went wrong there that deleting templates_c helped. That bug of changing templates is new to me.

The frontend and the backend template are set separately, I'd wager this is misleading. If the backend design breaks (like in the screenshot) have a look at what is written in the CSS used, serendipity_admin.css. There likely is a PHP error that prevents its output. If the CSS is just an empty file, you would have to look in the PHP error log of your server/hoster for the error message.

[EmEiBee]

Did you try to delete cookies so that PHPSESSID gets reset and you might start

Yep, more than I can count. After every change, I have deleted all available caches and cookies.

if serendipity_options DB table held some backend related caching

You can ask questions ;) I have no idea and can at best read and use a little SQL and PHP... ;)

look at what is written in the CSS used, serendipity_admin.css.

Where can I find the file respectively, where should it be? Also in the "templates_c" folder?
I've searched everything from root downward; this file doesn't exist.

[onli]

look at what is written in the CSS used, serendipity_admin.css.

Where can I find the file respectively, where should it be? Also in the "templates_c" folder?
I've searched everything from root downward; this file doesn't exist.

Logical thought given the problem solving route so far :) But no, look at it just in the browser, yoururl/serendipity_admin.css (the file is dynamically generated by serendipity). It's linked in the head of each backend page, best to have a look at the html code to get the link.

[EmEiBee]

LOL You have to say things like that to a dummy like me ;)
Ok, I have to wait a while now. I did a refresh in the meantime and the admin page is there, as is a filled CSS.

[EmEiBee]

So... Waiting time is over. I call the admin center and got the same broken view. But the css is filled with data.
Should I zip it and post it here?

[onli]

You can create a gist, https://gist.github.com/ - but have a look that there is no data you don't want to share in there.

But if the CSS data is there, the likely scenario is that the error is intermittent. The design returns after a reload? Then it might have been only missing on the first load. Share the file if possible please, but I'd also suggest you have a look in the PHP error log file to see whether something lines up with time of the page load.

[EmEiBee]

... I have no idea about gist. I was there and drag&drop the css-output... And now? This?
https://gist.github.com/EmEiBee/6c3b5ad3ef3346a692391cc96b24328a

The design returns after a reload?

Yes, that's right. If I then generate a forced reload, the view remains OK until I leave the page for about an hour and then come back. Then it is broken again. Crazy, isn't it?!

I can't touch the error-log at my provider. I have open a ticket to ask for read permission. Can take a while...

[onli]

And now? This?

Exactly!

CSS is there and looks fine to me. I bet it did not load before though. That could be a error in a plugin, or something on the server - let's hope there is something in the log.

[EmEiBee]

... no idea ...
Let us wait til I can read the php-log. It's weekend, so it can be Monday before I get access...

[garvinhicking]

@onli In our serendipity.css.php we do have this ETag and HTTP caching logic, so in case the ETag that is sent from the browser to the server matches the hash of the generated CSS, we emit a HTTP 304 header and the cache of the browser should be used.

Not sure if meanwhile something in ETag handling and browsers changed, or if a proxy (reverse proxy?) is involved.

@EmEiBee Maybe you could edit serendipity.css.php and change this all of this:

//
// Fetch output buffer containing the CSS output and create eTag header
//
$ob_buffer = ob_get_contents();

if ($ob_buffer) {

    // Calculate hash for eTag and get request header. The hash value
    // changes with every modification to any part of the CSS styles.
    // This includes the installation of a plugin that adds plugin
    // specific styles.

    // Send ETag header using the hash value of the CSS code
    $hashValue = md5($ob_buffer);
    @header('ETag: "' . $hashValue . '"');

    // Compare value of If-None-Match header (if available) to hash value
    if (!empty($_SERVER['HTTP_IF_NONE_MATCH'])) {
        // Get request header value and chop off optional quotes
        $reqHeader = trim($_SERVER['HTTP_IF_NONE_MATCH'], '"');

        if ($hashValue === $reqHeader) {
            // Tell client to use the cached version and destroy output buffer
            @header('HTTP/1.1 304 Not Modified', true, 304);
            ob_clean();
        }
    }
}

ob_end_flush();

just to:

ob_end_flush();

and see if the behaviour goes away.

Note that this:

header('Expires: ' . gmdate('D, d M Y H:i:s \G\M\T', time()+3600));

allows the browser to cache the response for exactly one hour. After that a CSS file is allowed to be rechecked, but it seems this ETag handling interfers. However, I find it odd that this is only reported now - I do believe some kind of reverse proxy or local proxy might be mangling the response here.

[EmEiBee]

Ty for the hint. I have comment it out and the 1st try right now give me the perfect GUI. It's more than an hour since I call it last. That let me hope.
It's late here and my bed calling my name. But the 1st thing I will try is to call it again and see what's going on.

So for now many thx for your help. I come back tomorrow and will report

[fe-hicking]

Cool thanks. Would be interesting if you use either a client-side proxy, or if your webserver is behind a reverse proxy / CDN setup.2

[EmEiBee]

Good morning all (muahhh)....
Problem is gone! 1st call of the admin-site comes up with a very well site. Perfect!

About your question:
On my side I don't use a proxy in any way for http(s), scp, (s)ftp, ... The only proxy here is an IceCast on my NAS.
If my webprovider use a proxy I don't know. Can be due it's a shared host. I have ask him right now.

Meanwhile, I have access to the php-log. There are no errors touching the serendipity-installation.

Good Morning again... I hate Mondays...
Info from my provider: They don't use any proxy also. All http(s) calls goes directly to the VServer