Forum Replies Created

Viewing 15 replies - 76 through 90 (of 1,808 total)
  • Hello supercain2. Often this type of behavior occurs because of caching. This is especially true if the servers have different DNS.

    There are generally 3 types of caching that may be involved–your computer’s dns caching, your browser cache, and serverside caching.

    Because you don’t tell us what browser or operating system you’re running, it’s very difficult to provide instructions. You should definitively clear any serverside caching you may have in place, either via a WordPress plugin or through facilities like Memcache or Redist.

    If the site changed DNS, then sometimes it’s just a matter of waiting for the computers around the world to get that news and the situation will sort itself within a few days at most. It might be helpful to go to a DNS resolver site like Google (https://dns.google.com), enter your new URL, and see if the DNS resolves.

    Each browser has its own particular set of instructions to clear the cache–the keyboard shortcut ctrl+shift+delete works on many of them.

    Sometimes your computer caches DNS queries as well, and these need to be cleared in order to get the new site. That’s usually done either via an IPconfig or IFconfig command, as in ipconfig /flushdns. But again, it differs between operating systems.

    You should also consider doing a search-&-replace of your database, making sure that your old URL is replaced w/your new 1. Back up your database prior to doing so, please.

    If you’re using any type of caching plugin, then please ensure that all caches are empty. Also clear any serverside caching that might be in place.

    DNS can be a tough subject to understand, so don’t hesitate to ask if you have questions. Actually, caching can be a tough subject as well, so please ask if any of this feels hard.

    Please let us know.

    Thread Starter abletec

    (@abletec)

    Thanks for the quick reply, Jeremy. I’ll play w/this & get back. Shortcodes definitively enabled.

    Hello, Andrés, & welcome. Could we please try deactivating all plugins on your site(s) & also switch to a default theme & try logging in/saving settings? Conversely, you could try downloading the health check plugin by ww.wp.xz.cn & put the site in troubleshooting mode using that so the appearance of the site won’t change for your guests. I do like the first option better personally, especially if the 2nd doesn’t work, just to make sure.

    The other thing is, though, you seem to indicate that you can get in using your phone but not your WiFi? If that’s the case, then I’m wondering if somehow Hostgator has blocked your WiFi’s IP w/its firewall. That usually doesn’t let you go to your homepage or anything else though.

    Hello, Paul, & welcome.

    There are just a lot of things that can be going on, as setting up a VPS can be quite complex. Can we please start by looking at your Nginx config file, also any vhost configuration files?

    Hello, ksawus, & welcome.

    It works for me, which suggests to me that the problem is a caching issue. Please clear your browser cache, as well as any caching you’re doing on your server, & let’s see if that doesn’t help.

    What plugins are you running, hndev? If you’re running any security plugins, please try disabling temporarily & see if the 403 goes away.

    Please ensure that your WordPress files are *all* owned by that group, ie, chown _R.

    Who owns your WordPress files, hndev?

    hndev, could you perhaps try doing a database search-&-replace w/something like interconnectit & change any instances of http://site.net to https://site.net & the same for http://www.site.net. It has both a GUI & CLI interface in the event the gui doesn’t work for some reason.

    I have not yet had coffee. This suggestion should likely not be trusted. But if you decide to do so, then obviously please, back up your database before doing anything. O, yeah, & did I mention it’s imperative to backup your database?

    Also, delete this tool when finished. It poses an incredible security risk.

    I have a good friend from Finland. Cool you’re from there. Next stop–caffeine!

    Hey, ivanmihalev, don’t even worry about it. We need all the help we can get on here. If we all quit because of a small mistake, this place would be a ghost town. Thank you for your contributions & please please please continue. I know I speak for all the volunteers here when I say that. We all appreciate you! In addition, I’m not sure where you’re from, but those forums where people post in other languages also *really* need help badly, if your native language is other than English. We need you here in whatever capacity you feel comfortable!

    hndev, I’m honestly a little confused as to how this is all playing out. I’m questioning the last 3 lines of the proxy file, but, again, since I’m not really certain how all your pieces fit together, I could well change my mind about that if I understood better. 1 thing I do when I have what appears to be a redirect problem is to run a trace command (tracert in windows) & redirect the output to a file. That way I can kind of get a picture of what is taking place w/the request on its travels. It’s helped me sort out more than 1 sticky wicket.

    How is your dns routed w/this setup?

    ivanmihalev, hndev is using Nginx, so in this case there won’t be a .htaccess file.

    Hndev, can we please see your nginx.conf files as well as any vhost config files? Yeah–you didn’t quite tell us all that initially :).

    Hi, hndev, & welcome. Firstly, unfortunately, you can’t do https from an IP. An SSL certificate is all about a domain name & verifying its owner, etc, prior to issuance of the certificate. You likely know that, but just a reminder.

    If you actually want to host your server on a home network, then, unless you have a static IP for that, you’ll need to use some form of dynamic DNS. For many reasons, including security, band width usage if the site gains traction, (you could exceed your acceptable use policy), & the DNS problem just mentioned, hosting a site on a home network just really isn’t a good idea in most cases.

    Your only (cheap) option, since the site is not reachable via public network, is a self-signed ssl certificate, which is pretty useless, since browsers flag it.

    I think your best bet, until you decide to make the site available on a public network, is simply to instal WordPress using http: & perhaps a hosts file, if required.

    Hello, Johnhrusky, & welcome. There’s a lot of things you don’t tell us, & they could prove important.

    1) What kind of hosting do you have–shared, VPS, or dedicated? On shared hosting, permissions issues are probably unlikely. On VPS or dedicated servers, however, they’re 1 of the most common causes for such issues. Closely related, are you using Windows or Linux?

    2) Please look at the health check screen on your dashboard. Are there any issues noted? I’m specifically wondering about Imagick or similar that may be needed.

    3) Closely related to the health check plugin previously mentioned, have you tried using its troubleshooting mode to see if you can upload images?

    Perhaps 1 or more of these will help. Please don’t hesitate to let us know if you need additional help w/this.

    Hello, kelownapassivehouse, & welcome. There are several ways you could do this, but if you have access to a file manager through your hosting provider, or know how to use ftp, then you can rename the plugin and log into your dashboard. That’s likely the easiest.

    Hello, noorman068, & welcome.

    There’s a lot you don’t tell us, & it’s important stuff. I’m going to make an assumption that you’re using some sort of VPS or dedicated server as opposed to shared hosting, but if that’s not correct, please let us know in your reply. You also don’t tell us what webserver software you’re running, which makes it tough to assist you, as well as your hosting operating system, ie, Linux or windows, and the path to your website files.

    Because of the lack of information, my comments are going to be very general. This sort of problem usually occurs when the owner of the WordPress files is incorrect. The WordPress files should be owned by the webserver group (often www-data in Apache & sometimes Nginx, but this varies greatly). Once you get the ownership correct, you won’t need that code in your wp-config.php file. In Linux, this change is made using the chown -r command.

    That was pretty nonspecific, & I apologize for that, but if you provide additional information, we can get more specific if required. Perhaps, however, this will be enough to get you headed in the right direction.

Viewing 15 replies - 76 through 90 (of 1,808 total)