Mailing List Archive: Bricolage: devel

ingesting new stories from alternative CMSes

1 2

View All

Index | Next | Previous | View Threaded

john.durkin at gmail

Jan 27, 2009, 12:14 PM

Post #1 of 26 (8468 views)
Permalink

ingesting new stories from alternative CMSes

I'm working on a perl program to run on the cron that will regularly sweep
my user/blogger's tumblr accounts checking for new or updated posts by
looking at the XML located at http://username.tumblr.com/api/read. Then,
using bric_soap, the script will create media objects in bric for any media
found in the post, then it will create stories for each new posts in bric,
populate them with proper tags and related media, and publish these new
stories to the site.

It seems crazy - but I think it's going to help my users a lot. They will be
able to post via iphone and gphone, other mobile phone browsers, and they
can post stories without getting confused about pictures. I would love to
fix the bric interface and add all these features to bric, but I think I can
make the tumblr ingestor fairly quickly and that way jump around many of the
interface issues my users have with bric, by letting them use tumblr as an
alternative blogging interface.

Has anyone else done something like this?

JD

greg at node79

Jan 27, 2009, 12:40 PM

Post #2 of 26 (8363 views)
Permalink

Re: ingesting new stories from alternative CMSes [In reply to]

Hi John,

I did something similar here:
http://blog.newint.org/cantankerousfrank/

The cartoonist has his own blog hosted at blogspot. I set up a Perl
script to parse the Atom feed, look for new posts, grab the cartoon
image, and do the bric_soap work. It sounds simpler than what you're
looking to do since I didn't have to deal with the text of the post,
just the linked image.

The bric_soap process is done in two steps: one to do the media create
(base64 encode the image data), and one for the story create. The
media create returns the media ID, which I then put into the
appropriate related media element in the story.

The reasoning behind this is different, as the folks at New
Internationalist are just syndicating the content, not trying to
provide an alternate interface to Bricolage. Still, it's been working
smoothly for over a month now and is definitely possible.

cheers,
-Greg

On 27-Jan-09, at 3:14 PM, John Durkin wrote:

> I'm working on a perl program to run on the cron that will regularly
> sweep
> my user/blogger's tumblr accounts checking for new or updated posts by
> looking at the XML located at http://username.tumblr.com/api/read.
> Then,
> using bric_soap, the script will create media objects in bric for
> any media
> found in the post, then it will create stories for each new posts in
> bric,
> populate them with proper tags and related media, and publish these
> new
> stories to the site.
>
> Has anyone else done something like this?
>
> JD

---
Greg Heo
web/software systems developer
greg [at] node79
416.826.7630

david at kineticode

Jan 27, 2009, 7:51 PM

Post #3 of 26 (8351 views)
Permalink

Re: ingesting new stories from alternative CMSes [In reply to]

On Jan 27, 2009, at 12:40 PM, Greg Heo wrote:

> The bric_soap process is done in two steps: one to do the media
> create (base64 encode the image data), and one for the story create.
> The media create returns the media ID, which I then put into the
> appropriate related media element in the story.

You can actually put both the media document and the story in the same
XML file and create them both at once, including the related media
element in the story pointing to the media document. Want to know what
it looks like? Export an existing story with a single related media
document (preferably something small) using bric_soap --with-related-
media. Then use that as the model for the XML you generate.

> The reasoning behind this is different, as the folks at New
> Internationalist are just syndicating the content, not trying to
> provide an alternate interface to Bricolage. Still, it's been
> working smoothly for over a month now and is definitely possible.

Nice.

Best,

David

greg at node79

Jan 27, 2009, 7:59 PM

Post #4 of 26 (8378 views)
Permalink

Re: ingesting new stories from alternative CMSes [In reply to]

On 27-Jan-09, at 10:51 PM, David E. Wheeler wrote:

> You can actually put both the media document and the story in the
> same XML file and create them both at once, including the related
> media element in the story pointing to the media document. Want to
> know what it looks like? Export an existing story with a single
> related media document (preferably something small) using bric_soap
> --with-related-media. Then use that as the model for the XML you
> generate.

I did the --with-related-media originally to see how the media XML
should be structured. From what I remember, the <story> comes first
and has the related_media_id filled in and is followed by the <media>.

For a new story+media combo though, how does this work? I figured the
media has to exist already so you can put its ID inside <story>. Is
there some way to skip the ID but flag it somehow to say the media
document follows and should be related?

david at kineticode

Jan 27, 2009, 11:15 PM

