Looks like you're right = )

Thanks for the catch!

is @Unset() legal? my IDE & script are borking on them, but there are
a few typos around them as well

I'm in paypal_paymentsstandard library, line 114 and a few cases further down

On Tue, Jan 31, 2012 at 1:50 PM, Calvin Froedge
reply@reply.github.com
wrote:

Looks like you're right = )

Thanks for the catch!

---

Reply to this email directly or view it on GitHub:
#3 (comment)

no good, methinks:

http://stackoverflow.com/questions/4675397/why-does-unset-give-a-parse-error

On Tue, Jan 31, 2012 at 2:02 PM, Jeff Madsen jrmadsen67@gmail.com wrote:

is @Unset()  legal? my IDE & script are borking on them, but there are
a few typos around them as well

I'm in paypal_paymentsstandard library, line 114 and a few cases further down

On Tue, Jan 31, 2012 at 1:50 PM, Calvin Froedge
reply@reply.github.com
wrote:

Looks like you're right = )

Thanks for the catch!

---

Reply to this email directly or view it on GitHub:
#3 (comment)

The implementation for paypal payments standard is not yet complete.

@Unset should just suppress errors on the unset operation - not sure why you're having issues.

ok; i pushed a few typos, but you can take or ignore.

@Unset isn't legal, I don't think - it certainly throws errors for me.

Is Paypal pro also still being worked on? It needs a much larger
$params payload in _build_oneoff_request() than what you are currently
giving it from examples/config required params

On Tue, Jan 31, 2012 at 2:29 PM, Calvin Froedge
reply@reply.github.com
wrote:

The implementation for paypal payments standard is not yet complete.

@Unset should just suppress errors on the unset operation - not sure why you're having issues.

---

Reply to this email directly or view it on GitHub:
#3 (comment)

No, paypal pro is finished. It was the first library that was implemented.

I'm pretty sure this is all that's required, even if more is being passed in the example:

      'cc_type',
      'cc_number',
      'cc_exp',
      'amt'

ok, I'll have another look. there's a function _build_request() or
similar that has a long list of $param[] s and most keys are not
passed the way I'm doing it.

it's line 207 on - don't have the file open right now

On Tue, Jan 31, 2012 at 3:22 PM, Calvin Froedge
reply@reply.github.com
wrote:

No, paypal pro is finished.  It was the first library that was implemented.

I'm pretty sure this is all that's required, even if more is being passed in the example:

         'cc_type',
         'cc_number',
         'cc_exp',
         'amt'

---

Reply to this email directly or view it on GitHub:
#3 (comment)

Ah, ok, I think I know why you're confused. All the available params get merged with the params that were actually provided. Even if it means a lot of empty keys that are just going to be dropped, it ensures all the params are there before it gets passed to the driver (and thus no need to make sure keys are set):

https://github.com/calvinfroedge/PHP-Payments/blob/master/libraries/payments.php#L256

right, except right now it is throwing a:

Notice: Undefined index: first_name....

on all the empty ones from this point on:

https://github.com/calvinfroedge/PHP-Payments/blob/master/libraries/payments/paypal_paymentspro.php#L207

now, they are only notices, so of course you can just let it slide if it is all being cleaned up later,

Ok, just cleared this issue up. Problem was that CI parsed config files slightly differently than I was - not enough of a difference to show up on some of the other stuff but enough so that the payment type config files were not being passed in right. Should be good now = )

Btw man, can we open separate issues? We can't just keep posting on this thread = ) People will laugh at us!

lol

I only just noticed 2 posts back these weren't regular gmails :-)