I sincerely appreciate the help you both gave :)
After almost a solid ten hours of googling and reading and staring at config files I stumbled on
this:
https://wordpress.org/support/topic/multiple-x-frame-options-headers-with-conflicting-values-sameorigin-deny/

I decided to have a look at my ssl-params.conf file. Which, BTW, I pasted from this tutorial on DO:
https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-16-04

Lo and Behold! This line doth exist therein:
add_header X-Frame-Options DENY; (lol! Just LOOK at how that word defiantly stands out!)

Note: l’m not dissing the tutorial at all. The DO tutorials are all top notch! For a noob to LEMP though, and one using Wordpress, This was a BIG-Time gotcha lol!

One, yes one keystroke later, the lil’ SOB was commented into eternity! And NOW the plugin details link works, as does the Customizer preview. My tension headache is already subsiding and normal vision will return upon a good nights sleep :)

I soooo appreciate your willingness to provide input! This is a great community :)

My first guess would be that you haven’t installed Curl (or php-curl), since the plugin details page is actually being downloaded to your server and then displayed to you. So it’s actually not displaying external links in the modal window.
Or it could be a firewall that is blocking outbound traffic, but that would be something that you’ve setup.

Thanks @hansen. That gives me a place to start. I will take a look at both to confirm.

Disabled firewall. Problem still exists. Installed php-curl. Problem still exists. If I select the link and choose open in new tab, the link loads in the ne tab properly. Could this be something to do with nginx and JavaScript or permissions in Wordpress??

@jameswestpaintings

Please post the server block for one of your WordPress installations in full so we can take a look at the configuration and see if there’s anything there that may be causing issues.

This is the server block. Install is fresh as of last night. Only site on server Thanks for the help! I’m baffled…

You should look at the following URL’s in order to grasp a solid understanding of Nginx configuration files in order to fully unleash the power of Nginx. http://wiki.nginx.org/Pitfalls http://wiki.nginx.org/QuickStart http://wiki.nginx.org/Configuration Generally, you will want to move this file somewhere, and start with a clean file but keep this around for reference. Or just disable in sites-enabled. Please see /usr/share/doc/nginx-doc/examples/ for more detailed examples. Upstream to abstract backend connection(s) for php

upstream php {
server unix:/tmp/php-cgi.socket;
server 127.0.0.1:9000;
}

Default server configuration

server {
listen 80 defaultserver;
listen [::]:80 defaultserver;
servername jameswestpaintings.com www.jameswestpaintings.com;
return 301 https://$servername$request_uri;
}

server {

# SSL configuration
#
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
include snippets/ssl-jameswestpaintings.com.conf;
include snippets/ssl-params.conf;
#
# Note: You should disable gzip for SSL traffic.
# See: https://bugs.debian.org/773332
#
# Read up on ssl_ciphers to ensure a secure configuration.
# See: https://bugs.debian.org/765782
#
# Self signed certs generated by the ssl-cert package
# Don't use them in a production server!
#
# include snippets/snakeoil.conf;

# Add index.php to the list if you are using PHP
index index.php index.html index.htm index.nginx-debian.html;

root /var/www/html;

location ~ /.well-known {
    allow all;
}

#location / {
    # First attempt to serve request as file, then
    # as directory, then fall back to displaying a 404.
    #try_files $uri $uri/ =404;
#}

# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
location ~ \.php$ {
    include snippets/fastcgi-php.conf;
#
#   # With php7.0-cgi alone:
#   fastcgi_pass 127.0.0.1:9000;
#   # With php7.0-fpm:
    fastcgi_pass unix:/run/php/php7.0-fpm.sock;
}

# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one

location ~ /\.ht {
    deny all;
}

location ~* /(?:uploads|files)/.*\.php$ {
deny all;
}

location = /favicon.ico {
log_not_found off;
access_log off;
}

location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}

location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
expires max;
log_not_found off;
}

location / {
# This is cool because no php is touched for static content.
# include the "?$args" part so non-default permalinks doesn't break when using query string
try_files $uri $uri/ /index.php?$args;
}

}

Virtual Host configuration for example.com You can move that to a different file under sites-available/ and symlink that to sites-enabled/ to enable it. server { listen 80; listen [::]:80; server_name example.com; root /var/www/example.com; index index.html; location / { try_files $uri $uri/ =404; }

code

@jameswestpaintings

The SSL plugin shouldn’t really be necessary since you can simply set both URL’s to use HTTPS in the WordPress Admin CP. Unless something has changed in WordPress to where a plugin is required to enable HTTPS (and setting both URL’s no longer works), it’s simply overhead and may be the source of one issue (as was the case with a previous community question).

You’re already redirecting using NGINX from Port 80 (HTTP) to 443 (HTTPS/SSL), so I’d simply disable the plugin and check to see if the issue persists.