Post #5 of 26 (8336 views)
Permalink

Re: ingesting new stories from alternative CMSes [In reply to]

On Jan 27, 2009, at 7:59 PM, Greg Heo wrote:

> I did the --with-related-media originally to see how the media XML
> should be structured. From what I remember, the <story> comes first
> and has the related_media_id filled in and is followed by the <media>.
>
> For a new story+media combo though, how does this work? I figured
> the media has to exist already so you can put its ID inside <story>.
> Is there some way to skip the ID but flag it somehow to say the
> media document follows and should be related?

No, you have to use placeholder IDs within your XML. Bricolage will
give the documents new IDs, but use the IDs you put into your XML file
to create the proper relationships. IIRC, it doesn't matter which
comes first, but it might be that the related hast to come before the
relatee. I can't remember, though; give it a try!

Best,

David

john.durkin at gmail

Jan 28, 2009, 11:16 AM

Post #6 of 26 (8343 views)
Permalink

Re: ingesting new stories from alternative CMSes [In reply to]

This sounds like it will make the process much easier, but I'm not sure I
understand.... Using bric_soap, do a create_story --with-related-media using
an XML document that refers to both story and media (as seen from exporting
a story with a media), and then for it's ID I just make any old ID up that
is consistent within my XML document in referring to the media?

can the media be grabbed directly from its url or do i need to grab it and
save it locally first, then in my xml point to its local path? or can it
remain at its web url?

On Tue, Jan 27, 2009 at 11:15 PM, David E. Wheeler <david [at] kineticode>wrote:

> On Jan 27, 2009, at 7:59 PM, Greg Heo wrote:
>
> I did the --with-related-media originally to see how the media XML should
>> be structured. From what I remember, the <story> comes first and has the
>> related_media_id filled in and is followed by the <media>.
>>
>> For a new story+media combo though, how does this work? I figured the
>> media has to exist already so you can put its ID inside <story>. Is there
>> some way to skip the ID but flag it somehow to say the media document
>> follows and should be related?
>>
>
> No, you have to use placeholder IDs within your XML. Bricolage will give
> the documents new IDs, but use the IDs you put into your XML file to create
> the proper relationships. IIRC, it doesn't matter which comes first, but it
> might be that the related hast to come before the relatee. I can't remember,
> though; give it a try!
>
> Best,
>
> David
>
>

greg at node79

Jan 28, 2009, 11:46 AM

Post #7 of 26 (8343 views)
Permalink

Re: ingesting new stories from alternative CMSes [In reply to]

On 28-Jan-09, at 2:16 PM, John Durkin wrote:

> Using bric_soap, do a create_story --with-related-media using
> an XML document that refers to both story and media (as seen from
> exporting
> a story with a media), and then for it's ID I just make any old ID
> up that
> is consistent within my XML document in referring to the media?

That sounds right. As David mentioned, the media might have to come
first in the combined XML file.

Normally if you're creating new assets you leave the ID field blank
since Bricolage assigns it. The big trick here is that you'll need to
put *something* into the media ID that matches what you put into the
story element's related_media_id attribute. Whatever this ID is won't
used once bric_soap is finished.

> can the media be grabbed directly from its url or do i need to grab
> it and
> save it locally first, then in my xml point to its local path? or
> can it
> remain at its web url?

The media goes right into the XML as base64-encoded data. So you'll
need it on disk, in memory, etc. for your script to encode it before
writing out the XML. I used HTTP::Request to fetch the JPEG and
base64_encode it in core rather than writing out to a temp file.

-Greg

david at kineticode

Jan 28, 2009, 11:46 AM

Post #8 of 26 (8349 views)
Permalink

Re: ingesting new stories from alternative CMSes [In reply to]

On Jan 28, 2009, at 11:16 AM, John Durkin wrote:

> This sounds like it will make the process much easier, but I'm not
> sure I
> understand.... Using bric_soap, do a create_story --with-related-
> media using
> an XML document that refers to both story and media (as seen from
> exporting
> a story with a media), and then for it's ID I just make any old ID
> up that
> is consistent within my XML document in referring to the media?

Yes, although I'm not sure you need `--with-related-media` when you're
creating your story and media document. I know you need it to export a
story with related media, but IIRC you don't need it when updating or
creating. Or maybe you do. I can't remember for sure.

> can the media be grabbed directly from its url or do i need to grab
> it and
> save it locally first, then in my xml point to its local path? or
> can it
> remain at its web url?

You need to put it into the XML base-64 encoded.

Best,

