Support

February 3, 2025 at 9:08 am

Hi there,

Not currently.

I’m assuming the new site is going to be use a page builder?

A lot of the EE data within the site are stored as custom post types and we then use the ID of those in custom tables. So the problem with the above is you can’t just copy the data over becuase anything you do within a page builder will store rows in the wp_posts tables and will then be lost, you’ll either lost the page builder changes or EE data wont match up (the ID’s wont match).

The way I’ve advised doing this in the past is to…

1. Copy the site to your dev site and make the changes there, you have some ‘live’ data you can work with there.

2. When ready for the move, put the LIVE site in maintenance mode to stop registrations for a little.

3. Copy the current LIVE site to a NEW dev/staging instance.

4. IF using a page builder, many have an export feature… so use that and export the new designs from the DEV site to the DEV SITE 2. Now you’ll have the live site with the new changes.

5. Export that site to replace the live site. (Make sure you have a backup of the live site before doing this, just to be safe)

February 27, 2025 at 3:12 pm

I think the easiest solution would be if there was a way to do an import/export with all the tables and information from the existing database in EE.

Unfortunately, there isn’t currently a way to export ‘just’ the EE data, and doing so is by no means easy, simple or quick to implement.

Events, venues, registrations, contacts, ‘people’ (to name a few of the entities we have) are all custom posts stored within wp_posts. The ID of each of those rows is then used as the foreign key in various custom tables to bind the relationship between them all.

What that means is you can’t copy ‘just’ the _esp_ tables (which are our custom tables) from one site to another as then all of the foreign keys will be incorrect/invalid, and the actual ‘posts’ won’t exist. Thats not even considering categories, tax, custom taxonomies and the various other WP data EE posts uses. You would need to copy all of the tables from the original site into the new site and drop the data you don’t need from there for this to work.

Even if I could force the team to drop all other works we have going on currently (to be clear, I can’t do that) and work exclusively on this, getting a working export/import system ‘just’ for Event Espresso planned, built, tested and battle-hardened would still be way outside of your timeframe here. It’s a massive undertaking.

Do the migration from the redesign and then simply import and overwrite the redesign database with the exported and updated EE database from the live site that is being replaced.

As mentioned above, this isn’t simple, I wish it were but its not.

As a most basic level, using just 1 EE event post, it would need:

1. Export the currently wp_post row containing the EE post type data and post ID (EVT_ID).

2. Export any additional data related to WP functions, taxonomies, categories, tags etc, basically anything built into WordPress itself that may be referenced by the post_id)

3. Export any rows from the custom tables (they have a prefix of esp_ related to that specific event. A quick search from my current database shows 45 esp_ tables in my database. Not all of those will hold data specifically related to the event post, but they will all need to be processed to confirm they don’t use the EVT_ID anywhere.

4. Related all of that data into some file format, lets say JSON just for something to reference.

5. Import the Event Post into the new site… starting with JUST the post itself and inserting that into wp_posts. The new site will than assign a new Post ID (which is used as the EVT_ID) to that specific event post.

6. Run through ALL of the WP features i mentioned above importing the data for those and mapping the new EVT_ID in place of the old one. Again not you can’t just import that data as is becuase the new Event post has a new EVT_ID used as the foreign key and need to be mapped).

7. Run through all of the data from the esp_ tables referenced above adding and rows into the DB in the relevant tables. As this happens each row needs to reference the new EVT_ID value within the row, so essentially old EVT_ID to new EVT_ID mapping again. This is things like registrations for a specific event, those reference the EVT_ID so need to map to the new ID, the tickets, datetimes, settings, questions, question groups etc etc all reference the EVT_ID to relate the data back to the event itself.

I’m giving a very high-level overview here and already you can see the amount of relationships and data that needs to be analyzed, mapped, updated, checked and saved is huge.

That seems more simple that trying to piece together imports from theme files, and css files, and new static templates etc… to an already existing running platform.

Sorry, but I can’t agree with this.

Importing a static theme is much less complicated than all of the above. Install the theme, activate it and all the files are there, done. Obviously there’s more to it than that with theme settings etc but still less than the alternative.

Even using a page builder theme (which then stores ALL of the design for each individual page/post within the wp_post row) and exporting that to then re-import into another site is much less complex than the above.

I would assume this is a very common issue going through a site refresh while still being live and taking registrations and keeping the online business running?

It’s not as common as one would think, but I’m aware that for those that need it it can be critical. It’s a complex issue that comes with complex solutions, I wish there was a simple solution.

The ‘easiest’ way to move forward depends on which redesign method you’re using. Page builder vs Standard theme for example but ultimately you can’t currently export just the EE data from Site A to Site B.

February 27, 2025 at 3:59 pm

Registrations relate directly to an event, ticket and price… and others Im likely forgetting (each of which are store in separate tables).

To to import a registration, you need the event to import it to, then you can use the attendee importer:

https://eventespresso.com/product/eea-importer/

But… you would do that on a per-event basis, so it’s not really what you are asking for here but the closest we have to it.

In short you could export all the registrations for a specific month.

Filter that within Excel and extract the registrations for each specific event to then be placed in individual csv files.

Then import each of those individual event registrations into the event using the above.

Its not expected to be used as a migration/update tool so there’s not checking for existing registrations as you import them, whatever is in the CSV will be imported on the event/ticket selected during the import.