Martin Kliehm

Fine, then please edit the content so that it is true. That hack will work for the moment.

See my reply to rrhobbs please.

Oh, it’s confusing how often Amazon changes it’s product names and documentation. From the XML response I read that “Help” has been deprecated in the current API. In my plugin the Help response group is used for key validation. So that’s the cause.

I need more time to look for an alternative in the API documentation. In the meantime you can hack it by adding a file amtap-aws-key-verification.txt in the wp-content/cache folder where the content is “true”.

The [tags] are filtered by the plugin, but they are replaced by an empty string, as Amazon apparently doesn’t return anything. It’s true, the plugin doesn’t write any debug code into the main text content, only if it’s in the sidebar.

Oh, I meant: convert & into &, the amp; got eaten before.

Hm, so this wasn’t the problem either. Still your XSL doesn’t get applied. If you go to the plugins admin page and scroll down to the bottom, there’s a checkbox “debug”. If you check that and open a page where an Amazon item is included, you should get a URL as a code comment in the sidebar (given that the plugin runs in the sidebar). Convert all & in that string to & and paste it into your browser URL bar. You should receive the naked HTML from Amazon then. Don’t wait too long until you paste it so that your timestamp doesn’t expire. If there’s an error message, double check that you only converted the ampersands and didn’t strip too much. That should absolutely throw an error in your case.

Another explanation could be if you have any exceptional characters in your keys beyond a slash (which works, there’s one in my own secret key) and that the encryption does funny things to it. Or you haven’t checked a checkbox in Amazon’s terms of services or something… ??

Interesting, because yes, we’re looking for IsValid = True. I expected the file to contain the XML only if it would have been false. For some reason your XSL doesn’t get applied. Can you call the XSL file from the web, or does this return an error “503 forbidden”? Just try to open https://yourdomain.com/wp-content/plugins/amazon-machine-tags/amtap-key-verification.v3.xsl and see the result.

If the file cannot be opened, there could be two reasons: a) the permissions for the plugins folder or the amazon-machine-tags folder prevent access: set them to allow access from the web. b) The WordPress rewrite engine prevents access to the plugins folder. I admit I haven’t updated my own blog to WordPress 3.0, but another installation allow to call https://yourdomain.com//wp-content/plugins/readme.txt, therefore I assume the rewrite engine remains unchanged. So my best bet is that the folder permissions are too restrictive.

Hi Ben,

I have no idea what’s causing the error. However, in your /wp-content/cache/ folder there is a file amtap-aws-key-verification.txt – if there’s an error, this file should be populated with an XML response from Amazon further explaining the problem.

In the long term I really should get rid of the cache files and write everything into the database. That would be one problem source less, but I’m not sure if it would solve your problem.

Are you sure you have the right access key and secret key? Amazon changed their API a year ago, thus I needed to adjust the plugin. Please verify in your Amazon partner profile that everything is correct.

Cheers,
Martin

Hi @bigtron, that’s an annoying bug: when I wrote the plugin I thought it would be wise to cache the results in files, hence the permission error. In the next version I will rather use the database for caching results, that’s more stable. Sorry for the inconvenience.

Ah, the time offset. Thanks for your efforts pinning down the problem. Hm, any idea how to connect to an open time server via PHP to check whether your server time is screwed?

Hi southernutahautism, sorry for the delay. I just upgraded to WordPress 2.9.1, and everything works fine. I think a problem might be that the WordPress upgrade process asks you to delete wpcontent/cache, so the folder is gone and with it all folder permission settings. You probably have to create the folder again and set the read/write permissions accordingly (or next time, just delete the cache folder contents, but keep the folder intact). Also the plugin writes a text file as confirmation that the key has been validated into the same folder. I admit this is annoying when you upgrade WordPress as that requires you to run the validation again on the plugin’s options page after you upgraded. It seemed like a reasonable idea to keep all files in an existing cache folder when I wrote the plugin, but looking back it would be better to keep the confirmation file in the plugin’s folder. I’ll fix that in a future version. ??

Sounds like a permission problem then. I’m glad it worked. ??

Err, I have no idea. Are the Apache configuration settings for the two hosts identical? You don’t get any other error messages, like your cache folder is not writable, and permissions are OK? Can you please check the XML files that get written to your cache folder and look up the exact error message from Amazon? Is the plug-in up-to-date? You know that Amazon changed their API policy and requires the secret key since July?
Could you make a screen-grab (I recommend the Firefox add-on Screengrab) of the entire administration screen?

Cheers,
Martin

@olederer do you know what IP address your machine uses?

@alastairmayer Well, I took the private IP ranges as defined by the HTTP spec. That wasn’t for simplicity, but the most logical choice. By definition those IP addresses aren’t unique or in a registry, so I wonder how Amazon could look those up and resolve them to your server?

The affected files are the XSL files. This was a very common error until I implemented this message as people often test-installed the plugin locally where no access was possible for the Amazon API. The reason for this approach is that Amazon can transform the results; I thought that is more reliable and reproducable than relying on an XSL transformation on a users’ server where the environment and processor is unknown.