Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Bricolage: users

cover date and future publish

 

 

Bricolage users RSS feed   Index | Next | Previous | View Threaded


terence.bodola at cbsparamount

May 28, 2008, 8:23 PM

Post #1 of 11 (5893 views)
Permalink
cover date and future publish

if i set a future date in the cover date and check in and publish the asset is published immediately, regardless of if in queued mode or default

if i have bric in queued mode and i check a story in to the publish desk with same future date it just sits there idle as the date passes...i guess b/c it's not in the jobs queue and bric_queued just watches the jobs queue

is there a way to do this? do i need to setup some kind of poller to watch the publish desk?

can i have check in and publish throw to the jobs queue with future date for publish somehow?


lannings at who

May 29, 2008, 12:40 AM

Post #2 of 11 (5724 views)
Permalink
Re: cover date and future publish [In reply to]

On Wed, 28 May 2008, bodola, terence wrote:
> if i set a future date in the cover date and check in and publish the asset is
> published immediately, regardless of if in queued mode or default

Right. So it means "Check in and publish NOW"

> if i have bric in queued mode and i check a story in to the publish desk with
> same future date it just sits there idle as the date passes...i guess b/c it's
> not in the jobs queue and bric_queued just watches the jobs queue

Right, you didn't actually publish it, just put it on the desk
to be published. (Though I think that's an interesting idea
of how to do publishing, just checkin to the publish desk
and it magically gets published.)

> can i have check in and publish throw to the jobs queue with future date for
> publish somehow?

Checkin to the publish desk as you've done, then visit that publish desk.
There is a 'Publish' checkbox that you check, and at bottom there
is a 'Publish Checked' button. The following interface allows you
to alter the publish date, then you click 'Publish Assets'.


phillip at communitybandwidth

May 29, 2008, 6:49 AM

Post #3 of 11 (5727 views)
Permalink
Re: cover date and future publish [In reply to]

Hey there Terence,

There are a couple of ways to do this, which are outlined here:
http://marc.info/?t=118962976800001&r=1&w=2

In short, you'll need to choose the distribution method: either
bric_queued or bric_dist_mon

Then you'll need to set the appropriate directive in the
bricolage.conf file and restart Bricolage.
http://www.perl.com/pub/a/2005/01/06/bricolage_configuration.html?page=2#queuepublishjobs

The bric_queued needs to be run as an aggressive cron job (IIRC), and
that will clear out the job queue regularly.

If you want to publish immediately _and_ set jobs to be published in
the future, I think you'll need to rely on the bric_dist_mon, which
monitors the queue vs. running as a cron job (again, IIRC).

Hope that helps a bit.

Phillip.

On 28-May-08, at 11:23 PM, bodola, terence wrote:

>
> if i set a future date in the cover date and check in and publish
> the asset is published immediately, regardless of if in queued mode
> or default
>
> if i have bric in queued mode and i check a story in to the publish
> desk with same future date it just sits there idle as the date
> passes...i guess b/c it's not in the jobs queue and bric_queued just
> watches the jobs queue
>
> is there a way to do this? do i need to setup some kind of poller
> to watch the publish desk?
>
> can i have check in and publish throw to the jobs queue with future
> date for publish somehow?

--
Phillip Smith,
Simplifier of Technology
Community Bandwidth
http://www.communitybandwidth.ca


terence.bodola at cbsparamount

May 29, 2008, 7:39 AM

Post #4 of 11 (5716 views)
Permalink
RE: cover date and future publish [In reply to]

i suppose i don't understand the croning of bric_queued, as it appears to be a daemon that polls every 30 seconds

the last post (by david) i see in that list thread he seems to indicate he isn't sure if you could cron bric_dis_mon to run regularly when you are setup in queued mode (running bric_queued as a daemon?)

i am assuming i could spool up multiple instances of the bric_queued daemon to try to fight the fifo nature of the queue?

Thanks,
Terence Bodola
terence.bodola [at] cbsparamount
323-956-4813



-----Original Message-----
From: Phillip Smith [mailto:phillip [at] communitybandwidth]
Sent: Thu 5/29/2008 6:49 AM
To: users [at] lists
Subject: Re: cover date and future publish


Hey there Terence,

There are a couple of ways to do this, which are outlined here:
http://marc.info/?t=118962976800001&r=1&w=2

In short, you'll need to choose the distribution method: either
bric_queued or bric_dist_mon

Then you'll need to set the appropriate directive in the
bricolage.conf file and restart Bricolage.
http://www.perl.com/pub/a/2005/01/06/bricolage_configuration.html?page=2#queuepublishjobs

The bric_queued needs to be run as an aggressive cron job (IIRC), and
that will clear out the job queue regularly.

If you want to publish immediately _and_ set jobs to be published in
the future, I think you'll need to rely on the bric_dist_mon, which
monitors the queue vs. running as a cron job (again, IIRC).

Hope that helps a bit.

Phillip.

On 28-May-08, at 11:23 PM, bodola, terence wrote:

>
> if i set a future date in the cover date and check in and publish
> the asset is published immediately, regardless of if in queued mode
> or default
>
> if i have bric in queued mode and i check a story in to the publish
> desk with same future date it just sits there idle as the date
> passes...i guess b/c it's not in the jobs queue and bric_queued just
> watches the jobs queue
>
> is there a way to do this? do i need to setup some kind of poller
> to watch the publish desk?
>
> can i have check in and publish throw to the jobs queue with future
> date for publish somehow?

--
Phillip Smith,
Simplifier of Technology
Community Bandwidth
http://www.communitybandwidth.ca


paulo at digitalcraftsmen

