Forum Replies Created

Viewing 15 replies - 1 through 15 (of 65 total)
  • Thanks. I’ve read the article. It’s much easier to disable caching at all – the practical effect is exactly the same.

    This is because whether you need the cookie bar HTML which depends on a missing cookie which is checked on the server side by PHP – or you need the consent based JS code, which is only dumped into HTML when positively found a given consent by the cookie setting which is checked on the server side by PHP.

    So whatever you configure in Cache settings – you’ll cause switching off caching at all.

    The plugin does not work together with caching by design.

    You’d keep away a lot of trouble, frustration and wasted time from plugin users pointing that out in the plugin description on wp.org

    Cheers.

    After having trouble with caching as well I had a look into the code.

    Guys, are you aware that your plugin is absolutely incompatible with caching?

    It’s even dangerous to use it since given consent from visitor 1 will be applied to visitor 2 and following ones. The only needed condition for reproducing this is that user 1 is the first visitor after a cache purge.

    I cannot believe that this behaviour is undetected since the early days of the plugin. However, it should be the first sentence of your plugin description that this plugin may lead to law violations and should never be used together with static page caching!

    Cheers.

    • This reply was modified 3 months, 1 week ago by Frank.
    Thread Starter Frank

    (@t-mug)

    Why? Static files are clearly faster …

    No, Shay, the dom-parser.php contains a check for class existence already – look into it: the file contents won’t be executed if the class is present.

    The real problem arises in case the next load of any dom parsers does not contain an existence check. It’s a problem of execution order. So as I had the same problem I could solve it like this (inside flying-scripts.php):

    add_action( 'plugins_loaded', function() {
        include('init-config.php');
        include('settings/index.php');
        include('inject-js.php');
        include('html-rewrite.php');
        include('shortcuts.php');
    }, 15 );

    This way the dom parser of Flying Scripts will be loaded after all other plugins which in my case effectively could avoid the class-already-exists error.

    Thread Starter Frank

    (@t-mug)

    Caching would work anyway – it’s more about delaying the loading of JavaScript files. I don’t understand why developers are not aware of this. Some are, like the people behind the Kadence suite, but speed awareness is really rare among net programmers.

    The lack of awareness in this particular case (this plugin is about speed optimisation, of all things!) is really remarkable.

    Appending the inline part to the file works fine with all JS-delaying solutions like WP Rocket and the like.

    Thread Starter Frank

    (@t-mug)

    Deprecated message still appears. Is it fixed meanwhile in a version not submitted on wp.org and that needs to be requested here?

    Thanks for the efforts!

    @michael8888
    You’re welcome, Michael.

    @contrid
    For me it’s the same, btw: if DOI is activated then a notification should be sent out only in case the subscription has been confirmed.

    After deactivation of the regular subscription notification as described above, you’d get a notification after DOI by this:

    add_action( 'newsletters_subscriber_activate', function( $subscriber, $mailinglists ){
    	wp_mail( 'yourmail@example.com', 'Your Site's New Subscriber', 'New subscriber after double opt-in: ' . $subscriber->email );
    }, 10, 2);

    Best would be to put this into a mini plugin named like “Newsletters Extra”.

    Thread Starter Frank

    (@t-mug)

    Bug collection:

    grep -r \(isset * | grep sanitize
    wp-mailinglist.php: $page = sanitize_text_field(isset($_GET[‘page’]));
    wp-mailinglist.php: $newsletters_method = sanitize_text_field(isset($_GET[‘newsletters_method’]));
    wp-mailinglist-plugin.php: $page = sanitize_text_field(isset($_GET[‘page’]));

    grep -r \(isset * | grep esc_html
    views/admin/head.php: $page = esc_html(isset($_GET[‘page’]));
    wp-mailinglist.php: $method = esc_html(isset($_GET[‘method’]));
    wp-mailinglist-plugin.php: $method = esc_html(isset($_GET[‘method’]));

    • This reply was modified 3 years, 6 months ago by Frank.
    Thread Starter Frank

    (@t-mug)

    I have a tip for your super stressed team (as you told me) because a not so stressed guy at Tribulant has “refactored” multiple occurences of this pattern:
    $var = sanitize_text_field( $_GET['some_key'] );
    and changed them to:
    $var = sanitize_text_field( isset( $_GET['some_key'] ) );

    Could you please teach him/her that this is a bad idea? A lot of misbehaviour was introduced by this after v4.6.19 and is at least present in v4.7.1.

    Both of the issues described in this topic will be solved by changing line 887 in file wp-mailinglist.php from:
    $newsletters_method = sanitize_text_field(isset($_GET['newsletters_method']));
    back to previous:
    $newsletters_method = sanitize_text_field( $_GET['newsletters_method'] );
    because $newsletters_method can otherwise never receive something else than a boolean value and the following “switch case” makes no sense any more.

    BTW: No need to prevent errors by missing GET vars because sanitize_text_field() returns an empty string in this case.

    Cheers.

    Thread Starter Frank

    (@t-mug)

    I don’t want to be bothersome. The opposite. I am interested in a working plugin. But what you deploy on wp.org, as said, is broken.

    See how wp.org advertises your plugin:

    • “Last updated: 1 year ago”
    • “This plugin hasn’t been tested with the latest 3 major releases of WordPress.”

    Those are NOT my warnings.

    Good luck with the strategy.

    Thread Starter Frank

    (@t-mug)

    The link created by shortcode [newsletters_online] does not work anymore, maybe the same cause. Instead you’ll see the management screen if you click that link in emails which should lead you to the online version of an email.

    Also it seems that no message at all is displayed on the [newsletters_management] screen.

    • This reply was modified 3 years, 6 months ago by Frank.
    Thread Starter Frank

    (@t-mug)

    Thanks for counting in the issue.

    For me the SVN issues have obviously more priorities than for you. This is because the old version deployed via wp.org DOES NOT WORK ANYMORE! So what you deploy is a waste of time for new people trying to evaluate the plugin on one hand and on the other they will clearly never turn into your customers. Have you given up to attract more customers? What can make you so extremly busy that you push potential customers away? Not to forget: it raises even for existing customers a red flag seeing that you treat things like that.

    The best,
    Frank

    • This reply was modified 3 years, 6 months ago by Frank.
    Thread Starter Frank

    (@t-mug)

    Thanks, this was quick!

    Who’s looking for the latest version with fixing the issue should have a look here: https://tribulant.com/support/tickets.php?id=75411

    The plugin should really be deployed by wp.org, but Tribulant has SVN issues on wp.org as described above.

Viewing 15 replies - 1 through 15 (of 65 total)