You are here
Bob - Thu, 2019/08/15 - 16:53
Hi everyone,
I just move and change the IP of one WordPress VM.
when I type http[s]://newip I'm still redirected to the old IP...
but all the web based service
newip:12322 - Adminer
:12321 - System control panel
:12320 - Web based command line terminal
and https://newip/wp-admin are working !!
I follow this guide : https://wordpress.org/support/article/changing-the-site-url/
Nothing worked !!!
The Database:
(was containing 127.0.0.1 as default)
The wp-config.php, functions.php (under the current theme), the Relocate method #, nothing worked..
any ideas ??
Forum:
Tags:
I suggest checking the HTTP return code
My first guess on a pesky redirect that keeps redirecting, is that it was initially done as a 301 (permanently moved). If that's the case, then it's likely been stored by your browser.
If you have another browser, you can test with that (or perhaps install an additional browser if you don't have one). Another option is to use curl. Curl is available for Windows and I'm sure Mac as well (it's usually pre-installed in Linux, or can be easily installed via package management).
By default, curl will not follow redirects, so instead of being redirected, you will get a message such as this:
Obviously that is a 302 redirect (temporarily moved, which is not cached by your browser). But it gives you the idea... You can also tune the switches that you use with curl to give you different info.
Even if you don't have curl locally, in this case, you could test it from the commandline of the machine itself. Obviously that won't tell you how it was redirecting before, but it will show you what it is doing now, which may assist in troubleshooting. So try these and see what happens:
If my guess is right, and it is (or at least was) a 301 being cached by your browser, you'll need to manually clear the browser cache. The easiest is to just manually clear your whole browser cache, although IIRC you can do it site-by-site, at least in Chrome. You'll need to google the specifics of your particular browser.
Having said that, there are multiple points where a redirect could be occurring. As noted above, it could be your browser; but it could also be the web server, or the application (WordPress in this case) itself. It's perhaps worth noting, that Webshell and Webmin (ports 12320 & 12321 respectively) are behind Stunnel, so it is not surprising that they don't redirect.
On the WordPress appliance, Adminer is hosted by Apache, but as it has it's own Apache configuration (it uses a separate virtual host) and (obviously) is a completely separate application to WordPress. So that rules out a global Apache (webserver) redirect, but still doesn't rule out a redirect by the WordPress virtual host, an .htaccess file (which is essentially an Apache config snippet) within the WordPress files or the WordPress software itself.
If you care to share your Apache config for WordPress (should be /etc/apache2/sites-available/wordpress.conf), I'm happy to give you my 2c on that, but I note that the default config the WordPress appliance ships with (see here) does not redirect by default. So that seems unlikely (if you added it, I'm sure you'd remember?!)
It does sound like you may have pretty much exhausted the WordPress possibilities... Although I did find this "Webmasters" stackexchange Q&A which notes that individual WordPress modules may have (or may be) causing the redirect. This AskUbuntu Q&A (Ubuntu is also based on Debian; as is TurnKey) dicusses how to enable redirect logging. There are likely lots of other resources online which might help.
Thank you @ Jeremy Davis !
Thank you @ Jeremy Davis !
But now I have the redirection to the right IP, but some of the element background and orther stuff are strill pointing to the old IP, so now I have a mix...
Simply I think I will start that WordPress from scratch... It think like that that sometimes give me cold to pass fully to linux....
anyway thank you, and thank for the Curl link ! useful tool !
It sounds like you're going to just start from scratch
It sounds like you're going to just start from scratch, but one other thing you could try is using grep to find a specific redirect (or at least pin down where it's occurring).
Assuming that it's only WordPress redirecting, and you've eliminated Apache (or at least the main config anyway), then you could check for redirects in .htaccess files and WordPress code using grep.
grep is a powerful command line file contents search tool. It allows you to search the content of files for specific text strings. By default it will only search a specific file, but the -r|--recursive switch will make it search all files found within a directory. So to check all WordPress files for mentions of a specific IP address (I'll use xxx.xxx.xxx.xxx, but replace that with the string you are searching for):
If it finds a match, it will return a list that looks a little like this:
If it doesn't find any files that contain matching contents, it will return nothing (except a non-zero exit code).
Whilst grep can only be used on files (or strings/variables via echo), you can also use grep to search your WordPress DB. It's possibly not the best tool for the job, as you'll still need to read the SQL to find what needs to be edited (with some other tool). But it is at least a quick and dirty way of seeing if a string exists within a DB. You can pipe the MySQL dump through grep directly, like this:
Or you can dump the DB to a file first and grep that (useful if you wish to search for multiple strings and have a big DB that takes a little while to dump):
It shouldn't be relevant in this case, but if you're using grep to search for a string, you'll find that it will match the text anywhere, so grepping for 'foo' will not just match 'line with foo in', but also 'line with foobar' as well as 'line with afoobar here'. You can force it to search for whole words (so it will match 'line with foo', but not 'line with foobar') using the -w|--word switch.
If you get too many results and it just scrolls on for ages and you want to have a closer look (especially useful if your terminal doesn't allow you to scroll back through the history), then you can pipe grep through less. Less will show the first screen of results, in a scrollable list (use arrow keys to scroll up and down, q to quit back to the commandline). E.g.:
This is all probably irrelevant to you right now, but I just love the commandline so much and can't help but try to share the love whenever I get the chance! :)
No client computer related
So I started from scratch.. :/
but I still remain with a bug.
All the images are not showing up :/ only when I access the WP from a remote location with a domain name like https://mylittleWP.domain.com
when I access it from the local lan 192.168.0.x everything show up
any ideas ?
To troubleshoot this sort of issue, try browser dev tools
My guess is that the pictures are only available via a specific domain/IP that is not available remotely.
To double check this sort of issue; recreate the problem (e.g. in your case, accessing the site remotely via domain) and with your site open in a web browser, open "developer tools" (in Chrome it's under "More Tools", not sure where you find it in other browsers, but it should be available). There will almost certainly be errors reported (in chrome; look for a red circle with a white cross). That will likely note an error such as "Failed to load resource - file not found" or similar. But it will also note where it's trying to load the resource from. My guess is that it's trying to load the pictures via the LAN IP address (i.e. 192.168.0.x).
Assuming that I'm right, you may need to go into your DB (and/or WP config) and adjust the domain that the files are served from (i.e. change the IP to the domain). To ensure that everything loads properly locally (and isn't looping via the internet) you can add an entry to your hosts file that points to your server.
Add new comment