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

Mailing List Archive: Bricolage: users

SOAP bug, or PEBKAC?

 

 

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


fulekia at denison

Sep 25, 2009, 7:56 AM

Post #1 of 14 (2167 views)
Permalink
SOAP bug, or PEBKAC?

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
---------------------------------


rolf at ohio

Sep 25, 2009, 8:00 AM

Post #2 of 14 (2095 views)
Permalink
Re: SOAP bug, or PEBKAC? [In reply to]

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 at communitybandwidth

Sep 29, 2009, 6:06 AM

Post #3 of 14 (2091 views)
Permalink
Re: SOAP bug, or PEBKAC? [In reply to]

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


fulekia at denison

Oct 6, 2009, 1:42 PM

Post #4 of 14 (2060 views)
Permalink
Re: SOAP bug, or PEBKAC? [In reply to]

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
>
>
>
>
>
>
>


fulekia at denison

Oct 14, 2009, 10:22 AM

Post #5 of 14 (2047 views)
Permalink
Re: SOAP bug, or PEBKAC? [In reply to]

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 at pectopah

Oct 14, 2009, 10:33 AM

Post #6 of 14 (2045 views)
Permalink
Re: SOAP bug, or PEBKAC? [In reply to]

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 [at] pectopah
www.pectopah.com


david at kineticode

Oct 14, 2009, 10:42 AM

Post #7 of 14 (2041 views)
Permalink
Re: SOAP bug, or PEBKAC? [In reply to]

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


rolf at ohio

Oct 14, 2009, 11:18 AM

Post #8 of 14 (2039 views)
Permalink
Re: SOAP bug, or PEBKAC? [In reply to]

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


rolf at ohio

Oct 14, 2009, 11:23 AM

Post #9 of 14 (2040 views)
Permalink
Re: SOAP bug, or PEBKAC? [In reply to]

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


david at kineticode

Oct 14, 2009, 11:28 AM

Post #10 of 14 (2036 views)
Permalink
Re: SOAP bug, or PEBKAC? [In reply to]

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


bret at pectopah

Oct 14, 2009, 12:01 PM

Post #11 of 14 (2043 views)
Permalink
Re: SOAP bug, or PEBKAC? [In reply to]

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 [at] pectopah
www.pectopah.com


fulekia at denison

Oct 15, 2009, 7:25 AM

Post #12 of 14 (2046 views)
Permalink
Re: SOAP bug, or PEBKAC? [In reply to]

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 [at] pectopah
> www.pectopah.com
>


david at kineticode

Oct 15, 2009, 12:03 PM

Post #13 of 14 (2033 views)
Permalink
Re: SOAP bug, or PEBKAC? [In reply to]

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


david at kineticode

Oct 15, 2009, 12:04 PM

Post #14 of 14 (2041 views)
Permalink
Re: SOAP bug, or PEBKAC? [In reply to]

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

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.