David

john.durkin at gmail

Jan 28, 2009, 1:46 PM

Post #9 of 26 (8352 views)
Permalink

Re: ingesting new stories from alternative CMSes [In reply to]

Thanks guys - I'm gonna give it a go.

On Wed, Jan 28, 2009 at 11:46 AM, David E. Wheeler <david [at] kineticode>wrote:

> On Jan 28, 2009, at 11:16 AM, John Durkin wrote:
>
> This sounds like it will make the process much easier, but I'm not sure I
>> understand.... Using bric_soap, do a create_story --with-related-media
>> using
>> an XML document that refers to both story and media (as seen from
>> exporting
>> a story with a media), and then for it's ID I just make any old ID up that
>> is consistent within my XML document in referring to the media?
>>
>
> Yes, although I'm not sure you need `--with-related-media` when you're
> creating your story and media document. I know you need it to export a story
> with related media, but IIRC you don't need it when updating or creating. Or
> maybe you do. I can't remember for sure.
>
> can the media be grabbed directly from its url or do i need to grab it and
>> save it locally first, then in my xml point to its local path? or can it
>> remain at its web url?
>>
>
> You need to put it into the XML base-64 encoded.
>
> Best,
>
> David
>
>

john.durkin at gmail

Feb 23, 2009, 1:36 PM

Post #10 of 26 (7980 views)
Permalink

Re: ingesting new stories from alternative CMSes [In reply to]

So, this tumblr ingest idea turned out to be harder than I thought, not
because of bricolage, but because of a few critical shortcomings on tumblr's
part. for instance, some post types on tumblr, notably video and image
posts, DON'T HAVE TITLES. it's not that you aren't *required* to put a
title, you actually just CAN'T! This means that if one of my users want to
create an image or video post, he can only fill in a text caption field.
This means that I could just tell my users to only create "regular" type
posts. The problem here is that for pics - the only type of post that allows
you to have tumblr (temporarily) host the pic is to do a "photo" type post,
which leaves you with no title. In a regular post you can add pics, but they
need to reside on the web somewhere already and you enter the url. That's
not quick or easy (for my users).

So then I've been looking at wordpress. I must say I'm impressed with it.
It's come a really long way since last time I checked. I've set up an
installation of it on the same server as my bric install, and I am
considering using it as an alternative front end. You would post through
your WP account, then i would have a program on the cron that checks the wp
mysql db for new items and makes entries in a new table, "imports," which
would keep track of which wp posts have been successfully imported. The
cron'd script would then create bric-soap XML to be used to recreate the wp
stories in bric, import them, and publish them.

There are some difficulties. how would a user entering a post through wp be
able to properly "preview" his story?

Then I also start to wonder - am I doing something with bricolage that I
*can't* do with WP? This is a hard one. Probably there is nothing I *can't*
do in wp with a some custom modifications... but of course, I don't really
want to do.

My main problem with bric always comes down to the user interface. It it
obviously fine for me; I'm a programmer who's been working with bric for
years... but let's be honest, it's glitchy, incomplete, error prone, too
many windows popping up everywhere, and too many options that basic users
just don't really even need to know about.

I don't want to scrap bric. I can only hope that many of these interface
problems will be repaired in the 2.0 release. When is that due out?

On Wed, Jan 28, 2009 at 1:46 PM, John Durkin <john.durkin [at] gmail> wrote:

> Thanks guys - I'm gonna give it a go.
>
> On Wed, Jan 28, 2009 at 11:46 AM, David E. Wheeler <david [at] kineticode>wrote:
>
>> On Jan 28, 2009, at 11:16 AM, John Durkin wrote:
>>
>> This sounds like it will make the process much easier, but I'm not sure I
>>> understand.... Using bric_soap, do a create_story --with-related-media
>>> using
>>> an XML document that refers to both story and media (as seen from
>>> exporting
>>> a story with a media), and then for it's ID I just make any old ID up
>>> that
>>> is consistent within my XML document in referring to the media?
>>>
>>
>> Yes, although I'm not sure you need `--with-related-media` when you're
>> creating your story and media document. I know you need it to export a story
>> with related media, but IIRC you don't need it when updating or creating. Or
>> maybe you do. I can't remember for sure.
>>
>> can the media be grabbed directly from its url or do i need to grab it
>>> and
>>> save it locally first, then in my xml point to its local path? or can it
>>> remain at its web url?
>>>
>>
>> You need to put it into the XML base-64 encoded.
>>
>> Best,
>>
>> David
>>
>>
>

