Print

Print


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?
>