Feature request as follows:
* Allow the insertion of domain tokens into filtered text, so that domain-specific values may be rendered.
For example:
This is [current-domain:path]
Should render as the following for example.com
This is http://example.com
And as follows for one.example.com
This is http://one.example.com
* Allow the insertion of domain-sensitive url paths, so that canonical urls can be placed in text.
For example:
This is a link to <a href="[domain:node/1]">node 1</a>
Will return:
This is a link to <a href="http://example.com/node/1">node 1</a>
When used with the URL filter provided by core, just inserting [domain:node/1] will return the proper url as a link.
Comments
Comment #1
agentrickardPatch. This has been committed.
Comment #2
agentrickardThe following tasks remain:
* Document the new features.
* Write unit tests for the new features.
* Make the collapsible tips function properly. (See attached)
Comment #3
agentrickardTests committed.
Comment #4
agentrickardScreenshots for use in documentation.
Comment #5
dave reidUm, so this duplicates a lot of work that is already done by http://drupal.org/project/token_filter (and would probably conflict with it). Maybe we should slim this down to only the usage of [domain:node/1] (which might have to get renamed since it uses a 'token' syntax, or make sure to weight it above the token filter).
Comment #6
dave reidPatch to remove the domain token filtering, and use the token browser in the domain editing form for the domain classes if available.
Comment #7
agentrickardWith token filter, you can use [node:url] or similar, can't you? (Maybe not, since you can't specify the path...
Comment #8
agentrickardI wonder if we can add this via an alter hook to the token_filter() list?
Comment #9
dave reidActually I think the [domain:node/1] handling is probably better handled by something like http://drupal.org/project/pathologic or http://drupal.org/project/pathfilter, the latter provding 'internal:node/1' as a filter.
Comment #10
agentrickardI'd like to keep the domain-sensitive URL filter. I don't like forcing people to install a module for such a small feature.
I am also confused, because the domain tokens don't "work" with Token Filter, which simply says "Global tokens will be replaced with their respective token values (e.g. [site:name] or [current-page:title])."
That doesn't seem very usable to me.
Comment #11
dave reidThe [current-domain:*] and [default-domain:*] tokens which are currently being replaced with the feature are global tokens. Are you sure they don't work?
Comment #12
dave reidThe reason I advocate getting ride of the domain filter as really it's just running through url() which several other filters can do too. I'm also worried that the [domain:path/to/item] will get confused for a token.
Comment #13
agentrickardThey may _work_, but there is no UI indication that they are available for a node.
On the Domain settings, page, the formatting is lovely, but introduces a dependency on Token module, and it doesn't show the 'current' / 'default' versions of the tokens.
I would (as a user) like to see the available list of tokens on the filter list, not on the advanced info list. (My plan here was to use a collapsible fieldset to show/hide the list.)
Comment #14
agentrickardSkitch fail.
Comment #15
dave reidOh, I made an incorrect change to the CSS part of the admin UI. The difficult thing with the token filter is we didn't want to put the full list of tokens in the help. But if you click the 'More information about this text format' you'll get the list. This seemed the proper way to handle this.
Comment #16
agentrickardI would rather have the full list expandable in the help, otherwise, i find it burdensome, but that's not necessarily relevant.
I'm wondering if these lines introduce a Token module dependency, or if this is handled by core.
Comment #17
agentrickardHere's a compromise patch which does the following:
* Removes a hard dependency on token.module from the last patch. (Though it's better with Token installed.)
* Changes the url filter string to [canonical-url:path], which is a nice-to-have that I'm going to leave in.
* Runs an update function to replace [current-domain:] with [domain:] in the setting.
* Ensures that [domain:] tokens run properly if $data['domain'] is not provided. (Which can happen in some situations.)
Tests all pass, should be RTBC.
Comment #18
dave reidYeah we can fix token_filter to display the token help on the same page as the text field - not a huge issue. I would still recommend using the [current-domain] tokens in the CSS classes - that was a mistake I made in the original rollback patch.
Comment #19
agentrickardAlright. Fixed and re-committed.
Comment #20
agentrickard