Hmm.

I still suggest using javascript to generate the library hours HTML. You can squeeze in a <script> right in the Wordpress text-editor and you can have that point to and parse a JSON string or XML so that every time that script runs you have the most recent hours. For instance, you could drop Matthew Riedsma's "Today's Hours"* somewhere (right in the block, if you like ...) and AJAX-in the results. Even a heavy page cache shouldn't effect hours displayed in this way. 

* https://github.com/mreidsma/Today-s-Hours/blob/master/todayshours.js

Michael
www.ns4lib.com

-----Original Message-----
From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Wilhelmina Randtke
Sent: Friday, May 31, 2013 8:10 PM
To: [log in to unmask]
Subject: Re: [CODE4LIB] Wordpress: Any way to selectively control caching for content areas on a page?

All campus pages are cached.  This is a huge problem for displaying library hours, because these change periodically (breaks between semester, spring to summer, intersession, holidays).  If a person has been to a page, even a month ago, they may see the older information - like seeing spring hours on the page, even though summer hours are posted.  I want the tiny little content area I can edit to not be cached, even though the giant campus template it appears in is cached and has to be lest the server go down with only tiny amounts of traffic.

I am guessing caching is through the browser and not server side.  Suppose, I go into a page with two browsers (so, maybe Firefox and Internet Explorer both on my computer).  Then I edit the page.  Then I refresh one browser.
Then I close the browsers and go back to the page with both browsers.  This will show me the old page with the browser I didn't refresh, and the new page with the one I did.

By the way, you can see what plugins are installed on a Wordpress site.
You take the list of plugins ( maybe this one posted here http://plugins.svn.wordpress.org/ ), then you append the plugin name to urlyouarelookingat.com/wp-content/plugins/ , then you run the list of URLs through Xenu Link Sleuth to check if you get a 404 or a 503.  404 means it is not installed.  503 (access forbidden) means the plugin is installed, but does not tell you if it is activated or not.  I think with some scripting and looking at Wordpress, I could get a list of active plugins, but I just pulled a list of installed plugins because that was what was easy to do.  This will not find custom plugins because it's just looking for the named list, so if you have a developer who wrote their own, then you can't see that, but you also wouldn't be able to examine the plugin source code, so it doesn't really matter to know names of custom plugins.
In my case, I highly doubt any custom plugins were used.

Based on a quickly pulled list of plugins, I suspect the caching is done through w3-total-cache.

-Wilhelmina Randtke


On Fri, May 31, 2013 at 6:11 PM, Jonathan Rochkind <[log in to unmask]> wrote:

> > What is most useful for me is very general conceptual directions on 
> > how
> to
> force certain pages to refresh within a CMS, and a sanity check as to 
> whether it is possible to force a refresh for only certain content 
> areas on a page with several content areas.
>
> > My feeling is that it would be possible to force a refresh of 
> > certain
> pages, but that needs to be done from the html header.  My feeling is 
> that it's not possible to force a refresh for specific content areas 
> only, but if anyone knows conceptually how to do this, then I would 
> love to be pleasantly surprised.
>
> If you're talking about HTTP-level caching, yes. It's controlled by 
> headers on the HTTP response, and thus is page-by-page, meaning both a 
> whole page (URL) at a time, and that for pages to be cached 
> differently they need different HTTP headers delivered with them, by 
> the CMS or web app or web server.
>
> Some CMS's have their own internal caching, that is not HTTP-level 
> caching and is invisible to the client or user-agent, it's done just 
> inside the 'black box' of the CMS. So even in cases where the browser 
> will not cache the page, where the browser will make a request to the 
> server for the page
> -- the server may then serve the page from it's own internal cache, 
> for instance to save the time of going to the database and rendering the HTML,
> just serve already rendered HTML out of an inside-the-server cache.   This
> kind of cache can possibly operate on a portion of the page, it 
> depends on how the hypothetical CMS is written.
>
> So that's a conceptual overview.
>
> With WordPress specifically? People have suggested some WordPress 
> plugins that do caching in various different ways. But when you don't 
> have any control over the WordPress installation? I guess it depends 
> on if they have any such plugins installed, which only they know.
>
> What is your motivation here?  Just curiosity?  Or are you _wanting_ your
> pages to be cached, when they are not already? -- if so, why?   Or are
> things being cached that you do not want cached, and you need to fix 
> it? Or what?
>