/ Register

Want to subscribe to topics you're interested in?
Become a Member

Wordpress Moved from a non-centminmod server to centminmod, now wordpress wont work

Discussion in 'Blogs & CMS usage' started by Afaq, Oct 22, 2017.

Previous Thread Next Thread
Loading...
  1. Oct 22, 2017 #1
    Afaq

    Afaq Member

    81
    3
    8
    Aug 5, 2015
    Ratings:
    +5
    Local Time:
    6:29 AM
    I just moved my WP website from a Vesta server to Centminmod. Here is what I did:
    1. Did a fresh Centmin install.
    2. Installed WP using the option # 22.
    3. Cleared the public folder, and copied my wordpress files from vesta server to it.
    4. Imported my database.

    Now, the wordpress website wont open.

    My previous setup was using Cloudflare SSL with Cloudflare Flexible SSL plugin. I also deleted the plugin files after moving. And I also changed the siteurl and homeurl in wp-options table to the non-https one. Still it wont work.

    Opening the website without-www gives 500 error. While opening with www takes it to Domain Name Registration and Web Hosting | Domain.com and gives the refused to connect error.

    Here is my nginx config:

    Code:
    # Centmin Mod Getting Started Guide
# must read http://centminmod.com/getstarted.html

# redirect from non-www to www
# uncomment, save file and restart Nginx to enable
# if unsure use return 302 before using return 301
#server {
#            listen   80;
#            server_name domain.com;
#            return 301 $scheme://www.domain.com$request_uri;
#       }

