Publish run unique ID

Hi,

We are generating a separate menu story which is later
<!--#included
by each story in a category, so that we don't have to
re-publish
entire categories of stories whenever one is added.

Currently there's no way to tell if, when publishing, the
menu needs
regenerating. What I'm ending up with is that the menu story
is
generated for each story during a bulk publish!
Ideally, we would do it just once per story publishing run.

My question is this: is there a global counter - or some
other value -
that I can store with $story->set_note to compare the
last time it was
published?

Cheers,
Matt.

-- 
Reclaim your digital rights, eliminate DRM, learn more at
http://w
ww.defectivebydesign.org/what_is_drm

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d-- s: a- C++++ UL+++ P++ L+++++ E--- W+++ N o-- K w--
O M V- PS+++ PE Y PGP t+ 5 X++ R+ !tv b+++ DI- D++
G-- e* h-- r+ y+++++
------END GEEK CODE BLOCK------

http://wlazlo.net/blog

On Wed, 28 Mar 2007, Matt Wlazlo wrote:
> Currently there's no way to tell if, when publishing,
the menu needs
> regenerating. What I'm ending up with is that the menu
story is
> generated for each story during a bulk publish!
> Ideally, we would do it just once per story publishing
run.

$story->needs_publish ?

On Wed, 28 Mar 2007, Matt Wlazlo wrote:

> Currently there's no way to tell if, when publishing,
the menu needs
> regenerating. What I'm ending up with is that the menu
story is
> generated for each story during a bulk publish!
> Ideally, we would do it just once per story publishing
run.

So would we but it doesn't work like that iirc.

Publishing things creates a series of jobs to achieve the
publish. Each
job contains only one story although it may contain multiple
pages (aka
resources).

Calling burn_another publishes another page within the
context of that job
(I believe) but it is unaware of any other jobs that are
queued to run.

> My question is this: is there a global counter - or
some other value -
> that I can store with $story->set_note to compare
the last time it was
> published?

There isn't a global counter that I know of that persists
across jobs so
I don't think that you can do want you want.

I've never understood why stories being published together
aren't put in
the same job, perhaps David can recall the reason for this
?

Simon.

On Wed, 28 Mar 2007, Simon Wilcox wrote:
> On Wed, 28 Mar 2007, Matt Wlazlo wrote:
>> Currently there's no way to tell if, when
publishing, the menu needs
>> regenerating. What I'm ending up with is that the
menu story is
>> generated for each story during a bulk publish!
>> Ideally, we would do it just once per story
publishing run.
>
> So would we but it doesn't work like that iirc.

I think we should be careful what we wish for.
There could be uses for running jobs every time they're
published.

> Publishing things creates a series of jobs to achieve
the publish. Each
> job contains only one story although it may contain
multiple pages (aka
> resources).
>
> Calling burn_another publishes another page within the
context of that job
> (I believe) but it is unaware of any other jobs that
are queued to run.

That's the problem, I think. It should probably have
like an "overwrite_existing_job" parameter. If
that is passed,
then it checks the job queue for whether the $asset is
already
waiting to be published, and if so it doesn't burn again.

> I've never understood why stories being published
together aren't put in
> the same job, perhaps David can recall the reason for
this ?

That's another possible place to merge jobs, but I think it
should
be carefully considered if it doesn't already work like
that.
For example, you might have an element that calls out to a
database
to obtain some content, and that you actually want to
publish
the identical story multiple times.

It might even be that you'd want the multiple jobs of the
same story
or media to be burned, with the option left to the template
during burn time
to decide whether to continue publishing this particular
story or media.

I have a similar problem which is that I like to publish an
RSS feed
whenever a new story in a given category is published... for
instance
if we have a new Fashion News story, then I'd want to
automatically
publish the Fashion RSS feed, too.  However, when I
republish every
story on the site at once, I don't want each fashion story
to trigger
the RSS feed to publish for every fashion story.  So - I
put
conditionals on the burn_another so that it will only burn
the right
RSS feed if the given story's cover date is equal to
$today.

I would suggest the same thing with your menu.  You probably
only need
to regenerate it one time after the most recent story has
been
published.

jd


On 3/28/07, Scott Lanning <lanningswho.int> wrote:
> On Wed, 28 Mar 2007, Simon Wilcox wrote:
> > On Wed, 28 Mar 2007, Matt Wlazlo wrote:
> >> Currently there's no way to tell if, when
publishing, the menu needs
> >> regenerating. What I'm ending up with is that
the menu story is
> >> generated for each story during a bulk
publish!
> >> Ideally, we would do it just once per story
publishing run.
> >
> > So would we but it doesn't work like that iirc.
>
> I think we should be careful what we wish for.
> There could be uses for running jobs every time they're
published.
>
> > Publishing things creates a series of jobs to
achieve the publish. Each
> > job contains only one story although it may
contain multiple pages (aka
> > resources).
> >
> > Calling burn_another publishes another page within
the context of that job
> > (I believe) but it is unaware of any other jobs
that are queued to run.
>
> That's the problem, I think. It should probably have
> like an "overwrite_existing_job" parameter.
If that is passed,
> then it checks the job queue for whether the $asset is
already
> waiting to be published, and if so it doesn't burn
again.
>
> > I've never understood why stories being published
together aren't put in
> > the same job, perhaps David can recall the reason
for this ?
>
> That's another possible place to merge jobs, but I
think it should
> be carefully considered if it doesn't already work like
that.
> For example, you might have an element that calls out
to a database
> to obtain some content, and that you actually want to
publish
> the identical story multiple times.
>
> It might even be that you'd want the multiple jobs of
the same story
> or media to be burned, with the option left to the
template during burn time
> to decide whether to continue publishing this
particular story or media.
>

On Mar 28, 2007, at 11:54, John Durkin wrote:

> I have a similar problem which is that I like to
publish an RSS feed
> whenever a new story in a given category is
published... for instance
> if we have a new Fashion News story, then I'd want to
automatically
> publish the Fashion RSS feed, too.  However, when I
republish every
> story on the site at once, I don't want each fashion
story to trigger
> the RSS feed to publish for every fashion story.  So -
I put
> conditionals on the burn_another so that it will only
burn the right
> RSS feed if the given story's cover date is equal to
$today.

That's the problem I was trying to fix in the patch attached
to this  
task:

   http://
bugs.bricolage.cc/show_bug.cgi?id=1050

But Wayne and I were never able to coordinate a time for me
to login  
to his system and troubleshoot, and now I don't really have
the time  
at all. I would love it if someone could take it on and
finish it  
properly.

Best,

David