May 30, 2008, 1:54 AM

Post #5 of 11 (5746 views)
Permalink
Re: cover date and future publish [In reply to]

Hi,

The way we do it is to create a desk called "auto publish" which editors can put
stories onto with future cover dates. We then have a shell script (run every 5
minutes through cron) that polls the desk and publishes any appropriate stories
where now > cover_date all using bric soap. It then emails the results to the
appropriate people

It's a bit hacky but it works very well. Happy to post it if people want it.

regards,

Paul


lannings at who

May 30, 2008, 4:56 AM

Post #6 of 11 (5727 views)
Permalink
Re: cover date and future publish [In reply to]

On Fri, 30 May 2008, Paul Orrock wrote:
> The way we do it is to create a desk called "auto publish" which editors can
> put stories onto with future cover dates. We then have a shell script
[...]
> It's a bit hacky but it works very well.

What are the advantages of it from a user perspective?
Is it basically just so that instead of having to put
the story on the publish Desk and then go to the Desk
and schedule the publish, they can now from within
the Story Profile just "Checkin to auto publish"?


paulo at digitalcraftsmen

May 30, 2008, 7:22 AM

Post #7 of 11 (5726 views)
Permalink
Re: cover date and future publish [In reply to]

Scott Lanning wrote:
> On Fri, 30 May 2008, Paul Orrock wrote:
>> The way we do it is to create a desk called "auto publish" which
>> editors can
>> put stories onto with future cover dates. We then have a shell script
> [...]
>> It's a bit hacky but it works very well.
>
> What are the advantages of it from a user perspective?
> Is it basically just so that instead of having to put
> the story on the publish Desk and then go to the Desk
> and schedule the publish, they can now from within
> the Story Profile just "Checkin to auto publish"?

Yes, that plus cancelling a story publish becomes a simple case of moving it off
the desk so it's very intuitive for the users, it does what it says on the tin.

However the main reason is that we use a lot of interaction between the
templates and other external modules built into the bricolage apache, so it
makes sense to use bric_soap so that everything is published as though a user
had hit the button rather than some of the bric_queued "outside of the apache
process" weirdness.

Plus from a sysadmin point of view it turns it into a zero maintenance issue
rather than having to check the bric_queued is running and resolving any
problems if it doesn't work, or doesn't publish correctly.

It's also one less part of Bricolage for me to have to get my head round :-)

regards,

Paul


david at kineticode

May 30, 2008, 9:17 AM

Post #8 of 11 (5729 views)
Permalink
Re: cover date and future publish [In reply to]

On May 30, 2008, at 07:22, Paul Orrock wrote:

> Plus from a sysadmin point of view it turns it into a zero
> maintenance issue rather than having to check the bric_queued is
> running and resolving any problems if it doesn't work, or doesn't
> publish correctly.
>
> It's also one less part of Bricolage for me to have to get my head
> round :-)

Seems to me that it's about equal to having bric_dist_mon as a cron job.

David


simonw at digitalcraftsmen

May 30, 2008, 9:35 AM

Post #9 of 11 (5712 views)
Permalink
Re: cover date and future publish [In reply to]

David E. Wheeler wrote:
> On May 30, 2008, at 07:22, Paul Orrock wrote:
>
>> Plus from a sysadmin point of view it turns it into a zero maintenance
>> issue rather than having to check the bric_queued is running and
>> resolving any problems if it doesn't work, or doesn't publish correctly.
>>
>> It's also one less part of Bricolage for me to have to get my head
>> round :-)
>
> Seems to me that it's about equal to having bric_dist_mon as a cron job.

Mostly but jobs in the jobs queue are less visible to the users and they
need extra permissions to cancel jobs.

I also have a vague feeling that the publish happens immediately, it's
just the distribution that happens later. In which case the story can't
take note of anything else that's happened between the initial publish &
the distribution. I think. But it's Friday, my brane is fading and I may
have that completely wrong!

S.

--
Digital Craftsmen Ltd
Exmouth House, 3 Pine Street, London. EC1R 0JH
t 020 7183 1410 f 020 7099 5140 m 07951 758698
w http://www.digitalcraftsmen.net/


david at kineticode

May 30, 2008, 10:03 AM

Post #10 of 11 (5716 views)
Permalink
Re: cover date and future publish [In reply to]

On May 30, 2008, at 09:35, Simon Wilcox wrote:

>>> It's also one less part of Bricolage for me to have to get my head
>>> round :-)
>> Seems to me that it's about equal to having bric_dist_mon as a cron
>> job.
>
> Mostly but jobs in the jobs queue are less visible to the users and
> they need extra permissions to cancel jobs.

Yeah, I meant from a sysadmin point of view.

> I also have a vague feeling that the publish happens immediately,
> it's just the distribution that happens later. In which case the
> story can't take note of anything else that's happened between the
> initial publish & the distribution. I think. But it's Friday, my
> brane is fading and I may have that completely wrong!

Not sure I follow you there. But when you use queuing, the publish
does not happen until bric_queued triggers it. It might be, though,
that the distribution doesn't happen until the next time bric_queued
runs, though. Lame if true.

Best,

David


phillip at communitybandwidth

May 30, 2008, 10:24 AM

Post #11 of 11 (5693 views)
Permalink
Re: cover date and future publish [In reply to]

On 29-May-08, at 10:39 AM, bodola, terence wrote:

> i suppose i don't understand the croning of bric_queued, as it
> appears to be a daemon that polls every 30 seconds

Think I got them backwards! :-P

--
Phillip Smith,
Simplifier of Technology
Community Bandwidth
http://www.communitybandwidth.ca

Bricolage users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.