MigrateXMLReader parses the elementyQuery xpath to validate its location during iteration (next). Unfortunately I've run into some xpath which the regex is choking on. (This is for a Taxonomy term migration which is why it is so specific.)
$item_xpath = "/catalog_titles/catalog_title/category[@scheme[contains(.,'genre')]]";
The first pass for the element query results in:
Array
(
[0] => Array
(
[0] => /catalog_titles/catalog_title/category[@scheme[contains(.,'genre')]]
)
[1] => Array
(
[0] => catalog_titles/catalog_title/category
)
[2] => Array
(
[0] => [@scheme[contains(.,'genre')]]
)
)
However, the following attribute search:
preg_match_all('|^\[@([^=]+)=[\'"](.*)[\'"]\]$|', $attribute_query, $matches);
on:
[@scheme[contains(.,'genre')]] returns no results.
I'm not the xpath whiz but I'll try to take some stabs at this. Unless someone reports that this is resolved in the dev version???
Comments
Comment #1
oddible commentedComment #2
dman commentedIt looks like you are trying to do an xpath that would be normally represented as:
/catalog_titles/catalog_title/category[contains(@scheme,'genre')]... Though any parser that is trying to merge xpath and regexp at the same time is risking all sorts of trouble.
Comment #3
oddible commentedThanks for the clean-up of my xpath @dman. Migrate uses regex to parse the xpath because it is trying to offer an xpath style search string as input for the xmlreader (streamed iterated) migration ui. This is working as intended - the code very explicitly states that it was only mean to work with a constrained xpath syntax. Not sure why to use xpath as the interface in the first place since it immediately gets parsed into element and attribute arrays. Overriding to allow the user (me) to pass in $element_query as a pre-parsed array.
Will switch to a feature request.
- Change MigrateXMLReader $element_query to a preparsed array.
Comment #4
oddible commentedComment #5
oddible commented