Support

February 1, 2013 at 5:04 pm

I’m reviewing the logs, and there’s a reference to WordFence

[ 2013-02-01 16:07:52 ] espresso.php

VARS : action = wordfence_testAjax

[ 2013-02-01 16:07:52 ] registration_page.php -> FILE LOADED

And then also:
[ 2013-02-01 16:07:53 ] espresso.php

VARS : action = wordfence_doScan & isFork = 0 & cronKey = 7fdaxxxxxxxxx3ff

[ 2013-02-01 16:07:53 ] registration_page.php -> FILE LOADED

Do you think the plugin could have to do with the randomly non-working payment collection?

February 6, 2013 at 12:52 pm

I just had a thought…we’re using PayPal Pro to process payments. Some people are being skipped past the payment page to the thank you page. Do you think we could put some kind of tracker on the thank you page to check which page they just came from? If it was the payment page, then proceed with the thank you message, but if it was any other page, redirect to the payment page.

February 6, 2013 at 1:56 pm

Good call – I had had the “skip confirmation” page set to Yes. I just changed it to “no”. Fingers crossed that helps somehow!

February 12, 2013 at 12:54 pm

Right – I was thinking that too. I could check my analytics program to see what browsers they’re using, but I’ve had trouble determining which visitors were which. Changing the skip confirmation page seemed to have helped a little – it’s been several days since it happened, but it just happened now. Fortunately we noticed it right away and I was able to check the logs, and I’m going to go look up the user’s browser information right now. I’ll share that shortly. Meanwhile here’s what was in the logs (for two tickets purchased at once:)

[ 2013-02-12 19:34:59 ]  espresso.php
    VARS : 
[ 2013-02-12 19:34:59 ]  registration_page.php  -> FILE LOADED
[ 2013-02-12 19:34:59 ]  cart.php  -> FILE LOADED
[ 2013-02-12 19:34:59 ]  payment_page.php  -> FILE LOADED
[ 2013-02-12 19:34:59 ]  add_attendees_to_db.php  -> FILE LOADED
[ 2013-02-12 19:34:59 ]  database_install.php  -> FILE LOADED
[ 2013-02-12 19:34:59 ]  espresso.php  -> espresso_load_pricing_functions
[ 2013-02-12 19:34:59 ]  espresso.php  -> espresso_export_certificate
[ 2013-02-12 19:34:59 ]  espresso.php  -> espresso_export_ticket
[ 2013-02-12 19:34:59 ]  espresso.php  -> ee_init_session
[ 2013-02-12 19:34:59 ]  espresso.php  -> load_event_espresso_widget
[ 2013-02-12 19:35:00 ]  espresso.php  -> espresso_load_jquery
[ 2013-02-12 19:35:00 ]  espresso.php  -> espresso_load_EEGlobals_jquery
[ 2013-02-12 19:35:00 ]  espresso.php  -> ee_check_for_export


[ 2013-02-12 19:35:09 ]  espresso.php
    VARS : post_type = page
[ 2013-02-12 19:35:09 ]  registration_page.php  -> FILE LOADED
[ 2013-02-12 19:35:09 ]  cart.php  -> FILE LOADED
[ 2013-02-12 19:35:09 ]  payment_page.php  -> FILE LOADED
[ 2013-02-12 19:35:09 ]  add_attendees_to_db.php  -> FILE LOADED
[ 2013-02-12 19:35:09 ]  database_install.php  -> FILE LOADED
[ 2013-02-12 19:35:10 ]  espresso.php  -> espresso_load_pricing_functions
[ 2013-02-12 19:35:10 ]  espresso.php  -> espresso_export_certificate
[ 2013-02-12 19:35:10 ]  espresso.php  -> espresso_export_ticket
[ 2013-02-12 19:35:10 ]  espresso.php  -> ee_init_session
[ 2013-02-12 19:35:10 ]  espresso.php  -> load_event_espresso_widget
[ 2013-02-12 19:35:10 ]  espresso.php  -> espresso_load_jquery
[ 2013-02-12 19:35:10 ]  espresso.php  -> espresso_load_EEGlobals_jquery
[ 2013-02-12 19:35:10 ]  espresso.php  -> ee_check_for_export

February 21, 2013 at 2:50 pm

Update message from my hosting company below. I’m using EE version 3.1.28.5.P. I don’t want to make any changes to the EE file versions – can you tell me what version of WordPress will work well with that version?

From the host:

The first issue is your ‘fpdf’ plugin which is causing problems with itself. The ‘fpdf.php’ file outputs some data, but the espresso.php tries to subsequently start an ob_session. This will not work, since the output of the PDF generator portion already sends headers and data, so when ob_session tries to initiate a session, the headers conflict out. In PHP, you cannot send headers after already sending data (output) to the browser. You would need to contact the developers of the ‘event-espresso’ plugin.

As for the registration portion, it is calling the ‘wpdb->prepare’ class function with an inappropriate number of arguments. The core class expects 2 arguments, and registration_page is only passing 1 argument. This is causing an error since the core class does not know how to respond to this issue (there is no instantiator or class call overload for a single-argument execution of the function).

In short, the event-espresso plugin seems to not be fully compatible with your version of wordpress. You will want to check for a newer version of that plugin or attempt to find a different plugin that does what you need it to do.

As a temporary stopgap, I have alleviated the wpdb->prepare problem with a small patch as a courtesy. I created a zero-length string to feed into the function to prevent the error from being shown. I can’t guarantee it will make the plugin work any better, and it might even make the problem worse (if that is the case let me know and I’ll revert it). This is a best-effort attempt only, as coding is far beyond our scope of support.