[Push #1]: Automatic url conversion to internal links

I had the same problem, and solved it slightly differently, before I saw your post here. I'm attaching my patch so the community can compare the approaches and maybe come up with the best possible.

If I understand your patch correctly, it will work only on nodes, while mine automatically converts URLs in any form. For example, when defining a block. My approach is rather simple, and does not distinguish between forms that actually use pathfilter and those that don't. Also, I don't convert the URLs back when editing a node the way your patch does.

+1 for this feature,

marking #283275: transparent link change into internal links. as duplicate

the following issue might be of infuence on this issue #127484: [Push #2] pathfilter for files directory

if we go for an setting where it would work on all input's, we need a blacklist/whitelist where (not) to use it.

also #0, your code has something.com, please use example.com per http://drupal.org/coding-standards (Example URLs)
also #1 has a closing [code]?>[/code], please remove this, see http://drupal.org/coding-standards (PHP Code Tags)

_normalize_and_internalize and _internal_replacement_re do not have pathfilter prefix.
also, you might want to think about the function names.... function_does_this_and_that should preferably be split into function_does_this and function_does_that

BTW, i think #127484: [Push #2] pathfilter for files directory should go in first.

#402296: Call for Action: Get Pathfilter Additional Functionality in before D7 makes pathfilter obsolete (Pathfilter in Core???)

So, I took the patch at #6 and updated it to work with the latest CVS. I had to make some changes in order to get it to work correctly (or at least, to make it do what my understanding of this patch is). For a start, I added support for translating to and from 'files:' style paths (#127484: [Push #2] pathfilter for files directory). Secondly, I use drupal_get_normal_path(), in order to ensure that the path that gets re-saved to the node uses the system path where possible, and not a path alias, since that is kinda the whole point of this module.

Now, I'm not sure why the original patch included class.pathparser.php - I think I managed to do just fine with PHP's native parse_url() function - correct me if I'm wrong.

Personally I don't really like the way this patch works (any of the versions on this thread) as they seem to a lot of unnecessary work. This version runs on every single property of a node - why? The input filter isn't set to run on every node property... The version at #1 runs for every single form textarea field! It just doesn't seem right somehow. I know there was talk about a whitelist/blacklist type functionally, and I think that is certainly a must if a patch more like the one at #1 is to be used.

I think we need to remember, Path Filter is an input filter - that is to say that users choose where they want this functionality to be performed and where they do not. None of these variations seem to respect that, but that is not to say that this module should not be performing more functionality than that of a simple input filter. Is the purpose of this module to provide a sitewide mechanism for entering internal links? Or, is to provide an input filter? or, is it/can it be/should it be both, or a combination of the two?

As I understood it, the original reason for this patch was to ensure that WYSIWYG text editors can work in harmony with the input filter...

ps. my patch is very very untested - actually, I literally only tested it with the following paths:

<img src="http://www.example.com/sites/sandbox.6/files/image.jpg">test</img>
(which translates to 'files:image.jpg' on editing of the node, and back again on saving)

<a href="http://www.example.com/content/page1">test</a>
(which translates to 'internal:node/[nid]' on editing of the node, and back again on saving)
 

EDIT: Sorry, got those examples the wrong way round... 'internal:node/[nid]' translates to http://www.example.com/content/page1 on editing, and back again on saving etc.

@harking: Thanks for posting this. However, there are quite a few major changes in the way the latest -dev version works (for both Drupal 5 and 6) so an update of this patch is a must before this can be considered for inclusion. Not only has the files: syntax been introduced, but preg_replace is no longer used as the means for performing the replacement, preg_replace_callback() is used instead as it is a) faster, and b) more flexible.

I also really think you need to look at using drupal_get_normal_path() when you are internalizing urls in order to be sure you are storing the actual internal path, and not a path alias (check my version of the patch).

EDIT: Also, you really shouldn't use a function name like _replace_links - you need to work within the pathfilter namespace, so that should be _pathfilter_replace_links()

It would be great if this module could also handle file paths embedded in CSS style statements i.e. background-image:url(internal:/sites/default/files/images/homepage_1100.jpg)

@adavis.co.uk: Please create a seperate ticket for your feature request. It has nothing todo with this ticket.

It would be great if this module could also handle file paths embedded in CSS style statements i.e. background-image:url(internal:/sites/default/files/images/homepage_1100.jpg)

I think I found a problem with this.

1. Create the following node

/test-node
<a href='/node/176'>linke to test node</a>

2. Save and view the node. Note that the link is to the nodes alias (/test-node in my case). Fine.
3. Look in the node_revisions table of your database and notice that it's been saved as internal:node/176. Fine.
4. Edit the node again - note that the link is now showing as a full, absolute url to the. Again, this is expected right?
5. But, now, save the node again (don't make any changes)
6. View the node and note that it's still linking to the node by its path alias, /test-node.
7. However, look in the database and you'll see that this time it's been saved as 'internal:test-node' - we have now lost the original link, which used the node id - the main purpose of the module!

It should always save the node in the format 'internal:node/[nid]' - and not the alias to the node. Otherwise, if the alias to the node changes, the link will be broken.

I've commited this to CVS now and will release a new beta shortly.

Marked #109992: Replace regular internal paths with URL aliases as a duplicate.

Does this filter change user entered code on submit? I was told Drupal doesn't change on input and only on output... only to make sure content is saved as entered. Sounds like you solved #517174: Auto-update could prefix urls and integrate with other modules?

If you have the 'Enable automatic url processing for attributes' checkbox ticked in the input filters configuration page (new in 6.x-2.x), then it does alter user entered code on submit. In this case, it will transform links into the internal: on submit, thus taking the job of adding internal: away from the user. Upon editing the node again, all internal: links are changed back to absolute paths/urls to ensure that WYSIWYG editors work correctly with any referenced nodes/files, and on submit they are once again converted to internal: links.

@hass: I'm not really sure I understand the problem being described at #517174: Auto-update could prefix urls and integrate with other modules

#517174: Was the idea to build this feature for pathologic and pathfilter... :-). If linkchecker updates broken links with 301 urls it saves the nodes. Than your filter need to hook in between and change from "base path/path" to "internal:path". I hope this works now...

The pathologic maintainer don't liked to implement such a conversion filter on save... for the reason that this is not a Drupal way.