Users have requested the ability to use Tokens for Amazon's ASIN field, most often for use with the Automatic Node Title module.

The following issues were opened requesting Automatic Node Title and Token support.
#392524: Add token support for automatic node title
#991994: Using Auto NodeTitle with an Amazon CCK field to generate title (and using ISBN-13)

Alternative solutions to CCK tokens were presented in the above issues. In #392524, rfay requested to open a new issue for patches.

Proposed resolution

This issue is to provide a patch to implement CCK field tokens for the ASIN field. This eliminates the need to use the solutions presented in #392524 and #991994, which required placing PHP code within "automatic title generation" field or creating a custom module.

Detailed information on the new Token functionality can be found at

Remaining tasks

User testing and feedback on the latest provided patch in Drupal 6 is needed.

Though originally this issue attempted to tackle D6 and D7 tokens, this issue now only applies to D6. Patches provided for D7 in this issue are no longer valid due to a change in the Token API.

For CCK field Token support in D7, see #1014036: Port token support to D7

Original report by cristinawithout

Sorry I couldn't do this sooner. I finally got some free time today, so here's a patch that implements tokens in the same manner that other CCK fields do so Amazon fields can used used . Regarding the issue of it needing to know the number, I believe it's safe to use item 0 for two reasons: 1. Why would anyone expect it to use a different number? 2. Other CCK field types use this behavior, therefore, it shouldn't be unexpected.

Anyway, I'm a PHP developer who's now doing Drupal, so forgive me if there's anything wrong with this patch or how I've submitted it.

Members fund testing for the Drupal project. Drupal Association Learn more


cwithout’s picture

3.25 KB

Oops. I named that patch with the number of a different issue I was looking into. This patch is the same, just a different file name.

rfay’s picture

Thanks for doing this!

If you can actually get tokens to do anything, I'll be much appreciative for you to explain how.


cwithout’s picture

I just noticed I had some mistakes in that patch (wrong variable name and left out ISBN from values). So here's a patch that fixes them.

I'm not sure if this is what you're asking, but the patch will allow you to use tokens anywhere you can use other CCK field tokens. So in places like Automatic Node Title or URL Aliases, you'll have all the Amazon options available to use as [field_isbn-title], [field_isbn-listprice], etc. (It'll use whatever your field name is, and you'll see it in the list of available token replacements.)

