Mailing List Archive

On 2012-01-16, at 2:32 AM, Zdravko Balorda wrote:

> Hi,
> to publish related stories are there any other conditions to be met
> beside config:
>
> PUBLISH_RELATED_ASSETS = Yes
>
> Somehow, related stories won't publish anymore. Or am I missing something?!


What do you mean by "related stories" exactly? I *think* that the PUBLISH_RELATED_ASSETS setting only publishing the single media or story asset that are _directly_ related to the story, not assets that are related through sub-elements. I could be wrong about this, but I believe that's the case.


--
Phillip Smith
http://phillipadsmith.com
http://twitter.com/phillipadsmith
http://linkedin.com/in/phillipadsmith

Save our in-boxes! http://emailcharter.org

Phillip Smith wrote:
> On 2012-01-16, at 2:32 AM, Zdravko Balorda wrote:
>
>> Hi,
>> to publish related stories are there any other conditions to be met
>> beside config:
>>
>> PUBLISH_RELATED_ASSETS = Yes
>>
>> Somehow, related stories won't publish anymore. Or am I missing something?!
>
>
> What do you mean by "related stories" exactly? I *think* that the PUBLISH_RELATED_ASSETS setting only publishing the single media or story asset that are _directly_ related to the story, not assets that are related through sub-elements. I could be wrong about this, but I believe that's the case.
>

Phillip, I'd agree. Yet, it doesn't publish "related stories". Only a leading story.
No related media, either!
Should I check anything in the database?
Zdravko

Phillip Smith wrote:
> On 2012-01-16, at 2:32 AM, Zdravko Balorda wrote:
>
>> Hi,
>> to publish related stories are there any other conditions to be met
>> beside config:
>>
>> PUBLISH_RELATED_ASSETS = Yes
>>
>> Somehow, related stories won't publish anymore. Or am I missing something?!
>
>
> What do you mean by "related stories" exactly? I *think* that the PUBLISH_RELATED_ASSETS setting only publishing the single media or story asset that are _directly_ related to the story, not assets that are related through sub-elements. I could be wrong about this, but I believe that's the case.
>

Phillip, I'd agree. Yet, it doesn't publish "related stories". Only a leading story.
No related media, either!
Should I check anything in the database?
Zdravko

Not even bric_soap would do:
bric_soap workflow publish story_9017 --with-related-media --with-related-stories

There should have been 2 stories and 1 media published, but only a story itself get's
published.

Hi!
Any pointers on this subject?
Regards, Zdravko


Phillip Smith wrote:
> On 2012-01-16, at 2:32 AM, Zdravko Balorda wrote:
>
>> Hi,
>> to publish related stories are there any other conditions to be met
>> beside config:
>>
>> PUBLISH_RELATED_ASSETS = Yes
>>
>> Somehow, related stories won't publish anymore. Or am I missing something?!
>
>
> What do you mean by "related stories" exactly? I *think* that the PUBLISH_RELATED_ASSETS setting only publishing the single media or story asset that are _directly_ related to the story, not assets that are related through sub-elements. I could be wrong about this, but I believe that's the case.
>

Phillip, I'd agree. Yet, it doesn't publish "related stories". Only a leading story.
No related media, either!
Should I check anything in the database?
Zdravko

Not even bric_soap would do:
bric_soap workflow publish story_9017 --with-related-media --with-related-stories

There should have been 2 stories and 1 media published, but only a story itself get's
published.

Can you export the story via bric_soap and paste the output into an e-mail and send it to the list?

On 2012-01-19, at 3:48 AM, Zdravko Balorda wrote:

>
> Hi!
> Any pointers on this subject?
> Regards, Zdravko
>
>
> Phillip Smith wrote:
>> On 2012-01-16, at 2:32 AM, Zdravko Balorda wrote:
>>> Hi,
>>> to publish related stories are there any other conditions to be met
>>> beside config:
>>>
>>> PUBLISH_RELATED_ASSETS = Yes
>>>
>>> Somehow, related stories won't publish anymore. Or am I missing something?!
>> What do you mean by "related stories" exactly? I *think* that the PUBLISH_RELATED_ASSETS setting only publishing the single media or story asset that are _directly_ related to the story, not assets that are related through sub-elements. I could be wrong about this, but I believe that's the case.
>
> Phillip, I'd agree. Yet, it doesn't publish "related stories". Only a leading story.
> No related media, either!
> Should I check anything in the database?
> Zdravko
>
> Not even bric_soap would do:
> bric_soap workflow publish story_9017 --with-related-media --with-related-stories
>
> There should have been 2 stories and 1 media published, but only a story itself get's
> published.
>

