Probably the easiest way to do this would be to make a new op, like
"blockrefresh" or something, and tie it to a box that does the
following:
my $theme = 'default'; # assuming that's the relevant theme
$S->cache->remove("blocks_$theme");
$S->cache->stamp("blocks_$theme");
$S->_set_blocks();
return;
Then just have your script call the page /blockrefresh when it's done
updating. That should do it.
--R
On Mon, 2007-06-04 at 13:26 -0400, Steve Linberg wrote:
> I run a private scoop site for my nerdy friends, and they frequently
> submit new graphical banners and highlight colors that I install in
> the "header" and "box_title_bg" blocks to change the look of the
> site. I've always done this manually through the admin interface, but
> my impatience finally kicked in and I wrote a short script to parse
> an inbound email, save the attachment in the Scoop images directory,
> and directly update the relevant blocks in the database, so I can do
> the whole thing with a quick email, which saves me braincells and
> time. This is hooked into procmail and runs outside the mod_perl
> environment and apache, it's just a short server-side script.
>
> Everything works, but Scoop doesn't activate the update because it
> doesn't know anything's been changed in the database. If I load the
> header block in the admin interface and just save it back out, the
> new data is there and saving it back does whatever cache-clearing is
> needed to make the change kick in.
>
> How can I trigger this cache-clearing from a standalone script? Is
> there some action an external script can take to communicate to
> script that blocks have changed and it's time to clear or update its
> cache?
>
> Thanks,
>
> Steve Linberg
>
> _______________________________________________
> Scoop-help mailing list
> Scoop-help at lists.kuro5hin.org
> http://lists.kuro5hin.org/mailman/listinfo/scoop-help