What's happening in the patch is: If you look at the CCK module inside includes/ at the function content_token_values(), you'll see this:

       $function = $field_types[$field['type']]['module'] . '_token_values';
        if (!empty($items) && function_exists($function)) {
          $token_values = (array) $function('field', $items, $options);
          foreach ($token_values as $token => $value) {
            $tokens[$field_name .'-'. $token] = $value;

Basically, CCK is taking the fields types (in the case of this module, that field type is 'asin') and calling the function [field_type]_token_values. So in this module, we need a function called asin_token_values and asin_token_list to go along with it. Then we get the Amazon info from the value of the field and assign those values to the tokens.

Is that what you wanted to know?

rfay’s picture

Fantastic! Just what the doctor ordered.

When this goes in, it will need to be added to the documentation page, explaining how to use tokens.

cwithout’s picture

Good news. For D7, I've got this partially working with the the patch in #92 at #691078: Field tokens. I need to clean it up and do some more testing, but it looks like it'll work after that patch to the Token module.

cwithout’s picture

Assigned: cwithout » Unassigned
2.7 KB

This should handle d7 tokens. I'm not exactly sure how to handle adding another file to the module, so I just zipped the new file with the patch to the .info file. Of course, I can add it to the .module file if you prefer, but I've noticed other modules separating them out into a It seems to keep things more organized.

I noticed ISBN and EAN, which were available from the amazon_item_lookup() in d6 were no longer available. So I left them out and added in the info I saw that was available.

We can do testing on this patch with the patch to the Token module, but this is nothing final until after Token rolls its patch.

EDIT: Do not use this D7 patch. The Tokens module has not decided on a means of implementing tokens, and the final decision will most likely make this patch unusable.

rfay’s picture

A patch can include new files - that's fine.

And if ISBN-13 (EAN) doesn't work in D7 it's a bug. Should work.

Anonymous’s picture

40.73 KB

@#6, about the D7 patch, thanks for this, but I can't get it to work. I added the line files[] =, and activated the token module. Refreshed cached. The function are called, but where can I select the new tokens? Can't see them in the admin interface (attached).

rfay’s picture

The "files =" lines are no longer required in D7's info files except when the file defines a class that should be autoloaded.

Anonymous’s picture

Ok, skip that, you have to add this patch too.

rfay’s picture

Status: Needs review » Needs work

Took a look at #3 and it seems fine to me... But it should be in asin.module, not amazon.module, right?

Thanks very much for your patch, and sorry it took me so long to look at it.


+++ amazon.module	28 Jan 2011 18:37:02 -0000
@@ -849,6 +849,66 @@ function amazon_token_values($type, $obj
+    $tokens['asin']['amazonprice'] = t('Current price offered by Amazon');
+    return $tokens;
+	  ¶
+  } ¶

Whitespace errors - if you wouldn't mind fixing them up too.

Powered by Dreditor.

cwithout’s picture

Assigned: Unassigned » cwithout

Just saw this. You're right. It does go in asin.module. Don't have time to do patch right now, but assigning so I remember later.

D7 version still relies on fully functional Token support, which remains unresolved.

cwithout’s picture

Status: Needs work » Needs review
3.29 KB

New patch.

rfay’s picture

Assigned: Unassigned » cwithout

@cristinawithout, thanks for your work on this. I'm a little confused about where we're at. #13 is a 6.x patch?

Could you please update the issue summary (edit the node) and explain the 6.x and 7.x issues and where we should go with them? The Issue summary template may be helpful.

Thanks so much for your help on this. I look forward to getting your work committed.

rfay’s picture

cwithout’s picture

Issue summary: View changes

Add issue summary.

cwithout’s picture

I added the issue summary. Hope that helps.

You're right. The patch is for D6 only. D7 Token support for CCK fields is in limbo right now. I had a patch that used a previous method they were going to implement, but they've scrapped it since then.

Since there's #1014036: Port token support to D7, I think this one should stick to D6 and keep future all D7 Token talk and patches within that issue.

rfay’s picture

Should we just rip out the existing amazon_token_values() and amazon_token_list()? I never was actually able to figure out how to use them for anything useful :-)

Thanks for the issue summary and for keeping me on track where this goes.

asb’s picture

What's the status of the issue? I noticed that 6.x-1.3 exposes 'Amazon' tokens, e.g. to the 'Page Title' module, but they can not be used.

Error message when using the tokens [label] and [binding]: Das %element-Title ist mithilfe die folgenden ungültigen Token: [label], [binding]. (localized message, not understandable even in German; the original error message string is probably: The %element-title is using the following invalid tokens: @invalid-tokens.).

Is this an issue of the 'Page Title' module, or does the patch from #13 target problems like this?


rfay’s picture

@asb did you try #13 ? If so, please let us know what your results are.

asb’s picture

@rfay: Actually no as I do not understand what this issue is about. It is labeled as a feature request against the dev release, but the latest stable release of 'Amazon' module already exposes it's tokens. However, these token do not work for me, so it'd be either a bug report against 'Amazon' module regarding existing functionality, or against 'Page title', 'Token', or anything else which causes an incompatibility. Or I don't get the point of this issue ;)

Anyway, I upgraded to the current dev release, ran update.php and tried to apply the patch from #13 without success. Running from within ./sites/all/modules, it can't find file to patch at input line 14 (running as patch or patch -p0). With patch -p1 I get:

# patch -p1 < asin-field-tokens-1043030-13.patch
patching file asin/asin.module
Hunk #1 FAILED at 514.
1 out of 1 hunk FAILED -- saving rejects to file asin/asin.module.rej

Contents of asin/asin.module.rej:

*************** function theme_asin_autocomplete($element) {
*** 514,516 ****
    return theme_asin_text($element);
--- 514,572 ----
    return theme_asin_text($element);
+ /**
+  * Implementation of hook_token_list()
+  */
+ function asin_token_list($type = 'all') {
+   if ($type == 'field' || $type == 'all') {
+     $tokens = array();
+     $tokens['asin']['asin'] = t("Product ID");
+     $tokens['asin']['title'] = t("Title retrieved from");
+     $tokens['asin']['isbn'] = t("The 10-digit ISBN (INternational Standard Book Number)");
+     $tokens['asin']['ean'] = t("The EAN or 13-digit ISBN");
+     $tokens['asin']['detailpageurl'] = t("The detail page URL for the item");
+     $tokens['asin']['salesrank'] = t("The product's sales rank");
+     $tokens['asin']['brand'] = t("The product's brand");
+     $tokens['asin']['publisher'] = t("The product's publisher");
+     $tokens['asin']['manufacturer'] = t("The product's manufacturer");
+     $tokens['asin']['studio'] = t("The product's studio");
+     $tokens['asin']['label'] = t("The product's label");
+     $tokens['asin']['binding'] = t("The product's binding type");
+     $tokens['asin']['releasedate'] = t("The product's release date");
+     $tokens['asin']['listprice'] = t("The product's list price");
+     $tokens['asin']['producttype'] = t("The product's Amazon product type");
+     $tokens['asin']['lowestprice'] = t("The lowest price currently offered by any merchant at Amazon");
+     $tokens['asin']['amazonprice'] = t("Current price offered by Amazon");
+   }
+ }
+ /**
+  * Implementation of hook_token_values()
+  */
+ function asin_token_values($type, $object = NULL, $options = array()) {
+   if ($type == 'field') {
+     $item = $object[0];
+     $asin = amazon_convert_to_asin($item['asin']);
+     $amazonArr = amazon_item_lookup($asin);
+     $item = $amazonArr[$asin];
+     $values['asin'] = check_plain($item['asin']);
+     $values['title'] = check_plain($item['title']);
+     $values['isbn'] = check_plain($item['isbn']);
+     $values['ean'] = check_plain($item['ean']);
+     $values['detailpageurl'] = check_url($item['detailpageurl']);
+     $values['salesrank'] = check_plain($item['salesrank']);
+     $values['brand'] = check_plain($item['brand']);
+     $values['publisher'] = check_plain($item['publisher']);
+     $values['manufacturer'] = check_plain($item['manufacturer']);
+     $values['studio'] = check_plain($item['studio']);
+     $values['label'] = check_plain($item['label']);
+     $values['binding'] = check_plain($item['binding']);
+     $values['releasedate'] = check_plain($item['releasedate']);
+     $values['listprice'] = check_plain($item['listpriceformattedprice']);
+     $values['producttype'] = check_plain($item['producttype']);
+     $values['lowestprice'] = check_plain($item['lowestpriceformattedprice']);
+     $values['amazonprice'] = check_plain($item['amazonpriceformattedprice']);
+     return $values;
+   }
+ }
rfay’s picture

Here's cristinawithout's #13 rerolled for current code. I haven't tested it.

We don't use patch -p0 any more since we moved to git. You'll want to do a git apply most of the time; patch -p1 does work, but you're better to move to git.

asb’s picture

Status: Needs review » Needs work

Git what? Oh I miss the old front page where changes like this were announced...

# git apply amazon.tokens_1043030_21.patch 
amazon.tokens_1043030_21.patch:5: new blank line at EOF.
warning: 1 line adds whitespace errors.

Assuming that this warning does not indicate something essential, I'm afraid the patch still doesn't fix the issue with the 'Page Title' tokens (same error as quoted in #18), or there is an incompatibility with 'Page Title'.

Anyway, thanks to both of you for working on this issue!

rfay’s picture

@asb, I have to assume that you're pulling my leg about having missed the git migration... But anyway there's lots of documentation about how to use git, on every project under the "revision control" tab, and at It was like a year's effort, with the migration completing last February.

asb’s picture

I am aware that the repositories were migrated from CVS to git, but until now I was not aware that git comes with its own patching mechanism. I believe that, like me, most non developers simply assume that stuff like source control doesn't concern them. At least until we're forced out of the state of denial ;)

To not drift completely into off-topoic smalltalk, I updated 'Amazon' module on another site to the current dev release and applied the patch before running update.php (with "amazon_update_6016 - Increase the length of the mpn field"):

# git apply -v amazon.tokens_1043030_21.patch 
Checking patch asin/asin.module...
Applied patch asin/asin.module cleanly.

However, the tokens still do not work als replacement patterns in 'Page Title', and they're not even exposed to 'Pathauto' (pathauto-6.x-1.5; recommended & supported release, but old & many issues). This applies to an environment with Pressflow 6.22 and token-6.x-1.16.

crosssover’s picture

Any news on this issue?
I'm having the same problem here using Amazon Module 6.x-1.3
Token 6.x-1.16 and Pathauto 6.x-1.5

cwithout’s picture

@asb - I just downloaded and installed 6.x-1.3. The support for Tokens in that version are the Tokens, which up to this point, no one has been able to determine a good use for and rfay has considered removing. I'm not sure how those should work with Page Title or if it there's any possibility that they even could. I was of the opinion that maybe those should stay in case someone actually is using them for something. But maybe it's best if they're taken out to avoid causing confusion, if no one can mention an actual use for them.

The issue/patch is meant to add Token support for the Amazon CCK fields. So when you're setting the page title (on admin/settings/page-title), the Tokens show up under "CCK asin" rather than "Amazon_item". Your token will be something like "[field_myfield-binding]" rather than "[binding]". This is the same as tokens for other CCK fields.

I tried out the patch and discovered the line "return $tokens;" was missing. It was in my working copy, but someone left out when I made the patch.

Here's an updated patch against dev with that necessary line. I was able to apply successfully using "patch -p1 < amazon-field-tokens-1043030-25.patch"

Clear cache after applying patch.

rfay’s picture

Status: Needs work » Needs review

@cristinawithout Thanks!

Could you please give us a step-by-step testing technique for this?

Do I understand correctly that field tokens in D6 are fairly well established, but that the approach to them in D7 is pretty much not done yet?

cwithout’s picture

Status: Needs review » Needs work

@crossover - I was able to successfully use the Amazon field tokens with Pathauto as well with this latest patch.

Please test it for your needs so we can find out whether it works and get the functionality into a release.

cwithout’s picture

Status: Needs review » Needs work
254.81 KB
308.21 KB
557.66 KB

@rfay - It appears field tokens in D7 has a beta release as of Aug. 17, so it's possible work could be started on the D7 version. Or we could wait for it to make it to full release.

Yes, D6 field tokens are well-established. We can include d6 support at any time and port d7 support later.

To Test:

  • Install/enable Amazon 6.x-1.x-dev. Also CCK, Tokens and any module that uses Tokens, such as Automatic Nodetitles, Pathauto, Page Title, or any other you know of.
  • Upload patch to the 'amazon' module directory.
  • From ssh, cd to 'amazon' directory and run "patch -p1 < amazon-field-tokens-1043030-25.patch"
  • In Drupal admin (admin/content/types), one or more Amazon fields to any content type

Depending on the module you're testing on, there will be different steps for testing at this point. (All of the 3 mentioned above can be installed at once)

For Automatic Nodetitle:

  • Go to the node edit form. (admin/content/node-type/[node type]) Content management > Content Types > edit
  • Expand "Automatic title generation"
  • Select "Automatically generate the title and hide the title field"
  • Expand "Replacement patterns"
  • Copy/paste the CCK asin tokens into the "Pattern for the title" box.
  • Create/edit content to see if the node title is set according to the tokens.

For Page Title:

  • Got to admin/settings/page-title
  • Expand the "CCK asin" arrow at the bottom so you see all your available tokens.
  • Copy/paste the tokens into the corresponding "Content type - [content type]" text box above"
  • Create/edit content to see if the page title (the HTML title tag) is set according to the tokens

For Pathauto:

  • Go to admin/build/path/pathauto
  • Expand "Node paths"
  • Expand "Replacement patterns"
  • Expand "CCK asin"
  • Copy/paste the tokens into the corresponding "Pattern for all [content type] paths" text box above"
  • Create/edit content to see if the URL alias is created based on the tokens (make sure the node has "Automatic alias" checked under "URL path settings"

- Multiple tokens can be used at the same time in combination with other characters, such as commas, colons, etc.
- Only ASIN or ISBN-13 seem to work when you create the content. ASIN 10 doesn't. Just go to and grab random numbers when populating content.

I'm not sure if they'll be helpful or not, but I attached screen shots of the edit forms for each with all the asin field tokens listed. In this example, there are 2 asin fields on this content type: 'field_asin' and 'field_asin2'

asb’s picture


Install/enable Amazon 6.x-2.x-dev release...

Is there really such a realease, or do you mean amazon-6.x-1.x-dev?

Regarding the token-enabled modules, it might be relevant as well which version you are (or: we should) use/ing, many of them are seriously broken for years, and some maintain different branches (like 'Pathauto') at the same time.

Regarding the patch from #26: it applies cleanly against amazon-6.x-1.x-dev; I'll check if Tokens are working in Nodewords, Pathauto, and the like, and report back later. Maybe then I even can remember what I originally tried to accomplish with this two weeks ago ;)

And, btw, thanks for the new patch!

asb’s picture

This is pretty exciting, so I did a quick look with pathauto 6.x-1.6 and the node pattern "[field_asin-title]"; doesn't work for me, gives an URL alias like ...%5Bfield_asin-title%5D.

Also, the Array (like provided at ./admin/settings/amazon/test) does only partially match the exposed tokens; e.g. the (imho pretty useful) strings from [creator] and [participants] are missing. I'm using, so ASINs from other countries or even other product groups might behave different.

cwithout’s picture

While I was testing, I came across something that had an ampersand (Label on ASIN 1451648537). Seems fine for Pathauto Page Title. But isn't compatible with Automatic Nodetitles. Because check_plain() converts the ampersand to its HTML entity equivalent, when it's displayed as the node title, it gets double encoded and comes out &amp;.

There might be some cases where the HTML entity is desired and some where it's not. So it occurs to me that we might need 2 token versions: one with and one without HTML entities.

If so, what name should be used to differentiate the 2 types of tokens in a way that people would understand? Most field types have "formatted" vs "raw" options. For example, a field's raw option would use its value exactly as-in without check_plain(). Currently, the Amazon field tokens are using check_plain(), which is where the html entity is coming from. I don't think Amazon fields should be truly "raw" content, since it's coming from an external source. So I think it's best to do check_plain() then decode_entities() afterward for the decoded version of the token. (It seems like a lot of overhead, but necessary for security.) Calling the token "raw" might be more familiar to people used to "raw" tokens. Or it might confuse people when what's returned isn't truly "raw".

So should we use "raw" or another nomenclature, such as "decoded"?

Example: You'd have 2 options for each token: [field_asin-title] and [field_asin-title-raw] (or [field_asin-title-decoded])

cwithout’s picture

@asb - Is your Amazon field called "asin"? That's just an example of what the token would be. The exact token depends on the name of your field. Your result is what I would expect if either the patch isn't installed or you've not used the name of your field. For example, if your field is called "field_amazon", your token would be "[field_amazon-title]". If your field is "field_book", your token would be "[field_book-title]".

When you go into the Page Title admin page at admin/settings/page-title, at the bottom of the page, is there "CCK asin" listed where it shows the available tokens? You should see something like this. You can copy/paste the tokens from that list. Those are specifically generated from your field names (or use put your cursor in the field and click on the token).

asb’s picture

211.27 KB

@cristinawithout: Yes, the field's name is actually 'field_asin' (actually there's also another one of field type 'Amazon item', 'field_legacy_asin'). Attaching a screenshot of the exposed tokens for those two 'Amazon item' field types.

Promise: I'll do more tests tomorrow, with the recently updated pathauto 6.x-2.0, nodewords, page title and the like. But I want to have backups of my sites (today I killed a couple of thousand taxonomy term URL aliases because I believed for some irrational reason that bulk alias generation would work in 6.x-2.0 as advertised, but (of course) it didn't, and I didn't make a backup prior to believing ;)

rfay’s picture

Status: Needs work » Needs review

Accidentally set to needs work in #28

crosssover’s picture

@crossover - I was able to successfully use the Amazon field tokens with Pathauto as well with this latest patch.

Please test it for your needs so we can find out whether it works and get the functionality into a release.

After Patching It's woking like a charm
Thanx a Lot Cristina !

cwithout’s picture

@asb - That's strange that it shows the available Tokens but isn't converting them. If the token system recognizes that the tokens are there and gives you a list of them, it should be swapping them -- even if the data returned was empty, it should replace the original token text.

I'm using it with Pathauto 6.x-1.6. What version of Token do you have? I have Tokens 6.x-1.17. Do tokens for other CCK field types work for you?

I missed comment #30 before now. I'm using the latest versions of all modules for my testing on a clean install. Testing with different versions of the other modules is good though, because it'll tell us if there are any issues with certain versions. Tokens support in d6 hasn't really changed that much in quite awhile. So even slightly older releases of those modules should work.

(And yes, I meant the dev. I'm working on quotes for 2 other projects as well a couple patches right now, so my comments are bound to not be flawless. )

If you want a dev server for testing, there are some services that make it quick to set up and let you skip most of the tedious steps of setup. I use webenabled. You can get a free account for 30 days. (It gets reset every 30 days.)

I don't really use the Amazon module. I just needed it for one site, which I handed off to the client's staff for maintenance and inputting data. Haven't had a need for it since, so I never even noticed that test page at admin/settings/amazon/test. Thanks for pointing it out. That'll come in handy for data verification.

The tokens that are currently available are pretty much just a direct copy of the ones that were available from those original Amazon tokens. I might be able to add the others as long as they're returned from the function amazon_item_lookup(). That could be the function that test page is using for its data or if not, I might be able to use what it's using. I don't see "creator" returned in the data array on that test page though.

I'm wondering if the data returned from Amazon is different for different product types?

asb’s picture

OK, is back again... there seems to be no amazon-6.x-2.x-dev:

# drush dl amazon-6.x-2.x-dev
Could not locate specified project version, downloading latest stable version...

So this was a typo and we're supposed to be working with amazon-6.x-1.x-dev (please correct me if I'm wrong). I just tried this on another site; environment: Pressflow 6.22.x, Token 6.x-1.17, Token actions enabled (this release of 'Token' might have intrduced a regession, at least it broke some 'Automatic Nodetitles' for me that were working before).

For this example, I'm working with ASIN 3931792048 from

Full array from ./admin/settings/amazon/test:

    [asin] => 3931792048
    [isbn] => 3931792048
    [ean] => 9783931792046
    [salesrank] => 163670
    [detailpageurl] =>
    [listpriceamount] => 1290
    [listpricecurrencycode] => EUR
    [listpriceformattedprice] => EUR 12,90
    [lowestpriceamount] => 1280
    [lowestpricecurrencycode] => EUR
    [lowestpriceformattedprice] => EUR 12,80
    [amazonpriceamount] => 1290
    [amazonpricecurrencycode] => EUR
    [amazonpriceformattedprice] => EUR 12,90
    [binding] => Gebundene Ausgabe
    [brand] => Trixie
    [iseligiblefortradein] => 1
    [label] => Bede
    [manufacturer] => Bede
    [numberofpages] => 120
    [productgroup] => Book
    [producttypename] => ABIS_BOOK
    [publicationdate] => 2000-10-06
    [publisher] => Bede
    [sku] => 320674012954999
    [studio] => Bede
    [title] => Mein gesunder Nordischer Schlittenhund
    [author] => Array
            [0] => Peer Anderson

    [participants] => Array
            [0] => Peer Anderson

    [imagesets] => Array
            [smallimage] => Array
                    [url] =>
                    [height] => 75
                    [width] => 56

            [mediumimage] => Array
                    [url] =>
                    [height] => 160
                    [width] => 120

            [largeimage] => Array
                    [url] =>
                    [height] => 180
                    [width] => 135


    [editorialreviews] => Array
            [0] => Array
                    [source] => Product Description
                    [content] => Das Hundebuch "Mein gesunder Hund". Im Gegensatz zu vielen anderen Rassehundbüchern setzen die Autoren hier den thematischen Schwerpunkt auf Gesundheitsvorsorge, bzw. Vorbeugung und Behandlung rassespezifischer Krankheiten und nicht auf Zuchtziele und -merkmale der jeweiligen Hunderasse. Weitere Inhalte: * Die Auswahl eines Hundes * Artgerechte und sinnvolle Erziehung * Gesunde Ernährung und Nahrungsergänzung * Erste Hilfe Je Titel 120 Seiten und ca. 100 Farbabbildungen


    [customerreviews_iframe] =>

My goal is to get a node title like

Peer Anderson: Mein gesunder Nordischer Schlittenhund (2000)

respectively an URL alias like


The example node is live at Please note that this is a "dummy node" which only consists of an ASIN field. The text is automatically generated via Views and the Amazon tokens exposed to Views. These tokens are:

Amazon: ASIN 
Amazon: All participants 
Amazon: Amazon Price (numeric) 
Amazon: Amazon price (formatted) 
Amazon: Aspect ratio 
Amazon: Audience rating 
Amazon: Binding 
Amazon: Customer reviews iframe 
Amazon: Detail page URL 
Amazon: Dewey decimal number 
Amazon: EAN (13-digit ISBN number) 
Amazon: ESRB age rating 
Amazon: Edition 
Amazon: Editorial content 
Amazon: Editorial review source 
Amazon: Genre 
Amazon: Hardware platform 
Amazon: ISBN number (10-digit) 
Amazon: Invalid ASIN 
Amazon: Label 
Amazon: Label 
Amazon: List price (formatted) 
Amazon: List price (numeric) 
Amazon: Lowest price (formatted) 
Amazon: Lowest price (numeric) 
Amazon: Manufacturer 
Amazon: Number of discs 
Amazon: Operating system 
Amazon: Pages 
Amazon: Part number 
Amazon: Participant name 
Amazon: Participant role 
Amazon: Platform 
Amazon: Product group 
Amazon: Product image 
Amazon: Product type name 
Amazon: Publication date 
Amazon: Publisher 
Amazon: Region code 
Amazon: Release date 
Amazon: Running time 
Amazon: Sales rank 
Amazon: Studio 
Amazon: Studio 
Amazon: Theatrical release date 
Amazon: Titel

The return values greatly differ depending on product type, product age, etc., so I worked a lot with field rewriting and the "hide if empty" feature which is broken in the recently released views-6.x-2.14.

However, the number of tokens in Views and tokens in other places greatly differ. The tokens we get for Pathauto and the like are just a very small subset of the array from Amazon API respectively what we get in Views with a relationship on the ASIN field.

a) nodewords-6.x-1.x-dev (please notice that all "stable" releases are broken beyond repair, so nodewords will only work, if at all, with nodewords-6.x-1.x-dev or nodewords-6.x-2.x-dev).

Nodewords does not allow node type specific sources for meta tags, and the current dev release seems not even to support tokens. However, it processes terms in taxonomy vocabularies, so it might be possible to bridge between Amazon tokens and website meta tags if one would get at least some Amazon tokens into taxonomy. Nice idea, but largely outside the scope of this issue.

b) pathauto-6.x-1.6.

