Disable automatic link rewriting for downloads not working

— I think the problem has to do something with the automatic conversion!
(but even converting back to the old format – does not help q-translate-x to handle the downloads fine).

As I noticed the problem too late – and restore the old database. I now converted to the old notation, disabled qtranslate-x and reenabled mqtranslate.

(I tried going back to qtranslate-x v3.1 but that did not solve the problem like i first thought).

Just for reference – all somehow relevant content from my nginx.conf – maybe it is related to something here?
(note on test3 testdomain it works, but on plain domain it doesn’t…)

server {

		server_name openmtbmap.org www.openmtbmap.com openmtbmap.com openfreemap.org openfreemap.com www.openfreemap.org www.openfreemap.com www.openmtbmaps.com openmtbmaps.com;
		rewrite ^ https://openmtbmap.org$request_uri? permanent;
 }

 server {
        listen 80;
        listen [::]:80;
		listen 443 ssl spdy;
		listen [::]:443 ssl spdy;
		spdy_headers_comp 1; 

		# Add perfect forward secrecy
		ssl_prefer_server_ciphers on;
		ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

		server_name  openmtbmap.org;
		root           /srv/www/htdocs;
        #access_log  /var/log/nginx/host.access.log  main;

		if ($http_user_agent !~ FeedBurner) {
        set $test  "${test}F";
        }

        location / {
			try_files $uri $uri/ /index.php;

			# does the requested file exist exactly as it is? if yes, serve it and stop here
			# if (-f $request_filename) { break; }

			# Sets the default type to text/html so that gzipped content is served
			# as html, instead of raw uninterpreted data.
			# default_type text/html;
        }

		location /test3/ {
			try_files $uri $uri/ /test3/index.php;

			# does the requested file exist exactly as it is? if yes, serve it and stop here
			# if (-f $request_filename) { break; }

			# Sets the default type to text/html so that gzipped content is served
			# as html, instead of raw uninterpreted data.
			# default_type text/html;
        }

		# Protecting s2-member-files folder
		location /wp-content/plugins/s2member-files {
		deny 	all;
		}

                # Add trailing slash to */wp-admin requests.
		rewrite /wp-admin$ $scheme://$host$uri/ permanent;

		# Add trailing slash to */wp-login requests.
		rewrite /wp-login$ $scheme://$host$uri/ permanent;

Well basically the /test3 block is identical to the / block. It will only be used if a location cannot be found. So if the server is getting the request http://www.example.com/test3/filenotexist.php it would redirect to http://www.example.com/test3/
instead of redirecting to http://www.example.com/ or showing 404.

On apache the redirect would be included in .htaccess – but that does not exist on nginx – hence the redirection rules are used.

Essentially for an Apache host the identical entry would be:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /test3/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /test3/index.php [L]
</IfModule>

# END WordPress

So maybe I guess that some of the redirection rules in qtranslate-x are incorrect and fail on / but work if using a subdomain – at least for nginx servers. There must be some error in the sourcecode of qtranslate-x that wasn’t there in qtranslate / mqtranslate. As written – this only happens if the language cookie is set to a secondary language (first language without /XX/ language code).

For me to switch to Apache from nginx would be a bit cumbersome, as I have all my sites using https:// and I haven’t configured the certs in apache, but I do guess the error will also happen on apache servers.
(I’ll give it a try now if I manage to get apache running using https – but I’m not sure if I do. The config of that pretty complicated).

No I didn’t. I was using 3.2.9 from wordpress.org repositories. But it’s the same on 3.2.9.5

BTW – I noticed something rather strange on the cookie function. If I have no cookie – and surf to my website – it will use domain.com (if I have the same language setup). I can then surf the site in the given language. If I then however surf once to domain.com/de/ then I get the german coookie – and will always be redirected to /de/ even if I try to surf to domain.com/examplesite/ I will endup at domain.com/de/examplesite/ until I use the language switcher widget. So qtranslate-x does not set a language cookie for default language it seems to me (at least if using “Hide URL language information for default language”. I would suppose also for default language a cookie should be set to offer consisten behaviour?

Ah – I just got it. I can change the cookie by going to domain.com/en/ manually. Then the cookie will be set back to english and I end up at domain.com/

I have none of the cookie options set. BTW – it is clear that qtranslate-x does something to the download link before s2member can operate. Those download links should redirect non logged in users to the checkout page. That works fine for English. In secondary /de/ lanugage – non logged in users instead end up on the frontpage. So I would guess the plugin doesn’t matter at all, because qtranslate-x is catching the request first.