Import EAC file results in white screen
|Assignee:||Jesús García Crespo||% Done:|
|Category:||EAC - Import/Export|
|Target version:||Release 2.1.0|
|Google Code Legacy ID:||Tested version:||2.0.0, 2.0.1, 2.1|
When testing imports of EAC files into 2.x from 2.0 non-hosted sites (UBC, AMA, CVA for example) the import resulted in a white screen. When the same EAC files were imported in debug mode, they imported without any errors. To reproduce:
1. Find an EAC file (three examples attached, or export from:
2. Import in 2.x using user interface
3. Should result in white screen.
If you perform the steps above in debug mode, the EAC file should import without errors.
During testing, the following error came through the nginx log for 2x:
2014/05/05 13:31:03 [error] 28166#0: *251328 FastCGI sent in stderr: "PHP message: PHP Fatal error: Call to a member function __get() on a non-object in /mnt/atom-hosting/2.x/atom-adfc4b1bb567a6bf1ed61c9e05241f1a6e520825/lib/model/om/BaseObject.php on line 505" while reading response header from upstream, client: 184.108.40.206, server: 2x.test.artefactual.com, request: "POST /object/import HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.testing.sock:", host: "2x.test.artefactual.com", referrer: "http://2x.test.artefactual.com/object/importSelect?type=xml"
#4 Updated by Dan Gillean almost 8 years ago
- Assignee changed from Mike Gale to Jesús García Crespo
- Priority changed from Medium to Critical
Still not sure if this is local or a problem everywhere - but I just reproduced trying to roundtrip in 2x.test. Marking critical so we can sort it out in time for 2.1 release - if EAC import is in fact broken for all users, this is a critical bug indeed. If not, we should still figure out the source of the issue so we can properly test.
#6 Updated by Jesús García Crespo over 7 years ago
In the XML doc surrey-berry-growers-cooperative-2;eac.xml, the href attribute points to "http://rbscarchives.library.ubc.ca/index.php/zennosuke-inouye". Notice that "index.php" is part of the URL.
During the import, sfEacPlugin.class.php#L626 assigns "/index.php/zennosuke-inouye" to $url, and that can't be parsed by routing->parse() and false is returned.
I'm not really familiar with this code at all. MikeG, what do you think? It looks like we could do a better job when we are calling preg_replace() and ignore the script name if it's included in the URL.
What do you think about replacing sfEacPlugin.class.php#L626 with the following?
$url = preg_replace('/^(?:[^:]+:\/\/[^\/]+)?(\/(index|qubit_dev)\.php)?/', null, $node->getAttributeNS('http://www.w3.org/1999/xlink', 'href'), -1, $count);For the following three cases:
... $url will equal to "/zennosuke-inouye" and that's what we want to achieve so parse() can do his job, right?
#11 Updated by Mike Gale over 7 years ago
Hey I think your suggestion is good... unfortunately at home the VM I was using for work was based on Ubuntu 12.10 which doesn't seem to have Docker and I don't really have time to learn Vagrant right now (for ES 0.9 vs. 1.3), so I'm in the process of creating a new VM with 14.04 :(
I'll check it out tomorrow!
#12 Updated by Jesús García Crespo over 7 years ago
- File test-eac.xml added
- Status changed from Feedback to QA/Review
- Assignee changed from Mike Gale to Dan Gillean
Ok, I think that this has been fixed in bf1c017. I have been testing this thoughtfully with different URL path forms in the @href attribute of <cpfRelation/>. I've also confirmed that a new resource is created if there is no matches, otherwise the matching record is used. Either way, errors are now avoided, i.e. white screens. See attached XML document and its <relations/> set.
#13 Updated by Sarah Romkey over 7 years ago
- Status changed from QA/Review to Feedback
- Assignee changed from Dan Gillean to Jesús García Crespo
- Tested version 2.1 added
I am still able to reproduce the white screen using the attached 12th-pa-group and rittenhouse examples. The test sample and the surrey-berry-growers work, but I think maybe because they already matched resources in the qa site?