rolfm at denison

Feb 24, 2009, 9:53 AM

Post #11 of 26 (7967 views)
Permalink

Re: ingesting new stories from alternative CMSes [In reply to]

On Feb 23, 2009, at 4:36 PM, John Durkin wrote:

> I don't want to scrap bric. I can only hope that many of these
> interface
> problems will be repaired in the 2.0 release. When is that due out?

Like I told Phillip on IRC last night - I'm rolling out Bricolage2 at
Denison this summer come hell or high water. Therefore, my interest
is keen on fixing as many bugs as possible before that time.

If you look at the bug list, there really aren't too many in there for
2.0 right now. A few of the javascript variety, but nothing that I'd
say is of the OMG variety. In trunk (not the 1.11.1 release) there
are some install bugs that need squashed, and those are really the
worst of them I'd say.

I'm assuming the Gossamer Threads work won't be making it in to 2.0?
Not sure where that stands (sorry for not slogging through all those
threads). But now that I'm (mostly) away from template development,
I'm going to be working totally on bug fixes for 2.0 so that we can
roll with 2.0 this summer. Help from others in closing and reporting
bugs in the development release is most welcome.

We'll work to get as many javascript bugs fixed as we can in the next
couple weeks. If someone could take a look at the install bugs and
maybe the Desk Story corruption bug in 1388, then it might be time for
an RC.

-Matt

david at kineticode

Feb 24, 2009, 10:52 AM

Post #12 of 26 (7957 views)
Permalink

Re: ingesting new stories from alternative CMSes [In reply to]

On Feb 24, 2009, at 9:53 AM, Matt Rolf wrote:

> Like I told Phillip on IRC last night - I'm rolling out Bricolage2
> at Denison this summer come hell or high water. Therefore, my
> interest is keen on fixing as many bugs as possible before that time.
>
> If you look at the bug list, there really aren't too many in there
> for 2.0 right now. A few of the javascript variety, but nothing
> that I'd say is of the OMG variety. In trunk (not the 1.11.1
> release) there are some install bugs that need squashed, and those
> are really the worst of them I'd say.

And I'll get to looking at some of these during March. No, *really*!

> I'm assuming the Gossamer Threads work won't be making it in to
> 2.0? Not sure where that stands (sorry for not slogging through all
> those threads). But now that I'm (mostly) away from template
> development, I'm going to be working totally on bug fixes for 2.0 so
> that we can roll with 2.0 this summer. Help from others in closing
> and reporting bugs in the development release is most welcome.

I expect the GS stuff will be added to 2.2.

> We'll work to get as many javascript bugs fixed as we can in the
> next couple weeks. If someone could take a look at the install bugs
> and maybe the Desk Story corruption bug in 1388, then it might be
> time for an RC.

Matt, have these been reported?

* In a new instance, I sometimes get an error in the autocomplete for
the primary category in the New Story interface. It drops down as an
error, which is kind of funky.

* In a Find Stories panel, with Advanced enabled, if I type something
in and hit return instead of click the "Search" button, the form is
submitted but reloads empty and with no results, as if I hadn't
searched at all.

If not, I can file them. The second one is similar to something I
fixed a while ago for 1.10 (or was it 1.8?), and obviously just needs
to be done again for the revamped search interface in 2.0.

Thanks,

David

david at kineticode

Feb 24, 2009, 10:56 AM

Post #13 of 26 (7947 views)
Permalink

Re: ingesting new stories from alternative CMSes [In reply to]

On Feb 23, 2009, at 1:36 PM, John Durkin wrote:

> So, this tumblr ingest idea turned out to be harder than I thought,
> not
> because of bricolage, but because of a few critical shortcomings on
> tumblr's
> part. for instance, some post types on tumblr, notably video and image
> posts, DON'T HAVE TITLES. it's not that you aren't *required* to put a
> title, you actually just CAN'T! This means that if one of my users
> want to
> create an image or video post, he can only fill in a text caption
> field.
> This means that I could just tell my users to only create "regular"
> type
> posts. The problem here is that for pics - the only type of post
> that allows
> you to have tumblr (temporarily) host the pic is to do a "photo"
> type post,
> which leaves you with no title. In a regular post you can add pics,
> but they
> need to reside on the web somewhere already and you enter the url.
> That's
> not quick or easy (for my users).

FAIL.

