Designing a mod that uses an API to send info offsite

[delia]

This API requires a few things sent off - very few things such as customer first and last names, email and the product modules from the order that are in a specific category.

I started working on just a query and insertion in the checkout success page and have just had a conversation with someone who suggested a different approach which makes more sense.

So somewhere in the process - possibly as part of the order creation process - the information will be pulled from the order and stored in a new database table. I want the info sent off automatically at the end of each order that contains those products from a specific category.

So the question is - how can I do this without mangling a number of core files? The order is created in the order classes file, I believe. Is this new table insertion going to have to be done in the class file? Is there any other way to do it?

Should I tie the API send to checkout success - like in the header or should I do it earlier in case the order gets created and something goes wrong and the customer never gets to the success page (for various and sundry bizarre reasons)?

Any suggestions would be appreciated!

[torvista]

in modules/checkout_process
the code after

// store the product info to the order

will I believe give you the meat you are looking for!

[delia]

thank you sir!!!!

[delia]

Well, I've run into a problem. After getting the code working separately, I'm finally trying to integrate this into the check_out process.

it's not happy. get an error message: Call to undefined method order::createSendMURPHY()

So I'm thinking it only allows payment or order total methods in here and not an additional function like I have created.

Any other ideas?

[lhungil]

There are a handful of notifies during the checkout process... You may be able too just hook into one of these with an observer which then runs your code...

I've used these in the past with success... For example to record live shipping request/responses for completed orders (useful for testing, saving the estimate REF#, saving user selected shipping options such as insurance, etc).

This also avoids the need to edit core files in most cases.

[swguy]

Delia, if you get a message that says undefined method order::createSendMURPHY()
It means you are trying to call $this->createSendMURPHY() on an order object. Just call it as a regular method

createSendMURPHY();

[delia]

Thanks to both of you.

I see the advantage of using observers - and not editing core files but by the time y'all had responded I started a different path (one that I wasn't really wanting to visit). So three sets of code later...

If doing it either as an additional observer class or inside the checkout process, the stumbling block is how to pull the order id for my use. In checkout process it's the $insert_id. I can't seem to pull that for my use from checkout process.

I changed the line in checkout process to createSendMURPHY($insert_id);

and changed the function to: function createSendMURPHY($order_id)

But that does not pick up the $insert_id during the process. I do have the $order_id as a global.

[lhungil]

Oversimplified Example ("/includes/classes/observers/dosometingafterorder.php"). This will be triggered by checkout_process or PayPal IPN when an order is successfully added to the database:

class DoSomethingAfterOrder extends base {

	function __construct() {
		global $zco_notifier;
		$zco_notifier->attach($this, array('NOTIFY_CHECKOUT_PROCESS_AFTER_ORDER_CREATE_ADD_PRODUCTS'));
	}

	function update(&$class, $eventID, $paramsArray = array()) {
		global $db;
		$order_id = $_SESSION['order_number_created']; // May also be available in $GLOBALS['insert_id'];

		// Do something with the order id and / or database
	}
}

And the simplified autoloader file ("/includes/auto_loaders/config.dosometingafterorder.php":

$autoLoadConfig[10][] = array('autoType'=>'class',
  'loadFile'=>'observers/dosometingafterorder.php' // File where the class is located
);

// 80 is where the shopping cart is established for the session
// 110 is where the language components are established for the session
$autoLoadConfig[115][] = array('autoType'=>'classInstantiate',
  'className'=>'do_something_after_order', // Variable name accessible by in other files
  'objectName'=>'DoSomethingAfterOrder' // Name of the class
);

[delia]

Yeah, I was looking at the products viewed observer class. Looks simple - deceptively so!

[lhungil]

...

// 80 is where the shopping cart is established for the session
// 110 is where the language components are established for the session
$autoLoadConfig[115][] = array('autoType'=>'classInstantiate',
  'className'=>'do_something_after_order', // Variable name accessible by in other files
  'objectName'=>'DoSomethingAfterOrder' // Name of the class
);

Should be:

// 80 is where the shopping cart is established for the session
// 110 is where the language components are established for the session
$autoLoadConfig[115][] = array('autoType'=>'classInstantiate',
  'className'=>'DoSomethingAfterOrder', // Name of the class
  'objectName'=>'do_something_after_order' // Variable name accessible by in other files
);

What I would not give for extended editing period when on a mobile phone (the scripts active when typing in this box seem to cause my mobile browser to crawl).