Support

March 10, 2014 at 5:18 am

Hi Peter,

Which version of the Event Espresso App are you using? Latest version is Event Espresso HD v2.0

When you say it’s not very fast, which part?
Scanning the tickets?
Retrieving the information?
The steps involved?

I will pass on any feedback you can provide to our android developer.

Regarding the emails.

There are so many steps that Event Espresso does not have control over in regards to emails that it is impossible for us to tell. Usually its down to an issue with the server (Event Espresso issues an email command and passes the content to WordPress, which then passes it only your server, which could do any number of steps)

We recommend using a service such as Mandrill or Postmark to send transactional emails.

Personally I use Mandrill as it offers up to 12,000 emails per month for free and removes much of the uncertainty of the emails (you can view in-depth reports of the emails sent) and use wpMandrill to connect to the service.

March 12, 2014 at 8:50 am

Hi Peter,

One difference between scanning on EventBrite’s app and our app is you are hosting our software on your server. EventBrite is hosting their software on their server. If your site is hosted on a overloaded shared server it will be a lot slower. Have you considered contacting your host about upgrading to something like a managed VPS server?

WPmandrill is a WordPress plugin that will route sending emails sent by WordPress (which includes Event Espresso’s email notifications, they all get sent through WordPress). Mandrill is a transactional email service that is separate from MailChimp’s newsletter service.

March 12, 2014 at 10:42 am

Hi Peter,

I think using WP super cache wouldn’t help in this case because when you use the ticketing add-on you’re actually reading and writing info to the database when you scan a ticket. Where WP super cache is useful is when you want to speed up the loading of a static website page or post that doesn’t need to be dynamic (ie read-only). Instead of serving the page dynamically, where WP normally runs PHP and accesses the database each time a page is loaded, it builds a “cached” copy of page that’s all html and serves it instead. The database speed is not affected, it’s not even relevant when it’s serving static files.

If you’d like to learn more about how WP super cache works, I recommend checking out this overview:

http://ocaoimh.ie/wp-super-cache/

March 12, 2014 at 12:39 pm

Hi Peter,

I don’t think changing the API to allow public access will help speed things up, but changing the defaults might help a little bit. An attendee can be part of a group registration, so for example two attendees could be part of the same registration.

March 12, 2014 at 4:58 pm

Hi Peter,

Our policy, like that of many companies, is not to comment on future plans or work in progress. I can tell you though that the API for EE4 that will be used by the ticket scanning app to interface with the WordPress database is very similar to the one that was built for EE3. Please note that it is not normal for ticket scans to take longer than less than one second. When you see a 4-6 second delay after scanning a ticket, that’s likely a network traffic or server issue.

March 12, 2014 at 5:18 pm

I can’t comment on future plans about viral add-ons or resellers because our policy, like that of many companies, is not to comment on future plans or work in progress.