zdravko.balorda at siix
Jan 24, 2012, 5:29 AM
Post #16 of 18
(1324 views)
Permalink
|
Nick, yes, indeed. I've been trying to publish old stories...
It just works, nicely. Thanks.
Suddenly I feel much better. :)
Anyway, since user can't manipulate needs_publish, it seems better
to publish regardless and let the bric_queued figure the unnecessary
(repeated) publishes. Which it does excellently. Or can I somehow fire
needs_publish condition by myself?
Best regards, Zdravko
Nick Legg III wrote:
> On Tue, Jan 24, 2012 at 5:52 AM, Zdravko Balorda
> <zdravko.balorda [at] siix>wrote:
>
>> /usr/local/bricolage/lib/Bric/App/Callback/Publish.pm
>>
>> # Examine all the related objects.
>>
>> if (PUBLISH_RELATED_ASSETS) {
>> foreach my $rel ($doc->get_related_objects) {
>> # Skip assets that don't need to be published.
>>
>> next unless $rel->needs_publish;
>>
>> According to this, related assets are published only if needs_publish is
>> true.
>> Since stories don't need to be published, it silently skips them.
>> is this really expected behavior? Even for media files?
>>
>
> So if you modify one of your related stories and check it in, then
> republish your "origin" story. I think you'll find that both stories are
> published.
>
> I think this is expected behavior. Bricolage tries to spare itself some
> unnecessary work here. Suppose the following scenario:
>
>> Story A contains a relation (link to) Story B. Story B has been published
>> in the past and hasn't been updated since. Story B has no relation back to
>> Story A so regardless of whether Story A's slug changes (or other
>> circumstance) Story B still doesn't need to republish.
>>
>
> If you have a more complex relationship between your stories where one
> story being published requires that all stories it links to (or that link
> to it) also be republished (regardless of whether these related stories are
> marked as *needs published*) then you'll have to handle that in your
> template(s).
>
> In our site, we want to republish both stories that *link to* Story A and
> stories that are *linked from* Story A. Our solution triggers a number of
> "unnecessary" republishes, but nicely handles cases where URIs change and
> updates related and reverse-related assets. Our autohandler contains the
> following code to accomplish this:
>
>> <%cleanup>
>> return if $burner->get_mode != PUBLISH_MODE ||
>> $burner->notes('in_another');
>> $burner->notes(in_another => 1);
>> $burner->publish_another($_) for ref($story)->list({
>> related_story_id => $story->get_id,
>> exclude_id => $story->get_id,
>> active => 1,
>> unexpired => 1,
>> published_version => 1,
>> });
>> $burner->notes(in_another => 0);
>> </%cleanup>
>>
>
> -Nick
>
--
Zdravko Balorda
Med.Over.Net
Jurčkova 229, Ljubljana
Tel.: +386 (0)1 520 50 50
Obiščite sistem zdravstvenih nasvetov Med.Over.Net
|
