Can it work with a “On Fly Generating Thumbnails” plugin

Well, I have finally tested it, but something is wrong. With or without the other plugin.

It displays a message “Original image not found or not available.” when clicking on the image SRC attribute, when these files exists physically. Moreover, the strangest thing is that these URL never display an updating link (like something referring to the plugin’s cache folder, which doesn’t exists).

Tried with a clean .htacess, doesn’t change anything, unfortunately. Do you have an idea on how yo debug the issue, since my servers log doesn’t report any problem related to this?

Allright, it is finally working, but because I have renamed my wp-content, I had to modify the adaptive-images-script.php too.My question is : why don’t you create a new field in the setting page in order to set our actual wp-content foldername? This will be an easy way to provide support for people like me.

Actually, I have just added a vraiable $wp_content_foldername = my-folder-name and this do the works :

// Beginning at line 70 of adaptive-images-script.php
// Resolve the path of the image file based on the /wp-content path and the request URI.

            $requested_uri = parse_url( urldecode( $_SERVER['REQUEST_URI'] ), PHP_URL_PATH );
            $wp_content_foldername = '/my-folder-name';
            $index = strpos( $requested_uri, $wp_content_foldername );
            $index += strlen( $wp_content_foldername );
            $source_file = $wp_content . substr( $requested_uri, $index );

Can you maybe think about a new field for this purpose in your next update? Or maybe something taking account some constants like WP_CONTENT_FOLDERNAME which is defined in our wp-confi.php?

Regards.

Hello, my friend,

Thank you very much for going to all this trouble to test out our plugin, we do appreciate it!

I am not sure how the Fly dynamic images resizer plugin works exactly. However if it does create the image thumbnails and put them in the expected directory, then most probably our plugin will find them there and use them. Of course, what these two plugins do is a lot different. Our plugin expects to find all the images in their expected directories while the other plugin tries to save disk space by not generating thumbnails until they are requested by the users.

About the wp-content directory name and path, you are absolutely right, this is a shortcoming which will be corrected in the next version. Actually the wp-content directory will be detected automatically by your settings and constants, so there will be no need for the admin to specify it in the plugin settings page.

Let me know if there is anything more you need!

Cheers,
Takis

Hi there,

After some test, this combo just work as expected :

1 – Deregistration of all automatically generated wordpress thumbnails
2 – Optimisation of full size image via ShorPixels
3 – Generation of thumbnails “on the fly” by replacing the_post_thumbnail() with Fly Dynamic Image Resizer
4 – Adaptive images thanks to your plugin

Perfect ??

PS : Do you think it will be a good idea to put the original file size in all my queries (average of 1280x720px) in order to let your plugin reduce them when needed? If this process doesn’t use any kind of bandwith but only server memory/processor, then the step (3) is not necessary.

• This reply was modified 8 years, 4 months ago by moxymore.

Hello, there,

So glad it all worked out. Seems that the whole ecosystem is designed so well (WordPress), along with its consisting parts (plugins)!

As you say, step 3 might not be necessary for the delivery of the images, because this is taken care Adaptive Images. But if you want to save disk space the you do need Fly dynamic. These are two different functions and you can choose which of them you actually need!

Cheers,
Takis

Allright, I have a last question then, since the space isn’t a problem, but I care about performance : what about CPU/RAM server consumption with a such process if I decide to put all my queries with the_post_thumbnail( ‘full’ ), in a page like my hom page which will have (soon) something like 7 or 8 post grids showing the last 6 posts of the CPT (which means 40-48 image to be generated before they are in cache)?

This would probably consume a lot of ressources isn’t it? My files are at an average of 100ko for a 1280x720px based full size. My server CPU is a 64 bits, and tha available RAM for scripts are at 1280 Mo. I just want to know what do you think about a such process, I haven’t a proper knowledge of the server-sided operations.

Regards.

• This reply was modified 8 years, 4 months ago by moxymore.

Well, since our plugin caches all images it creates, any impact it might have should only be slightly visible during the first request for each image. I cannot tell at exactly what point that “slight impact” might become annoying, but my best guess that you will not even notice it. All you have to do is make some tests and see for yourself.

If you see anything peculiar or noteworthy, we will be happy to hear it out and see if there is anything to fix or improve!

Cheers,
Takis

Allright, thank you again for your reply.

In facts, your plugin seems to take into account “only” the device width… and not the width of an image container.

I have seen it when looking at the HTML code of my 3×2 post-grid. Adaptive Images seems unable to determine the available space for each image (which is in this example 33% of (1370px-horizontal margins)), and then just take into account the full width of the device instead of taking into account the width available for the img tags, or his parent.

In facts, it’s maybe another related problem, because I remember yesterday, on my mobile, and even if the grid switch to 3×2 (3 rows / 2 lines) to 1×4, the images are not resized.The only resized images are the one of my themes, and the ones displayed in a lightbox. Everything else fails.

Well, dunno where is the issue, but I’ll investigate it, it sounds not normal.

Indeed our plugin does take into account *only* the device width. This is exactly what it is intended to do. This is its primary prurpose and this is explained in its description. To be honest, taking into account the width of an images container is an entirely different problem technically and I think is best tackled with a responsive images solution, like the picture element.

Hope this makes things a little clearer now!

Cheers,
Takis