]> git.mxchange.org Git - quix0rs-gnu-social.git/commit
Bookmark plugin: fixes for bad DOM element nesting in delicious import data
authorBrion Vibber <brion@pobox.com>
Fri, 31 Dec 2010 20:09:54 +0000 (12:09 -0800)
committerBrion Vibber <brion@pobox.com>
Fri, 31 Dec 2010 20:09:54 +0000 (12:09 -0800)
commitfedfde9bbb3c898328c6395a41c3243d6e97a2bf
tree68b4de42f31be174c16d8a65b2357978d376e975
parent56875318489b11c96d0360f7458bb3c6f1a25dc9
Bookmark plugin: fixes for bad DOM element nesting in delicious import data

delicious bookmark exports use the godawful HTML bookmark file format that ancient versions of Netscape used (and has thus been the common import/export format for bookmarks since the dark ages of the web :)
This arranges bookmark entries as an HTML definition list, using a lot of implied close tags (leaving off the </dt> and </dd>).
DOMDocument->loadHTML() uses libxml2's HTML mode, which generally does ok with muddling through things but apparently is really, really bad about handling those implied close tags.

Sequences of adjacent <dt> elements (eg bookmark without a description, followed by another bookmark "<dt><dt>"), end up interpreted as nested ("<dt><dt></dt></dt>") instead of as siblings ("<dt></dt><dt></dt>").
The first round of code tried to resolve the nesting inline, but ended up a bit funky in places.
I've replaced this with a standalone run through the data to re-order the elements, based on our knowing that <dt> and <dd> cannot directly contain one another; once that's done, our main logic loop can be a bit cleaner. I'm not 100% sure it's doing nested sublists correctly, but these don't seem to show up in delicious export (and even if they do, with the way we flatten the input it shouldn't make a difference).

Also fixed a clearer edge case where some bookmarks didn't get imported when missing descriptions.
plugins/Bookmark/deliciousbackupimporter.php