bret at pectopah
Oct 14, 2009, 10:33 AM
Post #6 of 14
(243 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[at]pectopah.com
www.pectopah.com
|
