Wordpress Whitelist file

You have wordpress comet cache enabled still ? Try disabling all wordpress plugins except this one and see as well.

You can also verify if it's nginx or wordpress by just uploading the js file itself and only the js to centmin mod site but in a directory outside of wordpress or in another site's web root i.e. main hostname upload to just js file to /usr/local/nginx/html/js directory and then access it via ip address of your server via 1.1.1.1/js/cs-vendor.js where 1.1.1.1 is your server IP. So you're accessing file outside of wordpress environment to confirm if contents are intact. If it is intact, then issue is with wordpress install and/or plugins etc.

---

Also what's exact steps of you uploading zip, extracting zip and moving files to nginx web root at /home/nginx/domains/domain.com/public ?

For example to do it via SSH after uploading zip file to say /home/nginx/domains/domain.com/zips/files.zip would be as follows where zip file named files.zip and extracted is a upload directory with all files intended for /home/nginx/domains/domain.com/public web root

Code (Text):

cd /home/nginx/domains/domain.com/zips
unzip files.zip
chown -R nginx:nginx upload
cd upload
\cp -af * /home/nginx/domains/domain.com/public

 

so on server main hostname complete and test.icoore.com is wordpress based site incomplete ?

don't post the output of this command but just inspect the output of this command in SSH session to confirm if cat output of file shows intact code or missing code

Code (Text):

cat /home/nginx/domains/test.icoore.com/public/js/cs-vendor.js

 

tried on a non-https nginx vhost for cs-vendor.js wonder if it's related to HTTP/2 HTTPS

was old non-centminmod working server using HTTPS was it HTTP/2 HTTPS ?

 

I took the complete version of your cs-vendor.js and uploaded to test centmin mod server with both non-https and https version of the file contents compared

download using curl output of non-https version into non-https.txt text file

Code (Text):

curl -s http://test.domain.com/js/cs-vendor.js > non-https.txt

check number of lines in non-https.txt

Code (Text):

wc -l < non-https.txt
158259

download using curl output of https version into https.txt text file

Code (Text):

curl -sk https://test.domain.com/js/cs-vendor.js > https.txt

check number of lines in https.txt which matches with non-https version

Code (Text):

wc -l < https.txt    
158259

check side by side sdiff of non-https.txt vs https.txt files output and no differences as it returns to prompt not showing any code differences

Code (Text):

sdiff -s non-https.txt https.txt

so for CentOS 7.4 curl 7.29 HTTP/1.1 HTTPS check it's the same

now to switch to curl 7.58 HTTP/2 HTTPS check to see if it's related to HTTP/2 HTTPS

install curl 7.58

Code (Text):

/usr/local/src/centminmod/addons/customcurl.sh

redo the HTTPS version curl check
download using curl output of https version into https-http2.txt text file

Code (Text):

curl -sk https://test.domain.com/js/cs-vendor.js > https-http2.txt

check number of lines in https-http2.txt which matches with non-https version

Code (Text):

wc -l < https-http2.txt    
158259

no change so the same

next check if it's gzip compression related as normally web browsers request with Accept-Encoding gzip,deflate,br
download using curl output of https version into https.txt text file

Code (Text):

curl -sk -H 'Accept-Encoding: gzip, deflate, br' http://test.domain.com/js/cs-vendor.js > http-compress.txt

download using curl output of https version into https-http2.txt text file

Code (Text):

curl -sk -H 'Accept-Encoding: gzip, deflate, br'  https://test.domain.com/js/cs-vendor.js > https-http2-compress.txt

check number of lines

Code (Text):

wc -l < http-compress.txt
4599

wc -l < https-http2-compress.txt
4599

looks same too

If it works on non-https site and doesn't on https site it could be related to size of your file and default nginx HTTP/2 HTTPS settings outlined at Module ngx_http_v2_module but looks at least from SSH session point of view the files are the same being served from non-https or HTTP/1.1 or HTTP/2 based https.

FYI, even in web browser both non-https and https version of the js file ends with

Code (Text):

/* jshint ignore:end */
//# sourceMappingURL=cs-vendor.map

 

let's try another check to see if you pre-compress your js file and trigger gzip static serving instead of nginx on the fly gzip compression if it makes a difference.

to pre-compress your js file use commands below

Code (Text):

cd /home/nginx/domains/test.icoore.com/public/js/
pigz -11k cs-vendor.js

you'll end up with cs-vendor.js.gz gzip compressed version of your js file

Code (Text):

cd /home/nginx/domains/test.icoore.com/public/js/
ls -lah | grep cs-vendor 
-rw-r--r-- 1 nginx nginx 5.3M Nov 15 15:51 cs-vendor.js
-rw-r--r-- 1 nginx nginx 1.1M Nov 15 15:51 cs-vendor.js.gz

restart nginx server

Code (Text):

ngxrestart

Then visit test.icoore.com/js/cs-vendor.js will allow nginx to serve the static gzip compressed version. Check contents is intact or missing

 

so you're missing code in between ?

works when visit https://test.icoore.com/js/cs-vendor.js ?

 

if it works, then it could be related to default nginx gzip_buffer size as your js is 5.3+ MB in size ! (again crazy size for js!)

so you can try raising the gzip_buffer just for *.js files by editing /usr/local/nginx/conf/staticfiles.conf and modifying the *.js location match to add and raise default gzip_buffers from 32 x 8K to 192 x 32K

Code (Text):

gzip_buffers      192 32k;

added to /usr/local/nginx/conf/staticfiles.conf

Code (Text):

    location ~* \.(js)$ {
  gzip_buffers      192 32k;
  #add_header Pragma public;
  #add_header X-Frame-Options SAMEORIGIN;
  #add_header X-Xss-Protection "1; mode=block" always;
  #add_header X-Content-Type-Options "nosniff" always;
  #add_header Referrer-Policy "strict-origin-when-cross-origin";
  add_header Access-Control-Allow-Origin *;
  add_header Cache-Control "public, must-revalidate, proxy-revalidate, immutable, stale-while-revalidate=86400, stale-if-error=604800";
        access_log off;
        expires 30d;
        break;
        }

remove the gzip pre-compressed file at rvlove.co/wp-content/themes/pro/cornerstone/assets/dist-app/js/cs-vendor.js.gz

then restart nginx

Code (Text):

ngxrestart

and verify if the raised gzip_buffers allows it to work

 

that's what previous post is trying to verify if it works with on the fly nginx gzip compression which relies on gzip_buffers while pigz pre-compressed js bypasses on the fly nginx gzip compression and thus not affected by gzip_buffers setting

 

what if you edit /usr/local/nginx/conf/nginx.conf gzip_buffers setting to above values and restart nginx

 

yeah that is nginx.conf default which applies server wide, so change it's value to either

Code (Text):

gzip_buffers      192 32k;

or

Code (Text):

gzip_buffers      1024 8k;

and restart nginx

Code (Text):

ngxrestart

and check in incognito web browser session with browser cache cleared