server {
  server_name domain.com www.domain.com;

# ngx_pagespeed & ngx_pagespeed handler
#include /usr/local/nginx/conf/pagespeed.conf;
#include /usr/local/nginx/conf/pagespeedhandler.conf;
#include /usr/local/nginx/conf/pagespeedstatslog.conf;

  # limit_conn limit_per_ip 16;
  # ssi  on;

  access_log /home/nginx/domains/domain.com/log/access.log combined buffer=256k flush=60m;
  error_log /home/nginx/domains/domain.com/log/error.log;

  root /home/nginx/domains/domain.com/public;

  include /usr/local/nginx/conf/wpsupercache_domain.com.conf;   

  location / {

  # Enables directory listings when index file not found
  #autoindex  on;

  # for wordpress super cache plugin
  #try_files /wp-content/cache/supercache/$http_host/$cache_uri/index.html $uri $uri/ /index.php?q=$uri&$args;

  # Wordpress Permalinks
  try_files $uri $uri/ /index.php?q=$uri&$args; 

  }

location ~* /(wp-login\.php) {
    limit_req zone=xwplogin burst=1 nodelay;
    #limit_conn xwpconlimit 30;
    auth_basic "Private";
    auth_basic_user_file /home/nginx/domains/domain.com/htpasswd_wplogin;   
    include /usr/local/nginx/conf/php-wpsc.conf;
}

location ~* /(xmlrpc\.php) {
    limit_req zone=xwprpc burst=45 nodelay;
    #limit_conn xwpconlimit 30;
    include /usr/local/nginx/conf/php-wpsc.conf;
}

  include /usr/local/nginx/conf/wpsecure_domain.com.conf;
  include /usr/local/nginx/conf/php-wpsc.conf;
  include /usr/local/nginx/conf/staticfiles.conf;
  include /usr/local/nginx/conf/drop.conf;
  #include /usr/local/nginx/conf/errorpage.conf;
  include /usr/local/nginx/conf/vts_server.conf;
}
    I made a non-self signed ssl vhost and my previous setup was running W3 total cache.

    Any help would be highly appreciated.
     
  2. Oct 22, 2017 #2
    wmtech

    wmtech Active Member

    187
    44
    28
    Jul 22, 2017
    Ratings:
    +139
    Local Time:
    3:29 AM
    I would look at the log files for the reason of the error 500.

    Also I would remove all occurrences of "domain.com" from the config files and change it to the name of my real domain.
     
  3. Oct 22, 2017 #3
    Afaq

    Afaq Member

    81
    3
    8
    Aug 5, 2015
    Ratings:
    +5
    Local Time:
    6:29 AM
    The actual conf file contains my real domain, I just changed it to domain.com for the purpose of posting here.
     
  4. Oct 22, 2017 #4
    wmtech

    wmtech Active Member

    187
    44
    28
    Jul 22, 2017
    Ratings:
    +139
    Local Time:
    3:29 AM
    Given your described error, you have at least 1 occurrence of "domain.com" in your config files. You should grep your config files at your server for it. Otherwise it would not redirect you to Domain Name Registration and Web Hosting | Domain.com

    Also you should read your nginx and php-fpm error logs and take the steps outlined there to solve your main issue. You also can post the errors in the logs here to get help. ;)
     
  5. Oct 22, 2017 #5
    eva2000

    eva2000 Administrator Staff Member

    58,893
    12,490
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +19,122
    Local Time:
    11:29 AM
    Nginx 1.31.x
    MariaDB 10.x/11.4+/12.3+
    1. still using cloudflare in front of centmin mod wp site as with vestacp site ? or did you disable cloudflare with centmin mod wp ?
    2. if with cloudflare did you setup http to https redirect page rules ? what specific page rules did you setup ?
    3. what was the nginx and/or apache vhost configuration of old vestacp setup ? did it have 301 permanent redirect ? they are permanently cached within web browsers
    What do you get for output for curl header checks in SSH where domain.com is yourdomain.com
    Code (Text):
    curl -I http://domain.com

    Code (Text):
    curl -I http://www.domain.com

    Code (Text):
    curl -I https://domain.com

    Code (Text):
    curl -I https://www.domain.com

    • If the problematic version(s) you are trying to get has a 301 HTTP status then it's probably a browser cached 301 permanent redirect issue.
    • If you use chrome in private incognito browsing session you probably have working www domain access ? if so you need to clear you browser of the 301 permanent redirect. If that works you need to clear your browsers' cache as outlined at Refreshyourcache.com - The Guide to Clear your Browser Cache!
    • That is dangers of 301 permanent redirects as they are cached in web browsers forever until cleared. 302 temp redirects are not permanent.
     
  6. Oct 22, 2017 #6
    Afaq

    Afaq Member

    81
    3
    8
    Aug 5, 2015
    Ratings:
    +5
    Local Time:
    6:29 AM
    It is not actually taking me to website that is "domain.com". I meant to say that opening the www version redirects to non-www version and gives the refused to connect error.
     
  7. Oct 22, 2017 #7
    Afaq

    Afaq Member

    81
    3
    8
    Aug 5, 2015
    Ratings:
    +5
    Local Time:
    6:29 AM
    1. I am not using Cloudflare in front on Centmin mod setup. Actually, its not even live yet. I am testing it using the hosts file hack.
    2. See above.
    3. I dont believe the previous setup had any 301 redirects. Anyway, I just tested on Chrome incognito. Non-www version opens fine. However, the www version redirects to https://www version and gives the refused to connect error. How can I solve this?

    I actually plan on using Cloudflare SSL once this issue is solved so please guide me keeping that in view.
     
  8. Oct 22, 2017 #8
    eva2000

    eva2000 Administrator Staff Member

    58,893
    12,490
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +19,122
    Local Time:
    11:29 AM
    Nginx 1.31.x
    MariaDB 10.x/11.4+/12.3+
    output for the 4 curl header check commands ?
     
  9. Oct 23, 2017 #9
    Afaq

    Afaq Member

    81
    3
    8
    Aug 5, 2015
    Ratings:
    +5
    Local Time:
    6:29 AM
    Code:
    curl -I http://domain.com
HTTP/1.1 200 OK
Date: Sun, 22 Oct 2017 14:16:40 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
Link: <http://www.domain.com/wp-json/>; rel="https://api.w.org/"
Link: <http://www.domain.com/>; rel=shortlink
Server: nginx centminmod
    Code:
    curl -I http://www.domain.com
HTTP/1.1 200 OK
Date: Sun, 22 Oct 2017 14:18:10 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
Link: <http://www.domain.com/wp-json/>; rel="https://api.w.org/"
Link: <http://www.domain.com/>; rel=shortlink
Server: nginx centminmod
    Code:
    curl -I https://domain.com
