Mailing List Archive: SOAP bug, or PEBKAC?

SOAP bug, or PEBKAC?

Sep 25, 2009, 7:56 AM

Post #1 of 14 (4857 views)

We recently tried the following SOAP command to republish all of our
staff bio/cv stories to reflect some template changes:

------------------------------------------------------------
/usr/local/bricolage/bin/bric_soap --username xxxx --password xxxx --
server https://freestyle.denison.edu story list_ids --search
"element_key_name=cv" --search "site=Denison University" --search
"publish_status=1" --search "unexpired=1" | /usr/local/bricolage/bin/
bric_soap --username xxxx --password xxxx --server https://freestyle.denison.edu
workflow --server https://freestyle.denison.edu publish --continue-
on-errors --published-only --chunks 1 -
------------------------------------------------------------

It worked great for 99% of the stories, except those that were checked
out and in a workflow. For those, we got the following error:

------------------------------------------------------------
Can't call method "get_id" on an undefined value at /usr/local/
bricolage/lib/Bric/Util/Burner.pm line 1203. [/usr/local/bricolage/lib/
Bric/Util/Burner.pm:1203] [/usr/local/bricolage/lib/Bric/Util/Job/
Pub.pm:191] [/usr/local/bricolage/lib/Bric/Util/Job.pm:1889] [/usr/
local/bricolage/bin/bric_queued:244] [/usr/local/bricolage/bin/
bric_queued:213]
------------------------------------------------------------

Line 1203 of Burner.pm looks like the first time the publish method
tries to access the bric asset object, where it promptly dies. Is
this a bug? Shouldn't the code be hardened to not pass incomplete/
missing parameters to publish?

Is there something we can do to have the SOAP command just grab the
last published version, and not the checked-out version? I though
Matt Rolf had figured this out at some point, but I can't find it in
his notes, or my searches of the list archives and docs.

The SOAP recipes page shows the use of a "checked_out" argument with
the story module, and the API docs refer to a "no_workflow" argument,
but I don't think that's what I want. I don't want to skip these
stories, because that leaves an old version of them on the production
servers - I want to make sure that every story gets published.

-Aaron

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

Re: SOAP bug, or PEBKAC? [ In reply to ]

rolf at ohio

Sep 25, 2009, 8:00 AM

Post #2 of 14 (4761 views)

Permalink

You might want to check out the bug lists - I'm 99% sure this is
something that has been fixed, perhaps in 10.7, but that we didn't get
around to patching on our install.

But I could be wrong.

-Mateo

On Sep 25, 2009, at 10:56 AM, Aaron Fuleki wrote:

> We recently tried the following SOAP command to republish all of our
> staff bio/cv stories to reflect some template changes:
>
> ------------------------------------------------------------
> /usr/local/bricolage/bin/bric_soap --username xxxx --password xxxx --
> server https://freestyle.denison.edu story list_ids --search
> "element_key_name=cv" --search "site=Denison University" --search
> "publish_status=1" --search "unexpired=1" | /usr/local/bricolage/bin/
> bric_soap --username xxxx --password xxxx --server https://freestyle.denison.edu
> workflow --server https://freestyle.denison.edu publish --continue-
> on-errors --published-only --chunks 1 -
> ------------------------------------------------------------
>
> It worked great for 99% of the stories, except those that were
> checked out and in a workflow. For those, we got the following error:
>
> ------------------------------------------------------------
> Can't call method "get_id" on an undefined value at /usr/local/
> bricolage/lib/Bric/Util/Burner.pm line 1203. [/usr/local/bricolage/
> lib/Bric/Util/Burner.pm:1203] [/usr/local/bricolage/lib/Bric/Util/
> Job/Pub.pm:191] [/usr/local/bricolage/lib/Bric/Util/Job.pm:1889] [/
> usr/local/bricolage/bin/bric_queued:244] [/usr/local/bricolage/bin/
> bric_queued:213]
> ------------------------------------------------------------
>
> Line 1203 of Burner.pm looks like the first time the publish method
> tries to access the bric asset object, where it promptly dies. Is
> this a bug? Shouldn't the code be hardened to not pass incomplete/
> missing parameters to publish?
>
> Is there something we can do to have the SOAP command just grab the
> last published version, and not the checked-out version? I though
> Matt Rolf had figured this out at some point, but I can't find it in
> his notes, or my searches of the list archives and docs.
>
> The SOAP recipes page shows the use of a "checked_out" argument with
> the story module, and the API docs refer to a "no_workflow"
> argument, but I don't think that's what I want. I don't want to
> skip these stories, because that leaves an old version of them on
> the production servers - I want to make sure that every story gets
> published.
>
> -Aaron
>
> ---------------------------------
> Aaron Fuleki
> Senior Web Architect
> Denison University
> 740.587.5752
> ---------------------------------
>
>
>