> So then I've been looking at wordpress. I must say I'm impressed
> with it.
> It's come a really long way since last time I checked. I've set up an
> installation of it on the same server as my bric install, and I am
> considering using it as an alternative front end. You would post
> through
> your WP account, then i would have a program on the cron that checks
> the wp
> mysql db for new items and makes entries in a new table, "imports,"
> which
> would keep track of which wp posts have been successfully imported.
> The
> cron'd script would then create bric-soap XML to be used to recreate
> the wp
> stories in bric, import them, and publish them.

With such an arrangement, what purpose is Bricolage serving?

> There are some difficulties. how would a user entering a post
> through wp be
> able to properly "preview" his story?

Oh, you mean WP would be a front-end for editors *creating* content,
not for serving it?

> Then I also start to wonder - am I doing something with bricolage
> that I
> *can't* do with WP? This is a hard one. Probably there is nothing I
> *can't*
> do in wp with a some custom modifications... but of course, I don't
> really
> want to do.

I don't know, not being familiar with WP. Does it have workflow and
permissions stuff? Templating to output anything you want? If not, do
you need those things? Those are the crucial types of questions.

> My main problem with bric always comes down to the user interface.
> It it
> obviously fine for me; I'm a programmer who's been working with bric
> for
> years... but let's be honest, it's glitchy, incomplete, error prone,
> too
> many windows popping up everywhere, and too many options that basic
> users
> just don't really even need to know about.

2.0 is better, though now there are even more windows popping up. It's
a feature, though, honest! ;-)

> I don't want to scrap bric. I can only hope that many of these
> interface
> problems will be repaired in the 2.0 release. When is that due out?

I'm thinking April now. But if Matt fixes all the bus sooner than I
get to them, maybe sooner�

Best,

David

rolfm at denison

Feb 24, 2009, 10:58 AM

Post #14 of 26 (7942 views)
Permalink

Re: ingesting new stories from alternative CMSes [In reply to]

On Feb 24, 2009, at 1:52 PM, David E. Wheeler wrote:

> Matt, have these been reported?
>
> * In a new instance, I sometimes get an error in the autocomplete
> for the primary category in the New Story interface. It drops down
> as an error, which is kind of funky.
>
> * In a Find Stories panel, with Advanced enabled, if I type
> something in and hit return instead of click the "Search" button,
> the form is submitted but reloads empty and with no results, as if I
> hadn't searched at all.
>
> If not, I can file them. The second one is similar to something I
> fixed a while ago for 1.10 (or was it 1.8?), and obviously just
> needs to be done again for the revamped search interface in 2.0.

No, those need to be filed.

david at kineticode

Feb 24, 2009, 3:37 PM

Post #15 of 26 (7943 views)
Permalink

Re: ingesting new stories from alternative CMSes [In reply to]

On Feb 24, 2009, at 10:58 AM, Matt Rolf wrote:

>> If not, I can file them. The second one is similar to something I
>> fixed a while ago for 1.10 (or was it 1.8?), and obviously just
>> needs to be done again for the revamped search interface in 2.0.
>
> No, those need to be filed.

Thanks, done in #1424 and #1425.

Best,

David

john.durkin at gmail

Feb 25, 2009, 5:59 PM

Post #16 of 26 (7899 views)
Permalink

Re: ingesting new stories from alternative CMSes [In reply to]

So I'm just seconds away from having imports from tumblr working. I do
actually have it working but not with a related image (or audio probably).

first, I have a perl script that checks my users' tumblr accounts. It
updates a mysql db with the data from an unimported tumblr post and sets its
status to 0, or if it's already in the mysql database and the info from
tumblr is now different, it updates it and sets the status to 2. (0 =waiting
/ 1=done / 2=changed)

next, I have a perl script that checks the mysql table for new or updated
import items per user. it creates one xml file per user containing the story
data and media data suitable for a bric_soap create command.

my (hopefully final) hurdle is this error i get when trying to create a
story that has a related media item.

please advise on this if anyone has any idea what I've done wrong. I've
attached the XML file I'm trying to use. The error I get is below... the
weird thing about it is that somehow in the process
Bric::SOAP::Media::list_ids gets called and says it can't find a category
matching "", site => "100" - but everywhere I can set a category I do, and
it's set to "/ti/". Looks like the correct category parameters are not being
passed successfully to Bric::SOAP::Media::list_ids.

