Use <a>-tags (instead of custom tags/tokens) and do NOT use URL aliases

Node picker does not insert path aliases but own tag [nodepicker==node/[nid]==Title==Link text]

But I agree using <a href="{some path}"> Link text </a> is better and simplier way then special tags that need to be decoded/encoded and links will not be lost if You disable nodepicker module. To get path alias You can use Pathologic filter that will transform internal paths into path aliases.

I prefer that both things are separated, Node picker module for picking nodes and inserting internal paths into node body, and separate filter for turning internal paths into path aliases.
Node picker uses js to replace own tags with path aliases, so if You disable rich text You will see special tags instead of common link.

That it uses JS to replace the encoded links are only true on node edit pages. In view mode transformations are done once and then cached like all other filters.

I will have a look at Pathologic and see if it can perform the same tasks as Node Picker with custom encoded tag does. If so, I will think about removing the custom tag from Node Picker and recommend using Pathologic for that certain functionality.

Changing the title since it's missleading.

Custom tags are used so that the links will always be valid even if title of a node is changed resulting in a new url alias.

You should consider an option to insert internal links like "?q=node/nid"*, and then use a filter like pathologic to generate url...
*This is the only kind of url that always work no settings dependencies....

Ok. I have tried the Pathologic module and it works as expected. So I will make the switch and remove the input filter from Node picker. Perhaps it's best if I make a new branch for the module without the filter so that people using the input filter wont get broken sites if they update.

I don't understand this entire thread. It just seems like not_Dries_Buytaert doesn't understand how to setup and configure Nodepicker. There IS an input filter that you can enable and re-arrange so that it executes before other input filters. Nodepicker even states this right on the module home page: Node Picker uses a input filter for outputing future proof links.

I see this as a two parts. First, not_Dries_Buytaert needs to create a separate support request ticket to get help configuring Nodepicker. Second, this ticket has a good underlying concept of leveraging an existing module's functionality and input filter (Pathologic) to accomplish the task of rewriting links to path aliases. This also adds and additional module dependency that some users might not like.

If the Nodepicker input filter is removed in favor of Pathologic, please ensure good documentation is written and a migration path is defined for existing users.

Your comment is a little insulting. not_Dries_Buytaert laid out some pretty clear reasons why it makes sense to have regular <a> links rather than the input-filtered special code. Among the other reasons mentioned above, this would allow for wrapping other elements, such as images (#785736: Allow node-picked links to wrap other elements). Moreover, the module maintainer is in agreement here -- regular <a> links to unaliased node links make the most sense.

I don't really understand the point of you coming in at the end of a productive, problem-solving thread just to insult people.

I do agree that documentation and an upgrade path would be important things to have in the new branch.

I'm sorry that my comment came across as insulting, that was not my intent at all. Let me try to be more supportive/helpful. It appears there continues to be confusion about Nodepicker and it's two variants. I'm obviously not the module maintainer, nor do I profess to be a Drupal expert by any means.

not_Dries_Buytaert,
I believe the TinyMCE Node Picker module is the original module. Node Picker is the newer, rewritten module and is meant to work with all WYSIWYG editors, hence the more generic name. The original module, TinyMCE Node Picker did NOT include an input filter, it wasn't until Node Picker came along that an input filter was added. I believe TinyMCE Node Picker is ultimately going to be replaced by Node Picker.

I agree with everyone else on this thread that if another, existing module/input filter can do the job of transforming the URL's into clean/aliased links, that functionality should be removed from Node Picker and the linking method should use more standardized, HTML code. I just ask that an upgrade path or instructions be provided for those of us who have been using Node Picker's input filter. I'm more then happy to help with this effort in whatever way I can.

Sorry again,
-Tim

On one hand, this approach seems very sensible - especially given modules like pathologic. However, I would propose that we allow the format to be plugable of some kind.

There is already an example where people want to be able to link with images (#785736: Allow node-picked links to wrap other elements). In a recent project, we have recently extended nodepicker to allow it to embed different types of nodes with different outputs. In our case, the client wanted to be able to embed teasers of other content into certain nodes - but the format of the teaser is different depending on the type of node. A story node is just an image + text and a gallery node is a slider of images - and we are also looking at passing options/parameters to each teaser to modify output like align left/right.

It would be great to be able to have a plugable formatter option so that these extensions could be cleanly implemented.

Please tell me I'm missing something here, but:
1) a custom tag of the form nodepicker==node/[nid] is robust against changes in URL alias of the node and gets converted to a link with href=the URL alias of the node in question.
2) a link <a>href="/url_alias"</a> is not robust to such changes
3) a link <a>href="/node/nid"</a> is not of the form I prefer (you could use Global Redirect but that misses the point I think)