Re: SOAP bug, or PEBKAC? [ In reply to ]

phillip at communitybandwidth

Sep 29, 2009, 6:06 AM

Post #3 of 14 (4755 views)

Permalink

Any luck on this issue, Aaron.

On 25-Sep-09, at 12:00 PM, Matt Rolf wrote:

> You might want to check out the bug lists - I'm 99% sure this is
> something that has been fixed, perhaps in 10.7, but that we didn't
> get around to patching on our install.
>
> But I could be wrong.
>
> -Mateo
>
> On Sep 25, 2009, at 10:56 AM, Aaron Fuleki wrote:
>
>> We recently tried the following SOAP command to republish all of
>> our staff bio/cv stories to reflect some template changes:
>>
>> ------------------------------------------------------------
>> /usr/local/bricolage/bin/bric_soap --username xxxx --password xxxx
>> --server https://freestyle.denison.edu story list_ids --search
>> "element_key_name=cv" --search "site=Denison University" --search
>> "publish_status=1" --search "unexpired=1" | /usr/local/bricolage/
>> bin/bric_soap --username xxxx --password xxxx --server https://freestyle.denison.edu
>> workflow --server https://freestyle.denison.edu publish --continue-
>> on-errors --published-only --chunks 1 -
>> ------------------------------------------------------------
>>
>> It worked great for 99% of the stories, except those that were
>> checked out and in a workflow. For those, we got the following
>> error:
>>
>> ------------------------------------------------------------
>> Can't call method "get_id" on an undefined value at /usr/local/
>> bricolage/lib/Bric/Util/Burner.pm line 1203. [/usr/local/bricolage/
>> lib/Bric/Util/Burner.pm:1203] [/usr/local/bricolage/lib/Bric/Util/
>> Job/Pub.pm:191] [/usr/local/bricolage/lib/Bric/Util/Job.pm:1889] [/
>> usr/local/bricolage/bin/bric_queued:244] [/usr/local/bricolage/bin/
>> bric_queued:213]
>> ------------------------------------------------------------
>>
>> Line 1203 of Burner.pm looks like the first time the publish method
>> tries to access the bric asset object, where it promptly dies. Is
>> this a bug? Shouldn't the code be hardened to not pass incomplete/
>> missing parameters to publish?
>>
>> Is there something we can do to have the SOAP command just grab the
>> last published version, and not the checked-out version? I though
>> Matt Rolf had figured this out at some point, but I can't find it
>> in his notes, or my searches of the list archives and docs.
>>
>> The SOAP recipes page shows the use of a "checked_out" argument
>> with the story module, and the API docs refer to a "no_workflow"
>> argument, but I don't think that's what I want. I don't want to
>> skip these stories, because that leaves an old version of them on
>> the production servers - I want to make sure that every story gets
>> published.
>>
>> -Aaron
>>
>> ---------------------------------
>> Aaron Fuleki
>> Senior Web Architect
>> Denison University
>> 740.587.5752
>> ---------------------------------
>>
>>
>>
>

--
Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
www.communitybandwidth.ca // www.phillipadsmith.com

Re: SOAP bug, or PEBKAC? [ In reply to ]

fulekia at denison

Oct 6, 2009, 1:42 PM

Post #4 of 14 (4735 views)

Permalink

Not yet. Hopefully we'll be up to 1.10.7 soon (this month), and I'll
see if it's still a problem.

-Aaron

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

On Sep 29, 2009, at 9:06 AM, Phillip Smith wrote:

