OAI-PMH Repository returns 0 records

[jvinke]

Greetings!

I’m encountering an issue with the version 2.2 of OAI-PMH Repository which seems to be returning unparsable xml. I can view the XML in browser and it doesn’t seem to be syntactically incorrect in an obvious way. (To me at least.)

OAI-PMH Data Provider Validation and Registration tells me that this might be an invalid UTF8 character, but I’m not able to compile and run the UTF8 conditioner program they recommend.

Trying from another angle, when I save and validate the XML within notepad++ I get the following error message 54 times:

ERROR: Element '{http://www.openarchives.org/OAI/2.0/oai_dc/}dc': No matching global element declaration available, but demanded by the strict wildcard.

I’m wondering if anybody has further recommendations on how I might troubleshoot this. Since I have previously harvested from this Omeka instance without incident, I’m a bit perplexed.

[jflatnes]

Can you link to the problematic OAI-PMH endpoint?

[jflatnes]

Something odd is happening there: there’s a PHP error occurring and outputting junk into the XML responses (which accounts for the harvest failures and validation errors), but not if you view the XML in a browser. My best guess is it’s something a little esoteric that’s making it not visible when viewed in a browser. But pull down an XML response from that site with curl or wget and you’ll see at the end of the response:

<br />
<b>Deprecated</b>:  Directive 'allow_url_include' is deprecated in <b>Unknown</b> on line <b>0</b><br />

Probably the site administrator just needs to remove an old php.ini setting somewhere to avoid this warning being triggered (they could also maybe just turn off Omeka’s “development” mode that displays errors).

This looks like it’s something specific to that server and settings rather than an issue with Omeka or the plugin.

[jvinke]

Ah, thank you! I was able to turn off that flag and it’s no longer outputting into the HTML and now it’s working with the validator.