aryanduntley

This does not work for me. Also, it is easy enough to add your custom fields to the a gravity forms HTML field. Still, looking for the code to do this manually. Might be useful to add a function that takes some param options so that it can be called manually from anywhere. Right now, it seems I have to instantiate MC4WP_Custom_Integration and maybe just call the process method, but I am not certain that the values will be gathered correctly since the method you explained above does not work.

I really do not have much appreciation for over ooping things. Many will argue that it is cleaner and more extendable, I say it’s extreme and you have to hunt down class files throughout excessive directory structures and so on. Makes it too time consuming to path everything out so you can study the code and make sure you are doing what you need.

Anyway, if you have the time, would you provide me with the code necessary to manually call the process method for MC4WP_Custom_Integration? I’d prefer not to chase down all the classes and methods that are chained here just to get the necessary data values; CLASS MC4WP_Custom_Integration >> method process >> CLASS MC4WP_Integration >> function mc4wp >> CLASS MC4WP_Container >> method get(param “I already have a damn headache”) And here I expect …_Container was supposed to be previously instantiated?

So, if you could, I would appreciate the quick hack code to process a mailchimp request. That way, I could simply do that at any point I wish within one of the gravity forms hooks.

If you created a simple function for this (params would be the same or similar option as in the custom integration UI in the admin along with whatever data fields that can be populated), anyone could REALLY use this plugin with any system they have in place. It would be very easy, actually, to integrate this in/with gravity forms by hooking into the “gform_after_submission” action (which has all of the data that was submitted with the form and processing mailchimp in whatever way the user set. The only other work with GF that would be needed is to add a UI in the integrations page for GF where the user can select 1) the forms they wish to use to send data to mailchip and 2)The fields within those forms they want to match to appropriate data fields that mailchimp needs.

GF completely overcomplicated their code (ridiculously so). I used to have a CSV importer plugin (still there but have not updated to work with their newer api) and when they changed their api, I took a look at their code and did not even want to bother with it. The way they structure their database and field (lead) id’s is beyond ridiculous. It works, but it sucks balls.

Anyway, your plugin can be easily adjusted to work with GF and any other platform if you would make the quick use function to perform actions in mailchimp. I’d appreciate the code for now if you can. Thanks either way.

I would suggest using their query args hook. Here is the example they provide:

function sc_redirect_args_example( $args, $charge ) {
    // Append the customer ID  to the redirect URL
    $args['cust_id'] = $charge->customer;
    return $args;
}
add_filter( 'sc_redirect_args', 'sc_redirect_args_example', 10, 2 );

=======================

So, for your specific use case, I would either use their shortcodes for creating custom form fields, or if you don’t want to send the data to stripe and only use locally, I would hook into this to create my own fields:

$html .= apply_filters( 'sc_before_payment_button', $filter_html );

So, that would look something like this:

function customStripeFields($hmel){
	$hmel .= '<input id="arbitrary_field" name="arbitrary_field" type="hidden" value="tricledsummersaltingwaterwaysdispropiddled"/>';
	return $hmel;
}
add_filter('sc_before_payment_button', 'customStripeFields', 10);

The data will now be available in the $_POST global for use with further hooks.

They have an action hook in the payment processing code:

do_action( 'sc_redirect_before' );

But if you use that, you will have to build the entire redirect yourself (which is what the extensions -pro and -subscriptions do).

So instead, you would use the query args filter and access the $_POST global, adding to the query arg list:

wp_redirect( esc_url_raw( add_query_arg( apply_filters( 'sc_redirect_args', $query_args, $charge ), apply_filters( 'sc_redirect', $redirect, $failed ) ) ) );

Which would look something like this:

function someCustomArgs($query_args, $charge){
	if(isset($_POST["arbitrary_field"])){
		$query_args["arbitrary_field"] = $_POST["arbitrary_field"];
                /*
                 Or if you do not want certain data sent visibly,
                 you can process it here and store in the db, or
                 whatever.
                */
	}
	return $query_args;
}
add_filter('sc_redirect_args', 'someCustomArgs', 10, 2);

Now that you have the variables available in the $_GET global, you can access them in your redirect page. If you do not want to send certain data visibly in the url query args, you can deal with the data within the sc_redirect_args function above and use the $_POST data directly, storing things in the db, sending emails, whatever you want. Just return the $query_args var when done.

For now, you should revert to version 7.0.22, then make your edits as needed. Once done, you can upgrade again and let it sit until the author fixes the bug or keep the older version until same.