Mailing List Archive

There is an API call to do what you need. In the template for the story itself, you'll need to incorporate $burner->publish_another and point it at the cover story.

It is in the template section of the API documentation.

-Matt

On Feb 12, 2010, at 7:29 AM, Zdravko Balorda wrote:

>
>
> Hi,
>
> how do you handle automatic publishing of cover stories?
> I always publish both, the story itself and the cover story.
> Is there a way just to mark cover pages for publishing so they
> can be published by bric_dist_mon. Any better ideas?
>
> Regards, Zdravko
>

That's not quite the same thing. That will publish the cover story at
the same time the story is published but that's not always what you want.

It would be useful if you could flag another story to be re-published
later. That could then be flagged by several stories in a time period
but only re-published once.

In a complex site with heavy dependency chains I could see how that
would save a lot of repeated and mostly redundant publications of cover
pages.

Simon.

On 12/2/10 14:23, Rolf, Matthew wrote:
> There is an API call to do what you need. In the template for the
> story itself, you'll need to incorporate $burner->publish_another
> and point it at the cover story.
>
> It is in the template section of the API documentation.
>
> -Matt
>
> On Feb 12, 2010, at 7:29 AM, Zdravko Balorda wrote:
>
>>
>> Hi,
>>
>> how do you handle automatic publishing of cover stories? I always
>> publish both, the story itself and the cover story. Is there a way
>> just to mark cover pages for publishing so they can be published by
>> bric_dist_mon. Any better ideas?
>>
>> Regards, Zdravko
>>
>
>

On Feb 12, 2010, at 11:00 AM, Simon Wilcox wrote:

>
> That's not quite the same thing. That will publish the cover story at the same time the story is published but that's not always what you want.
>
> It would be useful if you could flag another story to be re-published later. That could then be flagged by several stories in a time period but only re-published once.
>
> In a complex site with heavy dependency chains I could see how that would save a lot of repeated and mostly redundant publications of cover pages.

If you do a bulk publish in 1.11.x, that's exactly what it does now. This is an improvement over 1.10.

Best,

David

Simon Wilcox wrote:
>
> That's not quite the same thing. That will publish the cover story at
> the same time the story is published but that's not always what you want.
>
> It would be useful if you could flag another story to be re-published
> later. That could then be flagged by several stories in a time period
> but only re-published once.
>
> In a complex site with heavy dependency chains I could see how that
> would save a lot of repeated and mostly redundant publications of cover
> pages.
>

Exactly my point.
I am considering cron publishing all cover stories periodicaly. Every
15min or so, on all sites.
There is already "needs publish" red P marker. Any way to wave this flag
from story template? bric_dist_mon could schedule publishing, then.

Zdravko

Hi Zdravko,

That "needs publish" marker indicates that the current version of the
story is ahead of the published version. Something like this:

Story was published shortly after creation. Published version is #1.

Next, story was edited, then checked in. Current version is #2, but
published version is #1. In a case like this, the P will turn red.

This is different from a cover needing to be published. If you have
published a bunch of stories and want them to show up on the home page,
that won't do anything to the home page's P.

The way I've dealt with this recently is to make two utility templates.

The first one is called "index_publisher." Most stories call this one in
a <%cleanup> block. It looks at the story type and categories of the
story that called it, and it uses that to come up with a list of urgent
covers, and then it publishes those covers.

The second is called "archive_index_publisher," and is used for covers
that are not so urgent and can go three minutes or so between updates.

A very simple story called "Index trigger" is republished (via cron) by
bric_republish every three minutes, and this calls the utility template.

The template itself begins by looking up all the stories published in
the last hour. Then it runs through that list of stories, and for each
one, it figures out what sorts of covers ought to be triggered. Then it
does a story->list() for the covers that have publish dates earlier than
the publish date of the current story. If it finds any, it adds them to
an array of @covers_to_publish.

Then, in a <%cleanup> block, it calls publish_another() on each story in
@covers_to_publish.

I'd be happy to share the code, if that would help, although the mix of
story types and categories will probably be quite different from the
ones on your site. But let me know.


Cheers,

Bret


On Mon, 2010-02-15 at 13:56 +0100, Zdravko Balorda wrote:
> Simon Wilcox wrote:
> >
> > That's not quite the same thing. That will publish the cover story at
> > the same time the story is published but that's not always what you want.
> >
> > It would be useful if you could flag another story to be re-published
> > later. That could then be flagged by several stories in a time period
> > but only re-published once.
> >
> > In a complex site with heavy dependency chains I could see how that
> > would save a lot of repeated and mostly redundant publications of cover
> > pages.
> >
>
> Exactly my point.
> I am considering cron publishing all cover stories periodicaly. Every
> 15min or so, on all sites.
> There is already "needs publish" red P marker. Any way to wave this flag
> from story template? bric_dist_mon could schedule publishing, then.
>
> Zdravko
>


--
Bret Dawson
Producer
Pectopah Productions Inc.
(416) 895-7635
bret@pectopah.com
www.pectopah.com

>
> A very simple story called "Index trigger" is republished (via cron) by
> bric_republish every three minutes, and this calls the utility template.

This is a clever approach. I will go for hourly publishing of all cover
stories. There are not so many anyway, and users already have online preview.

Thanks, Zdravko.

On Feb 15, 2010, at 11:53 AM, Bret Dawson wrote:

