Hello, there,
Normally WPRocket should not have compatibility issues with Adaptive Images. There a number of other possible reasons for problems. Most of them we try to address in the plugin description page, but it does require some reading! 🙂
As a starting point could you possibly send us the results of the Print debug and Print diagnostics buttons in the Adaptive Images settings page?
Cheers,
Takis
Thank you so much for your support!
Debug info is:
✔ PHP GD library is installed.
✖ Image cache directory has not been created.
But this is probably because the cache has not been accessed yet.
After accessing your website from a mobile device the directory should be automatically created.
/home/www/[domainname]/site/wp-content/cache => drwxrwxrwx
✔ Installation .htaccess file is setup OK.
/home/www/[domainname]/.htaccess => -rw-r--r--
❖ Adaptive images settings dump:
array(14) {
["resolutions"]=>
array(4) {
[0]=>
int(1920)
[1]=>
int(1024)
[2]=>
int(640)
[3]=>
int(480)
}
["landscape"]=>
bool(true)
["hidpi"]=>
bool(true)
["cdn-support"]=>
bool(true)
["cache-directory"]=>
string(21) "cache/adaptive-images"
["watched-directories"]=>
array(2) {
[0]=>
string(18) "wp-content/uploads"
[1]=>
string(17) "wp-content/themes"
}
["jpeg-quality"]=>
int(75)
["sharpen-images"]=>
bool(true)
["watch-cache"]=>
bool(true)
["browser-cache"]=>
float(0)
["version"]=>
string(6) "0.6.67"
["sanitized"]=>
bool(true)
["wp-content-dir"]=>
string(43) "/home/www/[domainname]/site/wp-content"
["wp-content-url"]=>
string(45) "https://[domainname]/site/wp-content"
}
And diagnostics are:
Web Server
Apache
Document Root
/home/www/[domainname]/
PHP
7.3.7-1+0~20190710.40+debian9~1.gbp032aec
PHP Time Limit
30
PHP Memory Limit
512M
PHP Post Max Size
50M
PHP Upload Max Size
50M
PHP Max Input Vars
1000
PHP Display Errors
No
PHP Error Log
MySQL
5.5.5-10.2.25-MariaDB-10.2.25+maria~stretch-log
MySQL Ext/mysqli
Yes
MySQL Table Prefix
wp_
MySQL DB Charset
utf8mb4
WP
5.2.2
WP Multisite
No
WP Debug Mode
No
WP Site url
https://www.[domainname]/site
WP WP Home url
https://www.[domainname]
WP Permalinks
/%postname%-%category%/
WP home path
/home/www/[domainname]/
WP content dir
/home/www/[domainname]/site/wp-content
WP plugin dir
/home/www/[domainname]/site/wp-content/plugins
WP content url
https://www.[domainname]/site/wp-content
WP plugin url
https://www.[domainname]/site/wp-content/plugins
WP Locale
de_DE
WP Memory Limit
512M
WP Max Upload Size
50mb
WP Active plugins
Adaptive Images for WordPress v.0.6.67 by Nevma
Admin Menu Editor v.1.9.1 by Janis Elsts
Anti-Spambot Email Shortcode v.1.1.5 by Robert Peake
BackWPup v.3.6.10 by Inpsyde GmbH
ChimpMate - WordPress MailChimp Assistant v.1.3.2 by Voltroid
Contact Form 7 v.5.1.4 by Takayuki Miyoshi
Duplicate Page v.3.9 by mndpsingh287
Envato Market v.2.0.1 by Envato
Favicon by RealFaviconGenerator v.1.3.15 by Philippe Bernard
Flow-Flow Lite v.3.1.23 by Looks Awesome
Image Credits Nofollow v.1.3 by Apasionados.es
Jetpack von WordPress.com v.7.6 by Automattic
WPBakery Page Builder v.6.0.5 by Michael M - WPBakery.com
LEVELUP Core v.1.1.37 by Puzzlerbox
Loco Translate v.2.3.0 by Tim Whitlock
Mailchimp for WordPress v.4.5.3 by ibericode
New RoyalSlider v.3.3.5 by Dmitry Semenov
WP No External Links v.1.0.2 by nicolly
No Follow All External Links v.2.3.0 by gearpressstudio
Virtual Robots.txt v.1.9 by Marios Alexandrou
PHP Code Widget v.2.3 by Otto
Publicize With Hashtags v.0.1.4 by Darkseal
Really Simple CAPTCHA v.2.0.2 by Takayuki Miyoshi
Regenerate Thumbnails v.3.1.1 by Alex Mills (Viper007Bond)
Relevanssi v.4.3.2 by Mikko Saari
Remove Google Fonts References v.2.6 by Bruno Xu
Remove Yoast SEO Comments v.3.1 by Mitch
Slider Revolution v.5.4.8.3 by ThemePunch
Search In Place v.1.0.42 by CodePeople
SEO Friendly Images v.3.0.5 by Vladimir Prelovac
WP DSGVO Tools (GDPR) v.2.2.19 by Shapepress eU
Sitemap v.4.3 by webvitaly
Theme My Login v.7.0.14 by Theme My Login
Envato Toolkit v.1.4 by KestutisIT
User Role Editor v.4.51.2 by Vladimir Garagulya
Video Thumbnails v.2.12.3 by Sutherland Boswell
Yoast SEO v.11.9 by Team Yoast
WP Rocket v.3.3.6 by WP Media
WP Live Search v.0.9 by
WP MU plugins
WP Migrate DB Pro Compatibility v.1.1 by Delicious Brains
Meanwhile I read this thread and it seems to be the same problem. Images are not loaded and the directory has not been created. Could it be a problem of my webhost? Thanks a lot!
I’ve found something:
As in a former thread my WordPress is not in the root as well. As you can see it is in the directory /site/.
Now I found out that in the .htaccess the code was created with a double /site/site instead of a single:
# BEGIN Adaptive Images
#=======================
<IfModule mod_rewrite.c>
RewriteEngine On
# Watched directories
RewriteCond %{REQUEST_URI} /site/wp-content/uploads [OR]
RewriteCond %{REQUEST_URI} /site/wp-content/themes [OR]
# Redirect images through the adaptive images script
RewriteRule \.(?:jpe?g|gif|png)$ /site/site/wp-content/plugins/adaptive-images/adaptive-images-script.php [L]
</IfModule>
# END Adaptive Images
So I deleted one site/ manually and afterwards the images on the website are visable again. So it seems to be working!
But I have to delete the doubled site/ each time of changing the settings. If I can give you more details to fix it feel free to ask!
Hello, my friend,
Thank you for all this info!
What you are saying makes sense. And indeed it is not a nice thing having to manually edit the htaccess file every time you save the plugin settings. This is not how it is supposed to work.
I am trying to figure out exactly why this happened in your installation. Is your installation actually in a subdirectory, like http://www.domain.com/site/? Or have you kept the root domain of your WordPress, but installed it in the subdirectory? The problem must have something to do with this setup and the fact that we have possibly missed some sort of condition.
Lastly, we would love it if we had the chance to debug this issue first-hand in the actual or a staging environment. If you think this is possible you may contact us as at info [at] nevma [dot] gr.
Cheers,
Takis
Thanks, Takis and yes you are right! The WordPress is in a subdirectory as you already discussed – I think – 2 years ago in an older thread with another person. I can’t find the thread again (unfortunately the search function of this forum is ugly).
So that you can reproduce it …
The settings in WordPress admin are:
The website:
https://domain.example/
The WordPress:
https://domain.example/site/
Then just copy the index.php and .htaccess from /site/ into root directory.
And edit the index.php to
require( dirname( __FILE__ ) . '/site/wp-blog-header.php' );
Afterwards everything works from the root-domain, but the WordPress stays in the subdirectory.
So now the problem is your plugin seems to create the link to adaptive-images-script.php in the .htaccess double. Maybe it is because the plugin is from .htaccess one more subdirectory away as well. And so it linked back to root twice.
I have created a WordPress test environment where the problem appears by default and will send you test-admin access to check it out.
Thanks a lot for your quick and great support! Your plugin is fantastic!
Hello, my friend,
Thank you also for your time and your kind words!
Indeed this is the case and during the course of the years I have come to realise that not all users use the same technique to achieve this and this has been the cause for these minor discrepancies.
One can put WordPress in its own subdirectory and either make all urls (including the static ones in the /wp-content directory) appear as if they originate from the root url or one can let the static ones appear originating from their actual directory.
So in case 1 you have: http://www.domain.com for the domain and http://www.domain.com/wp-content for the /wp-content, whilst in case 2 you still have http://www.domain.com for the domain but you have http://www.domain.com/subdir/wp-content for the /wp-content (and of course same for /wp-admin and /wp-includes).
(These cases are explained here https://wordpress.org/support/article/giving-wordpress-its-own-directory/!)
We have properly taken care of case 1 but it seems that we missed case 2! What you are describing for your installation is actually case 2.
Although I am not particularly a big fan of this technique at all (it mostly creates causes for edge cases without much enhancement in security) this case is now under my radar and I will work on fixing it in future versions!
Cheers,
Takis
I sent you an email!
The thing is, on my own website I moved the .htaccess to root after publishing the website. So there is no old .htaccess in directory /site/
That’s why the rewrite rule of your plugin in the root-htaccess leads to broken image links.
On another server I’ve got a WordPress for testing. In a subdirectory as well. There I didn’t move but copied the .htaccess to root. So the origin file is still in /site/ directory with the old rewrite rule to index.php. That’s why the image links still work, but no cache directory can be created by the plugin and the caching doesn’t work.
Maybe that’s why some of your users have problems with getting the caching work and some with invisible images.
Hope this is helpful!
Thank you very much, I received your email and I will take it from there! 🙂
Related to NGinX, my webhost is a Apache/NGinX mix and I have only access to the Apache configuration. But not to nginx.conf. Is there a way to set it anyway?
Just for the history of it: the ticket was handled privately and is now complete. The issue had to do with finding the correct NginX configuration files and applying the Adaptive Images setting there.
