I've got a copy of our wordpress instance running inside a Docker container.
Our live instance works well but inside the docker container, I do get a redirect-loop as soon as I try to get access to wp-admin.
I've disabled all plugins, I've cleared my cache and so on but nothing worked so far.
OS is debian, similar to our live system. When I get the redirect-loop, there's no information written in my apache error.log-file.
Oh and this instance is accessible by using a subdomain. I had to rewrite all "www.domain.com" to "sub.domain.com".
If I can provide you with any informations to solve my problem just ask. I have absolutely no idea where to start.
Paddaels
Seems like you missed some records in the database. The best approach is to use a tool like https://interconnectit.com/products/search-and-replace-for-wordpress-databases/
If you download this free tool and upload to your server then it does a batch find-and-replace across every single table in your Wordpress database.
So, for example, replace http://www.example.com with http://sub.example.com
You can do a dry run and it will show you all the replaces that it will make. Once you're happy then click the "live run" button and all the changes are made.
I use this tool all the time when I am moving a site from my local machine to the live server. I also use the exact same approach when migrating a site from http to https
Related
I have a website that is running on an AWS server using the Bitnami Nginx and WordPress image.
https://www.athleticclubhk.com/
Recently it got all our ads on Google stopped due to malicious content. Oddly this time, its trickier then your standard malware of infected files. When visiting the site incognito, the first and only the first link click gets redirected using the following code:
window.location.replace("https://cartoonmines.com/scount");window.location.href = "https://cartoonmines.com/scount";
This is being injected on any link, however, upon investigating the loaded code on inspect its not injecting it into the page.
I've tried to hunt down the theme, plugins, core files and found nothing!
I replaced and reinstalled WordPress core files, deactivated all plugins and even swapped the theme - the problem is still there. I can't find any hidden .htaccess file in the entire root directory.
I even used GREP to try to look for anything fishy (any clues here that someone can help with?) nothing so far.
The site is still impacted with this so you can easily load the link ~ i do use malwarebytes to keep myself protected, incase you are opening this directly.
Can anyone help?
The redirection code is implanted to /wp-includes/js/wp-emoji-release.min.js.
How to confirm:
watch the cookies when clicking internal page, a new cookie is being set for tracking first clicks, named ht_rr
save complete webpage locally and try to load it, and check in Chrome dev tools, you'll see that in Console tab it complains about this Javascript file attempting to set the aforementioned cookie
While a temporary resolution of deleting the file will fix things for some time...
There's no excuse for not setting up a proper server stack. Bitnami or other "great stacks" won't cut it security-wise. They exist for "fast", but no "quality" setup, and of course, it's never going to be secure.
The file got created somehow / had write privileges. This indicates a problem with the setup most of the time. Unless you're using some nulled plugins or plugins from bad sources.
Once again, since the website was essentially "pwned", deleting the Javascript file does not mean complete disinfection. To preserve things in a secure state, I would recommend setting things on a clean server environment with strict PHP-FPM permissions aka "lockdown" chmod, and look for write errors to look for infected PHP files.
Check out some guides on the matter of secure NGINX/PHP-FPM setup:
NGINX and PHP-FPM. What my permissions should be?
Best practice secure NGINX configuration for WordPress
NGINX Security Headers, the right way
Just had the same problem and it was Zend Font Plugin, the same that some people mentioned before.
Installed Wordfence and this came out. Deleted the plugin and now the site is working perfectly.
Disable plugins and check again.
Change the database username and password.
Ask the hosting manager to check the host.
I am migrating my site to digital ocean and I am having an issue with Https. I have moved the directory and the apache2 config file and mysql database. I believe I set everything up correctly but now I want to test it. I have edited my /etc/hosts file with my new ip and sitename.com. However when I try to go to my browser and look to see if the site works it keeps trying to redirect me to the https version of my site.
I have tried going to chrome://net-internals/#hsts and deleting the site but it still redirects to https. How can I test my site without being redirected to the still hosted version of my site?
Thanks!
Aside of the wp_options field, WordPress stores lot's of links 'hard-coded' which all will contain the https. You would need to do a full search and replace on the database, but be aware of serialized stuff. To to safely perform a search and replace you could use a program found on: https://interconnectit.com/products/search-and-replace-for-wordpress-databases/
Works like a charm.
Another way is by using wpcli if you have commandline access and wpcli is available. From the command line go to your root directory (containing the index.php) and type:
wp search-replace https://www.your-domain.example http://www.your-domain.example
Or type:
wp search-replace https://your-domain.example http://your-domain.example
Based on your setup up course.
Always make a full backup of your database before performing these actions, so you can restore if any problems occur.
I am trying to set up a development site on the sub-domain development.warriorsliveon.org of warriorsliveon.org.
This is a WordPress site and I copied the plug-ins, themes, and upload folders to the new WordPress installation on the sub-domain. I also copied the database from warriorsliveon.org, did a find and replace of warriorsliveon.org to development.warriorsliveon.org.
When I go to the site , http://development.warriorsliveon.org. it either switches automatically to the follow address, or other times, lets me log into WordPress, but then goes to this address.
http://development.development.www.development.development.warriorsliveon.org/
Anyone have any ideas where I should look to resolve this issue?
I'm happy to post any code, just not sure at this point what would be useful. Any help is appreciated!
Changing the Domain Name that your Wordpress installation runs under is more complicated than just editing one or two files. The best approach is to use a tool like https://interconnectit.com/products/search-and-replace-for-wordpress-databases/
If you download this free tool and upload to your server then it does a batch find-and-replace across every single table in your Wordpress database.
So, for example, replace http://www.warriorsliveon.org with http://development.warriorsliveon.org
You can do a dry run and it will show you all the replaces that it will make. Once you're happy then click the "live run" button and all the changes are made.
I use this tool all the time when I am moving a site from my local machine to the live server. I also use the exact same approach when migrating a site from http to https
This one last shot before I delete my WordPress deployment installation on the Google Cloud Engine and start from scratch.
My WordPress site was working fine when first deployed about two months back. I then stopped the instance, as I didn't have time to work on it and didn't want to incur charges.
When it came to starting it last night, it seemingly starts ok, as per Google Developers console report, but the front end is everything, but ok. It is timing out, all I get is the index page (after a long time), but without any css and I can't get onto any other pages.
I can connect to the server using ssh command, I can even see the files via SFTP and I can't see anything obvious in phpmyadmin.
Does anybody have any pointers? What other info do you need? Sadly the documentation on Cloud Engine Wordpress deployment is very thin to offer much guidance beyond one click deployment.
Many thanks for any help.
ZONE
asia-east1-a
MACHINE TYPE
g1-small
IMAGE
wordpress-debian-7-wheezy-v20150127
WORDPRESS VERSION
4.1
HTTP traffic is allowed.
Update 26/03/2015:
As #Paolo P pointed out the problem was in the Google Compute Engine assigning an ephemeral address, which was replaced by a new one once the instance was restarted. To fix the issue I did:
login to phpmyadmin >wpdatabase > wp_options > edit siteurl and home with the new url.
edit wp-config.php > add (swap example.com for your new url):
define('WP_HOME','http://example.com');
define('WP_SITEURL','http://example.com');
at this stage your front end will be still unavailable, next
login to /wp-admin, which seems to update some settings in the background and voila, your front end is available at the new address.
comment out/delete the above code from wp-config.php once your site is back up and running again. If you don't, you won't have the ability to change the site urls within the WordPress content management end.
Some further info on changing site url is here. Note, I didn't have to touch functions.php to make it work https://codex.wordpress.org/Changing_The_Site_URL
If your instance had an ephemeral IP it could be changed after stopping it as documented here. After boot Wordpress internal configuration is still referring to a different IP and hence is not finding CSS and other page components.
Assign a static IP to instance and change WP configuration files accordingly. Note that some configurations may need to be updated inside DB data too.
Regards,
Paolo
It seems that using the define('RELOCATE') command is a convenient tool to perform site development using a local database and webserver, then to upload into production. Otherwise, its necessary to perform SQL REPLACE commands to update all the URLs in the posts, media and other content.
The Wordpress codex specifically states that it must be removed, but occasionally after removing, the links revert back to the dev server. Is there a reason for removal? it doesn't seem that security should be the issue, perhaps performance?
Thanks,
Jonathan
The reason you remove it is because define('RELOCATE',true); will point every visitor of your site to the admin login.
If you are still getting re-directed to the dev server then you need to re-configure your database.