This may be debatable, but I feel nodes and blocks that embed views should not be cached. This code should prevent the caching when insert view is added to an input format.

Comments

jpetso’s picture

Status: Needs review » Reviewed & tested by the community
StatusFileSize
new306 bytes

+1 on the wish, I consider this important as well. The patch works fine, but has been rolled against the profiles/custom/modules/insert_view/ directory and thus doesn't apply cleanly with "patch -p0 < insert_view_no_cache.diff".

The attached patch fixes this, and also indents the "return TRUE;" similar to the other "return" statements, although 3 spaces is one too much when looking at the official Drupal coding style. (Consistency is better than strict adherance to the guidelines, though.)

Considering that I didn't alter the patch except for non-functional formalities, I take the freedom to change the issue status to "reviewed & tested by the community".

mlsamuelson’s picture

Status: Reviewed & tested by the community » Fixed

After considering the cache issue, I've decided to apply the patch. It just makes sense. The gain in up-to-date views more than makes up for the performance loss.

Thanks for the patches, and for the review.

I've applied the fix both to the 5 development branch and also to HEAD.

(Additionally, under a separate commit, I fixed the non-standard indentation problem. Thanks for catching that.)

mlsamuelson

john bickar’s picture

Status: Fixed » Postponed (maintainer needs more info)

Hmm, I'm using the dev release from 03.11.2008 and I have noticed just recently (i.e., within the last week or so) that my inserted views are now being cached.

However, I can verify that my insert_view.module contains the code:

>
  // All operations besides "list" provide a $delta argument so we know which
  // filter they refer to. We'll switch on that argument now so that we can
  // discuss each filter in turn.
  switch ($op) {
    case 'description':
      return t('Inserts content lists into nodes using [view:myview] tags.');
    case 'prepare':
      return $text;
    case 'process':
      return _insert_view_substitute_tags($text);
    case 'no cache':
      return TRUE;
  }
}

I'm not sure if this is related to this issue or not? The View from which the insert view is pulling updates instantly; the node containing the [view:viewname] tag is not updating until I clear the cache.

mlsamuelson’s picture

I'm pretty sure what you're experiencing is that the filter cache hasn't updated to reflect the changes in the module. So try this, visit /admin/settings/filters and for the input formats being used, submit the forms again. I believe that ought to jog the filter cache's memory.

I'd tried to hint at this in the second paragraph below, but looking back, it seems I didn't word it clearly. Let me know if what I've suggested works and I'll tweak the upgrade wording in README.txt:

UPGRADING FROM A PREVIOUS VERSION?
----------------------------------
In previous versions of Insert View (including the 2008-Jan-11 development snapshot
and earlier) it was was not required to enable the Insert View filter for input formats
(by visiting the /admin/settings/filters pages) because Insert View was a pseudo filter
and used hook_nodeapi() rather than the filter system.

Insert View now runs as a classic Drupal filter module, and that means it now works
in blocks.  If you upgrade your site and find Insert View tags aren't working, please
visit /admin/settings/filters and enable the Insert View Filter for each input format
necessary.
john bickar’s picture

Status: Postponed (maintainer needs more info) » Fixed

You mean I'm supposed to read the thing that says "READ ME" in capital letters?

Yes, resubmitting the input format forms did the trick. You may want to add a line about resubmitting the form if necessary. That won't solve the problem of some people (not mentioning any names) never reading the thing, but it can't hurt.

Thanks!

mlsamuelson’s picture

Assigned: Unassigned » mlsamuelson
Category: bug » task
Status: Fixed » Active

Update README.txt in light of comment #s 3-5...

Marking as active, task, and assigning to me. I'd like to make the README.txt as straightforward as possible.

(Kicking myself for not doing this before the 5.x-1.0 release.)

(See also #148400: How to use Views Pager with Insert View, for README.txt updates.)

mlsamuelson

ashtonium’s picture

Just to make a note about clarity. I already had the view filter enabled so I didn't think I needed to do anything. (And the view_filter tags were still technically working, they just weren't being themed properly after being cached.) I re-submitted the /admin/settings/filters/# page where I had previously enabled the "insert view filter" and it's working properly now.

Might just want to mention in the upgrade instructions that everyone should go and re-submit their filter settings pages and enable the view filter for the relevant input filters. (unless there's some way to re-set the filter cache in an insert_view_update_#() call?)

As a side note, you may want to make a note about how the filter effects node caching. I don't remember seeing that anywhere and I think some people will want to know that.

mlsamuelson’s picture

Status: Active » Fixed

@ashtonium - All excellent ideas!

I'd intended to include better instructions on upgrading to this release, but somehow that slipped my mind. Your idea about clearing the cache is a better idea, anyway. As a result, I've committed changes to both HEAD and the 5.x-1.x-dev branches to:

1. clear the cache on update so folks shouldn't have to re-submit their filter settings.
2. provide a note in the README.txt to note how the filter effects node caching and potentially performance.

Thanks!

mlsamuelson

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.