Tokens exposed at ./admin/build/path/pathauto:


So tokens for [author] and [participants] are missing (that's the one I'd like to use); from [publicationdate] I'd only need the YYYY value, so I can only use [field_legacy_asin-title] in the URL alias, and this works on this site. However, in my use case the node title equals the Amazon "title" token anyway, so I could use the [title-raw] token as well. Tokens for stuff like [author] and [participants] would be a real enhancement, though.

c) auto_nodetitle-6.x-1.2. At ./admin/content/node-type/amazon-node, exactly the same tokens are exposed as in pathauto, so again I'm missing [author], [participants] and the like for my use case. Since 'Automatic Nodetitle' allows to evaluate PHP expressions, someone with proper coding skills might be able to extract the YYYY part from the [field_legacy_asin-releasedate] (obviously doesn't work with a simple str_replace()), but as is I have no use for any of the provided tokens other than [field_legacy_asin-title].

However, the [field_legacy_asin-title] token is properly replaced in the node title field.

d) page-title-6.x-2.5 is more interesting since it makes sense to put additional information in the page title. Again the same tokens are exposed, and to make proper use of [field_legacy_asin-releasedate] I'd need a different date formatting. But I can add the publisher and the (unformatted) ISBN number to the page title:

[page-title] by [field_legacy_asin-publisher] (ISBN [field_legacy_asin-ean]) - Product | [site-name]

