Bricoleurs,
I'm having some issues with publish_another() in Bric 2.0.1. Due to
performance reasons, I need to keep QUEUE_PUBLISH_JOBS enabled and use
bric_queued to handle publishing. Unfortunately, it appears most of the
updates to publish_another() between Bric 1.10.x and 2.x only apply if
QUEUE_PUBLISH_JOBS is disabled. Perhaps I don't fully understand it
yet, but it looks like the 'another_queue' process in publish_another()
doesn't quite work when the job(s) in it are not executed immediately
(i.e. bric_queued doesn't have enough information about the burner state
to keep the publish_another() jobs "together").
Here's my problem. My autohandler contains a cleanup block which is
used to trigger a republish of related assets:
> # Make it always return true to disable the triggered publishes.
> 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>|
If QUEUE_PUBLISH_JOBS is enabled, this creates an infinite publish loop
when you publish story A which relates to story B, and story B happens
to also have a relation back to story A.
It seems to me this can be fixed with one of the following methods:
1. Implement notes between publish jobs. It looks like this would
have to be added to the 'jobs' table in order for bric_queued to
pick them up, since you can't really pass a burner object.
2. Add an alternate code path to publish_another() in Burner.pm
which, instead of adding each job to 'another_queue' for later
publication, simply calls publish() directly on the asset if
QUEUE_PUBLISH_JOBS is enabled. See the attached patch file for
how I implemented this in my testing environment.
Thoughts? Are either of these potential fixes valuable, or can I do
something in my autohandler to work around this?
-Nick
I'm having some issues with publish_another() in Bric 2.0.1. Due to
performance reasons, I need to keep QUEUE_PUBLISH_JOBS enabled and use
bric_queued to handle publishing. Unfortunately, it appears most of the
updates to publish_another() between Bric 1.10.x and 2.x only apply if
QUEUE_PUBLISH_JOBS is disabled. Perhaps I don't fully understand it
yet, but it looks like the 'another_queue' process in publish_another()
doesn't quite work when the job(s) in it are not executed immediately
(i.e. bric_queued doesn't have enough information about the burner state
to keep the publish_another() jobs "together").
Here's my problem. My autohandler contains a cleanup block which is
used to trigger a republish of related assets:
> # Make it always return true to disable the triggered publishes.
> 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>|
If QUEUE_PUBLISH_JOBS is enabled, this creates an infinite publish loop
when you publish story A which relates to story B, and story B happens
to also have a relation back to story A.
It seems to me this can be fixed with one of the following methods:
1. Implement notes between publish jobs. It looks like this would
have to be added to the 'jobs' table in order for bric_queued to
pick them up, since you can't really pass a burner object.
2. Add an alternate code path to publish_another() in Burner.pm
which, instead of adding each job to 'another_queue' for later
publication, simply calls publish() directly on the asset if
QUEUE_PUBLISH_JOBS is enabled. See the attached patch file for
how I implemented this in my testing environment.
Thoughts? Are either of these potential fixes valuable, or can I do
something in my autohandler to work around this?
-Nick