Use of uninitialized value in exists at
/usr/local/bricolage/lib/Bric/SOAP/Story.pm line 770, <GEN3257> line 19.
Use of uninitialized value in hash element at
/usr/local/bricolage/lib/Bric/SOAP/Story.pm line 1101, <GEN3257> line 19.
Use of uninitialized value in concatenation (.) or string at
/usr/local/bricolage/lib/Bric/SOAP/Util.pm line 93, <GEN3257> line 19.
[Thu Feb 26 01:49:57 2009] [error] SOAP::Serializer::envelope: Server
Application error Bric::SOAP::Media::list_ids: no category found matching
(category => "", site =>
"100")\n[/usr/local/bricolage/lib/Bric/SOAP/Util.pm:93]\n[/usr/local/bricolage/lib/Bric/SOAP/Media.pm:717]\n[/usr/local/bricolage/lib/Bric/SOAP/Story.pm:1110]\n[/usr/local/bricolage/lib/Bric/SOAP/Asset.pm:246]\n[/Library/Perl/5.8.8/SOAP/Lite.pm:2744]\n[/Library/Perl/5.8.8/SOAP/Transport/HTTP.pm:394]\n[/Library/Perl/5.8.8/SOAP/Transport/HTTP.pm:717]\n[/usr/local/bricolage/lib/Bric/SOAP/Handler.pm:175]\n[-e:0]
[/usr/local/bricolage/lib/Bric/SOAP/Handler.pm:256]
[/Library/Perl/5.8.8/SOAP/Lite.pm:2838]
[/Library/Perl/5.8.8/SOAP/Lite.pm:1550]
[/Library/Perl/5.8.8/SOAP/Lite.pm:746]
[/Library/Perl/5.8.8/SOAP/Lite.pm:2802]
[/Library/Perl/5.8.8/SOAP/Transport/HTTP.pm:406]
[/Library/Perl/5.8.8/SOAP/Lite.pm:2795]
[/Library/Perl/5.8.8/SOAP/Transport/HTTP.pm:394]
[/Library/Perl/5.8.8/SOAP/Transport/HTTP.pm:717]
[/usr/local/bricolage/lib/Bric/SOAP/Handler.pm:175]
[-e:0]

On Tue, Feb 24, 2009 at 3:37 PM, David E. Wheeler <david [at] kineticode>wrote:

> On Feb 24, 2009, at 10:58 AM, Matt Rolf wrote:
>
> If not, I can file them. The second one is similar to something I fixed a
>>> while ago for 1.10 (or was it 1.8?), and obviously just needs to be done
>>> again for the revamped search interface in 2.0.
>>>
>>
>> No, those need to be filed.
>>
>
> Thanks, done in #1424 and #1425.
>
> Best,
>
> David
>

Attachments:

jdurkin.xml (57.6 KB)

david at kineticode

Feb 26, 2009, 9:05 AM

Post #17 of 26 (7887 views)
Permalink

Re: ingesting new stories from alternative CMSes [In reply to]

On Feb 25, 2009, at 5:59 PM, John Durkin wrote:

> Use of uninitialized value in exists at
> /usr/local/bricolage/lib/Bric/SOAP/Story.pm line 770, <GEN3257> line
> 19.
> Use of uninitialized value in hash element at
> /usr/local/bricolage/lib/Bric/SOAP/Story.pm line 1101, <GEN3257>
> line 19.
> Use of uninitialized value in concatenation (.) or string at
> /usr/local/bricolage/lib/Bric/SOAP/Util.pm line 93, <GEN3257> line 19.
> [Thu Feb 26 01:49:57 2009] [error] SOAP::Serializer::envelope: Server
> Application error Bric::SOAP::Media::list_ids: no category found
> matching
> (category => "", site =>
> "100")\n[/usr/local/bricolage/lib/Bric/SOAP/Util.pm:93]\n[/usr/local/
> bricolage/lib/Bric/SOAP/Media.pm:717]\n[/usr/local/bricolage/lib/
> Bric/SOAP/Story.pm:1110]\n[/usr/local/bricolage/lib/Bric/SOAP/
> Asset.pm:246]\n[/Library/Perl/5.8.8/SOAP/Lite.pm:2744]\n[/Library/
> Perl/5.8.8/SOAP/Transport/HTTP.pm:394]\n[/Library/Perl/5.8.8/SOAP/
> Transport/HTTP.pm:717]\n[/usr/local/bricolage/lib/Bric/SOAP/
> Handler.pm:175]\n[-e:0]

Can you send in the XML you're trying to import? It's not finding a
story ID or a category URI for some reason.

Best,

David

john.durkin at gmail

Feb 26, 2009, 10:03 AM

Post #18 of 26 (7876 views)
Permalink

Re: ingesting new stories from alternative CMSes [In reply to]