It'd be nice to replace "Product" by a more specific product category, but the [productgroup] token isn't exposed (and wouln'd be localized anyway). So I can add [binding]; [field_legacy_asin-producttype] returns no value.

For all those places where tokens are used it is a long standing feature request to allow conditions, especially a "hide if empty" option. This would greatly enhance the potential of tokens with unsure return values (which are characteristic for the data returned by Amazon API). However, this has not been implemented yet so the practical use cases are pretty much limited. The narrower the types of data you are using, the more use you can make of the available tokens (e.g. books only).

The main problems of the current token implementation for the 'Amazon' module are a) there's too much missing, and b) there might be some encoding issues.

Ad b) Example, the page title returns "...Gebundene Ausgabe von Mller Rschlikon..."; the publisher's name actually is "Müller Rüschlikon" (two umlauts). However, the output of the token is consistent with the output at ./admin/settings/amazon/test:

    [label] => Mller Rschlikon
    [manufacturer] => Mller Rschlikon
    [publisher] => Mller Rschlikon
    [studio] => Mller Rschlikon

So probably already Amazon garbled this data and neither a problem of the tokens integration, nor of the 'Amazon' module.

Double encodings in automatically generated node titles are a problem, indeed, but I wouldn't worry too much about it. Those are emitted frequently in automatically generated node titles, and I believe it'd be the task of the 'auto_nodetitle' module to sanitize or at least transliterate this - but it'd be great to get a showcase to prove that it is possible to prevent them.

