Connection reset – legacy filter required

Pretty weird, only thing I can think of is _very_ low php execution time limit. I’ll ping you here as soon as I have a test-version of 1.8 with the css-min update, maybe that’ll solve things indeed. And of all fails, we’ll always have legacy minifiers ??

OK, 1.8.0-test has just been published, looking forward to your feedback!

Thanks for the update!

Bummer though, I just tested it out on a couple of my local sites, and no luck. Same situation, all works great will legacy filters, but fails if not.

My max_execution_time = 60 so that shouldn’t be the issue, and it only takes 3-5 seconds maybe before it errors out.

Something else I noticed on one local site I tested. This happen in Firefox only, but sometimes it re-directs a “www” URL, ex: https://www.testsite.localhost even though the site is setup without a www.

Anything else I can help to track this down let me know or we can just let it ride since at least the legacy minification works for me.

Pretty weird … Regarding the redirect; is that the URL of your site itself, or the URL of the CSS?

That is the URL I get in my browser bar. I can’t even see the source code unfortunately because I either get that redirect to the www url that fails or the browser gives me a “The connection was reset” so nothing loads. Bummer hey. No worries though. Hope that makes sense at least.

Well, you’ve got some pretty weird things going on there, good thing there’s legacy ??

Hi futtta,

I’m having exactly the same behavior as onetrev here with CSS optimization being the problem:

• Connection reset in all browsers tested.
• A redirect under Firefox (but not under Chrome): “https://localhost/eng/” becomes “https://www.localhost.com/eng/”
• After some 7 or 8 seconds (that feels long…), I get:

• With Firefox: Server not found — Firefox can’t find the server at https://www.localhost.com.
• With Chrome: Inaccessible Web Page (however, the url remains “https://localhost/eng/”).

The above behavior is obtained with these settings:

• Optimize HTML Code? Box checked.
• Optimize JavaScript Code? Box checked.
• Optimize CSS Code? Box checked (any other variants of css settings do not eliminate the problem).
• All other Autoptimize settings are off (unchecked).
• In last resort, I inserted in wp-config.php the “define(“AUTOPTIMIZE_LEGACY_MINIFIERS”, “true”);” but without any success.

My test is done with the following:

• WordPress 3.8
• xampp/localhost (Windows 7)
• TwentyFourteen theme.

This test is made with a child theme where the [near] empty style.css is:

/*
Theme Name:     Twenty Fourteen Blues
Theme URI:      https://example.com/twenty-fourteen-child/
Description:    Twenty Fourteen Child Theme
Author:         dharma blues
Author URI:     https://example.com
Template:       twentyfourteen
Version:        1.0.0
*/
@import url("../twentyfourteen/style.css");

/* =Theme customization starts here
-------------------------------------------------------------- */

If I do the same test but in the parent theme (no more child), the same problem persists. So, child theme is not the culprit here.

Most notably: as soon as I uncheck the “Optimize CSS Code” setting, then everything runs fine (and HTML and javascript are indeed minified).

So, legacy minifiers do not appear to help here!

Hi (me again…),

Strangely, with another localhost website which is much more heavy with lots of css and javascript files (including jQuery), Autoptimize runs fine with everything minified (including css).

Test is done with the following:

• WordPress 3.8
• xampp/localhost (Windows 7)
• themeforest Mural theme

I’m looking forward with what could be so strange with the TwentyFourteen css files…

Hmmm, would love to be able to reproduce on my XAMPP-installation. what version of XAMPP are you using (or what version of apache and php)? and just to be sure; do you have any ohter plugin installed?

Tested on my work-laptop (Win XP + a 4-year-old version of XAMPP) with WP 3.8 + TwentyFourteen + Autoptimize CSS, can’t reproduce. I’ll download a more recent version of XAMPP & see if that “helps” … ??

Thanks for looking into this matter!

Versions used on XAMPP/Windows 7:

• XAMPP 1.8.3
• Apache 2.4.7
• PHP 5.5.6
• MySQL 5.6.14

After a fresh reboot this morning and making sure that no other plugins are running, I’m still getting the same problem…

I continue my investigation because this issue challenges me and will inform you of anything that might be interesting.

OK, can reproduce on a new XAMPP installation (1.8.2), I can dive in now ??

Hi there,

just a quick message as I have the same problem, and would follow up ??
WP – 3.8
Autoptimize 1.8
W7
Apache 2.2.21
PHP 5.3.13
MySQL 5.5.16

(Works like a charm on real server ?? – Thanks!)

Hi again,

Here is what is working for me:
In yui-php-cssmin-2.4.8-2.php
Line 291, change

// Remove the spaces before the things that should not have spaces before them.
        // But, be careful not to turn "p :link {...}" into "p:link{...}"
        // Swap out any pseudo-class colons with the token, and then swap back.
        $css = preg_replace_callback('/(?:^|\})(?:(?:[^\{\:])+\:)+(?:[^\{]*\{)/', array($this, 'replace_colon'), $css);

by

// Remove the spaces before the things that should not have spaces before them.
        // But, be careful not to turn "p :link {...}" into "p:link{...}"
        // Swap out any pseudo-class colons with the token, and then swap back.
        // CRASH HERE but not on Linux...
        // $css = preg_replace_callback('/(?:^|\})(?:(?:[^\{\:])+\:)+(?:[^\{]*\{)/', array($this, 'replace_colon'), $css);
        if (strtoupper(substr(PHP_OS, 0, 3)) !== 'WIN') {
        	$css = preg_replace_callback('/(?:^|\})(?:(?:[^\{\:])+\:)+(?:[^\{]*\{)/', array($this, 'replace_colon'), $css);
        }

Well, it’s doesn’t explain why it crash (*)(on windows only?), but sounds OK as a quick (& durty? ;)) patch.
(*) Don’t see (yet?) any side effect on commenting it out.

Enjoy ??

To Franck160,

Wow! Many thanks for such discovery and insight.

It’s good news that the plugin (version 1.7.3 or 1.8) would work A1 on Linux (on a real server).

I did look at the file yui-php-cssmin-2.4.8-1.php (under Autoptimize 1.7.3) and the incriminating line (291) is exactly the same as for yui-php-cssmin-2.4.8-2.php (under beta Autoptimize 1.8). That’s more good news as that suggests the change you propose would also work in the last stable version of Autoptimize (1.7.3).

As soon as I finish my ongoing project, you can be sure I will test that change (in a few days).

Many thanks!