Forum Replies Created

Viewing 6 replies - 1 through 6 (of 6 total)
  • Thread Starter warpdag

    (@warpdag)

    No adverse effects, just a minor annoyance

    Thread Starter warpdag

    (@warpdag)

    G – Thanks for the suggestion, appreciated, but I’m not sure we’re completely on the same page. I would rather have super-cache gzip the cached file directly, hence why I usually select the “Compress pages so they’re served more quickly to visitors. (Recommended)” option. IMO, it’s better to gzip it once rather than compress it on the fly each time it’s requested, more efficient and less load on the server– at least for me.

    I noticed the bug by chance, I use my own script to prime some key pages on my site (I load them every so often, and in some cases I cache them myself via a homemade script as supercache does not handle them well), and while I was tweaking the script I noticed that the result of a simple curl command didn’t return text/html as expected, but gzip content, even if I didn’t specify gzip compression in the request. Only happens when the requested file is not cached, as once the file is cached, supercache sends a proper text/html file.

    Tats – Thanks for confirming the bug.

    Cheers,
    David

    Thread Starter warpdag

    (@warpdag)

    Looks like the bug is in the code itself, and is reproducible on all my installs (3 separate installs). Dug further, 1.1 seems to stubbornly send gzipped content no matter what *ONLY WHEN* the requested file is not cached yet. Once cached, a proper plain text file is sent for browsers that don’t support gzip, and a gzipped version is sent to the ones that do.

    If you run into this issue, my advice is to remove 1.1 and revert back to 1.0 for now (via the developer link on the plugin page). Don’t get me wrong, the plugin is great and I love it, saves me a ton of bandwidth and speeds up my site, but I think 1.1 needs some add’l debugging. Please contact me if you want more details, would love to help squash the bug once and for all.

    David

    Thread Starter warpdag

    (@warpdag)

    Note: The bug is in the new htaccess ruleset, you might not see it if you don’t update your ruleset with the new one. Trying to figuring it out right now.

    Note 2: No it’s not htaccess, my bad. For some reason the plugin spits out gzip no matter what, I can reproduce the bug on 2 separate installs, but I can’t pinpoint why yet. On a third install, it works fine, odd.

    Updated to 5.2.3, the placement of the bar is completely random. Digg Digg worked just fine before it was taken over by Buffer, but now we’ve all been beta testing each release of this thing since the acquisition, and none of them seems to be working well! Time to move on?

    Cheers mate.

    Thread Starter warpdag

    (@warpdag)

    Mike – Fair enough, and the ‘bug’ could be theme/installation-specific. Since I like FSCF, I re-enabled it, and for now I tweaked your vcita_si_contact_add_script function to disable the call for the script.

    Cheers,

    warpdag

Viewing 6 replies - 1 through 6 (of 6 total)