2010-12-21 02:04:02 +09:00
|
|
|
<?php
|
2010-12-21 23:42:44 +09:00
|
|
|
/**
|
|
|
|
* StatusNet - the distributed open-source microblogging tool
|
|
|
|
* Copyright (C) 2010, StatusNet, Inc.
|
|
|
|
*
|
|
|
|
* Importer class for Delicious.com backups
|
|
|
|
*
|
|
|
|
* PHP version 5
|
|
|
|
*
|
|
|
|
* This program is free software: you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU Affero General Public License as published by
|
|
|
|
* the Free Software Foundation, either version 3 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU Affero General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Affero General Public License
|
|
|
|
* along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*
|
|
|
|
* @category Bookmark
|
|
|
|
* @package StatusNet
|
|
|
|
* @author Evan Prodromou <evan@status.net>
|
|
|
|
* @copyright 2010 StatusNet, Inc.
|
|
|
|
* @license http://www.fsf.org/licensing/licenses/agpl-3.0.html AGPL 3.0
|
|
|
|
* @link http://status.net/
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (!defined('STATUSNET')) {
|
|
|
|
// This check helps protect against security problems;
|
|
|
|
// your code file can't be executed directly from the web.
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Importer class for Delicious bookmarks
|
|
|
|
*
|
|
|
|
* @category Bookmark
|
|
|
|
* @package StatusNet
|
|
|
|
* @author Evan Prodromou <evan@status.net>
|
|
|
|
* @copyright 2010 StatusNet, Inc.
|
|
|
|
* @license http://www.fsf.org/licensing/licenses/agpl-3.0.html AGPL 3.0
|
|
|
|
* @link http://status.net/
|
|
|
|
*/
|
2010-12-21 02:04:02 +09:00
|
|
|
|
2010-12-22 01:09:01 +09:00
|
|
|
class DeliciousBackupImporter extends QueueHandler
|
2010-12-21 02:04:02 +09:00
|
|
|
{
|
2010-12-22 01:09:01 +09:00
|
|
|
/**
|
|
|
|
* Transport of the importer
|
|
|
|
*
|
|
|
|
* @return string transport string
|
|
|
|
*/
|
|
|
|
|
|
|
|
function transport()
|
|
|
|
{
|
|
|
|
return 'dlcsback';
|
|
|
|
}
|
|
|
|
|
2010-12-21 23:42:44 +09:00
|
|
|
/**
|
|
|
|
* Import an in-memory bookmark list to a user's account
|
|
|
|
*
|
|
|
|
* Take a delicious.com backup file (same as Netscape bookmarks.html)
|
|
|
|
* and import to StatusNet as Bookmark activities.
|
|
|
|
*
|
|
|
|
* The document format is terrible. It consists of a <dl> with
|
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.
2011-01-01 05:09:54 +09:00
|
|
|
* a bunch of <dt>'s, occasionally with <dd>'s adding descriptions.
|
2010-12-21 23:42:44 +09:00
|
|
|
* There are sometimes <p>'s lost inside.
|
|
|
|
*
|
2010-12-22 01:09:01 +09:00
|
|
|
* @param array $data pair of user, text
|
2010-12-21 23:42:44 +09:00
|
|
|
*
|
2010-12-22 01:09:01 +09:00
|
|
|
* @return boolean success value
|
2010-12-21 23:42:44 +09:00
|
|
|
*/
|
|
|
|
|
2010-12-22 01:09:01 +09:00
|
|
|
function handle($data)
|
2010-12-21 23:42:44 +09:00
|
|
|
{
|
2010-12-22 01:09:01 +09:00
|
|
|
list($user, $body) = $data;
|
|
|
|
|
2010-12-21 23:42:44 +09:00
|
|
|
$doc = $this->importHTML($body);
|
|
|
|
|
|
|
|
$dls = $doc->getElementsByTagName('dl');
|
|
|
|
|
|
|
|
if ($dls->length != 1) {
|
|
|
|
throw new ClientException(_("Bad import file."));
|
|
|
|
}
|
|
|
|
|
|
|
|
$dl = $dls->item(0);
|
|
|
|
|
|
|
|
$children = $dl->childNodes;
|
|
|
|
|
|
|
|
$dt = null;
|
|
|
|
|
|
|
|
for ($i = 0; $i < $children->length; $i++) {
|
|
|
|
try {
|
|
|
|
$child = $children->item($i);
|
|
|
|
if ($child->nodeType != XML_ELEMENT_NODE) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
switch (strtolower($child->tagName)) {
|
|
|
|
case 'dt':
|
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.
2011-01-01 05:09:54 +09:00
|
|
|
// <dt> nodes contain primary information about a bookmark.
|
|
|
|
// We can't import the current one just yet though, since
|
|
|
|
// it may be followed by a <dd>.
|
2010-12-21 23:42:44 +09:00
|
|
|
if (!empty($dt)) {
|
|
|
|
// No DD provided
|
|
|
|
$this->importBookmark($user, $dt);
|
|
|
|
$dt = null;
|
|
|
|
}
|
|
|
|
$dt = $child;
|
|
|
|
break;
|
|
|
|
case 'dd':
|
|
|
|
$dd = $child;
|
|
|
|
|
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.
2011-01-01 05:09:54 +09:00
|
|
|
// This <dd> contains a description for the bookmark in
|
|
|
|
// the preceding <dt> node.
|
2010-12-21 23:42:44 +09:00
|
|
|
$saved = $this->importBookmark($user, $dt, $dd);
|
|
|
|
|
|
|
|
$dt = null;
|
|
|
|
$dd = null;
|
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.
2011-01-01 05:09:54 +09:00
|
|
|
break;
|
2010-12-21 23:42:44 +09:00
|
|
|
case 'p':
|
|
|
|
common_log(LOG_INFO, 'Skipping the <p> in the <dl>.');
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
common_log(LOG_WARNING,
|
|
|
|
"Unexpected element $child->tagName ".
|
|
|
|
" found in import.");
|
|
|
|
}
|
|
|
|
} catch (Exception $e) {
|
|
|
|
common_log(LOG_ERR, $e->getMessage());
|
|
|
|
$dt = $dd = null;
|
|
|
|
}
|
|
|
|
}
|
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.
2011-01-01 05:09:54 +09:00
|
|
|
if (!empty($dt)) {
|
|
|
|
// There was a final bookmark without a description.
|
|
|
|
try {
|
|
|
|
$this->importBookmark($user, $dt);
|
|
|
|
} catch (Exception $e) {
|
|
|
|
common_log(LOG_ERR, $e->getMessage());
|
|
|
|
}
|
|
|
|
}
|
2010-12-22 01:09:01 +09:00
|
|
|
|
|
|
|
return true;
|
2010-12-21 23:42:44 +09:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Import a single bookmark
|
|
|
|
*
|
|
|
|
* Takes a <dt>/<dd> pair. The <dt> has a single
|
|
|
|
* <a> in it with some non-standard attributes.
|
|
|
|
*
|
|
|
|
* A <dt><dt><dd> sequence will appear as a <dt> with
|
|
|
|
* anothe <dt> as a child. We handle this case recursively.
|
|
|
|
*
|
|
|
|
* @param User $user User to import data as
|
|
|
|
* @param DOMElement $dt <dt> element
|
|
|
|
* @param DOMElement $dd <dd> element
|
|
|
|
*
|
|
|
|
* @return Notice imported notice
|
|
|
|
*/
|
|
|
|
|
|
|
|
function importBookmark($user, $dt, $dd = null)
|
|
|
|
{
|
2011-01-01 05:33:51 +09:00
|
|
|
$as = $dt->getElementsByTagName('a');
|
|
|
|
|
|
|
|
if ($as->length == 0) {
|
|
|
|
throw new ClientException(_("No <A> tag in a <DT>."));
|
|
|
|
}
|
|
|
|
|
|
|
|
$a = $as->item(0);
|
|
|
|
|
|
|
|
$private = $a->getAttribute('private');
|
|
|
|
|
|
|
|
if ($private != 0) {
|
|
|
|
throw new ClientException(_('Skipping private bookmark.'));
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!empty($dd)) {
|
|
|
|
$description = $dd->nodeValue;
|
|
|
|
} else {
|
|
|
|
$description = null;
|
|
|
|
}
|
|
|
|
$addDate = $a->getAttribute('add_date');
|
|
|
|
|
|
|
|
$data = array(
|
|
|
|
'profile_id' => $user->id,
|
|
|
|
'title' => $a->nodeValue,
|
|
|
|
'description' => $description,
|
|
|
|
'url' => $a->getAttribute('href'),
|
|
|
|
'tags' => $a->getAttribute('tags'),
|
|
|
|
'created' => common_sql_date(intval($addDate))
|
|
|
|
);
|
|
|
|
|
2010-12-22 01:09:01 +09:00
|
|
|
$qm = QueueManager::get();
|
2011-01-01 05:33:51 +09:00
|
|
|
$qm->enqueue($data, 'dlcsbkmk');
|
2010-12-21 23:42:44 +09:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Parse some HTML
|
|
|
|
*
|
|
|
|
* Hides the errors that the dom parser returns
|
|
|
|
*
|
|
|
|
* @param string $body Data to import
|
|
|
|
*
|
|
|
|
* @return DOMDocument parsed document
|
|
|
|
*/
|
|
|
|
|
|
|
|
function importHTML($body)
|
|
|
|
{
|
2010-12-21 02:04:02 +09:00
|
|
|
// DOMDocument::loadHTML may throw warnings on unrecognized elements,
|
|
|
|
// and notices on unrecognized namespaces.
|
|
|
|
$old = error_reporting(error_reporting() & ~(E_WARNING | E_NOTICE));
|
|
|
|
$dom = new DOMDocument();
|
2010-12-21 23:42:44 +09:00
|
|
|
$ok = $dom->loadHTML($body);
|
2010-12-21 02:04:02 +09:00
|
|
|
error_reporting($old);
|
|
|
|
|
2010-12-21 23:42:44 +09:00
|
|
|
if ($ok) {
|
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.
2011-01-01 05:09:54 +09:00
|
|
|
foreach ($dom->getElementsByTagName('body') as $node) {
|
|
|
|
$this->fixListsIn($node);
|
|
|
|
}
|
2010-12-21 23:42:44 +09:00
|
|
|
return $dom;
|
|
|
|
} else {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
}
|
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.
2011-01-01 05:09:54 +09:00
|
|
|
|
|
|
|
|
|
|
|
function fixListsIn(DOMNode $body) {
|
|
|
|
$toFix = array();
|
|
|
|
|
|
|
|
foreach ($body->childNodes as $node) {
|
|
|
|
if ($node->nodeType == XML_ELEMENT_NODE) {
|
|
|
|
$el = strtolower($node->nodeName);
|
|
|
|
if ($el == 'dl') {
|
|
|
|
$toFix[] = $node;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
foreach ($toFix as $node) {
|
|
|
|
$this->fixList($node);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
function fixList(DOMNode $list) {
|
|
|
|
$toFix = array();
|
|
|
|
|
|
|
|
foreach ($list->childNodes as $node) {
|
|
|
|
if ($node->nodeType == XML_ELEMENT_NODE) {
|
|
|
|
$el = strtolower($node->nodeName);
|
|
|
|
if ($el == 'dt' || $el == 'dd') {
|
|
|
|
$toFix[] = $node;
|
|
|
|
}
|
|
|
|
if ($el == 'dl') {
|
|
|
|
// Sublist.
|
|
|
|
// Technically, these can only appear inside a <dd>...
|
|
|
|
$this->fixList($node);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
foreach ($toFix as $node) {
|
|
|
|
$this->fixListItem($node);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
function fixListItem(DOMNode $item) {
|
|
|
|
// The HTML parser in libxml2 doesn't seem to properly handle
|
|
|
|
// many cases of implied close tags, apparently because it doesn't
|
|
|
|
// understand the nesting rules specified in the HTML DTD.
|
|
|
|
//
|
|
|
|
// This leads to sequences of adjacent <dt>s or <dd>s being incorrectly
|
|
|
|
// interpreted as parent->child trees instead of siblings:
|
|
|
|
//
|
|
|
|
// When parsing this input: "<dt>aaa <dt>bbb"
|
|
|
|
// should be equivalent to: "<dt>aaa </dt><dt>bbb</dt>"
|
|
|
|
// but we're seeing instead: "<dt>aaa <dt>bbb</dt></dt>"
|
|
|
|
//
|
|
|
|
// It does at least know that going from dt to dd, or dd to dt,
|
|
|
|
// should make a break.
|
|
|
|
|
|
|
|
$toMove = array();
|
|
|
|
|
|
|
|
foreach ($item->childNodes as $node) {
|
|
|
|
if ($node->nodeType == XML_ELEMENT_NODE) {
|
|
|
|
$el = strtolower($node->nodeName);
|
|
|
|
if ($el == 'dt' || $el == 'dd') {
|
|
|
|
// dt & dd cannot contain each other;
|
|
|
|
// This node was incorrectly placed; move it up a level!
|
|
|
|
$toMove[] = $node;
|
|
|
|
}
|
|
|
|
if ($el == 'dl') {
|
|
|
|
// Sublist.
|
|
|
|
// Technically, these can only appear inside a <dd>.
|
|
|
|
$this->fixList($node);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
$parent = $item->parentNode;
|
|
|
|
$next = $item->nextSibling;
|
|
|
|
foreach ($toMove as $node) {
|
|
|
|
$item->removeChild($node);
|
|
|
|
$parent->insertBefore($node, $next);
|
|
|
|
$this->fixListItem($node);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-12-21 02:04:02 +09:00
|
|
|
}
|