curl: (7) Failed to connect to domain.com port 443: Connection refused
    Last curl command took a lot of time but returned this:
    Code:
    curl -I https://www.domain.com
curl: (7) Failed to connect to www.domain.com port 443: Operation timed out
    I ran all these from my computer.
     
  10. Oct 23, 2017 #10
    eva2000

    eva2000 Administrator Staff Member

    58,893
    12,490
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +19,122
    Local Time:
    11:29 AM
    Nginx 1.31.x
    MariaDB 10.x/11.4+/12.3+
    As curl header checks don't cache 301 permanent redirects nor do they adhere to HSTS directives I see that the checked output is as expected working non-https and no connection to non configured https. So if you browser does redirect to HTTPS it could be HSTS related. Did you enable HSTS previously on cloudflare or vestacp? if you did then you're telling browsers to force HTTP to HTTPS redirected connections for domain.com and any *.domain.com subdomain as well even without actual redirect in nginx level.

    see Enabling HSTS for SSL for specifics
    To double check, you can just clear your web browser's HSTS record for the domain.com and www version so the web browser no longer redirects from HTTP to HTTPS. I posted a thread at SSL - How to clear HSTS browser cache | Centmin Mod Community specifically for this :)
     
  11. Oct 23, 2017 #11
    Afaq

    Afaq Member

    81
    3
    8
    Aug 5, 2015
    Ratings:
    +5
    Local Time:
    6:29 AM
    Ok so this is weird. I cleared the HSTS record using the link you gave. But still www version takes to the https version and gives the refused to connect error. However, when I open the non-www version. It opens fine. When I click on any page/post, it open that but with www url. I go to home again from a link on the website, that opens fine and that too with www url. But when I explicitly write www domain and enter, it gives the error.
     
  12. Oct 23, 2017 #12
    Afaq

    Afaq Member

    81
    3
    8
    Aug 5, 2015
    Ratings:
    +5
    Local Time:
    6:29 AM
    On safari it is working as expected. Both the www and non-www versions are opening fine. So I guess its just a chrome's cache related issue.

    Anyway, the non-www version is not directing to www version which it should. How should I do that? And secondly, I plan on using Cloudflare SSL once I put the website live, how should I go about that?
     
  13. Oct 23, 2017 #13
    eva2000

    eva2000 Administrator Staff Member

    58,893
    12,490
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +19,122
    Local Time:
    11:29 AM
    Nginx 1.31.x
    MariaDB 10.x/11.4+/12.3+
    uncomment the top server{} context and remove non-www from 2nd server{} context

    from
    Code (Text):
    # redirect from non-www to www
# uncomment, save file and restart Nginx to enable
# if unsure use return 302 before using return 301
#server {
#            listen   80;
#            server_name domain.com;
#            return 301 $scheme://www.domain.com$request_uri;
#       }

