Forum Replies Created

Viewing 15 replies - 1 through 15 (of 81 total)
  • Thread Starter Roy Orbitson

    (@lev0)

    Seriously, what the heck are you doing?

    Surfer_GSC_Drop_Monitor::init() makes sure that at 8am every Monday it runs Surfer_GSC_Drop_Monitor::gather_position_monitor_data(). This would be fine, but every time that function runs it dumps all its output, which nobody is requesting during a cron job, and it does call wp_die().

    You don’t call wp_die() in the middle of the site’s cron run!

    Thread Starter Roy Orbitson

    (@lev0)

    Still occurring.

    🦗🦗🦗

    Thread Starter Roy Orbitson

    (@lev0)

    it’s not fully relevant for email providers like SendLayer, Mailgun, etc

    But it is for other SMTP relays, and restricting by IP is a great additional measure as it prevents processing authentication when the origin is disallowed.

    only the provider’s IP address (i.e., the SMTP server’s IP) typically matters in terms of email delivery reputation, SPF/DKIM/DMARC compliance, and spam filtering.

    I have seen mail sent via a relay, which doesn’t scrub Received: headers, be rejected because it contained IPs that weren’t in SPF, though the relay’s IP was. Adding the origin IP to SPF only works if it can reliably send from the correct IP.

    Most users use external SMTP providers (e.g., Gmail, SendLayer, SendGrid), and these providers don’t care which IP your server uses to initiate the connection.

    Gmail, when used with Google Workspace, has a specific config area that allows restrictions based on IPs, so it most definitely does care. Putting those restrictions on websites that need to send mail shouldn’t be the only measure, but is just good security. It is also explicitly recommended in Google’s help articles that these restrictions be placed on devices that are unable to use OAuth. They wouldn’t make such recommendations if they didn’t care.

    PHPMailer acts as a client connecting to the SMTP server — the actual email is sent out from the provider’s trusted infrastructure, not your server.

    As I wrote above, some relays preserve the origin, so it must be correct. It’s more relevant to relays restricting incoming mail, and for that it can be critical.

    I understand that SendLayer authors this plugin primarily to promote its own service, but it also presents the pluigin as being general purpose, and not being able to bind to an IP can make it a poor choice for that.

    This plugin does not change how email is delivered. It uses the same core function of WordPress that everything else does. If you didn’t receive any email, you had something configured incorrectly.

    Thread Starter Roy Orbitson

    (@lev0)

    Don’t mark this as resolved if you have no intention of doing so. Users deserve to know what they’re getting. The code on SVN still uses raw $_POST everywhere, and sanitize_text_field() on fields that have nothing to do with HTML.

    Thread Starter Roy Orbitson

    (@lev0)

    I applaud your prompt response, but it’s still using sanitize_text_field() in several places it shouldn’t be, and using $_POST, directly, which should not be done in WordPress without stripping slashes.

    Plugin Author Roy Orbitson

    (@lev0)

    Hire someone. It’s explained in this blog post, the form could have a checkbox set like this:

    [checkbox* interests use_label_element "a|Subject A" "b|Subject B" "c|Subject C"]

    Then something like this as the body of your custom plugin:

    add_action(
        'wpcf7_before_send_mail',
        function($contact_form, &$abort, $submission) {
            $interests = (array) $submission->get_posted_data('interests');
            if (in_array('a', $interests))
                $submission->add_extra_attachments('path/to/info-a.pdf');
            ...
        },
        10,
        3,
    );
    Plugin Author Roy Orbitson

    (@lev0)

    Hi,

    This plugin only creates the additional form parts for extra emails by duplicating what the original plugin uses in email (2). Since that does not have such conditional sending, nor do the extra ones. It’s not something I plan on building into this.

    However, there is a filter called wpcf7_additional_mail in submission.php that can be used to inspect the current form submission and conditionally remove messages from that array.

    The problem you’re describing isn’t necessarily a multiple emails issue. Wouldn’t it make more sense to send one email, but change its content and the set of attached files? That is also possible by using the filter/action hooks in CF7 and using add_extra_attachments().

    Regards.

    Plugin Author Roy Orbitson

    (@lev0)

    Have a read of Google’s consent docs. You could achieve this client-side (in the browser) by entering something like the following in the Preliminary JavaScript setting of this plugin:

    gtag('consent', 'default', {
      'ad_storage': 'denied',
      'analytics_storage': 'denied'
    });

    Then have your consent management code (pop-up, etc.) change that default if allowed with JS like this:

    gtag('consent', 'update', {
      'analytics_storage': 'granted'
    });

    Alternatively, your own code (in plugins/themes) can use hook into this plugin’s tiny_gtag_js_analytics_output filter to modify the pre_extra value in options array. By default, this holds that same Preliminary JavaScript setting as above, which you could modify or replace based on the visitors’ consent responses.

    It’s not feasible for me to have comprehensive privacy defaults for different jurisdictions around the world, or to integrate with the countless consent management tools available. I’ve made this plugin extensible so site owners can easily use the standard API that Google’s gtag.js provides.

    Thread Starter Roy Orbitson

    (@lev0)

    Oh, sorry about that. I added admin_url('upload.php') for the form action in my patched version and it works again. I used printf with esc_attr__() and esc_html__(), as it’s not advisable to pass raw HTML for translation.

    Thread Starter Roy Orbitson

    (@lev0)

    Thanks but you missed a bunch of the fixes in that patch: moving the permission check to after page check (permissions are irrelevant if you’re on the wrong page, and they’re slower to check); you lost the href="#" on the close/cancel buttons that avoid a full page reload; and you still have the @media CSS that’s no longer needed because the popup markup is now outside the footer.

    Any reason you excluded the other improvements? Did you have problems with the patch as it was?

    Thread Starter Roy Orbitson

    (@lev0)

    Looks like this forum breaks data: URIs, but you can just add the scheme back to that link’s href to fix it.

    Thread Starter Roy Orbitson

    (@lev0)

    I was completely wrong about the cause. The runtime correctly detects public path, but then Elementor overrides the with its own config. The config property can be corrected by attaching to the elementor/frontend/assets_url filter in PHP, but it’s up to the site owner to add plugin code to do this, so the default behaviour of Elementor is still broken. It does not supply a similar filter for its post.featuredImage property, so one has to add a (temporary) filter to post_thumbnail_url.

    Thread Starter Roy Orbitson

    (@lev0)

    Plugin Author Roy Orbitson

    (@lev0)

    Not a bad idea, I have seen other plugins do this. However, this is trivial to do yourself: create a plugin with only the following code, or add it to your theme’s functions file.

    add_filter('tiny_gtag_js_analytics_output', function($options) {
        if (is_user_logged_in()) {
            $options['enabled'] = false;
        }
        return $options;
    });
Viewing 15 replies - 1 through 15 (of 81 total)