Sharing buttons open the same page in a new window unless using official buttons

This could be caused by your WP Super Cache configuration. Could you check your cache settings and make sure that pages including query strings aren’t cached?

Let me know how it goes.

“Don’t cache pages with GET parameters. (?x=y at the end of a url)” is checked and even disabling WP Super Cache doesn’t seem to change this behavior. This is the output in nginx log if it matters:

[06/Oct/2016:16:12:10 +0200] ~^(?<subdomain>[\x5Cw\x5C.]+)\[email protected]:443 <1149985+1>: Protocol="HTTP/1.1", Response="200", ResponseLength="17189 byte", Request="GET /tag/rc HTTP/1.1", RequestLength="423 byte", RequestHost="www.xaymar.com", RequestFile="/home/www-xaymar-com/public/www/index.php", RemoteAddr="66.249.76.112:57595", UserAgent="Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +https://www.google.com/bot.html)", GZipRatio="3.80", RequestURI="/tag/rc", URI="/www/index.php", FastCGIScriptName="/www/index.php"
[06/Oct/2016:16:12:17 +0200] ~^(?<subdomain>[\x5Cw\x5C.]+)\x5C.xaymar.com$@2001:4ba0:ffff:125::1:0:443 <1149981+2>: Protocol="HTTP/1.1", Response="200", ResponseLength="20082 byte", Request="GET /2016/10/06/version-1-3-3-0-of-the-encoder-plugin-has-been-released?share=tumblr&nb=1 HTTP/1.1", RequestLength="1378 byte", RequestHost="www.xaymar.com", RequestFile="/home/www-xaymar-com/public/www/index.php", RemoteAddr="2a02:8109:7c0:1024:1137:5956:aa5e:2e29:10297", UserAgent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36", GZipRatio="3.70", RequestURI="/2016/10/06/version-1-3-3-0-of-the-encoder-plugin-has-been-released?share=tumblr&nb=1", URI="/www/index.php", FastCGIScriptName="/www/index.php"

• This reply was modified 8 years, 1 month ago by Xaymar.

Thanks for giving that a try! What happens when you briefly disable your caching proxy, and flush your cache? Does it help?

I did that now, it seems to not have an effect (only increased page load time). It looks like whatever should intercept the page load isn’t doing that

Sorry that didn’t work.

Do you have anything in your nginx configuration file that may target pages with query strings?

Not that I am aware of, no. Pagespeed is disabled and fastcgi is pretty much the secure nginx setup from the nginx wiki.

fastcgi.conf

# FastCGI Settings {
        include                                         "fastcgi_params";

        fastcgi_param   PATH_INFO                       $fastcgi_path_info;
        fastcgi_param   PATH_TRANSLATED                 $document_root$fastcgi_path_info;
        fastcgi_param   SCRIPT_NAME                     $fastcgi_script_name;
        fastcgi_param   SCRIPT_FILENAME                 $document_root$fastcgi_script_name;
        fastcgi_param   SERVER_NAME                     $server_name;

        fastcgi_intercept_errors        on;
# }

# Default to no_cache if caching is enabled.
set $fastcgi_cache                              1;

fastcgi_php7.conf

location ~ [^/]\.php(/|$) {
        # Split the path information correctly.
        fastcgi_split_path_info         ^((?U).+\.php7)(/?.+)$;
        try_files                       $uri =404;

        fastcgi_pass                    unix:$server_root/php7.socket;
        fastcgi_index                   index.php;
}

fastcgi_php5.conf

location ~ [^/]\.php5(/|$) {
        # Split the path information correctly.
        fastcgi_split_path_info         ^((?U).+\.php)(/?.+)$;
        try_files                       $uri =404;

        fastcgi_pass                    unix:$document_root/../php5.socket;
        fastcgi_index                   index.php;
}

fastcgi_params

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;
fastcgi_param  REQUEST_SCHEME     $scheme;
fastcgi_param  HTTPS              $https if_not_empty;

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;

It is worth noting that this behavior wasn’t always like this, it worked fine on 4.2.2 (which is what the website started with) and seems to have broken with the later WordPress versions. Is there any way I can enable debug logging for jetpack so a better way of figuring out what is going wrong can be found?

I’m going to try reinstall php5 and php7 in case these are the ones causing issues.

Is there any way I can enable debug logging for jetpack so a better way of figuring out what is going wrong can be found?

You could enable logging for WordPress, and any Jetpack errors will be logged there as well. To do so, you can add the following to your site’s wp-config.php file:

define( 'WP_DEBUG', true );

if ( WP_DEBUG ) {

        @error_reporting( E_ALL );
        @ini_set( 'log_errors', true );
        @ini_set( 'log_errors_max_len', '0' );

        define( 'WP_DEBUG_LOG', true );
        define( 'WP_DEBUG_DISPLAY', false );
        define( 'CONCATENATE_SCRIPTS', false );
        define( 'SAVEQUERIES', true );

}

Once you’ve done so, you can check the wp-content/debug.log file for errors.

I’m not too hopeful, though, as I don’t believe an error will be triggered.

I can’t spot anything in your config files, but I’ve asked someone who knows Nginx better than me to take a look! We’ll get back to you soon. In the meantime, let me know if reinstalling PHP7 helps!

Reinstalling PHP7 only made it respond slightly faster, no change on what it does though. Does sharing work with permalinks enabled? Could that be why it’s getting messed up?

Does sharing work with permalinks enabled? Could that be why it’s getting messed up?

It should work regardless of your permalink structure, as it relies on WordPress to build the base link.

Xaymar,

Adding ?$args at the end of my try_files for /index.php
resolved this issue for me.

try_files $uri $uri/ /index.php?$args;

nginx 1.12.0, PHP7, wordpress 4.7.4

Thank you Rich, that was indeed what was causing it.