attached - jdurkin.xml

On Thu, Feb 26, 2009 at 9:05 AM, David E. Wheeler <david [at] kineticode>wrote:

> On Feb 25, 2009, at 5:59 PM, John Durkin wrote:
>
> Use of uninitialized value in exists at
>> /usr/local/bricolage/lib/Bric/SOAP/Story.pm line 770, <GEN3257> line 19.
>> Use of uninitialized value in hash element at
>> /usr/local/bricolage/lib/Bric/SOAP/Story.pm line 1101, <GEN3257> line 19.
>> Use of uninitialized value in concatenation (.) or string at
>> /usr/local/bricolage/lib/Bric/SOAP/Util.pm line 93, <GEN3257> line 19.
>> [Thu Feb 26 01:49:57 2009] [error] SOAP::Serializer::envelope: Server
>> Application error Bric::SOAP::Media::list_ids: no category found matching
>> (category => "", site =>
>>
>> "100")\n[/usr/local/bricolage/lib/Bric/SOAP/Util.pm:93]\n[/usr/local/bricolage/lib/Bric/SOAP/Media.pm:717]\n[/usr/local/bricolage/lib/Bric/SOAP/Story.pm:1110]\n[/usr/local/bricolage/lib/Bric/SOAP/Asset.pm:246]\n[/Library/Perl/5.8.8/SOAP/Lite.pm:2744]\n[/Library/Perl/5.8.8/SOAP/Transport/HTTP.pm:394]\n[/Library/Perl/5.8.8/SOAP/Transport/HTTP.pm:717]\n[/usr/local/bricolage/lib/Bric/SOAP/Handler.pm:175]\n[-e:0]
>>
>
> Can you send in the XML you're trying to import? It's not finding a story
> ID or a category URI for some reason.
>
> Best,
>
> David
>
>

Attachments:

jdurkin.xml (57.6 KB)

david at kineticode

Feb 26, 2009, 10:22 AM

Post #19 of 26 (7879 views)
Permalink

Re: ingesting new stories from alternative CMSes [In reply to]

On Feb 26, 2009, at 10:03 AM, John Durkin wrote:

> attached - jdurkin.xml

You need a URI field. And you'll need IDs -- any old numbers will do
-- in order to properly manage relateds.

I recommend that you export a story with a related media document that
you've created in the UI to be like what you want to create, and then
base your XML on that.

Best,

David

john.durkin at gmail

Feb 26, 2009, 11:36 AM

Post #20 of 26 (7875 views)
Permalink

Re: ingesting new stories from alternative CMSes [In reply to]

for what do i need a uri field? the media item? my stories that don't
contain media get created without issue. I added an id field to the story,
but still same problem.

On Thu, Feb 26, 2009 at 10:22 AM, David E. Wheeler <david [at] kineticode>wrote:

> On Feb 26, 2009, at 10:03 AM, John Durkin wrote:
>
> attached - jdurkin.xml
>>
>
> You need a URI field. And you'll need IDs -- any old numbers will do -- in
> order to properly manage relateds.
>
> I recommend that you export a story with a related media document that
> you've created in the UI to be like what you want to create, and then base
> your XML on that.
>
> Best,
>
> David
>
>

john.durkin at gmail

Feb 26, 2009, 11:44 AM

Post #21 of 26 (7875 views)
Permalink

Re: ingesting new stories from alternative CMSes [In reply to]

i have bric set to create a new unique filename for images on the Photos
output channel... I can't determine the URI - bric typically does that based
on category and output channel.

nonetheless I added a uri field to try it out but still no luck. the error
is always the same - it thinks site => 100 and category => "" when it's
trying to list media IDs.

JD

On Thu, Feb 26, 2009 at 11:36 AM, John Durkin <john.durkin [at] gmail> wrote:

> for what do i need a uri field? the media item? my stories that don't
> contain media get created without issue. I added an id field to the story,
> but still same problem.
>
>
> On Thu, Feb 26, 2009 at 10:22 AM, David E. Wheeler <david [at] kineticode>wrote:
>
>> On Feb 26, 2009, at 10:03 AM, John Durkin wrote:
>>
>> attached - jdurkin.xml
>>>
>>
>> You need a URI field. And you'll need IDs -- any old numbers will do -- in
>> order to properly manage relateds.
>>
>> I recommend that you export a story with a related media document that
>> you've created in the UI to be like what you want to create, and then base
>> your XML on that.
>>
>> Best,
>>
>> David
>>
>>
>

