Support

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.

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.

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.

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.

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.