alain2

Forum Replies Created

Viewing 13 replies - 1 through 13 (of 13 total)
  • Thread Starter alain2

    (@alain2)

    Smacksupport

    Thanks.
    1) was OK
    2) I disabled almost all plugins and then the import worked. A bit of a shock that even this functionality can break through other plugins.

    aguseo : I had the dates already formated in the iso based way (and tested also with the other formats)

    Thread Starter alain2

    (@alain2)

    Thank you very much.

    For me a very nice plugin.

    Hi

    Is it possible to make a new version fast, this bug is for me a show stopper at the moment. I disabled the cache for now…

    @auban: big thanks for finding it!

    Alain

    Thread Starter alain2

    (@alain2)

    Hi

    The Cache expire was far longer and I changed it to smaller after I noticed the problems (after the latest update).

    I’m using a event calendar snippet on the home page that has 10 events visible. I want home (not the other pages) to be updated at least daily and 3 times on saturday (more events in the weekend).

    I had the problem now also on one of my computers and I definitely got a 304 on home that was clearly days expired.

    I’ve disabled the cache now on the site.

    Is there a solution?

    Or how can I place the previous -which was working- of the plugin back?
    This version is clearly broken and should not be used.

    Thread Starter alain2

    (@alain2)

    expiry settings :

    Cache Expiry: 23 hours (but I want to increase it again to 4 days.)

    on:
    – Pre-compression of cached pages. Needs to be disabled if the decoding fails in the web browser.
    – Clear the complete cache if any plugin has been upgraded.

    I don’t know what return code the browser gets, because it’s not mine.

    cron job:
    /usr/local/bin/curl –silent https://www.website.invalid/adtestcache.php (every nigth at 5am 14 min followed by a curl off the homepage an 5am 15 minutes. off course with a real website url.

    php job:
    <html>
    <head>
    <title>PHP clear cache Test</title>
    </head>
    <body>

    <?php
    // initilize WordPress environment
    if ( !defined(‘ABSPATH’) ) {
    require_once(‘./wp-load.php’);
    }

    //if ( has_action(‘ce_clear_cache’) ) {
    // do_action(‘ce_clear_cache’);
    //}

    if ( has_action(‘ce_clear_post_cache’) ) {
    echo ‘<p>ce_clear_post_cache start</p>’;
    do_action(‘ce_clear_post_cache’, 23); // post_id home
    echo ‘<p>ce_clear_post_cache einde</p>’;
    }
    ?>

    <p>test clear cache</p>
    </body>
    </html>

    Thread Starter alain2

    (@alain2)

    What I know 100% sure :
    Every night the cache from the homepage is invalidated with a cron job that call’s the php job that’s plugin web page, off course modified for the correct page. This worked and works. reason is that there are events shown (by an event widget) on the homepage and past events should dissapear from home the next day.

    Since a little more than a week the complete cache expires after 23 hours, instead after 4 days.

    Several people complained that they got an older homepage and not the current one.

    Pushing ‘F5′ (aka ask the server if the files are still current), doesn’t solve the problem.
    CTRL-F5 (aka clear page from the local browser cache and request them again, does solve the problem.

    I suppose that it also happens after a complete “clear cache’ but I’m not sure.

    Thread Starter alain2

    (@alain2)

    Well I know that statify doesn’t aggregate on every hit. But registration of resolution and/or browser and/or OS on evry hit is a privacy problem.

    If only those are aggregated monthly from the start (in a separate table) the privacy will be far better preserved.

    An extension seems difficult because the javascript call has to be changed and also the logging part. Those seem to be rather specific for statify itself.

    Forum: Plugins
    In reply to: [Logo Slider] minify css?
    Thread Starter alain2

    (@alain2)

    nobody?

    Well if getting a 100/100 score is the goal….

    Pagespeed should be considered as suggestions.

    On a hand coded website pagespeed states that a 465 byte css response is blocking. But, it doesn’t state that it would be far better to aggregate the (only) two very small CSS files.

    BTW more than half of the webpagetest time is the DNS and https init.

    Just tested it on jquery.js itself. Going from compression 6 to 9 gave me a file reduction of 56 bytes.

    Hi

    While there’s a difference it isn’t that big ??

    A 726KB css file did:
    gzip -4 to 126KB
    gzip -6 to 116KB
    gzip -9 to 115KB.

    The current default zlib (as of 2013) and thus Apache is -6.

    Thread Starter alain2

    (@alain2)

    Thanks

    Another easy way (and maybe easier to program and test) :

    The short time caching is solved by clearing the cache for the pages in the short time caching at specific times of day. This could be solved by a cron like job.

    –> This gives more predictable results, but makes really short durations less easy to configure. for example every 15 minutes needs about 100 entries.

    Thread Starter alain2

    (@alain2)

    Thanks for the answer

    I tend to see it a bit easier:

    normal caching (default) expiration duration is a user choice
    no caching (list as is now)
    short time caching (list as in now in “no caching”), but a shorter expiration duration user choice as in normal caching.

    –> this is easier for the user and has less “edge cases” that need to be tested.

    BTW. I don’t have a gitHub account.

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