I like the ability to use tokens from Amazon and I would favour to get this committed. There is some room for enhancement, but this patch is definitely something to build on!

asb’s picture

Status: Needs work » Needs review

I'm wondering if the data returned from Amazon is different for different product types?

Yes, at least for it definitely is. [author] appears mostly for [productgroup] = book, movies or cds have different properties. Much data is duplicated in [participants]. [ean] is often empty, the "editorial reviews" show up only occasionally. The same goes for [listpriceformattedprice], [amazonpriceformattedprice], and [lowestpriceformattedprice], much of it is empty, especially for older products or stuff from marketplace/33rd party providers. Actually, the data from Amazon is quite a mess and I wouldn't consider it as "structured data" ;)

And, again, thank you for sharing your code!

cwithout’s picture

I just looked at the data available on the /admin/settings/amazon/test page and where it's coming from. Unfortunately, I can't use all that data without additional modifications to the module.

The test page is accessing the data directly from the web. The tokens are accessing the data the Amazon module has stored in the database. I think most of it's stored.

This is the data that's stored:


participants (including authors)

There is the option to have the tokens access the data from the web rather than the db, but I don't think that's a good idea for many reasons. One of which is that it needs to request Amazon data for every token used. If a node has 4 amazon tokens, that's 4 external calls to Amazon for that data when the node is saved. That could be gotten around with a caching mechanism, but with the database already storing node data, it makes more sense to use that.

