Enhance support for tokens

The patch looks good apart from the minor issue below (I will fix it myself while committing it). I didn't actually tested it yet, hope to do it soon.

+++ title.module
@@ -467,3 +467,39 @@ function title_form_field_ui_field_overview_form_alter(&$form, &$form_state) {
+            if(!empty($item)) {

Missing space between the if keyword and the condition.

Powered by Dreditor.

+++ title.moduleundefined
@@ -467,3 +467,39 @@ function title_form_field_ui_field_overview_form_alter(&$form, &$form_state) {
+  if ($fr_info && $context['data'][$context['type']]) {

Should use !empty($context['data'][$context['type']]) here as it may not be defined and will throw a PHP notice.

Powered by Dreditor.

subscribe

subscribe

Patch from #6 works fine for me, see http://drupal.org/node/1155134#comment-4648088

Committed to HEAD.

title-add-token-support.patch queued for re-testing.

Hi,

On a multilangual website with the Internationalization, Entity translation, Title, Pathauto and Token modules installed it occurred to me that the title attributes of links in the language switchers were incorrect, so I started digging and noticed something else. I am not sure whether this is considered a bug or not, but I thought it was worth mentioning since it might cause other problems.

In short: when translating a localized term, Pathauto generates a path according to the default pattern for terms [term:vocabulary]/[term:name]. This triggers title_tokens_alter() which calls title_field_sync_get() which sets the term object's name and name_original properties. These changes to the entity object are done to find a replacement for the token, but are also used by code executed after title_tokens_alter() is done.

The effects are:

1. After saving a translated term, an "Updated term [NAME_OF_TERM]." message should appear with the term's name in the source language, but it shows the translated name.
2. Records are automatically created in database tables locales_source and locales_target for this taxonomy term. The source should be in the term's source language, but after saving a translation it's in the language of translation. (NB: I do not know why these records are created, since the target value is empty and translations are stored in their respective field tables)

Though these effects seem rather harmless, it might cause trouble at other levels as well.

Workaround: use the [term:vocabulary]/[term:name_field] pattern.

Possible solution: clone the term object before sending to title_field_sync_get():

title_field_sync_get($entity_type, $entity, $legacy_field, $info, $langcode);
item = $entity->{$legacy_field};

could become:

$cloned_entity = clone $entity;
title_field_sync_get($entity_type, $cloned_entity, $legacy_field, $info, $langcode);
$item = $cloned_entity->{$legacy_field};

Hope this makes any sense!

NB: I tested this on a clean install at simplytest.me with named modules and i18n's submodule Taxonomy translation enabled. I added a 2nd language, set the vocabulary's translation mode to "Localize" and replaced the original name field for this module's name field.

Hi all,

Be aware that the committed patch in #6 might introduce security issue because the token values are not sanitized.

See this thread for more info: #2757739: Token value is not sanitized, when replaced from title field