Forum Replies Created

Viewing 10 replies - 1 through 10 (of 10 total)
  • Thread Starter Lucas Balzer

    (@lbalzer)

    Whatever rule was causing the issue has been removed in a recent update. Thank you for an awesome plugin! You can close this ticket.

    Thanks for your quick reply. I’m sorry — that post was a lot of info to include and it was kind of meandering.

    Here’s a more concise explanation: jquery.js IS in the exclusion list, but it has been modified from the default AO string. “js/jquery/jquery” -> “jquery.js”

    I have been able to replicate the following test cases on several sites:

    Test 1
    Excluding WP native jquery from the bundle simply by using the string “jquery.js” without any path info. (I double-checked using Chrome Dev Tools while logged out that the jquery that gets loaded is in fact /wp-includes/js/jquery/jquery.js?ver=1.12.4-wp).

    Upgrade to AO2.8, js/jquery/jquery.min.js is NOT added.

    Test 2
    Change the exact same exclusion list to reference jquery using the string “js/jquery/jquery.js” WITH path info.

    Upgrade to AO2.8, js/jquery/jquery.min.js IS added.

    Is there a specific order of operations to force AO2.8 to modify the excluded scripts string to include jquery.min.js? I’ve tried upgrading to 2.8 both before and after upgrading to WP5.6 and in neither case was jquery.min.js appended to my list of excluded scripts.

    * I tried a custom list of scripts which did not have jquery.min.js appended:

    s_sid,smowtion_size,sc_project,WAU_,wau_add,comment-form-quicktags,edToolbar,ch_client,seal.js,jquery.js,reviews.widget,scheduler.widget, wp-content/plugins/revslider/, wp-content/plugins/gravityforms/

    * The following excluded string DID get jquery.min.js added to the end:

    wp-includes/js/dist/, wp-includes/js/tinymce/, js/jquery/jquery.js, wp-content/plugins/revslider/, wp-content/plugins/modal-window/, wp-content/plugins/gravityforms/, wp-content/plugins/UABB/

    * I thought maybe your append search was looking for the inclusion of “js/jquery/jquery.js” and it appears that was a correct assumption. I modified the first completely non-default string to include the old-style WP path to jquery:

    s_sid,smowtion_size,sc_project,WAU_,wau_add,comment-form-quicktags,edToolbar,ch_client,seal.js, js/jquery/jquery.js, reviews.widget,scheduler.widget, wp-content/plugins/gravityforms/, datepicker.min.js

    which was updated to:

    s_sid,smowtion_size,sc_project,WAU_,wau_add,comment-form-quicktags,edToolbar,ch_client,seal.js, js/jquery/jquery.js, reviews.widget,scheduler.widget, wp-content/plugins/gravityforms/, datepicker.min.js, js/jquery/jquery.min.js

    If the conclusion I’ve come to is in fact accurate, I STRONGLY suggest simply setting the minimum requirement of the script exclusion string containing the regex

    /,.*?jquery\.js.*?,/

    have appended “js/jquery/jquery.min.js”, or perhaps more generically “jquery.min.js”

    or maybe you could use a regex of

    /,(.*?)jquery\.js(.*?),/

    replaced with

    “,$1jquery.min.js$2,”

    I think it’s of greater service to the plugin users to be overly-proactive about excluding jquery.min.js with the WP5.6 upgrade. As-is, the addition of jquery.min.js to the exclusion only addresses the WP-specific jquery, but if any site which has modified the _way_ jquery is excluded, the worst-case scenario of the site breaking will happen. Being more fast-and-loose about appending jquery.min.js to the exclusion string has the worst-case scenario of a single JS file being excluded from the autoptimize bundle.

    I’m going to post this reply to the handful of other topics related to the WP5.6 upgrade so that it’s as visible and discoverable as possible to others looking into this.

    Is there a specific order of operations to force AO2.8 to modify the excluded scripts string to include jquery.min.js? I’ve tried upgrading to 2.8 both before and after upgrading to WP5.6 and in neither case was jquery.min.js appended to my list of excluded scripts.

    * I tried a custom list of scripts which did not have jquery.min.js appended:

    s_sid,smowtion_size,sc_project,WAU_,wau_add,comment-form-quicktags,edToolbar,ch_client,seal.js,jquery.js,reviews.widget,scheduler.widget, wp-content/plugins/revslider/, wp-content/plugins/gravityforms/

    * The following excluded string DID get jquery.min.js added to the end:

    wp-includes/js/dist/, wp-includes/js/tinymce/, js/jquery/jquery.js, wp-content/plugins/revslider/, wp-content/plugins/modal-window/, wp-content/plugins/gravityforms/, wp-content/plugins/UABB/

    * I thought maybe your append search was looking for the inclusion of “js/jquery/jquery.js” and it appears that was a correct assumption. I modified the first completely non-default string to include the old-style WP path to jquery:

    s_sid,smowtion_size,sc_project,WAU_,wau_add,comment-form-quicktags,edToolbar,ch_client,seal.js, js/jquery/jquery.js, reviews.widget,scheduler.widget, wp-content/plugins/gravityforms/, datepicker.min.js

    which was updated to:

    s_sid,smowtion_size,sc_project,WAU_,wau_add,comment-form-quicktags,edToolbar,ch_client,seal.js, js/jquery/jquery.js, reviews.widget,scheduler.widget, wp-content/plugins/gravityforms/, datepicker.min.js, js/jquery/jquery.min.js

    If the conclusion I’ve come to is in fact accurate, I STRONGLY suggest simply setting the minimum requirement of the script exclusion string containing the regex

    /,.*?jquery\.js.*?,/

    have appended “js/jquery/jquery.min.js”, or perhaps more generically “jquery.min.js”

    or maybe you could use a regex of

    /,(.*?)jquery\.js(.*?),/

    replaced with

    “,$1jquery.min.js$2,”

    I think it’s of greater service to the plugin users to be overly-proactive about excluding jquery.min.js with the WP5.6 upgrade. As-is, the addition of jquery.min.js to the exclusion only addresses the WP-specific jquery, but if any site which has modified the _way_ jquery is excluded, the worst-case scenario of the site breaking will happen. Being more fast-and-loose about appending jquery.min.js to the exclusion string has the worst-case scenario of a single JS file being excluded from the autoptimize bundle.

    I’m going to post this reply to the handful of other topics related to the WP5.6 upgrade so that it’s as visible and discoverable as possible to others looking into this.

    I’m using the included “Material” Design Style and had to update the CSS as follows

    .forminator-field {
      display: grid;
    }
    
    label.forminator-label {
      order: 1;
    }
    
    span.forminator-description {
      order: 2;
      margin: 0 0 5px 0;
    }
    
    .forminator-field > div {
      order: 3;
    }
    
    .forminator-error-message {
        order:4;
    }
    • This reply was modified 4 years, 5 months ago by Lucas Balzer.
    Thread Starter Lucas Balzer

    (@lbalzer)

    Can you point me to the relevant code? What function call will trigger a cache purge?

    Thread Starter Lucas Balzer

    (@lbalzer)

    Thank you for that.

    Can you provide the code to use in my PHP to purge the cache? I don’t want to use the wp-admin interface.

    Plus 10 for this! I agree that the validation step restricting to a zapier URL is overly restrictive.

    WPMUDEV team, rather than just complaining about the situation, I’m also happy to offer a solution to drop into your next release: If you’re concerned about the general public inputting an invalid Zapier URL, you can add a simple filter to allow us to bypass the zapier prefix test:

    $forminator_addon_zapier_do_prefix_test = apply_filters( 'forminator_addon_zapier_do_prefix_test', 'true') === 'true'? true: false;
    if ( stripos( $submitted_data['webhook_url'], 'https://hooks.zapier.com/' ) !== 0 &&  $forminator_addon_zapier_do_prefix_test) {
    	$current_input_exception->add_input_exception( __( 'Please put a valid Webhook URL.', Forminator::DOMAIN ), 'webhook_url' );
    	throw $current_input_exception;
    }

    with the bypass flag set like this:

    add_filter('forminator_addon_zapier_do_prefix_test',function($do_prefix_test) {return "false";});

    @elbomnetanel Thank you for tracking down the file/line and providing the code change you made! If the above solution never makes it into the codebase, you can submit forms to Integromat (or any other endpoint) by modifying this code to fit your setup:

    function sc_sa_forminator_webhook($entry, $form_id, $field_data_array) {
    	
    	if (!$entry->is_spam && 1560 == $form_id) {
    		$post_data = (object)NULL;
    		foreach ($field_data_array as $o) {
    			$the_name = $o['name'];
    			$post_data->$the_name = $o['value'];
    		}
    		
    		// Generated by curl-to-PHP: https://incarnate.github.io/curl-to-php/
    		$ch = curl_init();
    
    		curl_setopt($ch, CURLOPT_URL, 'https://hook.integromat.com/xxxxxxxxx');
    		curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    		curl_setopt($ch, CURLOPT_POST, 1);
    		curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($post_data));
    
    		$headers = array();
    		$headers[] = 'Content-Type: application/json';
    		curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);
    
    		$result = curl_exec($ch);
    		if (curl_errno($ch)) {
    			echo 'Error:' . curl_error($ch);
    		}
    		curl_close($ch);
    	}
    
    }
    
    // fires just before saving the entries after passing all the checkings
    add_action( 'forminator_custom_form_submit_before_set_fields', 'sc_sa_forminator_webhook', 10 , 3 );

    and here’s what shows up in Integromat: https://i.imgur.com/PDdBNP6.png

    I agree! The concerns caused by the API key in clear text on the settings page pale in comparison to the key STORED as plain text in the DB — far more attack vectors on the DB than on the clear text of a single options screen.

    I understand there are issues surrounding encrypting data in the WP DB, (https://www.ads-software.com/support/topic/encrypt-smtp-login-information/) but since the CloudFlare API key is only necessary when actively making changes to the CF account in question, many of the concerns outlined in the referenced article are moot. Specifically, the API key could be encrypted with a user-known passphrase and decrypted (either 1 time or for the session) by requesting the passphrase whenever an API call needs to be made. Additionally, if this were a session-long decryption, it’s reasonable that the decrypted API key could be stored in cookies. (Yes, less secure. But again, the attack surface of a user’s computer is MUCH smaller than the WP DB.)

    • This reply was modified 8 years, 4 months ago by Lucas Balzer. Reason: Wanted to offer a solution. At first I just +1ed the feature request

    Plus one for this issue. Just downloaded the current version archive, and sreg.class.php is missing from the /lib directory. Can you please add back in, or let us know name of the file that includes the sreg class?

    Thanks. Really looking forward to this plugin. It’s exactly what I need!

    Lucas

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