I'm facing a problem the last couple of days and I can't figure it out. We changed the hosting company and move our website (same domain name) to another hosting provider. After migration, images not loading, and I can see them broken in WordPress's Media Library.
I tried to change the permissions in the upload folder but that didn't worked. SSL is also working as expected. I disabled all the plugins and even changed the theme, but the problem still persists. I re-uploaded all the backup files again to make sure that I wasn't missing something, but the problem haven't been solved.
I also have the support team from the hosting provider that works on the website, but there's been 2 days now and they can't find a way to solve the issue.
In the browser's Search Console I do see the following errors: https://ibb.co/y0KCmHY
I've also checked the DNS settings in CloudFlare to make sure that I have setup everything correctly.
Any help will be much appreciated!
I am no wordpress expert but I think I would first check whether image files in your backup files are not damaged/corrupted.
I would check both your backup files and image files in your new hosting server
(download image files from your new hosting server via FTP)
Sorry I couldn't help you much except where to look at first which you might already know.
From the image that you've provided, what I can tell the status is 404 like you know which means your image is not found. Something wrong with all your image URL. You need to make sure the URL is correct for each image you have.
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'm facing a problem with the following website: https://www.rhythmandstrums.ie/
When I open the "www" version of it: https://www.rhythmandstrums.ie/ I get a bugged website, failing to open stylesheets and possibly other file sources, whereas if I open the website without the "www", everything works as expected: https://rhythmandstrums.ie/
Some considerations:
This website is hosted in a Wordpress Multisite, so it shares the same configuration files as other websites, none of the other websites have this issue. So I was wondering if this could be a problem with redirection, although, again, none of the other websites have this problem and they share the same config files (including server block settings and such, it is in nginx).
I have checked the DNS values and nameservers and everything looks fine (I took base from all the other websites that were set up in the same way, I can post a screenshot if it might be of help).
This error also seems to happen in the Wordpress backend, with the admin dashboard not being able to load parts of plugins, it seems like it is looking where it doesn't exist.
I have replaced instances of the www version of the url in the database, as I do with other websites as well, but that didn't seem to fix the issue.
I have cleared cache a few times (both in the cache plugin and manually in the nginx server - manually deleting the contents of the cache folder), and since this has been going for a long time, I don't know if this is cache related, but any suggestion is highly appreciated. Again, all the configs, included the cache plugin settings are the same for all the other websites in the network, which none are having this issue.
If I inspect the console when I'm accessing both versions of the website, www and non-www it seems like it's trying to pull information from different locations, but I can't figure out why it's doing that.
Guys, I hope this was not confusing, but let me know if you you would like to see screenshots or other info that might be relevant. Thanks so much in advance, I really appreciate it.
I've transferred my wordpress website from a shared hosting to a linux VPS.
Everything is working fine instead of one thing. I'm getting realy weird pages for editing posts/pages.
I'm not sure how to name it and can't find anything on google about it, so I hope someone here can send me in the right direction.
Screenshot
At a quick glance, looks like a browser caching issue. Try the following:
Clear browser cache/cookies etc. and restart the browser/PC
Check with a different browser
Depending on how you migrated (transferred) the site, it is possible that all files did not get transferred fully and/or the database did not get imported fully. If 1. and 2. above fail, delete everything from the VPS and try again.
I'm sure when you check the network tab or console in inspect element on chrome, you will receive a lot of 404 errors because it is not able to load the required files for some reason.
What you can try is to add define('CONCATENATE_SCRIPTS', false) into your wp-config.php file. What this does is load all the javascript files individually, instead of one concatenated file.
Question: Are you using the same domain on your VPS? Or are you accessing the site on your VPS through a different domain? If so, you might want to update your database to correspond with the domain you're testing with now. Because this can cause strange behavior as well.
This is a weird one. I googled for hours but seems to me not a single person has this same issue.
I moved my website from http://www.domain1.com/wpfolder to http://www.domain2.com . Everything works fine except I cannot get the "wp-login.php?redirect_to" path to point to the correct url.
WordPress keeps setting it to:
"wp-login.php?redirect_to=http://www.domain2.com/wpfolder/wp-admin&reauth=1"
It should be setting it to:
"wp-login.php?redirect_to=http://www.domain2.com/wp-admin&reauth=1"
The "wpfolder" doesn't exist anymore..
I followed the instructions exactly on how to move a WordPress website, but the darn URL won't change...
Some forum mentioned changing the "site_url" and "home" from "http://www.domain2.com" to "http://domain2.com". Now I can finally get to the admin panel, but I don't get why it needs to be that way?
I cleaned my browser cookies and checked the wp-content folder for cache already. Nada..
Also the rest of the site is functional.
I would appreciate if anyone can help.
I moved the WordPress website from GoDaddy to Bluehost by copying the files and the database and the problem went away. I am not sure why this fixed it, but assuming it has something do with the cache.
If anybody has more information, I would love to read about it.
Thanks
I was facing the same issue, with same redirection to one of the sub-directory in which wordpress was installed.
Resolved this issue, by clearing the cache, if some cache plugin is active.
Or by deleting the cache plugin if any present and is currently not yet active.
As some entries made by cache plugin inside wp-config.php file creates the above mentioned problem.
After removing the cache plugin, it resolves the WP-admin URL issues.
wordprees print_thumbnail function is working correctly on testing server but it's not working on online server and giving wrong image path such as */var/www/vhosts/vinehospitality.co.za/httpdocs//wp-content/uploads/2011/12/slide-10-108048_56x56.jpg*.
So kindly help me to get proper url.
Link of website: http://vinehospitality.co.za.plesk15.wadns.net
Same problem is found in hosted on this server.
Regards
Neeraj
Not only did it work, it was SO MUCH easier for me.
Simply, delete whatever custom link you have in Media Settings. If you don't have one just put anything there..
Then save, again, put back the original path you have before, save.
Worked!
Somehow it seems wordpress reads the wrong values when you move servers and you don't resave media settings.
POSSIBLE FIX 2
Look, I've seen this problem on other threads and on other websites and no one gave information that helped most of the people with this issue, so since I somehow got my broken site to work, perhaps it will help the others who did not get their problem solved.
Here's a little background... I needed to move a wordpress site located on a dev server to the live server. They were different domain names of course. First of all, I should have followed Moving Wordpress instructions and updated the site url before I exported the database, but... I didn't because I'm obviously too cool for instructions.
In order to transfer the site, I zipped up the files and transferred them to the new server and unzipped them. Then I edited wp-config and pointed it to the new database.
I used phpmyadmin to export the old database and I imported it to the new database.
Then I ran a query on the wp_posts table to do a string replace on the guid field and replace all instances of the old domain name with the new domain name.
Then I checked in wp_options and changed 2 records to replace the old domain name with the new one. I think they were something like siteurl and home.
Everything seemed to be working fine except the theme was mangling the img urls, prefixing them with the absolute filepath.
I figured I must have missed some records in the database that give the print_thumbnail function whatever information it needs to output the right url for the img's src attribute.
I thought if I could change a setting somewhere and change it back, maybe wordpress would automatically fix the issue for me, and I was lucky.
I played around with several settings and what finally worked was:
I went to Media Settings and I unchecked Organize my uploads into month- and year-based folders -- I don't know if this had much to do with the fix.
I also changed the Store uploads in this folder to something like wp-content/uploads2. I never created that folder, but I just wanted to get it to overwrite whatever was controlling that value.
I checked the site again and there was a change to the html source... now, it didn't even give the img tags a src value... it was just like <img src title="blah blah" />, so I figured I was on the right track.
So then I went back and changed Store uploads in this folder setting and left it blank as it was originally.
After I did that, the img src values were correct.
Hope this saves someone some time.
Also, I should note, I played around with altering the file permissions for the wp-content directory. I wish I hadn't. I get the gist of file permissions, but I tend to try not to fool with them if I don't have to. Using Filezilla is a pain to change the file permissions because it takes forever. Unfortunately, as most clients, this one had a prior affiliation with their web host and refused to take my advice and host their site on a VPS that would be cheaper and allow me to use SSH and get work done much easier. I wonder if there's a fast way to chmod multiple files without ssh, I should look into that.
Cheers,
Will
Will's approach fixed the error for me, and was in fact the only answer that worked. This question is posted hundreds of times, so I figured I'd summarize the answer in short. I'll post the answer first and the research details after.
Login to WordPress
Goto Settings > Media
In "Uploading Files", modify the "Store uploads in this folder" to "http://www.yourdomain.com/wp-content/uploads2"
Notice the "2" added to the folder-name
Delete any entries in "Full URL path to files"
Save changes
Now your site should already show some images again
Do all this again but now change it back to "http://www.yourdomain.com/wp-content/uploads"
Save changes
This finally worked for me.
Gathering from other sources, this occurs mostly after moving a website from one location to another. Other fixes I did prior to this:
Within MySQL, replace the old URL in the GUID values in "wp_posts" to the new URL
Change "chmod" settings (it you never had any prior issues, don't)
Many other answers to this issue included changing chmod to give access to the files, which didn't do anything but crash the website. Other solutions would've been to change the code entirely to use a different function. I figured it's not broken, just missing a setting. Turns out that was the fact.
It worked for the domain http://www.in1week.nl, which runs on a modded DeepFocus template by ElegantThemes.com. The theme uses "timthumb" in the function "print_thumbnail()", which may have caused the issue. This reset the value needed to use the function.
I faced the same problem and had to look around a lot in search of an answer. After my host moved servers, thumbnails weren't appearing on the home page and category pages. Looking up the source showed me that the path generated for the thumbnails was incorrect. Instead of http://.. in the image paths, I was seeing absolute file paths in the server, such as /home/..
Couple of solutions that seemed to have worked for others did not work for me.
What did not work:
Changing permissions of wp-content/uploads and all the directories under it.
Changing media settings and again reverting back to original settings.
Using 'the_post_thumbnail' instead of 'print_thumbnail' function helped the thumbnails come back, but I am no programmer and could not figure out how to make the_post_thumbnail function work exactly as it was working with print_thumbnail
What worked:
In my many searches, I read someone saying that the problem was fixed by correcting the path for 'et_images_temp_folder' in the database. I ignored this for a while since I did not understand what it meant. Later, I searched wp_options table and found that it had the following entry.
option_name: et_images_temp_folder
option_value: /home/painteds/public_html/darter/wp-content/uploads/et_temp
When the servers were moved my home dir was changed from /home to /home3 Perhaps print_thumbnail was searching for /home folder, and was malfunctioning when it could not find it. Updating the database with the new value fixed the problem for me.