>
> Any luck on this issue, Aaron.
>
> On 25-Sep-09, at 12:00 PM, Matt Rolf wrote:
>
>> You might want to check out the bug lists - I'm 99% sure this is
>> something that has been fixed, perhaps in 10.7, but that we didn't
>> get around to patching on our install.
>>
>> But I could be wrong.
>>
>> -Mateo
>>
>> On Sep 25, 2009, at 10:56 AM, Aaron Fuleki wrote:
>>
>>> We recently tried the following SOAP command to republish all of
>>> our staff bio/cv stories to reflect some template changes:
>>>
>>> ------------------------------------------------------------
>>> /usr/local/bricolage/bin/bric_soap --username xxxx --password xxxx
>>> --server https://freestyle.denison.edu story list_ids --search
>>> "element_key_name=cv" --search "site=Denison University" --search
>>> "publish_status=1" --search "unexpired=1" | /usr/local/bricolage/
>>> bin/bric_soap --username xxxx --password xxxx --server https://freestyle.denison.edu
>>> workflow --server https://freestyle.denison.edu publish --
>>> continue-on-errors --published-only --chunks 1 -
>>> ------------------------------------------------------------
>>>
>>> It worked great for 99% of the stories, except those that were
>>> checked out and in a workflow. For those, we got the following
>>> error:
>>>
>>> ------------------------------------------------------------
>>> Can't call method "get_id" on an undefined value at /usr/local/
>>> bricolage/lib/Bric/Util/Burner.pm line 1203. [/usr/local/bricolage/
>>> lib/Bric/Util/Burner.pm:1203] [/usr/local/bricolage/lib/Bric/Util/
>>> Job/Pub.pm:191] [/usr/local/bricolage/lib/Bric/Util/Job.pm:1889] [/
>>> usr/local/bricolage/bin/bric_queued:244] [/usr/local/bricolage/bin/
>>> bric_queued:213]
>>> ------------------------------------------------------------
>>>
>>> Line 1203 of Burner.pm looks like the first time the publish
>>> method tries to access the bric asset object, where it promptly
>>> dies. Is this a bug? Shouldn't the code be hardened to not pass
>>> incomplete/missing parameters to publish?
>>>
>>> Is there something we can do to have the SOAP command just grab
>>> the last published version, and not the checked-out version? I
>>> though Matt Rolf had figured this out at some point, but I can't
>>> find it in his notes, or my searches of the list archives and docs.
>>>
>>> The SOAP recipes page shows the use of a "checked_out" argument
>>> with the story module, and the API docs refer to a "no_workflow"
>>> argument, but I don't think that's what I want. I don't want to
>>> skip these stories, because that leaves an old version of them on
>>> the production servers - I want to make sure that every story gets
>>> published.
>>>
>>> -Aaron
>>>
>>> ---------------------------------
>>> Aaron Fuleki
>>> Senior Web Architect
>>> Denison University
>>> 740.587.5752
>>> ---------------------------------
>>>
>>>
>>>
>>
>
> --
> Phillip Smith // Simplifier of Technology // COMMUNITY
> BANDWIDTH
> www.communitybandwidth.ca // www.phillipadsmith.com
>
>
>
>
>
>
>

Re: SOAP bug, or PEBKAC? [ In reply to ]

fulekia at denison

Oct 14, 2009, 10:22 AM

Post #5 of 14 (4733 views)

Permalink

So, with David's help we upgraded to 1.10.7. This time I tried the
following SOAP command, in the hopes of successfully republishing all
previously published, non-expired, active "cv" stories in a particular
site, regardless of workflow status:

----------------------------------------------------------------------
/usr/local/bricolage/bin/bric_soap --username USERNAME --password
PASSWORD --server https://freestyle.denison.edu story list_ids --
search "element_key_name=cv" --search "site=Denison University" --
search "active=1" --search "published_version=1" --search
"publish_status=1" --search "unexpired=1" | /usr/local/bricolage/bin/
bric_soap --username USERNAME --password PASSWORD --server https://freestyle.denison.edu
workflow --server https://freestyle.denison.edu publish --continue-
on-errors --published-only --chunks 1 -
----------------------------------------------------------------------

