Support

Home Forums Event Espresso Premium Incomplete Registration Report Downloads

Incomplete Registration Report Downloads

Posted: October 10, 2019 at 4:12 pm


Praxis

October 10, 2019 at 4:12 pm

Hi there,
Since upgrading to EE 4.10.1.p we are unable to download complete CSV reports of event registrations, filtered or unfiltered. Sometimes it downloads as expected and redirects back to the admin page as expected, but the full list of registrations is not in the CSV. The actual number of registrants in the event we are trying to download doesn’t seem to matter, whether it’s 17 or 215.

Other times it seems like it’s downloading but then it drops you on a 404 page (example 404 url: /wp-content/uploads/espresso/batch_temp_folder/##########/event-espresso-registrations-2019-10-10%2015-08-26.csv)

Any guesses about what might be going on? This is happening on my dev and test environs too, and i’ve tried turning off all non-EE plugins. It didn’t make a difference.

We’re on WP 5.2.3.
thanks!


Tony

  • Support Staff

October 11, 2019 at 4:25 am

Hi there,

Sometimes it downloads as expected and redirects back to the admin page as expected, but the full list of registrations is not in the CSV.

So when the CSV downloads, is there a pattern to the missing registrations?

Other times it seems like it’s downloading but then it drops you on a 404 page (example 404 url: /wp-content/uploads/espresso/batch_temp_folder/##########/event-espresso-registrations-2019-10-10%2015-08-26.csv)

If you open up Chrome dev tools (or similar) and view the console section when downloading the CSV, does it show any JS errors?

It’s possible the request is triggering a mod_sec rule on the server which is then being directed to a 404. It’s not common but we have seen it before.

Any errors in the error_log when you trigger a CSV download?


Praxis

October 11, 2019 at 7:04 pm

You get a different number of registrations in the CSV every time you download the same event, but it appears to be missing the registrations that happened in the middle time period, in groups of 50.

Here’s one example in detail: Out of 83 approved registrations, the CSV includes only 33. It includes the most recent registrant (from today) then skips 50 people and includes the first 32 people who registered.

Another event which has 218 approved registrations: The most recent 51 registrations followed by the first 17 registrations (missing 150).

I just exported the same event again, and this time only 50 rows are missing.

When it is writing the CSV file, you see this text printing:

The file will download automatically when done, and then you will be redirected.<br>
Registrations report started successfully...<br>
Wrote 50 rows to report CSV file...<br>
Wrote 50 rows to report CSV file...<br>
Wrote 50 rows to report CSV file...<br>
Wrote 50 rows to report CSV file...<br>
Wrote 17 rows to report CSV file...

But it looks like some of those 50 rows chunks aren’t getting written.

The only error that appears in the chrome dev console which seems relevant (whether or not a CSV file is written) is this:

batch_file_runner_init.js?ver=4.10.1.p:65 Resource interpreted as Document but transferred with MIME type text/csv: "../wp-content/uploads/espresso/batch_temp_folder/../event-espresso-registrations-2019-10-11%2017-32-33.csv".

No PHP errors are appearing.


Tony

  • Support Staff

October 14, 2019 at 4:46 am

Yeah, so it sounds like some of the batch requests are being dropped.

Do you have any customizations hooking into the CSV process? If so, try disabling those and see if you have the same issue.

Something else you can test is to set this in your wp-config.php file:

define('EE_USE_OLD_CSV_REPORT_CLASS', true);

Run another export and confirm if all registrations are included.

The only error that appears in the chrome dev console which seems relevant (whether or not a CSV file is written) is this:

Meaning there are other errors or that is the only error thrown?

If there are JS error being thrown during the batch process it can prevent it from working, although I’m guessing not based batch text you added above.

The above isn’t a problem, thats from the download itself rather than the batch processes (which appear to be the problem here).


Praxis

October 15, 2019 at 6:35 pm

Thanks for the suggestions, Tony. They seemed to help fix the bug on my Dev environment, but my Test and Live environments are still buggy. I have copied up the database and files, and copied down the code, so you would think they are all the same.

We have been experiencing another bug which might be related(?) —
When a user logs in or creates an account during the checkout process, the Step 2 or “Attendee Information” fields do not load
eg: https://imgur.com/a/1KYwaOp

If you reload the page, the “return to Event Cart” button appears, and nothing else. However, if I go into the dashboard from another window and flush the site cache, then refresh the checkout page, all of the Attendee Information fields load.

This bug also happens on Test and Live but not on Dev, FWIW.


Praxis

October 15, 2019 at 6:42 pm

BTW, this bug also seems to have appeared right after I updated to event espresso core update v4.10.1.p two weeks ago.


Tony

  • Support Staff

October 16, 2019 at 3:44 am

Thanks for the suggestions, Tony. They seemed to help fix the bug on my Dev environment, but my Test and Live environments are still buggy.

So using define('EE_USE_OLD_CSV_REPORT_CLASS', true); you still get missing registrations?

That constant tells Event Espresso NOT to use the batch process so if you still have missing registrations the batch write process isn’t the cause.

Note that with that constant set on a site you should NOT see anything like this: https://monosnap.com/file/WInYnS7r6Nchqab6gE7D58VPWqZyPW

The download should just start in the browser.

I have copied up the database and files, and copied down the code, so you would think they are all the same.

Do you have any customizations hooking into the CSV process?

However, if I go into the dashboard from another window and flush the site cache

Which cache? You can’t cache any of the EE critical pages so if they are cached you’ll need to exclude them, you can follow this guide:

https://eventespresso.com/wiki/setup-nocache-exclusion-rules-event-espresso/

This bug also happens on Test and Live but not on Dev, FWIW.

Are Live and Test on the same server whilst Dev is local/another server?

BTW, this bug also seems to have appeared right after I updated to event espresso core update v4.10.1.p two weeks ago.

Are you 100% sure that’s the case? Any other updates done at the same time?

I can’t see anything in the 4.10.1 changes that would link to any of these issues.


Praxis

October 16, 2019 at 10:05 pm

ok, so I got

define('EE_USE_OLD_CSV_REPORT_CLASS', true);

working and it seemed to fix my checkout problem.

Then I commented it out, turned debugging for my Test environment on and commented out the add-wp-username-to-csv customization i made hooking into the CSV process. Now I’m getting this error during the batch process:

The file will download automatically when done, and then you will be redirected.
Registrations report started successfully...
Wrote 50 rows to report CSV file...
Wrote 50 rows to report CSV file...

An exception of type EE_Error occurred while running BatchRunner::continue_job(). Its message was The requested event-espresso-registrations-2019-10-16 20-57-30.csv file could not be found or is not readable, possibly due to an incorrect filepath, or incorrect file permissions.

Please ensure the following path is correct: "/srv/bindings/../code/wp-content/uploads/espresso/batch_temp_folder/H6vtUQ3SgjktEyb/event-espresso-registrations-2019-10-16 20-57-30.csv".||The requested event-espresso-registrations-2019-10-16 20-57-30.csv file could not be found or is not readable, possibly due to an incorrect filepath, or incorrect file permissions.
Please ensure the following path is correct: "/srv/bindings/../code/wp-content/uploads/espresso/batch_temp_folder/H6vtUQ3SgjktEyb/event-espresso-registrations-2019-10-16 20-57-30.csv".

and had trace

#0 /srv/bindings/../code/wp-content/plugins/event-espresso-core-reg/core/helpers/EEH_File.helper.php(345): EEH_File::verify_filepath_and_permissions('/srv/bindings/2...', 'event-espresso-...', 'csv') 
#1 /srv/bindings/../code/wp-content/plugins/event-espresso-core-reg/core/helpers/EEH_Export.helper.php(78): EEH_File::get_file_contents('/srv/bindings/2...') 
#2 /srv/bindings/../code/wp-content/plugins/event-espresso-core-reg/core/libraries/batch/JobHandlers/RegistrationsReport.php(204): EEH_Export::write_data_array_to_csv('/srv/bindings/2...', Array, false) 
#3 /srv/bindings/../code/wp-content/plugins/event-espresso-core-reg/core/libraries/batch/BatchRequestProcessor.php(119): EventEspressoBatchRequest\JobHandlers\RegistrationsReport->continue_job(Object(EventEspressoBatchRequest\Helpers\JobParameters), 50) 
#4 /srv/bindings/../code/wp-content/plugins/event-espresso-core-reg/modules/batch/EED_Batch.module.php(295): EventEspressoBatchRequest\BatchRequestProcessor->continue_job('H6vtUQ3SgjktEyb') 
#5 /srv/bindings/../code/wp-includes/class-wp-hook.php(286): EED_Batch->batch_continue('') 
#6 /srv/bindings/../code/wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters('', Array) 
#7 /srv/bindings/../code/wp-includes/plugin.php(465): WP_Hook->do_action(Array) 
#8 /srv/bindings/../code/wp-admin/admin-ajax.php(173): do_action('wp_ajax_espress...') 
#9 {main}

Does this narrow it down at all?

  • This reply was modified 1 month, 3 weeks ago by  Tony. Reason: Code formatting


Tony

  • Support Staff

October 17, 2019 at 4:28 am

working and it seemed to fix my checkout problem.

May I ask what you changed? The above line should have nothing to do with the checkout process so I’m not sure how that caused the above.

Does this narrow it down at all?

Hmm, sort of.

EE can’t access the temp batch file in the above location but the odd part is that apparently it can for some requests on the batch process as your getting different results and missing registrations from various steps in the list (the first X registrations missing, or the middle X registrations missing and so on).

On the above site, look in /wp-content/uploads/espresso/batch_temp_folder/

Is it empty? If not, if you check in one of the directories, does it have a event-espresso-registrations-{date} {time}.csv file?

Currently, the only thing I can think of for the above is your host may be blocking the request and whatever rule they have to do so isn’t blocking every request.

I recommend opening a ticket with your host and have them confirm if this is the case, I’ll check in with our developers and see if there something I’m missing that may be causing this.


Praxis

October 17, 2019 at 6:01 pm

This is the code that I commented out: https://gist.github.com/hreidco/4b6f5f2a7f9f0337e6d2650b428cebe1
It hooks into WP Username, so I guess that’s why it was interrupting the login-during-checkout flow. And I was using

FHEE__EE_Export__report_registrations__reg_csv_array

which I just learned from EEH_Debug_Tools.helper was deprecated in version 4.9.69.p in favor of

FHEE__EventEspressoBatchRequest__JobHandlers__RegistrationsReport__reg_csv_array

.

I also learned from my host, Pantheon, that when we were bumped up to a higher traffic level on Oct 1 (whoops! forgot about that), we were put on multiple app servers (only Test & Live), which distributes temporary files across multiple urls, apparently (https://pantheon.io/docs/tmp#multiple-application-containers).
Pantheon suggests

if (isset($_ENV['PANTHEON_ENVIRONMENT'])) {
  define('SOME_TMP_SETTING', 'wp-content/uploads/private/tmp');
}

as a placeholder if the conflicting app can’t be changed. Do you have any suggestions for the SOME_TMP_SETTING that would put the CSVs in my custom directory?


Tony

  • Support Staff

October 18, 2019 at 4:14 am

This is the code that I commented out: https://gist.github.com/hreidco/4b6f5f2a7f9f0337e6d2650b428cebe1
It hooks into WP Username, so I guess that’s why it was interrupting the login-during-checkout flow.

That code only runs on the CSV export, it doesn’t run within the checkout process.

With regards to FHEE__EE_Export__report_registrations__reg_csv_array, you are correct, that filter is deprecated. However, if you want that snippet to run on both the batch CSV exports and the ‘old’ CSV export method (using the above constant I mentioned), which I did when I wrote that snippet, you need to use the deprecated filter.

Do you have any suggestions for the SOME_TMP_SETTING that would put the CSVs in my custom directory?

From the docs you linked to:

The default temporary path ($_SERVER[‘HOME’] . ‘/tmp’) is not synchronized across application containers, so operations that expect this path to persist will fail.

EE isn’t using $_SERVER['HOME'] . /tmp for the above batches (which is what the code you referenced fixes), it’s uploading the files to /wp-content/uploads/espresso/batch_temp_folder/{batch_job_number}/ and reading/writing to the file there until the batch process is complete which is basically what the docs are showing you should force plugins using the above to do.

I do think that multiple containers are causing this issue and your earlier comment:

This bug also happens on Test and Live but not on Dev, FWIW.

Would also point to multiple containers causing this as dev only runs on a single container, Test and Live do not.

Assuming you’ve pulled all of the code and database from test/live to dev to compare against the same data?

So if /wp-content/uploads/* is not persistent across multiple containers then I’m not really sure what location pantheon would prefer we use, the location is filterable in EE so it can be changed but we’d need to know what to change it to.

Can you create a ticket with pantheon and ask which directory we should be using? I can (and will) ask but I’m not a pantheon customer.

For the time being, you can export your registration by adding the constant I gave you earlier to your test/live sites wp-config.php file:

define('EE_USE_OLD_CSV_REPORT_CLASS', true);

Just make sure it’s above the line

/* That's all, stop editing! Happy Pressing. */

That does not use a temp file, only the batch process does, so it should work.


Praxis

October 18, 2019 at 5:53 pm

You were right, that deprecated expression is unrelated.
All of the issues we’re having now (including intermittent broken communications with our payment processor) are most likely related to this multiple containers thing.
We are on a basic support level with Pantheon, so their feedback has been sparse, but I got these responses today from Carl at Pantheon:

Regarding > is /wp-content/uploads/* persistent across multiple containers?
Yes but there is a delay for the files to be propagated across different appservers

and

Temporary files created from “wp-content/uploads/private” will not be publicly available compared to “/wp-content/uploads/espresso/batch_temp_folder/”

and

The issue that you may be getting related to the multiple appservers might be related to the open issue that we have with woocommerce https://github.com/woocommerce/woocommerce/issues/23751

This doesn’t exactly clarify a solution for me, but I would like to try filtering to the /uploads/private folder with

($_ENV['PANTHEON_ENVIRONMENT'])

to see if anything changes, even though that is obviously not a long-term solution.

Assuming you’ve pulled all of the code and database from test/live to dev to compare against the same data?

Yes, it’s all the same.

Can you create a ticket with pantheon and ask which directory we should be using?

This is all I got from them:

referencing to a tmp folder is a tricky issue specially on multiple appservers so it might be best to talk it out with the plugin developer

I also found this thread on the subject (re: drupal): https://github.com/pantheon-systems/documentation/issues/401. They start going into a WP solution here: https://github.com/pantheon-systems/documentation/pull/584#discussion-diff-32785886 but it doesn’t appear to be resolved.

Are communications with payment processors also using temporary file paths?


Tony

  • Support Staff

October 19, 2019 at 7:57 am

Regarding > is /wp-content/uploads/* persistent across multiple containers?
Yes but there is a delay for the files to be propagated across different appservers

In that case, the above directory isn’t shared, it’s synced, and that isn’t going to work with this setup.

This doesn’t exactly clarify a solution for me, but I would like to try filtering to the /uploads/private folder with

($_ENV[‘PANTHEON_ENVIRONMENT’])
to see if anything changes, even though that is obviously not a long-term solution.

You can’t use that directory, because of this:

Temporary files created from “wp-content/uploads/private” will not be publicly available compared to “/wp-content/uploads/espresso/batch_temp_folder/”

The browser won’t have access to the .csv file to download it once complete.

They start going into a WP solution here:

Initially, that would appear to be a step in the right direction until you remember this line:

Yes but there is a delay for the files to be propagated across different appservers

Whatever we do to use a temp directory/file in /wp-content/uploads/ simply isn’t going to work in this case and here’s a run down to explain why I think that is the case:

App Container 1 (AC1) starts the batch process and builds out the temp batch directory in uploads, right?

I then steps into the batch process and sends off an ajax request to collect the first batch of registrations (REQUEST 1), that batch goes to AC1 and processes fine taking say 3 seconds, then it does another (REQUEST 2), again that goes to AC1 and processes fine again taking 3 seconds, until….

The next request (REQUEST 3) is load balanced and hits App Container 2 (AC2). Now, the first thing that is going to happen here is the request to pull the details checks for the temp .csv file, lets say AC2 hasn’t had that file propagate from AC1 yet, it doesn’t exist and you get the above EE_Error stating the file is missing….

Even if that didn’t happen, lets say the file propagated fairly quickly and did so right after REQUEST 1 on AC1, if its not a shared directory across App containers then the .csv is now going to be out of date on AC2, it has the details from Request 1 but does it have them from Request 2? If not, you now have missing rows but EE can’t identify that is the case, AC2 now writes to the .csv file with REQUEST 3’s details, if that is then synced BACK to AC1 without some kind of merge (that’s not as simple as it sounds) your data is now inconsistent.

In short, a batch process that writes to a directory/file like ours that is then synced (not shared) across multiple containers with a delay (however short) isn’t going to work, the requests are sequential so there can not be a delay between when it writes one batch and the other.

Without a persistent shared (not synced) directory we can use across all app containers (or a way to force specific requests to use a specific App Container) the batch process simply will not work with Pantheon and you’ll need to use the EE_USE_OLD_CSV_REPORT_CLASS const above to get any kind of consistent exports.

If you really want to try using wp-content/uploads/private (personally I think you are wasting your time), take a look at these filters:

FHEE__EventEspressoBatchRequest\JobHandlerBaseClasses\JobHandlerFile__get_base_folder

and

FHEE__EventEspressoBatchRequest\JobHandlerBaseClasses\JobHandlerFile__get_base_url

They allow you to change the base URL used but again, I don’t think it will work.

Are communications with payment processors also using temporary file paths?

No, what (if any) issues are you getting with payment methods?

Disclaimer – this is all based on my assumptions of how Pantheon works, I may be completely wrong but the above is my best guess.


Praxis

October 21, 2019 at 3:53 pm

Thanks for spelling that out, Tony. I really appreciate your time on this thread. I’m starting to wrap my head around the concept. And I’m thinking we may need to switch hosts.
The issues we’ve been having with billing through Authorize.net Accept have been intermittent but regular, and also starting around Sept 30.

Reported intermittent issues:
* The aforementioned pg.2 of checkout appears blank if user logs in or registers during the checkout process instead of before.
* Reports of the payment options screen being blank or getting stuck on “loading payment information”.
* After submitting the payment info, users getting the error message, “The billing form was not submitted or something prevented it’s submission.” Meanwhile the transactions are not delivered to Authorize.
* The payment seems to go through on the user’s end, makes it to Authorize, is Approved, but there is no transaction data for the registration in EE.
* Users and Admins are sometimes not receiving some of the emails at the conclusion of some successful registrations.

Do you think these are likely caused by the switching app servers? If so, we’ll need to leave Pantheon immediately.


Tony

  • Support Staff

October 22, 2019 at 2:41 am

And I’m thinking we may need to switch hosts.

To be honest, thats sounding likely. The more I think about it, if some requests for the same user are hitting one AC and then another, it’s going to fail.

Either that or switch to a package that does no use multiple app containers with Pantheon.

The issues we’ve been having with billing through Authorize.net Accept have been intermittent but regular, and also starting around Sept 30.

You site switched to multiple app containers around Oct 1st, so this would suggest it its an issue from multiple containers but I’ll break each one down:

* The aforementioned pg.2 of checkout appears blank if user logs in or registers during the checkout process instead of before.

This one I’m a little unsure of as its been mentioned working and then not working a couple of times when changing a function that appears irrelevant to that step, but….

If we take the function out of the equation a second, the login request we use is done via an ajax request, if that request is being sent to a different app container than the one you are on, thats likely going to cause the login to fail and the if the request returns nothing but is authorized then EE will load nothing. Again that’s just a guess though.

* Reports of the payment options screen being blank or getting stuck on “loading payment information”.

Same again here really, if the user is loading the site on AC1 and then the payment options request is going to AC2, I’m fairly sure it’s going to break the checkout process and do the above.

* After submitting the payment info, users getting the error message, “The billing form was not submitted or something prevented it’s submission.” Meanwhile the transactions are not delivered to Authorize.

There’s lot of possible causes for this, if we stick with the AC1 and AC2 problem it’s the same thing over again, however, if the user got through on AC1, hit and error from a request going to AC2 it may also break the checkout continuing forward (hard to say for sure) but say they refreshed the page and the form loaded when submitting that could just be completely different from what EE is actually expecting.

* The payment seems to go through on the user’s end, makes it to Authorize, is Approved, but there is no transaction data for the registration in EE.

When you say no transaction data, do you mean no EE Transaction at all or no payment within a EE transaction?

* Users and Admins are sometimes not receiving some of the emails at the conclusion of some successful registrations.

Could be linked with the above issue, but we would need to investigate this further.

Do you think these are likely caused by the switching app servers? If so, we’ll need to leave Pantheon immediately.

I can’t say for sure, I’m not a sys admin and my understanding of how their systems work is very limited. I’m making some educated guesses and a lot of assumptions above (which I generally try to avoid doing) which may be incorrect but seem feasible.

What I can tell you is the CSV issue seems likely to be from multiple containers, especially with the feedback from support, it just seems likely that the request is hitting another container and can’t find the file in /wp-content/uploads/.

We don’t often run into all of the above issues at once with users using single containers/sites/servers/{insert new term here}.

I’m assuming this worked fine for you up until around Oct 1st onwards? That is appearently when Pantheon switched you over to multiple containers, so if you started running into issues then, it points to that being the likely cause.

It works on Dev (which uses a single app container) but not Test/Live (which uses multiple app containers).

If Pantheon does not want to troubleshoot this further then my recommendation would be to switch hosts, EE’s batch CSV process works fine on the majority of setups and splitting up requests for any e-commerce type setup is going to cause similar problems to this.


Praxis

October 25, 2019 at 1:21 pm

OK, we’re migrating to a new host. Pantheon believes the fault lies with Event Espresso 🙂
Thanks again for your take on this. Very helpful!

The support post ‘Incomplete Registration Report Downloads’ is closed to new replies.

Have a question about this support post? Create a new support post in our support forums and include a link to this existing support post so we can help you.

Support forum for Event Espresso 3 and Event Espresso 4.
Documentation for EE3 and EE4
Documentation for Event Espresso 3

Documentation for Event Espresso 4

Status: closed

Updated by  Praxis 1 month, 2 weeks ago ago

Topic Tags

Notifications

This topic is: resolved
Do NOT follow this link or you will be banned from the site!