RE: [Fez-users] Creating Community Error - again ;)

[<pen...@rh...>]

Thanks for the offer to help, Matt. Printing out variables is definitely
telling me a little more about what is going on.

First of all, the namespace is correct as rds. The ns vs. rds was my
attempt at obfuscation of output for the list.

What I found out is that, everything works fine up to this line in the
fedoraInsertUpdate function:

Record::insertXML($pid, compact('datastreamTitles', 'xmlObj',
'indexArray', 'existingDatastreams' ), $ingestObject);

If I put the following code above that line:

echo "PID: ".print_r($pid, true);
echo " | Created Date: ".print_r($this->created_date, true);
echo " | Updated Date: ".print_r($this->updated_date, true);
echo " | File Downloads: ".print_r($file_downloads, true);
echo " | Datastream Titles: ".print_r($datastreamTitles, true);
echo " | XMLObj: ".print_r($xmlObj, true);
exit;

I get output (see below). If I let that line execute, I get a blank
page.

I think the problem has to do with Tidy. I added some variable dump
lines to inside the insertXML function, and while I do get output for
"XML Object Before Tidy" I never get anything from "XML Object After
Tidy" which leads me to believe that the
Fedora_API::callIngestObject($xmlObj); command is failing.

        if ($ingestObject) {
            // Actually Ingest the object Into Fedora
            // We only have to do this when first creating the object,
subsequent updates should just work with the
            // datastreams.
            // will have to exclude the non X control group xml and add
the datastreams after the base ingestion.
            $xmlObj =3D
Misc::removeNonXMLDatastreams($datastreamXMLHeaders, $xmlObj);

echo " | XML Object Before Tidy: ".print_r($xmlObj, true);

            $config =3D array(
                    'indent'         =3D> true,
                    'input-xml'   =3D> true,
                    'output-xml'   =3D> true,
                    'wrap'           =3D> 200);

            $tidy =3D new tidy;
            $tidy->parseString($xmlObj, $config, 'utf8');
            $tidy->cleanRepair();
            $xmlObj =3D $tidy;

echo " | XML Object After Tidy: ".print_r($xmlObj, true);

            Fedora_API::callIngestObject($xmlObj);
        }

I never see any objects get created in our Fedora 2.1 repository.
Strangely, as long as I exit out of the insertXML function or exit out
of the fedoraInsertUpdate before the insertXML function is called, I can
get variable dumps. If I let the insertXML function get called and
execute all the way through, I get a blank page.

Any ideas for what I should try next? Thanks in advance for the help,
Matt.

Stacy


> -----Original Message-----
> From: fez...@li...=20
> [mailto:fez...@li...] On Behalf Of=20
> Matthew Smith
> Sent: Monday, March 06, 2006 5:40 PM
> To: fez...@li...
> Subject: Re: [Fez-users] Creating Community Error - again ;)
>=20
> Stacy,
>=20
> The namespaces in your email don't match - are you using 'ns'=20
> or 'rds'?  There's an earlier post that suggests checking the=20
> namespace in config.fcfg:
>=20
>     fedora.fcfg  the value of pidNamespace must be included=20
> in retainPIDs
>     , so I think you must include m05  or place a  *.
>=20
> Worth a try.  I'm not very familiar with the fedora side of=20
> things but I'm trying to handle some of the queries on this=20
> list while Christiaan is busily engaged with some internal UQ=20
> customers...
>=20
> I searched for your error message on the Fedora mailing list=20
> but haven't found much - possiblility of  a bug with long=20
> label names on datastreams...
>=20
> Meanwhile, to debug from the Fez end, the function that=20
> creates the community is in the file class.record.php and in=20
> the function called fedoraInsertUpdate.  Right at the top of=20
> that function it tries to get a new PID (in the case of=20
> insert it will need to get a pid).
>=20
> To debug your way through it, try adding the following line=20
> after the call to getNextPID()
>=20
>   echo "PID:".print_r($this->pid, true); exit;
>=20
> This will print out whatever the fedora server result PID was=20
> and exit the rest of the page script so that only that result=20
> will be printed on the screen.  Once you've established that=20
> it's getting a pid, delete the debug line you just added and=20
> move it down the function a bit and try printing out=20
> different variables until you find the spot where it dies.
>=20
> If you get nothing at all even then, let me know too as it=20
> must then be failing even before it gets to the=20
> fedoraInsertUpdate function.
>=20
> I'm sure this is a simple fix once we find it.
>=20
> Matt
>=20