 |
 |
If client-side caching is the problem, you can force a refresh of the cache by appending a querystring to the end of the resource you want to refresh. In your case, one solution would be to keep your hours in a separate HTML file and then pull them into your page via AJAX (I could help you with AJAX if you are unfamiliar). When you make the AJAX request for your hours HTML page, you'd do it like this: hours.html?2013-06-03. When you update the hours, you change the AJAX reference to this: hours.html?2013-06-04. Every time you change the querystring at the end, it will force browsers to refresh the cached version of the page. Josh Welker -----Original Message----- From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Wilhelmina Randtke Sent: Friday, May 31, 2013 7: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? >