Problems with qTranslate Pre-Domain Mode and Google Chrome

I was having some trouble with the latest release of Google Chrome and my qTranslate powered wordpress site and I think it is worth sharing this.

The Symptom:

1. The Media Upload Overlay when creating posts was totally blank. No image insertion possible!
2. Install importer was blank too!
3. I expect a lot of other problems in the backend beeing there I didn’t even notice.

The assumed conditions for this problem:

1. A newer Version of Google Chrome (I use Version 19.0.1084.56)
2. WordPress 3.2 or newer
3. Working with different URLs for you wordpress installation like I did using qTranslate in Pre-Domain Mode

The Explanation for this issue:
Since WordPress 3.2 the header X-Frame-Options: SAMEORIGIN will be send in the backend to protect your backend from “frame attacks” (don’t know the correct word). Under the above circumstances it happens that you open the backend with a host different then the host used for rendering screens like media upload or importer install in an iframe.

In my case for example I was viewing a post in english under the url http://EN.mydomain.com/post. Hitting the edit button in the admin bar would direct me to http://EN.mydomain.com/wordpress/wp-admin/post.php?post=8198&action=edit (I am running wordpress in a subdirectory). The media uploader is using a “canonical” url http://mydomain.com/wordpress/wp-admin/media-upload.php?post_id=8198. So the host of the iFrame resource (mydomain.com) is different from the website’s host (EN.mydomain.com). Since wordpress sends the header X-Frame-Options: SAMEORIGIN Chrome will not allow to display the iFrame.

Solution:
Unfortunately I didn’t found a generic solution that most likely everyone could use having similar problems. There is a plugin preventing wordpress from sending the X-Frame-Options header but this did not solve all problems for me (I think there were still some same origin policy issues).
My solution is to always redirect the backend to the “canoical” host which should exist for all wordpress installations. In my case this host ist mydomain.com with no subdomain!
To complete this information I will post the code I added to my /wordpress/.htaccess file at the very end but this is the solution for my very specific environment (my canonical host, having wordpress installed in a subdir):

# Redirect *.mydomain.com/wordpress to mydomain.com/wordpress
RewriteCond %{HTTP_HOST} !^mydomain.com
RewriteCond %{REQUEST_URI} ^/wordpress/.*
RewriteRule ^(.*) http://mydomain.com/wordpress/$1 [R=301,L]

Further Links:

• http://core.trac.wordpress.org/ticket/17990
• http://core.trac.wordpress.org/changeset/18013

http://wordpress.org/extend/plugins/qtranslate/