PHP Warning :: DOMDocument::loadXML(): xmlParseEntityRef: no name in Entity, line: 78

Project:RUcore SOLR Searching and Indexing
Category:bug report

[10-May-2016 10:34:36 America/New_York] PHP Warning: DOMDocument::loadXML(): xmlParseEntityRef: no name in Entity, line: 78 in /mellon/htdocs/dlr/EDIT/INT/solrfilter-api.php on line 885
[10-May-2016 10:34:47 America/New_York] PHP Warning: DOMDocument::loadXML(): xmlParseEntityRef: no name in Entity, line: 78 in /mellon/htdocs/dlr/EDIT/INT/solrfilter-api.php on line 885



Is there a PID for the object generating this? This is the rather general error I now get whenever there is bad data that fails XML parsing. It could be bad or broken multi-byte characters.


Sorry, but I have no idea. Tailing the php error log and this popped up. No context provided. You might have to check against the apache access log for more info.


I'm sure I can find some on rep-test at least. In general I need a filter to perform a function like perl's utf8 function, such as
$string = utf8($string);
I've been trying various mb_ functions in PHP, but have not found something robust enough to replace utf8.


While testing another issue I saw this in the /solr/logs/solr-0.log from the same time.

<message>org.apache.solr.common.SolrException: Illegal processing instruction target ("xml"); xml (case insensitive) is reserved by the specs.
at [row,col {unknown-source}]: [1,385]
at org.apache.solr.handler.XMLLoader.load(
at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(
at org.apache.solr.handler.RequestHandlerBase.handleRequest(
at org.apache.solr.core.SolrCore.execute(
at org.apache.solr.servlet.SolrDispatchFilter.execute(
at org.apache.solr.servlet.SolrDispatchFilter.doFilter(
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(
at org.mortbay.jetty.servlet.ServletHandler.handle(
at org.mortbay.jetty.servlet.SessionHandler.handle(
at org.mortbay.jetty.handler.ContextHandler.handle(
at org.mortbay.jetty.webapp.WebAppContext.handle(
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(
at org.mortbay.jetty.handler.HandlerCollection.handle(
at org.mortbay.jetty.handler.HandlerWrapper.handle(
at org.mortbay.jetty.Server.handle(
at org.mortbay.jetty.HttpConnection.handleRequest(
at org.mortbay.jetty.HttpConnection$RequestHandler.content(
at org.mortbay.jetty.HttpParser.parseNext(
at org.mortbay.jetty.HttpParser.parseAvailable(
at org.mortbay.jetty.HttpConnection.handle(
at org.mortbay.thread.QueuedThreadPool$
Caused by: com.ctc.wstx.exc.WstxParsingException: Illegal processing instruction target ("xml"); xml (case insensitive) is reserved by the specs.
at [row,col {unknown-source}]: [1,385]
at org.apache.solr.handler.XMLLoader.processUpdate(
at org.apache.solr.handler.XMLLoader.load(
... 22 more


I've seen that too. I'm not sure what it means. It's onl;y started showing up with the PHP version and I wonder if it has something to do with a misreading of the new errors thrown by PHP. I'd like to try /mellon/includes/classes/php/string_cleaner/class.string.cleaner.php to deal with the bad character or utf8 errors and hope fixing that might get the Solr complaints to go away as well.


Here is an example of how to implement that class.


Still seeing loads of errors in the php_error log. If I may, I would suggest the following.

1) When instantiating a new XML DOM object include the version and encoding parameters.

$inputdom = new DomDocument('1.0', 'UTF-8');

2) Next suppress warnings as follows

$inputdom->@loadXML($xmldata, LIBXML_NOERROR);

3) Then check that the $inputdom is valid; which means converting the one-liner from:

$inputdom->loadXML($xmldata) or exit("Could not parse the xmldata");


if (!$inputdom){
exit("Could not parse the xmldata");

so all put together....

$inputdom = new DomDocument('1.0', 'UTF-8');
$inputdom->@loadXML($xmldata, LIBXML_NOERROR);
if (!$inputdom){
exit("Could not parse the xmldata");


I'm running it now (57% so far with no errors, though these come near the end). I am trying to catch the loadXML problem before it hits and exit with an error, which seems to work on command line tests. I'll know soon if there are no errors in this morning's run. I'm holding off if I can on suppressing errors with @. We'll see.


I see a few more errors in the run. Perhaps I'll need to suppress the DOMDocument::loadXML() after all. I'll do that and rerun the portalcron.


I'm running a new test; I had to use
@$inputdom->loadXML($xmldata, LIBXML_NOERROR);
$inputdom->@loadXML($xmldata, LIBXML_NOERROR);
threw a PHP parse error.


Yes, sorry about the misplaced @ sign.


Assigned to:triggs» chadmills
Status:active» test

The latest run of portalcron just before lunch produced no new errors. The last loadXML error is 16-May-2016 11:26:06, before the last run of the cron. The 4 o'clock cron should verify this.


Status:test» fixed


Status:fixed» closed

Back to top