Re: Deleting links when expiring stories

> I don't believe that is the case because the list()
method behavior
> operates completely independently of the Burner -- and
the list of
> stories you retrieve are discrete story instances, even
if the version
> number is the same -- if you use the checked_in
parameter above, you
> shouldn't get the publishing problem you mention below
-- list() will
> return the instance prior to the instance that is
created at check  
> out.

Thanks for the response.  Yes, we thought about that.  It
might be  
something we look at doing.

One more thing - we neglected to sort out how to actually
run this  
template at expire time.  We attempted to insert

             $m->comp( '/related_list_print.mc' );

into /lib/Bric/Util/Burner.pm, at line 1252, but it says
that $m is  
not defined.  /lib/Bric/Util/Burner/Mason.pm has

my $template = $burner->find_template($uri, $tmpl_name)

Do we just need to use the second method and return the
template?  Or  
are we barking completely up the wrong tree?

Thanks,

Matt


>
> -----Original Message-----
> From: Matt Rolf [mailto:rolfmdenison.edu]
> Sent: Wednesday, June 06, 2007 10:20 AM
> To: userslists.bricolage.cc
> Cc: Faith Bazley
> Subject: Deleting links when expiring stories
>
> The following is an e-mail from one of our students
working on the
> CMS that she wanted to send to the message board.  I'm
including it
> here so others can respond, and also wanted to ask if
there was an
> issue with new people subscribing to the mailing list.
We've had two
> students try to subscribe and they have been unable
to.
>
> Thanks,
>
> Matt
>
>
> On Jun 6, 2007, at 10:04 AM, bazleyfdenison.edu wrote:
>
>> I have designed a template that deletes related
links from stories
>> when the story that the link goes to is deleted. It
calls $burner-
>>> publish($story, 'story', $user_id, '') to
republish the story
>> after the link is deleted. But there's a problem
when a user has
>> this story checked out at the time the template is
called. When the
>> template executes, the story is changed, but then
the story is
>> automatically published despite the fact that the
user may have
>> made other changes that were not meant to be
published yet. An
>> error then returns that the story doesn't have a
workflow because
>> it was moved upon publishing, just like the problem
reported here:
>> http://marc.info/?l=bricolage-general&m=1
15946749314263&w=2
>>
>> I had originally written the template to make the
changes on the
>> pages, then check to see if the story is on a
workflow, and only
>> publish if it is not on a workflow. We then ran
into the problem of
>> users leaving pages sit on workflows for too long,
causing the
>> broken links to remain on the site even though they
were taken off
>> the pages.
>>
>> To overcome this workflow error, David suggested to
use the
>> parameter published_version => 1 when looking up
stories in the
>> template. However when this is done it seems that
the published
>> version is the same as a checked out version
because a new version
>> is not created until a story is checked IN. So if I
tell the burner
>> to only publish stories of published_version=>1
and the user has
>> that story checked out, the checked out version is
the same as the
>> published version and we run into workflow error
above.
>> Furthermore, it appears that
published_version=>1 may only work
>> when used by publish_another.  Can anyone confirm
if that is the  
>> case?
>> Our ideal situation is to grab the version that is
currently
>> published, make the changes and republish; but if
the story is in a
>> workflow and/or checked out we want to make the
changes to the
>> prior published version, republish that version,
and also make
>> changes to the version which is in a workflow
without publishing
>> it.  When pages are changed, we are able to send
alerts to the
>> session user and whoever has checked out a
document, but so far we
>> have not been able to pull a group of users based
on story id.
>
>> Does anyone have suggestions about these two
issues?
>>
>
>
>
>

On Wed, 6 Jun 2007, Matt Rolf wrote:
> One more thing - we neglected to sort out how to
actually run this template 
> at expire time.  We attempted to insert
>
>           $m->comp( '/related_list_print.mc' );
>
> into /lib/Bric/Util/Burner.pm, at line 1252, but it
says that $m is not 
> defined.  /lib/Bric/Util/Burner/Mason.pm has
>
> my $template = $burner->find_template($uri,
$tmpl_name)
>
> Do we just need to use the second method and return the
template?
> Or are we barking completely up the wrong tree?

I'm not sure you're even in the right forest. ;)
I'm kind of lost what's going on in the thread, though,
so this is just a generic explanation, as far as I
understand things
(might be wrong, I guess):

Expiring is (unfortunately) not a time when templates
get evaluated. It basically just runs backwards through
the Actions you put in your Destination; usually there's
just the Move action, so when you Expire it'll just do
the "undo_it" method of
lib/Bric/Dist/Action/Move.pm ,
which deletes the file. No template burning going on.

You could make your own Action if you wanted,
though that's non-trivial (but easy).

I don't think Bricolage handles this well,
where you expire a story and want to update
links to it. I think you basically have to have a cronjob
running that periodically republishes things. (no?)