Search Google Appliance


Why do edits on my Drupal site not show after logout?

Our Drupal CMS is utilizes a caching mechanism to reduce the load on the web servers, and offer faster page loads to the general public on a daily basis. What this means for you is that just after making an edit or uploading upated versions of media and documents to your library, non-logged in users of the site may not see those updates immediately. 

When you are logged into your site, the caching mechanism knows if you are logged in or not. If you are logged in, the request by-passes the caching mechanism and gets "sent" into Drupal to build the page (or serve media) for you from scratch, yielding the most current version of the page. 

If you are not logged in, then in some cases you will get a "saved" version of the page (or media), which was built and saved when an anonymous user previously visited the page. The process of "saving" a page specified by a given URL is known as caching. Once cached, it is much faster to serve the cached version of the page than it is to rebuild the page from scratch via Drupal, and thus the performance improvement.

The length of time it takes for a cached page to expire, thus revealing edits to anonymous users of your site depends upon the URL in question. The URLs of concern here fall into two categories: (1) Drupal pages, and (2) media URLs.

Drupal Pages

Any page within Drupal has a URL of this format:

Pages will be cached for one hour. But, if you go to edit a page, and save it, the cached version will be cleared. So, your edited page will become available immediately. For example, if the undergraduate admissions page ...

... were edited, public (non-logged-in users) would see the update to the page content immediately. This is for the entire page so if your page edit included a change to the main menu block, that change on that page would be immediate to anonymous users.

The catch here is that if the edit you made caused a change in the navigation menu, that change will only be apparent immediately on the edited page (not on other pages showing the same menu). In other words, there are other pages in the site showing the same menu without the changes since they were cached before the edit. What non-logged in users might see in this case is a slightly-outdated menu on a number of pages until they expire.

Keep this in mind when rolling out time-critical content changes. The thing to be aware of is that it could take several hours for the system to sync up to the most current version of all content site-wide. 

Media & Documents

Links to media or documents follows the same idea. URLs of this format ...

... will take up to two weeks to update (except for PDFs, see below). For example, if you simply upload a new version of a Word document to your media library, it will take two weeks for the cache to update and serve the new version when non-logged in users click on the link leading to the media. 

One way to mitigate this delay is to upload the file with a slightly-modified filename, and delete the old file. Doing so produces a different URL, and the caching mechanism will go into the library and serve up (and cache) the most recent version. One tactic that works well for dated materials is to include some form of the date in the filename.

In a nutshell, you are going to have to wait a significantly longer for document updates to be visible to the public when you simply replace media with the same filename. Of course, we can manually clear the cached version of media in the library if you drop a line to, but please reserve those use cases for mission-critical updates. Clearing cached media over and over dilutes the performance gains we get by utilizing caching.

What About PDFs?

PDFs are a special case in the caching scheme. If you upload a new version of a PDF as the same filename, the cached version expires in one minute. Meaning you only wait one minute for public users to see the updated file.

On a related note, consider the question of whether or not you want to maintain content in documents or directly in Drupal pages:

A Note on Best Practice

If you are hosting content in documents instead of in Drupal pages, and you are finding that you are updating quite often—and the cache delay is a problem—then perhaps hosting that content in the form of a document isn't the best option. Perhaps moving the content from a PDF to actual Drupal page content is a better idea.

Consider the example of office hours. If it were on a page or in a block, when you update your hours, you only wait up to an hour for public visibility. Plus, it is more readily accessible and more findable via search. Finally, the whole point of utilizing a CMS to manage your website is to regularly update content, so let the CMS help you and keep as much content as possible in Drupal pages or blocks; use documents only when necessary.

In the end it is up to you—the content manager—to decide what works best for your mission.