|
Ian Just
|
August 25, 2014 at 1:46 pm
From looking at the other posts here, EE4 saves everything in the WP database, correct?
I see the licence deal is ‘one licence to one database’, but is it connected to the database’s name or something else? The use case is at most two events every year, with no overlap in booking etc, and that is usually done by having a new eventname.example.com site. Could that it be done via copying the database to the new event site, and changing stuff to reflect the next event? Or is it ‘one simultaneous use’ and disabling it from the finished one and installing it on the new one would be ok?
What’s the format of the ‘175-22-1-0fcb6b-0’-style registration code – it looks like the number in front of the first hyphen is unique within any event, and increments by one with each new one, and the next two sections indicate the event in question for example? The next six characters are some hexadecimal hash or CRC.
I’m currently having a little difficulty seeing the wp-admin/admin.php?page=espresso_registrations page on demoee, but when I could, I could view the data and export it to a CSV file… but there didn’t seem to be an obvious way to say ‘I want this field and that field too’ in addition to the ones that were there.
How hard would it be to add say Stripe as a payment processor?
|
|
Sidney Harrell
|
August 25, 2014 at 5:56 pm
EE stores everything in the WP database, but not in the WP tables. We do add a number of EE specific tables, so be sure to copy all the tables when copying the database.
The domain name associated with the license key is stored on our end, which would probably be affected by the subdomain change. But the only thing affected would be the one-click updates. You would still be able to manually download the updates from your account page and install them. If you let us know that you changed subdomains, however, we can reset your license key to restore one-click updates.
We have tried to anticipate third party developer needs and have added a number of hooks and filters to the code, so the format of the registration code could probably be customized. If it is not, we can add a filter to make it so. Similarly, which fields are exported in the CSV report should be programmatically customizable.
All the EE3 gateways will eventually be ported over to EE4. Currently we are in the midst of a rewrite of how the gateways interact with the EE4 core code, so we have not yet begun to migrate them all over. It would not be very hard to port Stripe over right now, but it would then need to be rewritten again after the gateway rewrite is completed.
|
|
Ian Just
|
August 26, 2014 at 2:21 am
Thanks.
Yes, I expected there to be new tables.
It’s struck me that one way around the issue would be to have each event use a single site for the actual bookings, so that eventone.example.com and eventtwo.example.com would both link to the bookings.example.com site – the benefits of not having any overlap in registrations etc!
The reg code question was me thinking that the first number could be their ‘registration number’ for human use.
|
|
Dean
|
August 26, 2014 at 3:33 am
Hi,
The number at the start of the registration ID should refer to the Transaction ID, which is why some registrations will start with the same number.
|
