This module provides a filter and a token replacement. In almost all practical cases, a site will be using other modules to do things like aliasing paths. Because this module passes the resulting path through url, you have to try to deal with language issues, and if using another tool that also passes the path through url() (for example the link module), you'll see the base path doubled.

I'd propose this module simply translate the link to a system uri and allow other modules to format that URI for output. So it should return node/123 instead of the aliased node path. Pathologic, the link module, other filters, etc are then responsible for formatting the rendered link. I've attached a patch that does this.

Alternatively perhaps the filter behaves differently than the token replacement? If there's a use case for just dropping this in content:
[uuid-link:node:<<some guuid>>]
and have it appear as an absolutely formatted link, that makes sense, but if we provide the link module with a uuid link token it should output correctly instead of passing through url() twice. In that case you'd only pass it through url in the filter. Perhaps it becomes an option to the token replace call. It's not documented that token_replace will pass all arbitrary options through to the replacement function, but it does so.

CommentFileSizeAuthor
uuid_link-entity-uri.patch1.5 KBfearlsgroove
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

skwashd’s picture

Status: Needs review » Needs work

I am trying to get a better understanding of the use case/s you're trying to describe. UUID Link basically replicates the functionality of pathologic but with uuid based tokens, so I'm not sure why you would have the 2 modules enabled at the same time.

I have never tried using the UUID Link tokens with the link module. I'd suggest that if you want to link to content within the same site you should be using entity reference instead of link. If you really want to use link for this purpose I'd recommend you use the URL director built into UUID and so the relative URL would look like uuid/[entity-type]/[uuid].

Finally I have some concerns about how this might impact SEO given that without using any other modules the raw [entity-type]/[id] URLs will be rendered in the markup.

As a compromise maybe we can look at making this configurable on a per text format basis. What do you think?

fearlsgroove’s picture

Thanks for following up -- UUID link fixes a specific problem of resolving entities by uuid which is great. Pathologic is still important (for me at least) to standardize base paths to file links and non-entity links (views pages for instance) and a number of other functions. In short, for me at least, this module is very helpful but doesn't replace pathologic, nor should it try. Pathologic has also invested quite a bit in solving the language redirect issue, which this module still seems to have a few issues with (based on issue queue only, I don't actually use multilingual stuff myself).

I use link fields because in a single field, I may want to link to an internal node, an internal file, a path i.e. a view, or an external URL. I often make use of an entity reference when the use case is more clear cut.

Would you consider providing an alternative token that only translates to the entity uri, so the use cases such as the link field still work? So something like [uuid-link:node:(_UUID_HERE__):uri]

skwashd’s picture

I will look at adding a text filter option to disable the url aliasing. The default state will be for the filter to use aliases as the several sites I'm using this module on don't use pathologic.