About: YoniExpress

Does that mean city, state, zip are working fine in your test and appear in both the emails and thank you pages or that you haven’t been able to attempt it?

Just re-ran, we have a checksum warning (because we had to mod custom-fields-inc.php – long story) and a memory warning, we’ve only got 40MB. I chased all those yesterday, it’s unrelated (see results above, custom fields are working in one email, not the other.)

Bruce – thank you for looking. Private form won’t be necessary, it’s sandboxed at PayPal. Here’s one entry from paypal-api-log, form data is submitting fine. Note how city, state, zip, etc. are all intact (I have descended to the point of just rattling the keyboard for some fields like fghfdhfghf.)

The problem is, part of the data is available to the user signup, the other parts to the new user registration email, and those also go missing from the thank you URL but in all cases, address, city, state, zip go empty (details above.)

Closest I can figure is it happens after curling payPal and getting a response.

LOG ENTRY: Thu Apr 11th, 2013 @ precisely 10:54 pm UTC
PHP v5.3.21 :: WordPress® v3.5.1 :: s2Member® v130221 :: s2Member® Pro v130221
Memory 3.46 MB :: Real Memory 4.00 MB :: Peak Memory 3.50 MB :: Real Peak Memory 4.00 MB
(obscured).com/dev/checkout
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
-------- Input vars: ( Thu Apr 11, 2013 10:54:23 pm UTC ) --------
array (
  'METHOD' => 'CreateRecurringPaymentsProfile',
  'EMAIL' => 'webdev@(obscured).com',
  'FIRSTNAME' => 'bill',
  'LASTNAME' => 'testing',
  'SUBSCRIBERNAME' => 'bill testing',
  'DESC' => '2 Boxes',
  'PROFILEREFERENCE' => '1368356063:0 D:1 M~(obscured).com~2',
  'INITAMT' => '17.00',
  'FAILEDINITAMTACTION' => 'CancelOnFailure',
  'CURRENCYCODE' => 'USD',
  'AMT' => '17.00',
  'TAXAMT' => '0.00',
  'MAXFAILEDPAYMENTS' => '2',
  'AUTOBILLOUTAMT' => 'AddToNextBilling',
  'PROFILESTARTDATE' => '2013-05-12T00:00:00Z',
  'BILLINGPERIOD' => 'Month',
  'TOTALBILLINGCYCLES' => '0',
  'BILLINGFREQUENCY' => '1',
  'CREDITCARDTYPE' => 'Visa',
  'ACCT' => '************3972',
  'EXPDATE' => '042018',
  'CVV2' => '123',
  'STREET' => 'fghfgh',
  'CITY' => 'fdhghg',
  'STATE' => 'ca',
  'COUNTRYCODE' => 'US',
  'ZIP' => '56789',
  'VERSION' => '71.0',
  'USER' => '(obscured).com',
  'PWD' => '1364319780',
  'SIGNATURE' => 'AFcWxV21C7fd0v3bYYYRCpSSRl31AmWWBw7udQZarMmEHCHu-fnNQROx',
)
-------- Output string/vars: ( Thu Apr 11, 2013 10:54:27 pm UTC ) --------
PROFILEID=I%2d014UK2AERVYG&PROFILESTATUS=PendingProfile&TRANSACTIONID=8J152958YA825620L&TIMESTAMP=2013%2d04%2d11T22%3a54%3a27Z&CORRELATIONID=4425d8921165e&ACK=Success&VERSION=71%2e0&BUILD=5650305
array (
  'PROFILEID' => 'I-014UK2AERVYG',
  'PROFILESTATUS' => 'PendingProfile',
  'TRANSACTIONID' => '8J152958YA825620L',
  'TIMESTAMP' => '2013-04-11T22:54:27Z',
  'CORRELATIONID' => '4425d8921165e',
  'ACK' => 'Success',
  'VERSION' => '71.0',
  'BUILD' => '5650305',
)

I’ve tracked it as far down as paypal-checkout-in-inc.php and found that even at that point the internal variable $post_vars **STILL contains these missing values. We’ve almost got this finished, please let us know what’s going wrong here or where to look.

Added: we’ve been walking through setting up the thank you page in the interim (see above) and these two issues might be related. With a dump of various variables, we can see that many of the values are getting nuked, and they’re all the ones missing from the signup confirmation email (example: city, state, zip, etc.) These are straight from the default paypal-checkout-form.php, unaltered. Any idea why they are posting **empty?**

The issue with that will probably solve the email issue (I hope.)

Okay so more stuff we’ve tried:

– Verified the IPN URL in payPal’s sandbox (sitename/thank-you)

Added that URL to the success parameter of the shortcodes.

– I left our var_dump in paypal-checkout-in-inc.php which verified the successful transaction.

– Created a custom thank you page at sitename/thank you.

– Emails work (sorta,) order shows up in the sandbox, user shows up in admin, all that works . . . . still outputs an no-content page at the checkout URL. Additionally, none of the custom field info is coming through in the emails, followed your documentation to the letter.

