Here is just one of a couple of scenarios where this could come up.
Let’s say you add a plugin on your development server, which requires a wordpress page to do its magic.
There are a couple of problems.
- There is no easy way to move the page over to production. The pages and posts are intermingled.
- Event if you do move it over, there is no guarantee that the pages ID will be the same, since likely new content was created on production in the interim. Most plugins that operate this way, store a page ID.
@Blockhead,
You also might want to check out DeployMint which only works on WordPress Multisite – but could be the best solution for what you are looking for.
http://markmaunder.com/2011/08/19/deploymint-a-staging-and-deployment-system-for-wordpress/
I’ve recently heard of RAMP for WordPress, which is a $99 solution. Looking forward to checking it out more thoroughly.
I don’t know if it takes database IDs into account.
There are two ways to avoid having to manually re-configure the plugin, given the scenario you describe. Neither option is attractive. For myself, I’d opt for option #2. Most of the other members on WPSE seem more inclined towards option #1.
Move your development or staging database to production – and then migrate the newer content from the previous production database using wordpress export / import feature.
Examine the content of the plugins options/settings data as stored in the database. Write a custom migration script that will
a) create any necessary pages or posts, including custom fields, capturing the post_id of the newly created page, and then
b) insert updated options/settings data with the newly created post_id, using plugin specific custom php or sql that you write. If the plugin’s options/setting data is serialized, then the information here will be useful.