--
Phillip Smith
http://phillipadsmith.com
http://twitter.com/phillipadsmith
http://linkedin.com/in/phillipadsmith

Save our in-boxes! http://emailcharter.org

Phillip Smith wrote:
> Can you export the story via bric_soap and paste the output into an e-mail and send it to the list?
>

Here it is. Probably all you wanted are <containers>. Note that "linked_news" are of type
Related Story. When it's published related documents should appear in a Job queue
immedialtely, right? They don't. Not even when queued runs the job. The story itself is
the only job in the queue.

Regards, Zdravko
-------------------------------------------------------

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assets xmlns="http://bricolage.sourceforge.net/assets.xsd">
<story id="9257" uuid="66CFDBEC-D300-11E0-8949-B53D66B94067" element_type="news">
<site>Aphaia-SI</site>
<name>Urša Primožič</name>
<description></description>
<slug>ursa_primozic</slug>
<primary_uri>/sodelavci/ursa_primozic/</primary_uri>
<priority>3</priority>
<publish_status>1</publish_status>
<active>1</active>
<source>Internal</source>
<cover_date>2011-08-30T12:05:00Z</cover_date>
<publish_date>2012-01-17T13:02:00Z</publish_date>
<first_publish_date>2011-09-02T07:54:48Z</first_publish_date>
<categories>
<category primary="1">/sodelavci/</category>
</categories>
<output_channels>
<output_channel primary="1">PHP Aphaia-sl_SI.UTF8</output_channel>
</output_channels>
<contributors></contributors>
<elements>
<field type="text" order="0"></field>
<container displayed="1" order="1" element_type="related_media"
related_media_id="21710" />
<container displayed="1" order="2" element_type="linked_news" related_story_id="9255" />
<container displayed="1" order="3" element_type="linked_news" related_story_id="9256" />
<container displayed="1" order="4" element_type="see_alsoflag" />
</elements>
</story>
</assets>

Zdravko,

When you publish story 9257 with PUBLISH_RELATED_ASSETS = Yes, I would
expect assets 21710, 9255, and 9256 to be published as well. If that's
not the behavior you are seeing, can you confirm a few circumstances?

- Assets 21710, 9255, and 9256 are not checked out or "lost" (remember
your lost story from the other day?)
- Assets 21710, 9255, and 9256 are publishable on their own, i.e. they
don't fail when you try to publish each individually
- Assets 21710, 9255, and 9256 *are on a publish desk*
- There appears to be no error output in your bric_queued.log regarding
these assets

You may be affected by the following bug which would cause your related
assets' publish jobs to fail silently:
http://bricolage.lighthouseapp.com/projects/29601/tickets/277

-Nick

Nick Legg III wrote:
> Zdravko,
>
> When you publish story 9257 with PUBLISH_RELATED_ASSETS = Yes, I would
> expect assets 21710, 9255, and 9256 to be published as well. If that's
> not the behavior you are seeing, can you confirm a few circumstances?

Nick, hi!
I saw this working in the past, too, not so long ago. :)

> - Assets 21710, 9255, and 9256 are not checked out or "lost" (remember
> your lost story from the other day?)

Everything is there.

> - Assets 21710, 9255, and 9256 are publishable on their own, i.e. they
> don't fail when you try to publish each individually

Yes, I can republish each one individually.

> - Assets 21710, 9255, and 9256 *are on a publish desk*

They are all moved to Shelve (archive desk).

> - There appears to be no error output in your bric_queued.log regarding
> these assets

error.log is clean.

It works exactly as if PUBLISH_RELATED_ASSETS = No but it's set to Yes.
For what's it worth: $burner->publish_another gets called from a template
and is working. Cover page is published. But this is not relevant.

> You may be affected by the following bug which would cause your related
> assets' publish jobs to fail silently:
> http://bricolage.lighthouseapp.com/projects/29601/tickets/277

I looked at this, but I can't really relate. Because it's just plain dead and
I don't have a clue what is wrong, yet.

