Support

January 13, 2020 at 2:07 pm

Hi,

The approach you’ve outlined will result in losing all of the data on the live site that was added after the development site was started. Are you changing to a new WordPress theme or are the changes also involving page/post changes too?

With regards to the site license key, on the temporary domain you don’t need a license because it’s not a live site.

January 13, 2020 at 4:37 pm

The approach you’ve outlined will not work because you’ll lose most of the Event Espresso data. Specifically, steps 2 and 3 will not transfer Event Espresso’s data. Step 4 also will not work because custom invoice templates and email templates are stored in the database, they are not loaded from a templates folder.

I’ll re-post the steps again, with additional comments to help clarify them:

1. Run the WP export tool on the development site, then set that backup aside. Also do a full database backup just in case.
2. On the live site, Put Event Espresso into maintenance mode (so no new registrations happen while doing the next steps)
3. Migrate the current live site’s database to the dev site (minimum of wp_posts table & all wp_esp_* tables) The WP Migrate DB plugin can be used for this
4. On the dev site, delete all standard WP posts/pages. The posts and pages deleted in this step are the posts/pages from the original live site, so you do want to delete them.
5. Then, on the dev site run the WordPress import tool to import the WP posts/pages, importing the export file that was made in step 1 (restoring the dev site’s posts & pages)
6. If there are other custom things like theme options those would need to be re-imported too

January 13, 2020 at 5:09 pm

May I ask how is what I’ve outlined here impractical? I’ve actually used this approach and found that it works quite well. I must admit I’m a bit surprised whenever this idea gets the push back it gets, but maybe I’m missing something.

January 13, 2020 at 6:25 pm

You may not be aware that Event Espresso uses the wp_posts tables (and other native WordPress tables too). This means that migrating data from one site to another is more involved than copying over “just the EE tables”. The approach I’ve outlined works well because it isn’t confined to just the EE tables. It also works well because it’s simple and thorough: In a nutshell it deletes all the old and imports all of the new posts/pages/tags/categories/menu items.

There was another approach available at one time that made use of the Mergebot plugin, but sadly the plugin & its accompanying service was shut down. To the developers of Mergebot’s credit, making a way to automatically merge data from one site to another site isn’t quite as straightforward as it might seem, but they gave it a good effort.

Had this question been asked before the dev site had any changes made to it, you would have had the option of VersionPress, which can be used to help keep track and merge changes to the database. It cannot be made use of now because VersionPress needs to be set up before the two sites diverge.

I get your frustration with the idea of having to run more than a few steps to migrate the data, but as of right now the simplest way I can think of to accomplish what you’re looking to do involves 6 steps. It may help to know that 3 of those steps are very easy to do (1, 2, and 5 will typically take a few seconds to minutes each with a few clicks).

I can think of other ways to migrate/merge the data from wp_posts that don’t involve the above steps, but they’re more prone to error and could be a more difficult (or even an impossible) path. e.g. Another approach could be to export out all of the rows from the wp_posts table that have post types “espresso_events”, “espresso_attendees”, and “espresso_venues”, also export post_meta if applicable, then import into the new site’s database. Then export/import all of the esp_tables. This will only work if no posts from the new site’s database have the same post IDs of the EE posts. It also doesn’t handle any of the options (wp_options table) so the settings would likely need to be redone or copied over somehow.

January 14, 2020 at 2:40 pm

They’ll transfer over OK because in step 1 an export/backup is made of the posts, pages, menu items, and so on. Then in step 5 the backup is imported. So unless the posts/content are storing things outside the wp_posts and post_meta tables they’ll be fully restored over to the live site.

One item I didn’t realize until I checked the dev site: I can see it currently has the Event Espresso plugin activated. That’s fine for now, but when the export is run, Event Espresso will need to be deactivated so events from the dev site do not get imported onto the live site.

Also should mention again: This should be first done on a staging server, in other words “a dry run”, before doing the final move of the data to a live server.

January 15, 2020 at 1:59 pm

That’s not actually an export, it’s more like a report that can be reviewed in a spreadsheet app or anything else that can open a CSV file.

There is an attendee importer add-on but I’m afraid it’s not intended to be used as a way to migrate data from website to another. The way it works is you import a CSV file with attendee data, and it imports the registrations into one event. So it would require running an import for each event.

January 16, 2020 at 2:57 pm

Step 3 isn’t possible because the registrations would then be “orphaned” without an event.

January 17, 2020 at 8:13 am

You could trash the event, but if you go further and try to delete it permanently, the option to permanently delete will not be there because the registrations are still attached to the event.

There’s a new feature being developed that will allow for deleting and event that has registrations attached to it, but what it does is it deletes the registrations along with the event when permanently deleting an event.