Need a little help here, what’s up?

Edit: Entry below.

LOG ENTRY: Wed Apr 10th, 2013 @ precisely 9:16 pm UTC
PHP v5.3.21 :: WordPress® v3.5.1 :: s2Member® v130221 :: s2Member® Pro v130221
Memory 6.59 MB :: Real Memory 7.00 MB :: Peak Memory 6.65 MB :: Real Peak Memory 7.00 MB
(obscured).com/dev/?s2member_paypal_notify=1
User-Agent: WordPress/3.5.1; https://(obscured)/dev
array (
  'txn_type' => 'subscr_signup',
  'subscr_id' => 'I-WDRKLCAJY2EV',
  'custom' => '(obscured).com',
  'txn_id' => 'I-WDRKLCAJY2EV',
  'period1' => '1 M',
  'period3' => '1 M',
  'mc_amount1' => '0.00',
  'mc_amount3' => '9.00',
  'mc_gross' => '0.00',
  'mc_currency' => 'USD',
  'tax' => '0.00',
  'recurring' => '9.00',
  'payer_email' => '(obscured)',
  'first_name' => 'bill',
  'last_name' => 'testing',
  'option_name1' => 'Originating Domain',
  'option_selection1' => '(obscured)',
  'option_name2' => 'Customer IP Address',
  'option_selection2' => '70.166.6.10',
  'item_name' => '1 Box',
  'item_number' => '1',
  'proxy_verified' => 'paypal',
  's2member_log' => 
  array (
    0 => 'IPN received on: Wed Apr 10, 2013 9:16:51 pm UTC',
    1 => 's2Member POST vars verified with a Proxy Key',
    2 => 's2Member originating domain ( `$_SERVER["HTTP_HOST"]` ) validated.',
    3 => 's2Member `txn_type` identified as ( `web_accept|subscr_signup` ).',
    4 => 's2Member `txn_type` identified as ( `web_accept|subscr_signup` ) w/o update vars.',
    5 => 'Signup Confirmation Email sent to: "bill testing" <(obscured)>.',
    6 => 'Storing IPN signup vars now. These are associated with a User\'s account record; for future reference.',
  ),
  'subscr_gateway' => 'paypal',
  'eotper' => NULL,
  'ccaps' => NULL,
  'level' => '1',
  'ip' => '70.166.6.10',
  'initial_term' => '1 M',
  'initial' => '0.00',
  'regular' => '9.00',
  'regular_term' => '1 M',
  's2member_paypal_proxy' => 'paypal',
  's2member_paypal_proxy_use' => 'pro-emails',
  's2member_paypal_proxy_coupon' => 
  array (
    'coupon_code' => '',
    'full_coupon_code' => '',
    'affiliate_id' => '',
  ),
  's2member_paypal_proxy_verification' => '4b2d6ea3f800c96727e93b502ea40cb7',
)

More info: the API explorer says our sandbox creds are fine:

https://www.paypal-labs.com/apiexplorer/PayPalAPIs

Do you really need to remove part of the JS? Have you tried the pro-form with the default JS and had the blank page problem then?

There are several things that are troublesome about this, the largest being that if the form and process is Javascript dependent, it’s built of straw. Yes, we had to remove it, it was bloated with things we didn’t need and interfered with the construct of the design and function. I’ll temporarily re-enable it, but it will be looking for elements that aren’t in our forms and will probably break in a different way.

I guess I’ll have to route this out myself, what would be helpful is if we got a definitive answer on the Javascript issue. If I solve it, I’ll post the solution (like I did with my other unanswered thread.)

The link is helpful, thank you, but I’ve been to nearly every page in the documentation. I’ll look closer as time allows, that piece is later in the puzzle.

I hit the logs, and there are two entries for today, but nothing showing any of the current posted data.

Another question: The client has decided different options on the pricing. Is there an easy way to apply some form of discount with different payment options without creating more levels? Example:

level 1: $9 month
Pay quarterly: (some discount OR 1 month free)
Pay bi annually: (larger discount or x months free)

From what I can see without deeper digging is we’d have to do those as multiple “levels” and we already have three levels and only see the ability to create 5 levels, wich leaves us one short. Is there an easier way to do that?

Never mind. This project is overdue and I’ve figured it out, posting solution for those who might need a similar usage.

I was looking in the wrong place (sorta,) as shortcodes are ultimately parsed by W.P. It wasn’t fun locating where to grab the shortcodes, but it’s stored like so:

$sc = $GLOBALS["scode"];

(get_defined_vars() outputs what appears to be the exact same dump, seems redundant. You probably have your reasons.)

Then using the wordpress function,

$tst = shortcode_parse_atts($sc);

A var_dump() on $tst shows all the selected level shortcodes in place. More gracefully,

$s2shortcode = shortcode_parse_atts($GLOBALS["scode"]);
echo "PRICE {$s2shortcode['ra']} FIRST MONTH {$s2shortcode['ta']}";

As mentioned, a var_dump() shows all the array keys that can be accessed.