HTTP/HTTPS issue causing security warnings about autoptimize HOT 15 CLOSED

btw, turning off inline all css puts the right stuff into the files

from autoptimize.

it could also be the case that the admin ui should let the user put scheme relative urls in as the cdn url?

from autoptimize.

Looks like making the cdn write to url relative can fix the issue

I add this little snippet to the site and the https warnings go away

add_filter( 'pre_option_autoptimize_cdn_url' , 'pre_option_autoptimize_cdn_url' , 10, 1 );

function pre_option_autoptimize_cdn_url( $option_value ) {
    if ( defined( 'PBCI_CDN_TO_HTTPS' ) ) {
        $option_value = '//' . PBCI_CDN_TO_HTTPS;
    }

    return $option_value;
}

The PBCI_CDN_TO_HTTPS constant is defined in my wp-config.php

from autoptimize.

Weird. Is this with the "in development version" here on Github or the "current" 1.9.4 (or both)?

from autoptimize.

It's Version 1.9.4.

Not sure if it's related or not but found another behavior that is not what I would expect.

If I use the filter to set cdn url to something like "//cdn.mysite.com", and I turn on the minify option with the checkbox. All of the links in the html become relative to "cdn.mysite.com", even the page hyperlinks.

One click and the user end up browsing the site via the cdn, in my case cloudfront :)

How can I help diagnose this?

from autoptimize.

It's worth mentioning that wp-super-cache is on the site, cdn option not enabled.

Doubtful it's an interaction with the buffering, but who knows.

from autoptimize.

Could you test if this is also the case with the soon-to-be-2.0 version (the one here on GitHub)? quite a lot of changes here, also in the CDN-functionality, so this might be fixed already :-)

from autoptimize.

sure thing

from autoptimize.

I tested and the same behavior happens with the development version of AO. I made you a video

http://www.screencast.com/t/BfOhWTt4v

I can't make it break on my development system. The application configurations are almost exactly the same. Production is Apache 2.4.17 on Ubuntu, development is apache 2.4.4 on Windows.

from autoptimize.

I'll see if I can reproduce on any of my environments.

Could any other plugin be interfering here somehow?

from autoptimize.

My thoughts also. I am thinking that there is an interaction with another plugin. I have two sites running the same configuration and one site does not have the problem and the other does.

My theory is that the ob_start() technique that is used to capture the output is setup in a different order on the the two sites, so it unwinds in a different order, and that causes the different behavior.

If you never see this don't dig to deep, i''ll add some logging to my sites and see if I can trace it down. I can debug on the live sites early in the morning USA/EST when they are not busy.

from autoptimize.

regarding priority of AO; you can try forcing it to fire earlier by adding
define("AUTOPTIMIZE_INIT_EARLIER","true");

to your wp-config.php

what strikes me is that this only occurs if CSS is inlined; AO goes through the exact same aggregation & minification process for inlined or normal CSS, the difference is only in how it is re-injected in the HTML. this confirms that something else is altering the inline CSS, probably after AO has injected it.

from autoptimize.

so was looking into the fixurl() function in autoptimizeStyles.php, which is the one responsible for turning relative URL's in the original CSS-files into absolute URL's (to make sure they work in the optimized CSS) and it already removes the http(s), cfr. https://github.com/futtta/autoptimize/blob/master/classes/autoptimizeStyles.php#L599

so except when the URL is already absolute, AO would spit out nice protocol-less URL's.

have you been able to debug?

frank

from autoptimize.

It seems to be directly related to one of the several plugins that have code trying to make sure that a page served over https doesn't have any non-https static resources. I suspect a poorly written regex somewhere to be at fault. I'm just not good enough at regex writing to spot the issue.

My solution for the immediate issue is to disable this functionality in the other plugins.

from autoptimize.

In that case (other plugin changing URL's in HTML, confirmed by the fact this does not happen if autoptimized CSS is not inlined), I think we can close this. Don't hesitate to re-open (or create a new issue) if you can track this down to AO after all.

from autoptimize.