server {
  server_name domain.com www.domain.com;

    to setting 302 temp redirect first

    Code (Text):
    # redirect from non-www to www
# uncomment, save file and restart Nginx to enable
# if unsure use return 302 before using return 301
server {
            listen   80;
            server_name domain.com;
            return 302 $scheme://www.domain.com$request_uri;
       }

server {
  server_name www.domain.com;

    Just setup cloudflare and you need to setup nginx realip to be passed onto Nginx.

    See Getting Started Guide step 4 and setting correct real ip via nginx module config at http://centminmod.com/nginx_configure_cloudflare.html.

    If using Centmin Mod 123.09beta01 and newer, there's an added tools/csfcf.sh script to aid in this. Details at:
    You just need to setup a cronjob to run
    Code (Text):
    /usr/local/src/centminmod/tools/csfcf.sh auto

    and ensure your nginx.conf http{} context has the include file /usr/local/nginx/conf/cloudflare.conf and/or your individual nginx vhost's server contexts has the same include file

    Then restart nginx server via command shortcut
    Code (Text):
    ngxrestart

    or
    Code (Text):
    service nginx restart
     
  14. Oct 23, 2017 #14
    Afaq

    Afaq Member

    81
    3
    8
    Aug 5, 2015
    Ratings:
    +5
    Local Time:
    6:29 AM
    ^
    1. I should set a 302 redirect for testing and then eventually change it to a 301, right?
    2. And for setting the realip, you mean to say I should check the step 5, right? The Step 4 is about the firewall.
     
  15. Oct 23, 2017 #15
    eva2000

    eva2000 Administrator Staff Member

    58,893
    12,490
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +19,122
    Local Time:
    11:29 AM
    Nginx 1.31.x
    MariaDB 10.x/11.4+/12.3+
    yup 302 can be used forever if you want too - safer than 301

    ah yes step 5
     
  16. Oct 23, 2017 #16
    Afaq

    Afaq Member

    81
    3
    8
    Aug 5, 2015
    Ratings:
    +5
    Local Time:
    6:29 AM
    Thanks a lot. I have setup everything. Its now up and running with Cloudflare.

    One issue I have noticed though. Previously, I was using W3TC. Now I moved to SuperCache on your recommendations. However, I am feeling that website is not as fast as before. In Pingdom tool, there are two major issues. 1)No CSS, JS magnification and 2)downloads are not being parallelized across domains.

    Any idea what steps can I take to improve speed?

    And what does this line in vhost config do? I have it commented out.
    Code:
    # for wordpress super cache plugin
  #try_files /wp-content/cache/supercache/$http_host/$cache_uri/index.html $uri $uri/ /index.php?q=$uri&$args;
     
  17. Oct 23, 2017 #17
    eva2000

    eva2000 Administrator Staff Member

    58,893
    12,490
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +19,122
    Local Time:
    11:29 AM
    Nginx 1.31.x
    MariaDB 10.x/11.4+/12.3+
    centmin.sh menu option 22 for wordpress setup would of auto installed autoptimise wp plugin which you can enable and configure for css and js minification

    that line is needed for wp super cache otherwise commenting out means wp super cache is disabled
     
  18. Oct 25, 2017 #18
    Afaq

    Afaq Member

    81
    3
    8
    Aug 5, 2015
    Ratings:
    +5
    Local Time:
    6:29 AM
    I have activated the said line. However, I am running into an issue. Though I think its not related to this line. The visual composer is not working in Dashboard. It gives a 403 error on
    wp-includes/js/tinymce/wp-tinymce.php file in browser console. Does the Centminmod WP install restrict execution of php code in the wp-includes/js/ folder? Because everything was working fine on previous host/vesta.
     
  19. Oct 25, 2017 #19
    eva2000

    eva2000 Administrator Staff Member

    58,893
    12,490
    113
    May 24, 2014
    Brisbane, Australia
    Ratings:
    +19,122
    Local Time:
    11:29 AM
    Nginx 1.31.x
    MariaDB 10.x/11.4+/12.3+
    Centmin Mod values security and puts additional measures in place so that end users are also mindful of security. So in your case, you might need to whitelist or unblock the WP plugins related to your 403 permission denied messages.

    If you used centmin.sh menu option 22 auto installer Wordpress Nginx Auto Installer, the default wpsecure conf file at /usr/local/nginx/conf/wpsecure_${vhostname}.conf where vhostname is your domain name, blocks php scripts from executing in wp-content for security

    Below links you can see examples of setting up specific wordpress location matches to punch a hole in the wpsecure blocking to whitelist specific php files that need to be able to run.
    If on Centmin Mod 123.09beta01, you may have ran into the new tools/autoprotect.sh cronjob feature outlined at Beta Branch - autoprotect.sh - apache .htaccess check & migration to nginx deny all | Centmin Mod Community You uploaded scripts may have .htaccess deny from all type files in their directories which may need bypassing autoprotect. It's a security feature that no other nginx based stack has as far as I know :)

    So instead, all .htaccess 'deny from all' detected directories now get auto generated Nginx equivalent location match and deny all setups except if you want to manually bypass the directory from auto protection via a .autoprotect-bypass file - details below here.

    You can read a few threads below on how autoprotect.sh may have caught some folks web apps falsely and the workarounds or improvements made to autoprotect.sh with the help of users feedback and troubleshooting.
     
Previous Thread Next Thread
Loading...

.