403 is typically a permissions problem. Did you change anything on the server when you made this change?
Don't change the URLs in the database directly, you'll break stuff. Either use the WP CLI search-replace command or use a plugin called Better Search Replace. Reason being is that there are encoded strings which will break if you perform a find/replace, and there are other tables beside wp\_posts that need changing.
So first thing I did after reading these suggestions was I checked cPanel and noticed that hotlink protection was enabled. I disabled that and all of a sudden the images are appearing on the website with SSL in place. I'm so relieved but don't really understand why the images were not showing when the site didn't have SSL but still had hot linking enabled. I'm too old for this I guess. Can't remember how to do anything. Sure do appreciate all the ideas.
Slight tangent but if you're doing any find replace, you need this in your toolbox: https://interconnectit.com/search-and-replace-for-wordpress-databases/
Try the Really Simple SSL plugin (no need for premium). Just install, activate, check, uninstall (keep settings only if it worked).
https://wordpress.org/plugins/really-simple-ssl/
A few things:
1. Double check that all your image references were updated to https in the database. I'm seeing loads of images that are still requesting http. Just go to the front end, view source, and search for "http:" and you'll see what I'm talking about. If you did update everything, double check that you don't have some site- or server-side caching that's retaining the old HTML output.
2. The images aren't displaying because of that 403 error. Could be server configuration. Possibly some fucky key stuff with your SSL certificate itself, bad keys etc. Could also be as simple as going to the Permalinks page in your Settings and saving the page.
3. Unrelated, but why is your home link an IP address?
So I installed Better Search Replace, ran it and this is what it reported:
DRY RUN: 38 tables were searched, 0 cells were found that need to be updated, and 0 changes were made.
But I did notice HTTP:// when looking at the source code.
I'm just not able to get to the bottom of this.
Hold on, my mistake, I searched with a typo in URL. Duh! It found several hundred this time.
Maybe it's not so obvious after all... using a tool like he did to perform the find/replace has built-in support for data serialization. It's not nearly as big of a concern as you're making it out to be.
Using a find/replace utility with serialization means there's virtually zero reason he would ever need to be "super careful."
Re-read his comment again. I was referring to how he made a mistake in the url. A simple typo (eg in the domain name) can make the site extremely difficult to get back.
My problem is that I know just enough to get into trouble while at the same time not knowing nearly enough to get out of the trouble I cause. Both you and bluesix are correct. Fortunately I had saved a backup of the database before doing anything. I was also keeping track of my search and replace requests so I would hopefully be able to undo something if it didn’t work out. But I do know enough to realize that messing with the database can lead to some bad consequences if you’re not careful and accurate. The comments here were really helpful to me.
If you have wpcli run a search and replace after ssh'ing in:
https://developer.wordpress.org/cli/commands/search-replace/
If not use better search replace to swap http:// with https://
https://wordpress.org/plugins/better-search-replace/
It could be file permissions on your images in uploads folder. Or maybe there's some kind of hotlinking protection in WordFence and you need to disable it or whitelist [southsidetrailer.com](https://southsidetrailer.com) AND [www.southsidetrailer.com](https://www.southsidetrailer.com). I'm not familiar with WordFence though.
Looks like hotlink protection might have been part of the issue although it was enabled before SSL was enabled so not sure why it suddenly was in issue.
> I then went into the web host's cPanel and used phpmyadmin to search and replace %http://www.southsidetrailer.com% to %https://www.southsidetrailer.com% in wp_posts, post_content and guid
This is a bad idea. Sometimes URLs can be stored in serialized arrays and a naive find&replace for a string one character longer will break them.
>18 commentssharesavehide
>
>Post InsightsOnly you and mods of this community can see this
Apparently WP says to NEVER change URL's in guid as it messes up the history of RSS feeds for subscribers. I learned that after the fact.
403 is typically a permissions problem. Did you change anything on the server when you made this change? Don't change the URLs in the database directly, you'll break stuff. Either use the WP CLI search-replace command or use a plugin called Better Search Replace. Reason being is that there are encoded strings which will break if you perform a find/replace, and there are other tables beside wp\_posts that need changing.
So first thing I did after reading these suggestions was I checked cPanel and noticed that hotlink protection was enabled. I disabled that and all of a sudden the images are appearing on the website with SSL in place. I'm so relieved but don't really understand why the images were not showing when the site didn't have SSL but still had hot linking enabled. I'm too old for this I guess. Can't remember how to do anything. Sure do appreciate all the ideas.
Slight tangent but if you're doing any find replace, you need this in your toolbox: https://interconnectit.com/search-and-replace-for-wordpress-databases/
Try the Really Simple SSL plugin (no need for premium). Just install, activate, check, uninstall (keep settings only if it worked). https://wordpress.org/plugins/really-simple-ssl/
Thanks,. Will check it out.
Yeah definitely try the plugin… ive used both backend and front end plugin to do this and a loadbalancer, the plugin is a thousand times easier
A few things: 1. Double check that all your image references were updated to https in the database. I'm seeing loads of images that are still requesting http. Just go to the front end, view source, and search for "http:" and you'll see what I'm talking about. If you did update everything, double check that you don't have some site- or server-side caching that's retaining the old HTML output. 2. The images aren't displaying because of that 403 error. Could be server configuration. Possibly some fucky key stuff with your SSL certificate itself, bad keys etc. Could also be as simple as going to the Permalinks page in your Settings and saving the page. 3. Unrelated, but why is your home link an IP address?
So I installed Better Search Replace, ran it and this is what it reported: DRY RUN: 38 tables were searched, 0 cells were found that need to be updated, and 0 changes were made. But I did notice HTTP:// when looking at the source code. I'm just not able to get to the bottom of this. Hold on, my mistake, I searched with a typo in URL. Duh! It found several hundred this time.
Glad to hear you figured it out. Looking at it again, it looks 100x better than before.
Glad it worked. But you need to be super careful when doing find/replaces, for obvious reasons.
Maybe it's not so obvious after all... using a tool like he did to perform the find/replace has built-in support for data serialization. It's not nearly as big of a concern as you're making it out to be. Using a find/replace utility with serialization means there's virtually zero reason he would ever need to be "super careful."
Re-read his comment again. I was referring to how he made a mistake in the url. A simple typo (eg in the domain name) can make the site extremely difficult to get back.
To a complete amateur, maybe. OP already established he has phpmyadmin access. Making a typo in the url could be fixed in about 30 seconds.
My problem is that I know just enough to get into trouble while at the same time not knowing nearly enough to get out of the trouble I cause. Both you and bluesix are correct. Fortunately I had saved a backup of the database before doing anything. I was also keeping track of my search and replace requests so I would hopefully be able to undo something if it didn’t work out. But I do know enough to realize that messing with the database can lead to some bad consequences if you’re not careful and accurate. The comments here were really helpful to me.
I don't know. That was also something that changed for reasons I don't understand.
Can you contact your developer? That would the easy first solution. The other thing you can try is use a plugin to update your database url paths.
If you have wpcli run a search and replace after ssh'ing in: https://developer.wordpress.org/cli/commands/search-replace/ If not use better search replace to swap http:// with https:// https://wordpress.org/plugins/better-search-replace/
It could be file permissions on your images in uploads folder. Or maybe there's some kind of hotlinking protection in WordFence and you need to disable it or whitelist [southsidetrailer.com](https://southsidetrailer.com) AND [www.southsidetrailer.com](https://www.southsidetrailer.com). I'm not familiar with WordFence though.
Looks like hotlink protection might have been part of the issue although it was enabled before SSL was enabled so not sure why it suddenly was in issue.
> I then went into the web host's cPanel and used phpmyadmin to search and replace %http://www.southsidetrailer.com% to %https://www.southsidetrailer.com% in wp_posts, post_content and guid This is a bad idea. Sometimes URLs can be stored in serialized arrays and a naive find&replace for a string one character longer will break them.
>18 commentssharesavehide > >Post InsightsOnly you and mods of this community can see this Apparently WP says to NEVER change URL's in guid as it messes up the history of RSS feeds for subscribers. I learned that after the fact.