Regards, Zdravko

On Jan 20, 2012, at 5:39 AM, Zdravko Balorda wrote:

> It works exactly as if PUBLISH_RELATED_ASSETS = No but it's set to Yes.
> For what's it worth: $burner->publish_another gets called from a template
> and is working. Cover page is published. But this is not relevant.

Did you recently change PUBLISH_RELATED_ASSETS to Yes and not restart Bricolage?

Best,

David

On 2012-01-20, at 11:15 AM, David E. Wheeler wrote:

> On Jan 20, 2012, at 5:39 AM, Zdravko Balorda wrote:
>
>> It works exactly as if PUBLISH_RELATED_ASSETS = No but it's set to Yes.
>> For what's it worth: $burner->publish_another gets called from a template
>> and is working. Cover page is published. But this is not relevant.
>
> Did you recently change PUBLISH_RELATED_ASSETS to Yes and not restart Bricolage?

Ha! That was the first question I was going to ask, but I forgot to ask it. :)

--
Phillip Smith
http://phillipadsmith.com
http://twitter.com/phillipadsmith
http://linkedin.com/in/phillipadsmith

Save our in-boxes! http://emailcharter.org

Phillip Smith wrote:
> On 2012-01-20, at 11:15 AM, David E. Wheeler wrote:
>
>> On Jan 20, 2012, at 5:39 AM, Zdravko Balorda wrote:
>>
>>> It works exactly as if PUBLISH_RELATED_ASSETS = No but it's set to Yes.
>>> For what's it worth: $burner->publish_another gets called from a template
>>> and is working. Cover page is published. But this is not relevant.
>> Did you recently change PUBLISH_RELATED_ASSETS to Yes and not restart Bricolage?
>
> Ha! That was the first question I was going to ask, but I forgot to ask it. :)

:)
Well, I must say I can't recall ever changing ti from Yes. But, just in case,
I checked:

bric_soap workflow publish story_9255 --with-related-media --with-related-stories

this time twice: with PUBLISH_RELATED_ASSETS = Yes, and with no. (while restarting
bric_apache)

Both times only the leading story appeared in the job queue even though this story also
has two related stories and one related media.

Looking forward to hearing from you, Zdravko

On Jan 22, 2012, at 10:23 PM, Zdravko Balorda wrote:

> :)
> Well, I must say I can't recall ever changing ti from Yes. But, just in case,
> I checked:
>
> bric_soap workflow publish story_9255 --with-related-media --with-related-stories

Oh, did you mention before you were doing it via SOAP? I don’t think the SOAP interface does anything with PUBLISH_RELATED_ASSETS. Though obviously it ought to.

What happens if you publish that story via the UI?

Best,

David

David E. Wheeler wrote:
> On Jan 22, 2012, at 10:23 PM, Zdravko Balorda wrote:
>
>> :)
>> Well, I must say I can't recall ever changing ti from Yes. But, just in case,
>> I checked:
>>
>> bric_soap workflow publish story_9255 --with-related-media --with-related-stories
>
> Oh, did you mention before you were doing it via SOAP? I don’t think the SOAP interface does anything with PUBLISH_RELATED_ASSETS. Though obviously it ought to.
>
> What happens if you publish that story via the UI?

UI, too. Please, here is what I have found in
/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?

Regards, Zdravko

On Tue, Jan 24, 2012 at 5:52 AM, Zdravko Balorda
<zdravko.balorda@siix.com>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

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@siix.com>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

On Tue, Jan 24, 2012 at 8:29 AM, Zdravko Balorda
<zdravko.balorda@siix.com>wrote:

> Or can I somehow fire needs_publish condition by myself?
>

Possibly. According to the API:

$asset->needs_publish() Compares current_version and published_version from
> asset table. If the same, needs_publish returns 0. If different, returns 1.


So if you manipulate current_version (probably a bad idea) or
published_version (probably a slightly less bad idea) on the story it might
"trick" needs_publish() into returning 1.

But I still recommend using publish_another() to accomplish your goal since
the above seems tenuous at best.

Regards,
Nick

On Jan 24, 2012, at 2:52 AM, Zdravko Balorda wrote:

> UI, too. Please, here is what I have found in
> /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?

Yes. The assumption is, if you haven’t changed the story or media document, there is no reason to republish it.

Best,

David