Pro Form Returns Empty Page on Submit

This is one of Mr. Flynn’s developers.

payPal pro forms, linux server, everything is fine up until we attempt to submit.

Like the topic says, we’ve worked on this for weeks trying to get it to work into the design constraints and went to test it today . . . . nada. On submit returns to the checkout page, with no content, nothing.

We have a payPal sandbox account configured, there are no errors, server or otherwise, and everything else appears to work normally.

We had to remove the javascript inclusion on the checkout page (very long and painful story,) is it related to this in any way?

I can provide code and links, but would prefer to do so in a private venue as this site is not ready to launch (but is overdue.)

We have only made two hacks to the plugin in custom fields.inc. and paypal-form-in-inc (another long story,) but reverted them for this test. Nada.

Please advise and let us know what we need to provide to resolve and debug this, I am a developer of 16 years and can handle any techno-talk.

I am sorry to say the support documentation is **extremely** difficult to find what we need to answer basic questions. There is a lot of **content**, but any searches on your site pull in irrelevant documents from external sites, most of it garbage with one or two keywords in it.

I can provide code and links, but would prefer to do so in a private venue as this site is not ready to launch (but is overdue.)

You can use the contact form. Let me know here when you sent it, so I look for it. s2Member® » Private Contact Form

We had to remove the javascript inclusion on the checkout page (very long and painful story,) is it related to this in any way?

You mean s2Member’s JavaScript? That’d be a problem, the pro-form needs it to function.

On submit returns to the checkout page, with no content, nothing.

You mean you get a blank page? What response do you get from the server? I ask because another site owner is currently getting 414s due to his server having a low limit for the URI length, causing him to get a blank page after checkout.

---

By the way, make sure you have logging enabled during your testing, so we can see in the logs what the entries say. They’re very helpful to diagnose what’s causing some problems. [hilite path]Dashboard -› s2Member® -› Log Files (Debug) -› Logging Configuration[/hilite]

And also try this, please: Knowledge Base » s2Member® Server Scanner

Thank you – you mean the JS is required to **submit** the form? All of the (other) functions are irrelevant to our environment.

Yes, it returns to the checkout page itself, with nothing in the_content() (basically a blank page.) It’s not a PHP error blank page, the template renders fine, just nothing in it.

I will send the relevant links and test CC numbers (sandbox) in the next ten minutes.

Edit: Will check logging and I sent the contact info. There was nowhere to send the test CC info, use
bill-moretests@eboostconsulting.com
Testing123
card # 4358145975103972
Exp 4/2018 and any CVV (123)

This is a sandbox account, so these numbers require no security. You will see the wp-admin link in the email, the dev site is at dev (then “get started”)

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?

Any assistance on this issue? Today is their launch day.

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?

You can sell the same level in different ways, you don’t need a different level for each payment plan. Don’t use more than one pro-form in the same page, but you can have a separate page for each pro-form like we did for our licenses here, or adjust the same pro-form with variables. Knowledge Base » Using Variables In A Shortcode

Thank you – you mean the JS is required to **submit** the form? All of the (other) functions are irrelevant to our environment.

I’m sorry, I’m not familiar with removing the JS for the pro-forms, actually I don’t know much JavaScript at all. I just know that when another plugin messes up the JavaScript, the pro-form will most likely stop working correctly, and that when someone asked about not including s2Member’s JS file Jason said it’s required. So if you’ll hack it to remove JS, I’m afraid I can’t help much there, it’ll be up to you to make it work if it can be done.

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?

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.

OK, so perhaps you can let us know this:

I’ve found the include where the form posts data. An example, I intentionally used my wordpress admin login and of course it won’t let me sign up with that as a login. A var dump clearly shows the error in an array (to the effect of “you’re an administrator . . . “)

The %%response%% placeholder is intact and in our form, which is where I presume (so far) that this is where that error should output. It’s not doing that . . . just the template page with no content.

So when an error is returned, what is supposed to happen? Where would it output? There’s no placeholder for it in the original form.

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

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

Okay, so I’ve got this “working” in that it submits the form, connects with the API, returns a response (which I can only see with a var dump,) but **does not output to the browser. MADDENING!

We’ve determined

– s2Member is indeed submitting to the framework without Javascript. I am able to dump variable/object content at various points.

– I discovered (and it should have been obvious) that different classes are called based on what’s entered into the paypal configuration.

– In any case, the root of the problem remains: s2Member is not returning anything back to browser checkout page.

I placed a var_dump in paypal-checkout-in.inc.php and get

array(1) {
  ["response"]=>
  string(109) "<strong>Thank you.</strong> Your account has been approved.<br />&mdash; You'll receive an email momentarily."
}

Which is a big breakthrough as far as I’m concerned. Why won’t it output to the %%$#% page?

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',
)

we had to remove it, it was bloated with things we didn’t need and interfered with the construct of the design and function.

JavaScript is required for a Pro Form to function as intended, because that’s the way it was built.

if the form and process is Javascript dependent, it’s built of straw.

Pro-forms use an [hilite code]input type="submit"[/hilite] button, so it can be submitted without our JavaScript file. However, the display of certain fields (based on user interaction with the Pro Form) and the overall look and feel of a default pro-form are dependent upon the JS file. If you remove the JS file without duplicating and/or supplementing the default behavior, there will be problems.

array(1) {
  ["response"]=>
  string(109) "<strong>Thank you.</strong> Your account has been approved.<br />&mdash; You'll receive an email momentarily."
}

If it’s there in the var_dump, I don’t know why it’s not being displayed. What I’d do is start with a clean installation, verify it’s working correctly, and then add one tweak at a time, testing after each to notice what breaks it.

And I’d also test with live, 1 cent transactions rather than the Sandbox. I’ve seen the Sandbox give its own set of problems that don’t happen with live transactions, so it just adds more unnecessary work and trouble sometimes.

By the way, have you tried using the success attribute to instead show the person another page after checkout? It may help avoid the no-content problem. [hilite path]Dashboard -› s2Member® -› PayPal® Pro Forms -› Custom Return URLs Upon Success[/hilite]

Thank you for getting back to us.

JavaScript is required for a Pro Form to function as intended, because that’s the way it was built.

2Member is indeed submitting to the framework without Javascript. I am able to dump variable/object content at various points.

And I’d also test with live, 1 cent transactions rather than the Sandbox.

We have that all working, and will go live after we work other stuff out.

Emails work (sorta,) order shows up in the sandbox, user shows up in admin, all that works . . . .

We made a breakthrough yesterday on our own and have sorted out the display issue. We now have a much easier (hopefully) problem to solve, which I’ll open in another thread.

That’s great! Thanks for the update. I’m glad you could sort it out. :)