The views cache invalidation form at admin/build/views/tools is not properly submitted after it has been invoked at least one time. Forms API does not execute the views_ui_admin_tools_submit() function on subsequent form submissions.

It looks like FAPI does not invoke the submit function because there are no input fields. Adding a dummy textfield

$form[] = array('#type' => 'textfield');

solved the problem. But that is obviously no choice for this form.

The attached patch turns views_ui_admin_tools() into a confirm_form(), which always invokes the submit function afterwards.

Without this patch I had to log out and back in each time I wanted to clear the views cache.

CommentFileSizeAuthor
#7 views_ui.module.cache__0.patch509 bytessun
views_ui.module.cache_.patch1.63 KBsun

Comments

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

hmmmm... I've just seen that the whole views_ui_admin_tools() function is gone in latest HEAD. How is the views cache cleared in HEAD?

Nevertheless, this patch saved hours for me... Each time I thought the cache was cleared, it wasn't (which can be determined by reading the message The Views cache has been cleared.).

merlinofchaos’s picture

merlinofchaos commented

I don't commit to HEAD and DRUPAL-5 simultaneously (that's too much work) so I sync DRUPAL-5 (which currently contains the latest code) to HEAD when I roll real releases (and that's still too much work =). I should probably stick a note in HEAD about this.

I'm a little weirded out by fapi refusing to submit the form multiple times, there's got to be some kind of a trick there. Maybe just adding a hidden will fix it, but if you're seeing "The Views cache has been cleared." then either the form is being submitted or for some reason you're seeing a cached page. That alone would be really really odd. This will take some experimentation, I guess.

yched’s picture

yched commented

would that be a case where $form['#skip_duplicate_check'] = TRUE might help ?

chx’s picture

chx commented

Another victim of the duplicate checker, use #skip_duplicate_check . I do not like that and it's removed in the FAPI3 patch.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

#1 was about the (outdated?) issue submit notice:

If you're CVS updating out of the DRUPAL-5 branch it sometimes lags behind HEAD which is where I work for DRUPAL-5 right now and then sync the branch over.

@merlin: I've already tested to insert a hidden field and a #value field, both approaches without success.

If #skip_duplicate_check is only temporarily needed, I'd stick to the simple confirm_form() solution provided in the patch.

yched’s picture

yched commented

If #skip_duplicate_check is only temporarily needed
Well, it won't be needed for D6, but is the recommended way for D5
(and actually confirm_forms do use #skip_duplicate_check = TRUE internally...)

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
StatusFileSize
new views_ui.module.cache__0.patch509 bytes

Thanks for this insight.

Well, seems like it doesn't make a difference which solution is used. Attached patch just inserts #skip_duplicate_check, which I've tested and works, too.

merlinofchaos’s picture

merlinofchaos commented

THe reason not to use a confirm form, IMO, is that this form was meant to be able to grow, which is why it's named tools.

Thanks for the help with the skip duplicate check stuff!

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Needs review » Reviewed & tested by the community

Any chance to get this 1-liner (#7) committed? :)

merlinofchaos’s picture

merlinofchaos commented
Status: Reviewed & tested by the community » Closed (won't fix)

The duplicate check has been removed from Drupal: See http://drupal.org/node/141636

There is no need for Views to use this. Either upgrade or downgrade (since the duplicate check was only ever in a -dev version anyhow).