So as far as this issue goes, I think we need to limit the available tokens to what's in the database. For additional tokens, additional database fields would need to be added.

I'll make sure the appropriate data above is available as tokens and separate the release date into a couple different tokens, like only the year. I'll make that patch, which will have all available data tokenized. If we need more tokens after that, you can open a new issue to add more stored data the database. Then adding those to tokens would be a new issue after the new info is added to the database.

@asb - yes, the 1.x-dev. I edited #29 to correct.

asb’s picture

The additional tokens are exposed to Views only after establishing a Views relationship on the Amazon item field, but it'd be interesting where the data actually comes from if the View is run. If I put an [author] token into a View, does this actually trigger an API call each time?

Release date: I believe, splitting this into three tokens (like [field_asin-releasedate-yyyy], [field_asin-releasedate-mm], [field_asin-releasedate-dd]) would be great. Making it into a full 'Date' field would be even greater, but for sure is out of the scope of this issue as well ;)

Anyway, the tokens are good stuff. Thank you!

@rfay: Do you know anything about the design decision to store a limited number of fields in the database? Maybe there's a reason behind it?

rfay’s picture

@asb, there are some good benefits of putting it all in db tables. Like the views integration.
But it was that way long before I got here. And it's always been a bit strange IMO.

cwithout’s picture

