views_invalidate_cache() at the end of your update. Everything will be reread properly on the next page update.

Wow! the lord and creator of views himself is here. My site won't live without views. :)

merlinofchaos: Right, but not in time for other update functions that try to mess around with the blocks table to set visibility and things like that. What's the canonical Drupal 5 way to set block visibility for views that provide blocks, in code? I think the developer tried inserting into the blocks table, but he reported problems with it.

Ugh, block visibility. Since the delta of the view won't change, being based on the view name, you could just write the block record directly instead of trying to modify it, I suppose. There's nothing dynamic going on in there that I can think of, so just writing it the way you know it should be should work for that update.

Also, possibly moving the module enables earlier? I realize that might not be feasible, sometimes order of things is important. It is *very* rare that the available default views is expected to change during a single pageload (first time in 3 years I've heard of anybody needing to, for example) so I guess I'm not surprised I never thought to put in a way to reset that static cache.

Here is how I update my blocks table in my hook_update_N, 4 days ago:

views_invalidate_cache(); // to be sure our last default views (defined in files) are loaded

// change theme_key just during _block_rehash, so that blocks for the good theme are rehashed
global $theme_key;
$old_theme_key = $theme_key;
$theme_key = 'blog_rfi';

// rebuild the blocks entries from blocks table for theme 'blog_rfi'
_block_rehash();

// restore old theme_key (which is probably something like administration_theme, as we're in hook_update_N)
$theme_key = $old_theme_key;

After this, I can do some UPDATE on blocks visibility, with WHERE clauses looking like "theme='blogs_rfi AND module='my_module' AND delta=1".

Hope this will help. :)

Regards,
David

That generally worked for us, until we had a case where we had two update functions that called _block_rehash, which causes _views_get_default_views to store the results in a static variable. Or maybe it's just the version of Views we're still using... (Ah, the Drupal 5 world).

merlinofchaos: Yeah, I suggested using DELETE and INSERT instead of UPDATE, but the developer mentioned he had been having weird problems with that, too. I haven't confirmed for myself how deep the rabbit hole goes, though.

Three years, eh? <laugh> Maybe I really am weird for insisting that all behavior-related changes (blocks, views, anything that moves) need to be checked into the source code some way or another, which usually means writing install functions. This has been fantastic for smoothly deploying to production sites, but occasionally runs into assumptions in code.

For example, I live in dreadful fear of running into an update function that uses #finished = 0, because I don't know how to simulate a browser refresh and new instance of PHP (while still keeping session variables) in my Drush command-line tool for updating all the modules... <laugh>

By the way, thank you so much for your time and insight, and for the awesomeness that is Views!</laugh>

Sacha Chua: you just made me understand where really was your problem, and that the code I pasted won't help... That was a tough one! ^^

By the way, you're not so weird: I have been thinking the same thing for long and started doing it for real some days ago. :D

David

It's not weird to want to do this, it's just that most of Drupal does not currently provide the tools necessary to do this. Views actually for the most part does; the problem you're running into is that blocks don't, and because they don't, they run into something where *I* made an assumption that default views would never actually change during a page load.

We still live in a world where sometimes you have to use drupal_execute(). This is unfortunate.

As an aside, the captcha words for this comment disturb me.

drupal_execute wouldn't solve this particular views problem, I think, but it does come in handy for other things. =) (I think every module developer should write APIs first.)

I wonder how to control the words for my reCAPTCHA...