This successfully republished all of our "cv" stories, including the
checked-out ones, and the correct versions no less, which had failed
before. However, stories that were checked out were removed from
their workflows, and left in a no-workflow-no-desk limbo state.
Touching the stories in the UI (e.g., viewing the story log) forces a
reassignment to a valid workflow and desk (browser said "Warning:
object BLAH had no associated workflow. It has been assigned to...").

So, did I do something wrong, i.e., are there other soap parameters
that would prevent this, but still work as described above? Should
SOAP functions that change workflows/desks be smart enough to change
them back, if it must do it at all?

-Aaron

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

On Oct 6, 2009, at 4:42 PM, Aaron Fuleki wrote:

> Not yet. Hopefully we'll be up to 1.10.7 soon (this month), and
> I'll see if it's still a problem.
>
> -Aaron
>
> ---------------------------------
> Aaron Fuleki
> Senior Web Architect
> Denison University
> 740.587.5752
> ---------------------------------
>
>
>
> On Sep 29, 2009, at 9:06 AM, Phillip Smith wrote:
>
>>
>> Any luck on this issue, Aaron.
>>
>> On 25-Sep-09, at 12:00 PM, Matt Rolf wrote:
>>
>>> You might want to check out the bug lists - I'm 99% sure this is
>>> something that has been fixed, perhaps in 10.7, but that we didn't
>>> get around to patching on our install.
>>>
>>> But I could be wrong.
>>>
>>> -Mateo
>>>
>>> On Sep 25, 2009, at 10:56 AM, Aaron Fuleki wrote:
>>>
>>>> We recently tried the following SOAP command to republish all of
>>>> our staff bio/cv stories to reflect some template changes:
>>>>
>>>> ------------------------------------------------------------
>>>> /usr/local/bricolage/bin/bric_soap --username xxxx --password
>>>> xxxx --server https://freestyle.denison.edu story list_ids --
>>>> search "element_key_name=cv" --search "site=Denison University" --
>>>> search "publish_status=1" --search "unexpired=1" | /usr/local/
>>>> bricolage/bin/bric_soap --username xxxx --password xxxx --server https://freestyle.denison.edu
>>>> workflow --server https://freestyle.denison.edu publish --
>>>> continue-on-errors --published-only --chunks 1 -
>>>> ------------------------------------------------------------
>>>>
>>>> It worked great for 99% of the stories, except those that were
>>>> checked out and in a workflow. For those, we got the following
>>>> error:
>>>>
>>>> ------------------------------------------------------------
>>>> Can't call method "get_id" on an undefined value at /usr/local/
>>>> bricolage/lib/Bric/Util/Burner.pm line 1203. [/usr/local/
>>>> bricolage/lib/Bric/Util/Burner.pm:1203] [/usr/local/bricolage/lib/
>>>> Bric/Util/Job/Pub.pm:191] [/usr/local/bricolage/lib/Bric/Util/
>>>> Job.pm:1889] [/usr/local/bricolage/bin/bric_queued:244] [/usr/
>>>> local/bricolage/bin/bric_queued:213]
>>>> ------------------------------------------------------------
>>>>
>>>> Line 1203 of Burner.pm looks like the first time the publish
>>>> method tries to access the bric asset object, where it promptly
>>>> dies. Is this a bug? Shouldn't the code be hardened to not pass
>>>> incomplete/missing parameters to publish?
>>>>
>>>> Is there something we can do to have the SOAP command just grab
>>>> the last published version, and not the checked-out version? I
>>>> though Matt Rolf had figured this out at some point, but I can't
>>>> find it in his notes, or my searches of the list archives and docs.
>>>>
>>>> The SOAP recipes page shows the use of a "checked_out" argument
>>>> with the story module, and the API docs refer to a "no_workflow"
>>>> argument, but I don't think that's what I want. I don't want to
>>>> skip these stories, because that leaves an old version of them on
>>>> the production servers - I want to make sure that every story
>>>> gets published.
>>>>
>>>> -Aaron
>>>>
>>>> ---------------------------------
>>>> Aaron Fuleki
>>>> Senior Web Architect
>>>> Denison University
>>>> 740.587.5752
>>>> ---------------------------------
>>>>
>>>>
>>>>
>>>
>>
>> --
>> Phillip Smith // Simplifier of Technology // COMMUNITY
>> BANDWIDTH
>> www.communitybandwidth.ca // www.phillipadsmith.com
>>
>>
>>
>>
>>
>>
>>
>

Re: SOAP bug, or PEBKAC? [ In reply to ]

bret at pectopah

Oct 14, 2009, 10:33 AM

Post #6 of 14 (4716 views)

Permalink

Hi Aaron,

It would be nice if there were powerful AI built into the publish
process, but there isn't, so you can really clobber a lot of stories if
you're not careful.

In general, it's a bad idea to use the API to publish a story somebody
else has checked out. Which means you really do need to pay attention to
workflow status when you're attempting a bulk operation like this.

One approach would be to add --search "checked_out=0" to your initial
list_ids pass, and get all the easy ones done.

Then you could repeat the search, looking only for the checked-out ones,
and check them in, move them to publish desks, and publish them after
that. Or you could use that list to hassle the people who have them
checked out.

Hope this helps,

Bret

On Wed, 2009-10-14 at 13:22 -0400, Aaron Fuleki wrote:
> So, with David's help we upgraded to 1.10.7. This time I tried the
> following SOAP command, in the hopes of successfully republishing all
> previously published, non-expired, active "cv" stories in a particular
> site, regardless of workflow status:
>
> ----------------------------------------------------------------------
> /usr/local/bricolage/bin/bric_soap --username USERNAME --password
> PASSWORD --server https://freestyle.denison.edu story list_ids --
> search "element_key_name=cv" --search "site=Denison University" --
> search "active=1" --search "published_version=1" --search
> "publish_status=1" --search "unexpired=1" | /usr/local/bricolage/bin/
> bric_soap --username USERNAME --password PASSWORD --server https://freestyle.denison.edu
> workflow --server https://freestyle.denison.edu publish --continue-
> on-errors --published-only --chunks 1 -
> ----------------------------------------------------------------------
>
> This successfully republished all of our "cv" stories, including the
> checked-out ones, and the correct versions no less, which had failed
> before. However, stories that were checked out were removed from
> their workflows, and left in a no-workflow-no-desk limbo state.
> Touching the stories in the UI (e.g., viewing the story log) forces a
> reassignment to a valid workflow and desk (browser said "Warning:
> object BLAH had no associated workflow. It has been assigned to...").
>
> So, did I do something wrong, i.e., are there other soap parameters
> that would prevent this, but still work as described above? Should
> SOAP functions that change workflows/desks be smart enough to change
> them back, if it must do it at all?
>
> -Aaron
>
> ---------------------------------
> Aaron Fuleki
> Senior Web Architect
> Denison University
> 740.587.5752
> ---------------------------------
>
>
>
> On Oct 6, 2009, at 4:42 PM, Aaron Fuleki wrote:
>
> > Not yet. Hopefully we'll be up to 1.10.7 soon (this month), and
> > I'll see if it's still a problem.
> >
> > -Aaron
> >
> > ---------------------------------
> > Aaron Fuleki
> > Senior Web Architect
> > Denison University
> > 740.587.5752
> > ---------------------------------
> >
> >
> >
> > On Sep 29, 2009, at 9:06 AM, Phillip Smith wrote:
> >
> >>
> >> Any luck on this issue, Aaron.
> >>
> >> On 25-Sep-09, at 12:00 PM, Matt Rolf wrote:
> >>
> >>> You might want to check out the bug lists - I'm 99% sure this is
> >>> something that has been fixed, perhaps in 10.7, but that we didn't
> >>> get around to patching on our install.
> >>>
> >>> But I could be wrong.
> >>>
> >>> -Mateo
> >>>
> >>> On Sep 25, 2009, at 10:56 AM, Aaron Fuleki wrote:
> >>>
> >>>> We recently tried the following SOAP command to republish all of
> >>>> our staff bio/cv stories to reflect some template changes:
> >>>>
> >>>> ------------------------------------------------------------
> >>>> /usr/local/bricolage/bin/bric_soap --username xxxx --password
> >>>> xxxx --server https://freestyle.denison.edu story list_ids --
> >>>> search "element_key_name=cv" --search "site=Denison University" --
> >>>> search "publish_status=1" --search "unexpired=1" | /usr/local/
> >>>> bricolage/bin/bric_soap --username xxxx --password xxxx --server https://freestyle.denison.edu
> >>>> workflow --server https://freestyle.denison.edu publish --
> >>>> continue-on-errors --published-only --chunks 1 -
> >>>> ------------------------------------------------------------
> >>>>
> >>>> It worked great for 99% of the stories, except those that were
> >>>> checked out and in a workflow. For those, we got the following
> >>>> error:
> >>>>
> >>>> ------------------------------------------------------------
> >>>> Can't call method "get_id" on an undefined value at /usr/local/
> >>>> bricolage/lib/Bric/Util/Burner.pm line 1203. [/usr/local/
> >>>> bricolage/lib/Bric/Util/Burner.pm:1203] [/usr/local/bricolage/lib/
> >>>> Bric/Util/Job/Pub.pm:191] [/usr/local/bricolage/lib/Bric/Util/
> >>>> Job.pm:1889] [/usr/local/bricolage/bin/bric_queued:244] [/usr/
> >>>> local/bricolage/bin/bric_queued:213]
> >>>> ------------------------------------------------------------
> >>>>
> >>>> Line 1203 of Burner.pm looks like the first time the publish
> >>>> method tries to access the bric asset object, where it promptly
> >>>> dies. Is this a bug? Shouldn't the code be hardened to not pass
> >>>> incomplete/missing parameters to publish?
> >>>>
> >>>> Is there something we can do to have the SOAP command just grab
> >>>> the last published version, and not the checked-out version? I
> >>>> though Matt Rolf had figured this out at some point, but I can't
> >>>> find it in his notes, or my searches of the list archives and docs.
> >>>>
> >>>> The SOAP recipes page shows the use of a "checked_out" argument
> >>>> with the story module, and the API docs refer to a "no_workflow"
> >>>> argument, but I don't think that's what I want. I don't want to
> >>>> skip these stories, because that leaves an old version of them on
> >>>> the production servers - I want to make sure that every story
> >>>> gets published.
> >>>>
> >>>> -Aaron
> >>>>
> >>>> ---------------------------------
> >>>> Aaron Fuleki
> >>>> Senior Web Architect
> >>>> Denison University
> >>>> 740.587.5752
> >>>> ---------------------------------
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >> --
> >> Phillip Smith // Simplifier of Technology // COMMUNITY
> >> BANDWIDTH
> >> www.communitybandwidth.ca // www.phillipadsmith.com
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
>
>
--
Bret Dawson
Producer
Pectopah Productions Inc.
(416) 895-7635
bret@pectopah.com
www.pectopah.com

Re: SOAP bug, or PEBKAC? [ In reply to ]

david at kineticode

Oct 14, 2009, 10:42 AM

Post #7 of 14 (4717 views)

Permalink

On Oct 14, 2009, at 10:33 AM, Bret Dawson wrote:

> One approach would be to add --search "checked_out=0" to your initial
> list_ids pass, and get all the easy ones done.

I highly recommend this. Also recommend `--search publish_status=1` so
as to avoid publishing something that's not yet ready to be published.
Oh, and pass `--published-only` to your call to `workflow publish`.

Best,

David

Re: SOAP bug, or PEBKAC? [ In reply to ]

rolf at ohio

Oct 14, 2009, 11:18 AM

Post #8 of 14 (4716 views)

Permalink

On Oct 14, 2009, at 1:33 PM, Bret Dawson wrote:

> In general, it's a bad idea to use the API to publish a story somebody
> else has checked out. Which means you really do need to pay
> attention to
> workflow status when you're attempting a bulk operation like this.

Absolutely. However, it should be smart enough to publish the non-
checked out, last published version of the story without messing stuff
up. I thought that was what published-only was supposed to do.

-Mateo

Re: SOAP bug, or PEBKAC? [ In reply to ]

rolf at ohio

Oct 14, 2009, 11:23 AM

Post #9 of 14 (4718 views)

Permalink

On Oct 14, 2009, at 1:42 PM, David E. Wheeler wrote:

> On Oct 14, 2009, at 10:33 AM, Bret Dawson wrote:
>
>> One approach would be to add --search "checked_out=0" to your initial
>> list_ids pass, and get all the easy ones done.
>
> Oh, and pass `--published-only` to your call to `workflow publish`.

And it looks like they did that last part.

But if you do checked_out=0, how else are you supposed to, say,
publish a template change to every page on your site if Bricolage
can't successfully publish previously published versions of documents
people are working on? For sites of Denison's size, it's unrealistic
to try and go remove every page that's being editted from workflows.

-Mateo

Re: SOAP bug, or PEBKAC? [ In reply to ]

david at kineticode

Oct 14, 2009, 11:28 AM

Post #10 of 14 (4712 views)

Permalink

On Oct 14, 2009, at 11:23 AM, Matt Rolf wrote:

>> Oh, and pass `--published-only` to your call to `workflow publish`.
>
> And it looks like they did that last part.

Yes, which means it will only publish stories that have been published
before.

> But if you do checked_out=0, how else are you supposed to, say,
> publish a template change to every page on your site if Bricolage
> can't successfully publish previously published versions of
> documents people are working on? For sites of Denison's size, it's
> unrealistic to try and go remove every page that's being editted
> from workflows.

Clearly there needs to be a `--published-version` parameter for
`workflow publish`. Anyone want to add it? It should probably be in
bric_republish, too.

Best,

David

Re: SOAP bug, or PEBKAC? [ In reply to ]

bret at pectopah

Oct 14, 2009, 12:01 PM

Post #11 of 14 (4722 views)

Permalink

On Wed, 2009-10-14 at 11:28 -0700, David E. Wheeler wrote:
> Clearly there needs to be a `--published-version` parameter for
> `workflow publish`. Anyone want to add it? It should probably be in
> bric_republish, too.

Unless I'm misreading something, it's already in bric_republish. Or,
rather, bric_republish only ever publishes published versions.

Can you pass a whole list of IDs to bric_republish? Or does it only like
one at a time?

Talk to you soon,

Bret

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

Re: SOAP bug, or PEBKAC? [ In reply to ]

fulekia at denison

Oct 15, 2009, 7:25 AM

Post #12 of 14 (4722 views)

Permalink

So, what's the consensus on best practice here? Can we currently do
what my initial post asked? That is, programatically republish all
published assets, grabbing the last published version if one is
checked out?

As Matt said, this is pretty critical to maintaining the integrity of
a complex site, and I don't think manual exception handling is a
reasonable expectation.

-Aaron

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

On Oct 14, 2009, at 3:01 PM, Bret Dawson wrote:

> On Wed, 2009-10-14 at 11:28 -0700, David E. Wheeler wrote:
>> Clearly there needs to be a `--published-version` parameter for
>> `workflow publish`. Anyone want to add it? It should probably be in
>> bric_republish, too.
>
> Unless I'm misreading something, it's already in bric_republish. Or,
> rather, bric_republish only ever publishes published versions.
>
> Can you pass a whole list of IDs to bric_republish? Or does it only
> like
> one at a time?
>
>
> Talk to you soon,
>
> Bret
>
>
>
>
> --
> Bret Dawson
> Producer
> Pectopah Productions Inc.
> (416) 895-7635
> bret@pectopah.com
> www.pectopah.com
>

Re: SOAP bug, or PEBKAC? [ In reply to ]

david at kineticode

Oct 15, 2009, 12:03 PM

Post #13 of 14 (4714 views)

Permalink

On Oct 15, 2009, at 7:25 AM, Aaron Fuleki wrote:

> So, what's the consensus on best practice here? Can we currently do
> what my initial post asked? That is, programatically republish all
> published assets, grabbing the last published version if one is
> checked out?

Yes, you should be able to. The first call to bric_soap, with `story
list_ids`, should have `--search publish_status=1" and the second call
to bric_soap, with `workflow publish`, should have `--published_only`.

If that's not working properly, it's a bug.

Best,

David

Re: SOAP bug, or PEBKAC? [ In reply to ]

david at kineticode

Oct 15, 2009, 12:04 PM

Post #14 of 14 (4704 views)

Permalink

On Oct 14, 2009, at 12:01 PM, Bret Dawson wrote:

> Unless I'm misreading something, it's already in bric_republish. Or,
> rather, bric_republish only ever publishes published versions.

Correct.

> Can you pass a whole list of IDs to bric_republish? Or does it only
> like
> one at a time?

No, it republishes *everything*.

Best,

David