Hello, my friend,
I think this is a classic problem these days, because HTTPS is becoming more and more a standard for websites.
Can you check if the urls in your admin Settings > General page do contain the “https” instead of “http”? They should contain the “https” and (sorry about this inconvenience) you need to update your Adaptive Images settings one more time after this.
Also, for a proper and complete migration from HTTP to HTTPS, I would advice performing a url rewrite in your database, which will replace each and every url of your domain from “http” to “https”.
Let me know how this works out for you.
Cheers,
Takis
Hello Takis,
I had the same problem with https and I broke the problem down to the line:
$wp_content_url = 'http://' . $_SERVER['HTTP_HOST'] . '/wp-content';
in adaptive-images-script.php. To fix it I replaced it with:
$ssl = ( ! empty( $_SERVER['HTTPS'] ) && $_SERVER['HTTPS'] == 'on' );
$wp_content_url = 'http'. ($ssl ? 's' : '' ) . '://' . $_SERVER['HTTP_HOST'] . '/wp-content';
It would be wonderful if you considered this fix for a future commit.
With best regards,
George
Hello, my friend @gklauda,
Thank you for sharing your solution with us!
The thing is that your code is perfectly correct, but it only covers the standard cases where the /wp-content folder lies exactly where it is expected and with the name it is expected to have. There are many other cases where one may have changed the path or the name (or even both) of the /wp-content folder. For this reason and because of the added factor that we have chosen to not load the whole of WordPress environment on image requests, it is difficult to determine the images path for all cases in a uniform manner. To be frank, it is quite a pain!
However, we are always on the lookout for a better solution and we love to hear your feedback and ideas.
Cheers,
Takis
Hi Takis,
well, this is an altogether different problem.
If somebody decides to move his /wp-content folder, I think this goes by defining the WP_CONTENT_DIR and WP_CONTENT_URL constants in the wp-config.php. So for your plugin to work properly in such a scenario, it would have to check if these constants are set and, if this being the case, use them instead:
http://hookr.io/constants/wp_content_url/
Cheers,
Georg
Hello, George,
Well, you are right so far, but there are two more tiny details that made the difference:
1. When our plugin is invoked in order to serve adaptive images we have chosen to not load the WordPress environment so that these request can be as lightweight as possible. So, for one thing, we need to be setting the information about the actual location of /wp-content in some place “outside” WordPress (we use a special PHP config file for this, located inside our plugin directory.
2. We need to be able to translate image url requests like http://www.mysite.com/wp-content/uploads/2017/07/myimage.jpg to their original paths in the server which, having renamed or moved the wp-content folder, may result into something like /home/mysite.com/public_html/new-wp-content/uploads/2017/07/myimage.jpg. Having to do this for all possible cases has proven to be quite tricky so far.
(What also adds to the complexity is that the /wp-content folder may have been simply renamed or moved or both and the WordPress itself may be lying inside a subdirectory of the root domain or it may be lying virtually in a subdirectory of the server root.)
However, I will give it another thought, as you may be right after all and perhaps this bit of code needn’t be so complex after all. I certainly hope so!
Cheers,
Takis
Hello Takis,
I understand the problem. And there doesn’t seem to be a convenient solution. Fortunately, the problem afflicts only a relatively small portion of users, and I guess the most rational approach would be to enable people to fix the problem on the options page by letting them indicate the correct location of the wp-content folder. One could also support them by scanning the wp-config file when they visit the options page and showing them the value of WP_CONTENT_DIR if it is defined there. Those are just some ideas that come to my mind and I hope they are not utterly stupid. 🙂
Cheers,
George
Hey, George,
Thanks for taking the time to give it some extra thought!
No, your ideas are not stupid, at all. I love hearing new ideas. My concern is to find a way to cover all cases in a uniform and robust way, because it is all very easy to fix one thing and break another.
Cheers,
Takis
Hello,
sorry for beeing late.
I had changed http to https in the Settings and I also did a search and replace in the database. With no effect (unfortunately the plug still does not work).
I thought about doing the changes @gklauda suggested but decided to wait for a solution by the plugins author :).
It would be great if the PlugIn can handle http to https changes without any troubles for standard wordpress installations (folder not changed).
If a user changes the WordPress folder I think that this will be an advanced user and should know what he is doing. In this case: might it be a possibility to let the user enter the WordPress folder? Just as a simple solution. If you as author of the PlugIn have the possibility to search for the folder for yourself (e.g. by looking for the config files path?) you can make an suggestion for the path.
For me at the moment I decided to wait for an update of the PlugIn which can handle https better.
Thanx for your help
Horst
Hello, Horst,
I am very sorry that it hasn’t worked out for you so far. If you have indeed changed all your urls to https and the plugin still doesn’t work, then this sounds like a really strange situation. I am sure I am missing some important detail here. If you feel like it, perhaps you can send me an email and we can further debug this from the “inside”. Otherwise, we will definitely try to see what we can do in future versions.
And thank you for the rest of your suggestions and ideas!
Cheers,
Takis
Thanks, gklauda! Great solution.
Nevma, I understand your stance of not knowing where wp-content is located, but looking at your code, you’re just hard coding the location in that variable anyway. gklauda’s solution just adds the “S” to HTTPS pages without changing anything for non-HTTPS. Simple and elegant. You should really consider incorporating gklauda’s code–it’s a great fix for the majority of people with standard WordPress installations.
Again gklauda, great find. Thanks!
Hi, @benntech,
You are probably looking at the point where we are setting the default value for the /wp-content location. Just a few lines further on we try to read it based on the user’s settings which derive from their WordPress installation where the WordPress code has actually been loaded.
Now, I could go on and on about how tricky it is to universally guess all the necessary variables during requests which happen when the WordPress code has been loaded, in order to use them at later requests, where the WordPress code has not been loaded, but there is no point.
However, I do promise to consider @gklauda’s solution!
Cheers,
Takis
Why not just remove any protocol either with regex or a simple array of removals? This will avoid any problem even if someone has a saved version of user-settings.php with either http or https.
So something like:
$protocols = array('http://', 'https://');
$wp_content_url = str_replace($protocols, '', $wp_content_url);
$image_url = str_replace($protocols, '', adaptive_images_script_get_url());
$source_file = str_ireplace($wp_content_url, $wp_content_dir, $image_url);
You could also go with the nicer parse_url
-
This reply was modified 8 years, 7 months ago by
renegeuze.
Hello, @renegeuze,
Indeed, it seems that the solution to the problem is like you propose. It has also been proposed earlier in this thread as well. The reason we have not included such a piece of code is -more or less- the historical evolution of our own code. We do pledge take this proposal into serious consideration in our next versions.
Thank you for chipping in!
Cheers,
Takis
