scriptorium

Hi Rogiers,
Thanks for your fast answer.
As for the $ in the code I’m surprised since the plugin is regularly updated meaning this should have happened to any of the updates of the 2.2 branch or at least to one of them.
Regarding the check mixed content fixer I do not see any more the animation during the checking meaning I cannot check any pages any more from the plugin admin page.
2 “bugs” or “dysfunctions” with the same version cannot be a coincidence. Rather I have installed or uninstalled something that broke your plugin -this I can’t believe for you’ve submitted 2 or 3 updates within a few days only, if I’m not wrong- or rather this very update has something specific. That’s only some theoretical thoughts.
Anyway, thanks again.
Regards.
Gilles

Hello there,
A million thanks to you wonderm00n.
I’ve been facing the same issue for months and months, looking for THE answer: how to make Autoptimize aggregating css and js on a multilingual site with virtual multi-domain (.fr and .com), one per language, and one only physical wordpress install.
And wonderm00n, you’v done it!
Kind regards
Gilles

Hi Rogier,
Thanks again for the clue. That’s what I was guessing.
Regards.
Gilles

You are welcome Rogier.
You are right regarding the permissions check (last plugin version 2.2.6 in use).
I’ve just changed my .htaccess permissions to 404, which I have rather keeping, and the .htaccess configuration was positively detected! Up to now I had to shift through ftp from 644 to 404 ad reverse from 404 to 644. Thanks!

If I may, have you ever heard of any kind of interaction between the PHP allow_url_fopen directive and your plugin?
My webhoster sees the directive set to true (both local and master) but my website -through phpinfo()- sees it set to false (both local and master). I’ve been said that it was due to the fact that from my webhoster side the test was made through http connection when from my website it was made through https connection. If so I should have the local directive set to false and the master set to true.
I wonder if it is a false positive answer, I mean it is set to true but wrongly detected, or if the plugin does interact in anyway and changes the directive values.
Thanks in advance for your kind help.
Regards.
Gilles

Hi everybody,
There’s a simple workaround:
First check using a ftp client (FileZilla is a very good choice) your .htaccess file access right and set them 0644 in order to edit and save any change made in the file.
The following lines are automatically set by WordPress in a .htaccess file, created if none found, in order to have the permalink working:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

So, simply edit your .htacces file and add bellow the following lines:

# BEGIN rlrssslReallySimpleSSL rsssl_version[2.1.18]
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>
# END rlrssslReallySimpleSSL

Most important let .htaccess file access rights set to 0644. When set bellow this, like 0404 for instance, which is far better, the plugin can’t check your .htaccess file and therefore decide to use javascript instead.
That’s all.
Gilles

P.S.: to Rogier: please think in the next version to first check the .htacces rights level, before enacting javascript redirection