You are not logged in.
Pages: 1
OK, I think I've got it. It is pretty much what you suggested, Tim. Here's a link to the change on github: https://github.com/MindscapeSolutions/B … c22e15cf80
The changes I made were as follows:
1. On line 1633 of /core/inc/bigtree/apis/payment-gateway.php, the code is now:
$response = BigTree::cURL($this->PostURL, $params);
2. In place of line 430 of /core/inc/bigtree/utils.php, (curl_setopt($ch, CURLOPT_POSTFIELDS, $post);) are the following lines:
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($post));
This appears to be how several examples are set up and this works. However, I believe this is just doing the same thing you are already doing. It's just using the http_build_query function to create the query string instead of manually creating it like you are to make the fields array which you then implode. If you do not use http_build_query on the $params array, you get an error from Authorize.
The next thing is that I have not figured out a way to determine if this is actually being sent as a POST request now or not. I'll keep working on it.
We just received an email from Authorize.net informing us that our paid forms are making GET requests to their API, and they will begin blocking them after July 30, 2016.
After looking at the BigTreePaymentGateway class, which calls BigTree::cURL() to send to Authorize, I'm wondering if this is the only line that needs to be added:
curl_setopt ($ch, CURLOPT_POST, 1);
This would be inserted right before:
curl_setopt($ch, CURLOPT_POSTFIELDS, $post);
Just wanted to share how we've been using BigTree as an API in a recent project.
We do work for a client whose site runs on another CMS, and we have no access to the site with the exception of a place we can drop some JavaScript. The challenge was to start collecting user data based on products they were viewing to not only store it for analysis, but to also give the user some extra pieces to interact with when they return to the site.
Here is an overview of the pieces involved:
1. We wrote some JavaScript that we place inside of Google Tag Manager, which also houses other marketing scripts we use.
2. Google Tag Manager gets injected on the third-party site.
3. In this script we work with user data via cookies, but we also make ajax calls to a BigTree site we developed that sits under our control. Let's call it api.mysite.com.
4. The script makes calls like api.mysite.com/api/v1/store-user-product and api.mysite.com/api/v1/get-user-products.
5. Our site has a routed template at api.mysite.com/api/v1/default.php.
6. Default.php looks at the commands and delegates the tasks to the appropriate modules and returns JSON to the caller.
7. The BigTree site has a site setting called Allowed Referrers that default.php consults to make sure the caller has authorization to interact with the API.
There were a few challenges, such as learning to use JSONP in the AJAX calls to work around the cross-origin requests, but it has been really working great. Our next step is to make the BigTree site more robust so that it can be our hub for all of our web service calls.
I kept having the Extension Builder bomb out on me on the last step with a bunch of "failed to open stream" errors. I traced it down to BigTree::makeDirectory().
I dumped out the paths as the function attempts to create directories for the new extension. Line 1394 begins the path with a "/". If I change this line to:
$dir_path = "";
the function works fine. So I'm assuming that the leading slash is really only for Linux systems?
I actually found a bug which is causing this to occur. Each field is given a unique id via the uniqid() php function. Sometimes the field creation process happens so fast that uniqid() does not actually create something unique. Therefore, two or more fields receive the same id which messes up the javascript.
The statement in question is in two places:
Line 61 of core/admin/auto-modules/forms/_form.php
Line 52 of core/admin/ajax/pages/get-template-form.php
It looks like this:
$field["id"] = uniqid("field_");
To fix the problem, I initiated a counter called $fCounter before the foreach loop that this statement is in, then modified the statement to the following:
$field["id"] = uniqid("field_") . $fCounter++;
So simply appending a new number to each field's id took care of the problem.
Pages: 1