@asb - Right after I posted, I modified the list to include participants/authors. I left it off at first, because it's stored in a separate database table. So authors is available for Tokens.

There are still some things that aren't stored, like EAN and ISBN. I didn't do a comparison of what's not being stored though.

Here's a patch will all the available data -- except for customerreviews_iframe and imagesets. I don't see any real use for those, and they might require extra handling I'd rather not deal with right now. They could always be added later.

There are multiple date options available. They're distinguished using the PHP date format characters.

Also, I tried to keep the tokens themselves as short as possible, so I shortened a few from the last version. I remember for something at some point I ran out of space in an input and still needed to add more tokens, so I figure shorter is better.

@rfay - To save lines of code, I used a foreach loop with $$k = $v. That's not always a good idea, but since we're pretty much using every value within the array, and it's limited to the database fields retrieved, it shouldn't be a problem. I could always write it them out line by line if you'd prefer.

asb’s picture

There are still some things that aren't stored, like EAN and ISBN.

You got me confused again ;) The tokens [field_asin-ean] and [field_asin-isbn] are working for me.

Also I believe that if there's a ISBN-10 it's always := ASIN; an ISBN-13 might be = EAN, but might differ as well. IMO any ISBN-10 can be converted into an ISBN-13 (but of course not every ASIN can be converted into an ISBN).

Will test the new patch later, it sounds like amazing work!

cwithout’s picture

It depends on the content type. ISBN and EAN are returned for some, but not all types. (Ref on UPCs, EANs, ISBNs, and ASINS) ISBN only applies to books. Not sure why EAN doesn't come back for everything. Seems like it ought to, but that would be a separate issue.

The rest of the fields are returned for types as far as I've seen.

Converting between ISBN -> ASIN etc is out of the scope of this issue, since we're not doing any data manipulation at the token level. Just spitting out what comes back from the function that's in charge of returning the data.

asb’s picture

Status: Needs review » Reviewed & tested by the community

Next try:

# rm -r amazon/
# drush dl amazon-6.x-1.x-dev [...]
# cd amazon/
# wget [...]
# patch -p1 < amazon-field-tokens-1043030-43.patch 
patching file asin/asin.module

Now, a huge number of tokens are exposed. Many new ones are there, [field_asin-ean] is gone, probably because of the limitations you mentioned in #43. Testing for ASIN 3440097447 from (this is a printed book):

In Pathauto, the pattern


gives me an URL alias like


The autor token is working, but not the product's release date as 4 digit year. Same result with Automatic Nodetitle and Page Title, but that's not your code's fault.

(The problem seems to be that the Amazon API returns [publicationdate] => 2003-08-01, but no "release date". Not very nice how hard it Amazon makes to work with their data. In 'auto_nodetitle' I'll try to put some PHP together to not use [field_asin-release-Y] if = 0, in 'pathauto' and 'page_title' it's more problematic to use this token for books.)

More important is that the tokens seems to work consistent between Pathauto, Automatic Nodetitle, and Page Title; also, the recently released token-6.x-1.18 introduces no further regressions. I have checked a couple of other tokens, and all were working as expected, when manually editing the node.