So my initial thought was that 1) is best. But if this issue is proposing 3) then does something like pathologic sort out the internal Drupal path to path alias conversion? That would be nodepicking nirvana!

Hope I'm not lowering the quality of the discussion here ;)

[update: fixed minor typo]

gpk: Yes, the idea is to produce links like <a href="node/1">Text</a> and let Pathologic do the transformation to URL aliases.

Are you sure that the Pathologic input filter does pathalias transformations on internal links? Does it need to be configured in a specific way to support this? The documentation page here doesn't discuss this scenario. Pathologic module maintainer Garrett Albright answers another user with a similar question in this ticket comment, but I wonder if the url() function will resolve to the correct, aliased path for a new content item that is just created. I guess the question to ask Garrett is: Does the input filter cache get created before the path alias is made available for a new piece of content.

Thoughts?

@not_Dries_Buytaert: Thanks for posting the question to the Pathologic issue queue.

Thanks for the reply/updates. I've just started looking into pathologic and can confirm that it *does* transform unaliased (internal) paths to aliased paths, if pathologic considers the unaliased path to be "local".

@25:
>I wonder if the url() function will resolve to the correct, aliased path for a new content item that is just created. I guess the question to ask Garrett is: Does the input filter cache get created before the path alias is made available for a new piece of content.
I don't really see what the question is here.. usually you are creating a link to *another* page so its URL alias will already exist. Perhaps I'm misunderstanding the point??

However a potential problem I can see is that if page_A (node/1) links to page_B (node/2) then in page_A my link to node/2 gets transformed to page_B. OK so far. But if I edit page_B and change its URL alias to page_BB (or do the same via the site building -> URL aliases screen) then the link in page_A will be incorrect until the entry in cache_filter gets cleared. From what I can make out by looking at the {cache_filter} table, entries therein expire after 24 hours, so the link could remain incorrect for up to a day.

Whether it's possible for pathologic to reliably work round this I don't know ... although the {search_node_links} table tells us which nodes link to page_B (actually it sometimes seems to miss a few out) I don't know how we get the entry/ies in {cache_filter} corresponding to page_A (node 1) to update without emptying the entire table. Even re-saving node_A wouldn't update {cache_filter} because the content of node 1 hasn't changed and so nor will the cid (which is defined as $cache_id = $format .':'. md5($text); in http://api.drupal.org/api/function/check_markup/6).

Also there is no hook for a path being updated though it might be sufficient to use hook_nodeapi() and also add a submit handler to catch the case when an alias is directly updated/added.

Having said all that, this is all still probably rather better than creating all your links by hand in aliased form and then having to go back and e.g. edit page_A when you change node/2 to have alias page_BB.

I wonder how projects like pathfilter get round these problems.

OK, pathfilter doesn't get round the caching problem, it just gives a warning in README.txt:
http://drupalcode.org/viewvc/drupal/contributions/modules/pathfilter/REA...

See #80681: Aliases updated only when page is edited.

Also it looks like this may be fixed in pathologic 7.x-dev, and 6.x-3.x-dev, though from looking at the source I can't for the life of me figure out how! #542984: Problem with output caching. I've not tested 6.x-3.x.

I was just looking for a simple way to create internal links...

So, rather than get bogged down in input filters or use the Pathological module, I just edited the nodepicker module as follows...

FILE:
/sites/all/modules/nodepicker/plugins/nodepicker/nodepicker.js

LINE 45:
var inlineTag = '[nodepicker==' + $self.attr("href") + '==' + encodeURIComponent($self.attr("title")) + '==' + encodeURIComponent($self.text()) + ']';

CHANGE TO:
var inlineTag = '<a href="' + $self.attr("href") + '">' + encodeURIComponent($self.text()) + '</a>';

This ignores any of the potential complications mentioned above - but it does work - and makes things more simple.

Please use this module to convert Node Picker links to static links:

https://github.com/happiness/Node-Picker-Migrate