Migration Script for Weblinks 4.6

Nice....thanks for the contrib.

I haven't had time to review it in detail yet, but have a couple of comments/questions based on your posts to the issue and on a quick look at the code.

To answer your question about link_title in the {links_node} table vs. in the {links} table, this duality is to allow a node that refers to a link to retitle the link within its local context only -- without creating a duplicate entry in the {links} table itself with the same URL. The links package is designed to rigidly enforce the notion that each normalized URL appears only once in the {links} table, so that link validation, dead link checking, and destination-page change monitoring are maximally efficient for the Drupal site as a whole. But it's still desirable to have the same destination named different things by different referring nodes.

As an example, suppose I create a "weblink" node with a destination of http://www.example.com, a page whose title is "Example Company Home Page". Suppose that happens to be my employer. Later on, I may create a "page" node containing my CV or resumé that happens to refer to example.com as a related link, but in that context I might want to call it "my current employer, Example Inc.". And maybe later I write a "story" about some open source code my company has released, and I want to refer to http://example.com in a related link as the "ExampleWare project home page". In these situations, there is no need to duplicate the internal URL record (and thereby have to scan it thrice for dead link detection and other monitoring, or update it multiple places if it is relocated), but I want to have the user-visible text be different depending on the context in which the link is used.

This feature could also be useful if the nodes that refer to a given link URL happen to be of different languages. If the site is mainly English, the {links} version of link_title could be in that language, but a node that is in German could locally retitle the link in its own language.

I don't pretend to be able to envision all the ways in which modules might use the links API -- that's why I allowed for as much flexibility as I could in the database schema and API design. :-)

In the context of this import, you probably want to take your title from the title of the existing "weblink" node that you are importing. The links API will automatically examine the title to see if it matches any existing title in the {links} table, before creating the entry in {links_node}. If there is no preexisting {links} row with this normalized URL, then your suggested title becomes the canonical title and is placed into {links}.link_title, and {links_node}.links_title is empty or NULL. If there is a preexisting {links} row, and your suggested title is the same as what's already there, then your new {links_node} row will omit the local title and defer to the existing default. If there is a preexisting {links} row but the title is not the same as what you requested, the new {links_node} row will refer to the existing {links} row as usual but will retain your localized title in {links_node}.link_title.

I hope that helps to explain this field. I'm working on documentation for the API, and will be sure to include this explanation (or one like it) in those docs.

You may want to review your code against the actions of the links_put_link() function, because I believe you are calling some of the API's normalization and title-generation functions redundantly. I'm pretty sure links_put_link() already normalizes the URL internally, and that it will call links_suggest_link_title() if it needs to do so. So you may be able to shorten your code a bit. :-)

I have a question, also. Can you explain in more detail the intent of your checking for existing nodes, and the use of links_delete_links_for_node()? I see what you're doing, but I'm not clear on the intent of this section.

Thanks again for the contrib! I hope I've answered your questions adequately (let me know if not), and I look forward to hearing from you further.

Kind regards,

Scott

In head we now have the ability to hook into the update.php script with any contrib.

This is very bad documented, and I have asked for support to get this weblinks upgrade script use that hook. But so far no luck.

I think that route is a better one to investigate, though. Its much user friendlier.

FYI: http://cvs.drupal.org/viewcvs/drupal/contributions/docs/developer/hooks/...

has good documentation on the update hooks.

Hi, folks.

Just wanted to let you know, I'm fighting a major problem with a production server. It may be another day or two before I get time to work on Drupal code, but I wanted to let you know I haven't vanished.

Scott (syscrusher)

John,

I've committed an adapted version of your code. There were a couple of changes needed, but it's largely based on what you've kindly provided.

I don't have a Drupal 4.6 test bed at the moment to check this on, so it's completely untested as of now. I'll try to get to that in a few days, but in the meantime, test reports and patches (if needed) from anyone with time to run a quick test would be appreciated, as I'm working on other things at the moment.

The new file is update-weblinks.php (NOT update-weblinks-old.php, which is for the Drupal 4.5 versions of weblink.module).

Thanks for the contrib!

Syscrusher

Tested the migration on several hundred links and several thousand webstories (a custom node type of mine) with no further problems.

Nice script-- migrated my links from weblinks (4.6) to links (4.7) without trouble. Thank you!