Effect of Clear Cache checkbox

When the Clear Cache checkbox is set, does MODx clear the entire cache on Save or just the cache for that page?

Is that for Revo or Evo?

Both Revo and Evo have that setting and I believe, in Evo anyway, that the entire cache is cleared - i.e. the equivalent of doing ’Clear Cache’ from the top menu.

Sorry, I was asking about Revo. Saving the page with it checked seems faster than a full cache clear. I thought it would faster to ask than to dig though the code.

Im still wondering about Revo.

In Revo, we can do it however we want to easily, so I think the better question right now is how should we do it in Revo, and can we provide a more granular cache clearing feature in the interface.  IMO, even without versioning, we need to start thinking more about the effects of publishing, and how to ( p )review changes before they are made to the public.  Saving without clearing specific portions of the cache can be critical to this depending on your approach to publishing new or changes to existing content.

I welcome your thoughts on this.

As for how it is currently, I’ll have to "use the source" to find out when I get a moment...

Tough questions.

I think Empty cache should probably clear the page cache and recurse its way though all the cached tags and clear those as well. That could get hairy and hard to test and maybe it would be as fast (and certainly safer) to just clear the whole cache. There are probably more important things to work on for quite a while.

The versioning discussion probably belongs in another thread, but in my dreams I see it as duplicating SVN, a repository somewhere, checkin and checkout to the Trees, revert, commit, and update for individual elements and for containers and their descendents, and icons in the Trees showing up-to-date, to be added, to be deleted, dirty, etc. Of course we’d have diffs, branching and tagging. Essentially, the current site would be a working copy. In theory, it could be integrated into the Manager in the same way that TSVN is integrated with Windows Explorer (and my code editor). It would be a major undertaking and the support load would be crushing so it’s probably just a bad idea.

Maybe a smaller step would be to just clear the cache and take a user-named snapshot of the whole site (automatically appending the date to the name a la Windows System Restore). It shouldn’t be too hard to do that and give the user a screen that would show the backups and offer to restore to any of them. We could save the whole site in each backup at first, then later graduate to just storing diffs and/or showing diffs between versions.

None of that speaks to your question about (p)reviewing changes before publishing. The only way I can think of to address that is to add "Save Draft" and "Update" to every Save screen. I think it would mean new tables (site_content_draft, site_template_draft, site_snippet_draft, etc.). "Publish" would only show for unpublished Resource drafts (maybe just for Documents). After publication, "Publish" would change to "Update." Some users could have the right to "Save Draft" but not to "Update" or "Publish." The easy way would be for the draft tables to just duplicate the current tables, but then you have no option to revert unless the new tables have an extra content field for the previous version.

If we wanted to integrate true versioning into that, we’d have to store a series of diffs in tables, but I think that means a separate table for each individual snippet, chunk, resource, etc. I don’t see a good migration path from the previous scenario to this one, but that doesn’t mean there isn’t one.

I hope at least some of this makes sense.

I already have MODx content versioning modeled and the prototype working (though there will definitely not be advanced features like branching at first), and that’s not what I was getting at.

I was getting at the fact that I can save a change to a Resource now without affecting the live site (if it’s properly cached); and it would be good to allow users the option to either save and clear all caches, or save and not clear any of the cache; maybe even save and just clear that pages cache (i.e. so it doesn’t show up in the dynamic menus on other pages). This would arguably be a power user feature, but I think it’s an important one in the intermediate stages before we introduce content versioning.

Ultimately, what I’m envisioning is a configurable cache clearing mechanism/UI that would allow customization of this behavior per user or based on parent resources or whatever criteria you could use in the process. Maybe an advanced button next to the clear cache checkbox that exposed all the possible options which most users won’t care about on demand?

Quote from: OpenGeek at Mar 05, 2009, 04:25 PM

I already have MODx content versioning modeled and the prototype working (though there will definitely not be advanced features like branching at first), and that’s not what I was getting at.

Most excellent!

I was getting at the fact that I can save a change to a Resource now without affecting the live site (if it’s properly cached); and it would be good to allow users the option to either save and clear all caches, or save and not clear any of the cache; maybe even save and just clear that pages cache (i.e. so it doesn’t show up in the dynamic menus on other pages). This would arguably be a power user feature, but I think it’s an important one in the intermediate stages before we introduce content versioning.

Ultimately, what I’m envisioning is a configurable cache clearing mechanism/UI that would allow customization of this behavior per user or based on parent resources or whatever criteria you could use in the process. Maybe an advanced button next to the clear cache checkbox that exposed all the possible options which most users won’t care about on demand?

My gut reaction is that it opens a can of worms. IMHO, using the cache as part of the versioning and/or (p)review process is asking for trouble in terms of support and robustness. What if some other user (or some snippet or plugin) clears the whole site cache on you? It seems more solid to me to clear the whole cache before every versioning event, and maybe after any (p)review approval.

Doesn’t giving granular cache control to individual users require that they remember the nested path to all tags related to the current resource or element? You might be the only person who could use it correctly.

Maybe I’m misunderstanding the whole concept (it wouldn’t be the first time ).