ignore duplicate entries upon phpmyadmin import

Your concern is well founded. Exporting, then importing a while later on an active production site risks loss of data. Ideally, don’t do that ?? Why not make any modifications to the DB directly on the production site? Typically locally developing plugin or theme code does not require modifying DB data. If you really must for some reason, it’s feasible to only export the local data that has been added. The export file will need modification. The INSERT queries need the IDs removed so that new production IDs are assigned and superfluous queries removed, like table inserts and the like. Updating existing data must be avoided for the same reasons that importing a full DB must be avoided.

You might be able to connect your local site to the production DB so “local” changes are in fact made directly to production.

There are DB sync apps available that maintain two different DBs as perfect mirrors of each other. I’ve no experience with them myself.

I see, thanks for your insight. I guess I liked the idea of doing everything locally, then pushing to Github which automatically deploys to live. That way I can always revert back if something goes wrong. But I’m learning with WordPress that is a bit more challenging.

This is my first WordPress website, you recommend to just move to the live site now that I have it all installed and running properly?

• This reply was modified 4 years, 11 months ago by airontheshore.

Yeah, it takes some experience before a lot of WP starts making sense. Don’t worry, initial bewilderment is normal ??

You’ll need to figure out what workflow works best for you. Working locally at first is a great choice even though it could introduce sync issues as things progress. When you first start building a site, do so locally and develop as far as you possibly can before doing anything anywhere else. As soon as another DB copy exists it gets a lot more complicated. Avoid creating copies until there is no choice. I’m assuming in this scenario you’re a solo developer. If developing with a team, you’ll need some sort of version management scheme like subversion or git.

At some point you’ll likely need to launch a staging site to get client feedback and eventual approval. There shouldn’t be any need for anyone else to alter DB data of a staging site, so you could still safely overwrite the DB without risk of losing data. But doing so is an extra step better avoided. At this point, I make any DB changes directly to the staging site. My local DB becomes “stale”, which is usually OK. I can still code locally using stale data for the most part. Coding changes at this point are usually limited to a theme file or two and are easily uploaded to staging.

Once the staging version has been approved and you’re ready to launch the production site, you can usually just search and replace the staging URLs with production URLs since staging is usually on the same server as production. Now others could be altering the DB. It’s no longer feasible to make a copy and later on write it back. At this point there shouldn’t be any need to. You can still code locally and upload the affected files.

Any DB changes should be done on the production DB itself. If there is any chance of someone else using the plugin or theme editor while you’re coding locally, disable the editors so that is not possible. There remains a risk of someone using FTP to alter code files while you have them locally. In my environment that is extremely unlikely. If it’s a real possibility, then a version management scheme should be in place.

This is a reasonable starting point. You’ll find reasons to change and adapt as you gain experience. That’s normal and fine as long as consequences of any change are well considered. There will be occasions where deviation is required, that’s OK too.

Thank you so much for your insight. It gave me reassurance, as well as made me realize I may have been overdoing it for this project. Cheers!