To apply the new tokens on a larger scale, I tried a bulk operation with 'Views Bulk Operations' and the actions "Update URL alias", and "Update automatically generated node title" on ~800 nodes. This worked well, also (important: 'Automatic Nodetitles' has to be set to unconditionally generate the node title, otherways it won't be updated). Observations:

The book title "Reserve hat Ruh...Ein Leben im Rudel" is expanded to &quot;Reserve hat Ruh...Ein Leben im Rudel&quot; with the token [field_asin-title] (Pathauto strips this, if configured to discard "). With [field_asin-title-dec], I'm getting the correct title. It's very thoughtful of you to provide this additional token!

About 10% of the automatically generated node titles are not usable, because of missing author data or other inconsistencies of the Amazon database. So it's definitely a good idea to write some wrapper code to sanitize the data before relying on it too much. But, again, that's a problem of the Amazon data, your code works perfectly.

This patch is really good stuff!

asb’s picture

This was easy... the following snippet allows to build sane node titles with 'Automatic Nodetitle'. It conditionally discards the "author: " string if the "author" token is empty and outputs a node title of either "author: title", or just "title".

  $author = '[field_asin-author]';
  $title = '[field_asin-title-dec]';
  if (empty($author)) {
    return $title;
      return $author . ': ' . $title;

Based on this, one might get more consistent node titles, e.g. on a review site, than with user generated content.

Populating a vocabulary with tokens, or entering tokens into CCK field seems to be a lot more complicated; however, the Amazon token are processed by the 'Rules' module. Attached my approach to grab the "publisher" token and enter it in a predefined vocabulary (rules export).

asb’s picture

4.88 KB

This Rule takes an ASIN enabled node and enters the contents of the "publisher" token into the vocabulary "Akteur" when the node is being saved. This is just a prove of concept; to make this useful, this definitely needs some work, e.g. the rule should check if the term already exists; also, I have not tested what would happen if the node is already tagged with the presumably "new" taxonomy term.

On different sites, I'm using vocabularies for the publishing/release date, the publisher/label/studio, composer, director, and actor. In theory, those could be populated with similar rules and the new Amazon tokens - if this approach proves feasible:

  • release date (movies, cds, maybe books) -> [releasedate]
  • publisher/label/studio -> [publisher], [studio], [manufacturer], [label]
  • director -> [director]
  • actor -> [actor]
  • composer -> [creator] (?)

Probably CCK fields can be populated in a similar fashion. For that I could use [runningtime], [audiencerating], [releasedate], [numberofpages], [binding], and [edition] - all stuff so far the users have to enter manually (or not enter at all ;) I haven't checked the intersections between the Amazon API array and the new tokens, but I'm pretty sure that they might save a lot of typing.

...that to answer the question if there are use cases for Amazon tokens ;)

Update: This approach works, at least partially. To check in a Rule if a taxonomy terms already exists, a patch is required (#490898: Condition: does term exist?, #40). That patch works for me, but has not yet been committed to the Rules dev release. Also, the way Rules is processing the logic, a node will only be tagged with a new term; a second rule would be required to tag nodes with an existing term, but it couldn't prevent duplicates.

I had no success with dates at all. As with other import tools, it is virtually impossible to get a proper date into a CCK date field without manually typing it in; there seem to be a lot of hidden valiations which cause dates to be either rejected, or falsified. Example for [releasedate]: Trying to enter data in a date field with formatting/granularity d.m.Y (like "13.03.2012"). The token [field_asin-release] is supposed to return a ISO formatting (Y-m-d, like "2012-03-15"), so I have to concatenate the parts in the right order; Rules expects an array, so I tried:

return array(
  0 => array('value' => '[node:field_asin-release-d].' . '[node:field_asin-release-m].' . '[node:field_asin-release-Y]')

If I print this in a message, I get the proper "15.03.2012"; the CCK date field receives: "01.01.2011". When I print the token [field_asin-release] in a message, I get: "[field_asin-release]".

Btw, at least seems to never return any [releasedate] for printed books, it's always "publishing date" (which we don't get in the new tokens). The data stored in the row "publicationdate" of the table amazon_book is a mess (a mixture of complete (like "2001-12-01") and incomplete (like "1996") dates.

For movies, there are no other tokens I could use. [field_asin-participants] returns an unsorted mixture of director(s) and actor(s). Amazon API has [actor] and [director], but those are not exposed as tokens.

The database table amazon_item_participant contains data like this:

| asin       | type     | participant
| 3453194381 | author   | Arthur C. Clarke
| B001AKTZSM | creator  | Mark Snow
| B000051WDE | creator  | Alan Menken
| B000051WDE | director | Eric Goldberg
| B000051WDE | director | Mike Gabriel 
| B0000AOD3Y | creator  | Ron Grainer
| 3426628074 | creator  | Frauke Czwikla
| B00004L8J5 | director | Wolfgang Reitherman

This probably would have to be preprocessed to populate a "director" or "actor" token, which again is outside the scope of this issue, I believe.

On the positive side: the new Amazon tokens work more or less with Rules. On the other hand, 'Rules' seems to be much to inflexible to populate a vocabulary or a CCK field with sane values from Amaton tokens. For that, I'm back to manually copying & pasting.

rfay’s picture

I really appreciate the work and testing on this and I'll try to review and commit this week or at least soon.

rfay’s picture

Title: Improved token support (especially for Automatic Node Titles) » D6: Improved token support (especially for Automatic Node Titles)
Status: Reviewed & tested by the community » Fixed

Committed and included in new 6.x-1.4 release.

Thanks so much for the great patch and for the great reviews

Looking forward to 7.x support :-)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

dman’s picture

Issue summary: View changes

Fix typo