> I'd be happy to share the code, if that would help, although the mix
> of
> story types and categories will probably be quite different from the
> ones on your site. But let me know.

I'd love to see your code Bret - that would be very useful to us. We
do a lot of just-in-time republishes (which is buggy), but we'd like
to cron things like recent posts widgets, archives, etc.

-Aaron

---------------------------------
Aaron Fuleki
Senior Web Architect
Denison University
740.587.5752
---------------------------------

Hi Aaron (and Phillip, who also asked),

I've attached a template that seems to work quite well. It's a utility
template, which is itself called by a story template.


Here's how it goes:

1. bric_republish republishes a story called "archive tickler" every
three minutes.

2. The archive tickler story template does nothing but call this utility
template.


There's a lot of what feels like repeated code here, so I'm sure it
could be shortened. It's just that each story type has a set of covers
that feels unique, with unique rules. Anyway, all the verbosity makes it
easy to adjust the cover behaviour for each story type.


Hope this helps,

Bret



On Thu, 2010-02-18 at 11:07 -0500, Aaron Fuleki wrote:
> On Feb 15, 2010, at 11:53 AM, Bret Dawson wrote:
>
> > I'd be happy to share the code, if that would help, although the mix
> > of
> > story types and categories will probably be quite different from the
> > ones on your site. But let me know.
>
> I'd love to see your code Bret - that would be very useful to us. We
> do a lot of just-in-time republishes (which is buggy), but we'd like
> to cron things like recent posts widgets, archives, etc.
>
> -Aaron
>
> ---------------------------------
> Aaron Fuleki
> Senior Web Architect
> Denison University
> 740.587.5752
> ---------------------------------
>
>
>


--
Bret Dawson
Producer
Pectopah Productions Inc.
(416) 895-7635
bret@pectopah.com
www.pectopah.com

Hi,
let me continue this thread with yet another suggestion:
Could one play with publish date of a cover story? That is
if one wants it published one would push the cover story
publish date which then will be caught by que daemon.
Would it work? And could this be done without checkout/in
unless there is no cost to winding story version number?

Regards, Zdravko

On Oct 3, 2010, at 10:09 PM, Zdravko Balorda wrote:

> let me continue this thread with yet another suggestion:
> Could one play with publish date of a cover story? That is
> if one wants it published one would push the cover story
> publish date which then will be caught by que daemon.

The queue system is just a queue. It doesn't check any attributes to determine whether or not to publish something.

> Would it work? And could this be done without checkout/in
> unless there is no cost to winding story version number?

Best with checkin/checkout, though not absolutely essential, I'd say. Just don't do it if the story is checked-out, as it might lead to conflicts.

Best,

DAvid

Hi, David!

You have encouraged me to dig into this further. It goes even simpler:
As you want some story to be published check first if there is a job
in the queue already, via Bric::Util::Job. Then push the schedule date
forward a bit. If the story is not scheduled yet call
$burner->publish_another some time later.

This way cover story will be published soon after a story, while
republishing many stories will still publish a cover story only once.

Huh!
Maybe I' obsessed with this issue. :) I just can't find a solution
for users to seamlessly publish all the stories that may have changed.

Regards, Zdravko


David E. Wheeler wrote:
> On Oct 3, 2010, at 10:09 PM, Zdravko Balorda wrote:
>
>> let me continue this thread with yet another suggestion:
>> Could one play with publish date of a cover story? That is
>> if one wants it published one would push the cover story
>> publish date which then will be caught by que daemon.
>
> The queue system is just a queue. It doesn't check any attributes to determine whether or not to publish something.
>
>> Would it work? And could this be done without checkout/in
>> unless there is no cost to winding story version number?
>
> Best with checkin/checkout, though not absolutely essential, I'd say. Just don't do it if the story is checked-out, as it might lead to conflicts.
>
> Best,
>
> DAvid
>
>
>

On Oct 4, 2010, at 11:01 PM, Zdravko Balorda wrote:

> Hi, David!
>
> You have encouraged me to dig into this further. It goes even simpler:
> As you want some story to be published check first if there is a job
> in the queue already, via Bric::Util::Job. Then push the schedule date
> forward a bit. If the story is not scheduled yet call
> $burner->publish_another some time later.


> This way cover story will be published soon after a story, while
> republishing many stories will still publish a cover story only once.

Bricolage 2.0 does this already.

> Huh!
> Maybe I' obsessed with this issue. :) I just can't find a solution
> for users to seamlessly publish all the stories that may have changed.

If you're running 2.0, you should already be all set.

Best,

David

Well, not yet. But this was the last drop. :)
Regards, Zdravko


David E. Wheeler wrote:
> On Oct 4, 2010, at 11:01 PM, Zdravko Balorda wrote:
>
>> Hi, David!
>>
>> You have encouraged me to dig into this further. It goes even simpler:
>> As you want some story to be published check first if there is a job
>> in the queue already, via Bric::Util::Job. Then push the schedule date
>> forward a bit. If the story is not scheduled yet call
>> $burner->publish_another some time later.
>
>
>> This way cover story will be published soon after a story, while
>> republishing many stories will still publish a cover story only once.
>
> Bricolage 2.0 does this already.
>
>> Huh!
>> Maybe I' obsessed with this issue. :) I just can't find a solution
>> for users to seamlessly publish all the stories that may have changed.
>
> If you're running 2.0, you should already be all set.
>
> Best,
>
> David
>
>