david at kineticode

Feb 26, 2009, 12:44 PM

Post #22 of 26 (7873 views)
Permalink

Re: ingesting new stories from alternative CMSes [In reply to]

On Feb 26, 2009, at 11:44 AM, John Durkin wrote:

> i have bric set to create a new unique filename for images on the
> Photos
> output channel... I can't determine the URI - bric typically does
> that based
> on category and output channel.

Yeah, maybe you don't need it for media. I can't remember.

> nonetheless I added a uri field to try it out but still no luck. the
> error
> is always the same - it thinks site => 100 and category => "" when
> it's
> trying to list media IDs.

It might be primary_uri. As I said, export a sample from Bricolage and
then do what you can to replicate the exported example.

Best,

David

john.durkin at gmail

Feb 26, 2009, 6:16 PM

Post #23 of 26 (7872 views)
Permalink

Re: ingesting new stories from alternative CMSes [In reply to]

i finally got it working. I didn't have my <file> tags in the right place
plus a few other errors.

now, of course, i have a new problem, which is that stories with related
media won't publish... I think it's because the story tries to publish
first, but can't because the media is not published, and then the media
tries to publish but it doesn't seem to actually do so. I find the media
item does get properly created and related to the story... but the story
just isn't published right. When I look up the media item indivdually, it is
not in a published state. Once I publish it manually and then try to publish
the story manually, it works.

any ideas about this?

On Thu, Feb 26, 2009 at 12:44 PM, David E. Wheeler <david [at] kineticode>wrote:

> On Feb 26, 2009, at 11:44 AM, John Durkin wrote:
>
> i have bric set to create a new unique filename for images on the Photos
>> output channel... I can't determine the URI - bric typically does that
>> based
>> on category and output channel.
>>
>
> Yeah, maybe you don't need it for media. I can't remember.
>
> nonetheless I added a uri field to try it out but still no luck. the error
>> is always the same - it thinks site => 100 and category => "" when it's
>> trying to list media IDs.
>>
>
> It might be primary_uri. As I said, export a sample from Bricolage and then
> do what you can to replicate the exported example.
>
> Best,
>
> David
>
>

david at kineticode

Feb 26, 2009, 6:23 PM

Post #24 of 26 (7847 views)
Permalink

Re: ingesting new stories from alternative CMSes [In reply to]

On Feb 26, 2009, at 6:16 PM, John Durkin wrote:

> i finally got it working. I didn't have my <file> tags in the right
> place
> plus a few other errors.
>
> now, of course, i have a new problem, which is that stories with
> related
> media won't publish... I think it's because the story tries to publish
> first, but can't because the media is not published, and then the
> media
> tries to publish but it doesn't seem to actually do so. I find the
> media
> item does get properly created and related to the story... but the
> story
> just isn't published right. When I look up the media item
> indivdually, it is
> not in a published state. Once I publish it manually and then try to
> publish
> the story manually, it works.
>
> any ideas about this?

You might have to use `bric_soap workflow transfer` to move both
documents to a publish desk before you can publish them.

HTH,

David

john.durkin at gmail

Feb 27, 2009, 11:09 AM

Post #25 of 26 (7823 views)
Permalink

Re: ingesting new stories from alternative CMSes [In reply to]

yes i'm going to have to do something like that to get my stories working
and published properly.

i can create stories using the bric_soap cmd line program, but when I try to
create stories using Bric::SOAP::Story I can't get it right. there is a
parameter called "document" which I pass a url (filename because file is in
same folder) but that doesn't work. what is it expecting in the "document"
argument... a filename / path or something else?

On Thu, Feb 26, 2009 at 6:23 PM, David E. Wheeler <david [at] kineticode>wrote:

> On Feb 26, 2009, at 6:16 PM, John Durkin wrote:
>
> i finally got it working. I didn't have my <file> tags in the right place
>> plus a few other errors.
>>
>> now, of course, i have a new problem, which is that stories with related
>> media won't publish... I think it's because the story tries to publish
>> first, but can't because the media is not published, and then the media
>> tries to publish but it doesn't seem to actually do so. I find the media
>> item does get properly created and related to the story... but the story
>> just isn't published right. When I look up the media item indivdually, it
>> is
>> not in a published state. Once I publish it manually and then try to
>> publish
>> the story manually, it works.
>>
>> any ideas about this?
>>
>
> You might have to use `bric_soap workflow transfer` to move both documents
> to a publish desk before you can publish them.
>
> HTH,
>
> David
>

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads