MikeD

I should probably have mentioned that the above changes are only needed if you want to format your “sticky” posts differently to regular posts (I made mine look like Post-it notes with a push-pin).

If you do want a distinct appearance, then you need to make some changes (to the Kubrick theme at least) like those above, or else you may get different formatting depending on whether you are viewing the main page, Search, Archives&Categories, etc.

Note that the Adhesive plugin assumes certain things about the assigment of document element id’s. These are defined in the Theme files, not in WordPress itself, and they may or may not match Adhesive’s assumptions for display of index, search, archive etc.

For example, for the Kubrick Theme, I did the following:
1. Change .parentNode.className to just .className in adhesive.php itself.

2. In the Theme files archive.php and search.php, move the id from the <h3> tag to the <div> tag, so it becomes:
<div class="post" id="post-<?php the_ID(); ?>">

(Arguably, it might be better to move the id from the <div> tag to the <h2> or <h3> in index.php, page.php and single.php. Then adhesive.php can remain unchanged.)

eyetag et-al.,

Another (better?) way to fix this and retain formatting, is to make Archives and Categories get formatted the same way as the index page. Normally, Archives and Categories have most of the formatting stripped out (which is just confusing in my opinion).

Go to archive.php (not archives.php) in your Theme, find where it says “the_excerpt” and change it to “the_content”. This makes any formatting / images you have in the posts appear the same as they do on the index page.

The knock-on effect of this is that Adhesive’s filter then works as expected, which eliminates the window.document… message.

I checked the headers produced by the server, using the Firefox Web Developer extension. Look OK to me.

Date: Thu, 23 Jun 2005 00:39:45 GMT
Server: Apache/2.0.40 (Red Hat Linux)
Accept-Ranges: bytes
X-Powered-By: PHP/4.2.2
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Last-Modified: Thu, 23 Jun 2005 00:39:45 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

Lorelle, if I disable *both* the memory cache and the disk cache, then the problem indeed goes away. As you say though, this makes the browser very slow, and I can’t see my colleagues going for that as a fix.

It does appear to be a browser issue (although WordPress does issue cache-control headers, and for all I know it isn’t sending one when it should ?? ), so I will try the Mozilla forums. I tried here first because it only affects WordPress and I thought someone might already know of a magic fix.

I even put a small test PHP script in the wordpress/wp-admin directory that simply increments a counter via a POST form. It works fine, even though it doesn’t produce any cache-control headers. I can see that by the end of this, I’m going to know a whole lot more about caching than I ever wanted to….

Thanks for the suggestion Croila, but I don’t think that’s it. (I don’t have a ‘.’ user).

Actually the easiest way to demonstrate the problem, is to choose any user in Authors & Users and try to promote them by clicking on the “?action=promote” link. The display refreshes but doesn’t change. After a few repeat attempts, press Ctrl-F5 and the display refreshes and shows the user level incremented by just +1.

Using the local server or using IE, the user level increments by +1 on each click on the “?action=promote” link.

Have also just tried setting the following in Firefox about:config :-

browser.cache.check_doc_frequency = 1
Then quitting and re-starting Firefox.

Still no improvement….<sigh>