Support » Fixing WordPress » Syncing production and development databases

  • When using wordpress as a CMS, I imagine it’s quite common to establish a set of pages for the site that the client will edit. In this case, these particular posts are part of the “structure” of the site. As time goes on, the posts table will fill up with “content”.
    Now, if on a development server, I add a new page, I can’t just push this up to production, because it will likely overwrite some content from the client.

    If I was building a site with a framework, this would not be an issue since all the structure of the site is in code. In this case, the structure is mixed in the database with the content.

    How have other people dealt with this issue?

Viewing 4 replies - 1 through 4 (of 4 total)
  • Not sure I understand your usage of “page” and “structure”. In wordpress the structure of the site (layout and design of pages) is controlled by the Theme files. These are NOT part of the database.

    The content of the post or page (word that a user writes) go in the database and are separate from the Theme. If you make changes to the Theme or create a Template for a new type of page that will not change or overwrite user created posts/pages.

    Obviously if you are talking about you writing a page of content that has the same name as an existing page written by a user then that would be an issue.

    @blocka – Yes, that’s a serious problem that has baffled me for a long time. Recently though I’ve started to convert those things into a script. The idea is if that you write a plugin that lets you run the PHP initialization scripts from an admin option. In the case of a post_type=='page' your script would first check to see if the page exists and if not it would add it.

    I’m not all the way in terms of my implementation yet but here’s a starting point:

    @obscure – What @blocka describes is a common problem for people delivering websites for clients on a professional level, clients who ask for lots of customization and who expect it to be 100% right once deployed. There are many situations where there would be a need to merge database content from a development instance into a production instance such as taxonomy terms that have been added to support menu options or other functionality and/or data in the wp_options table in addition to content in a page. Often clients want to make sure the page is “perfect” before letting it deploy, and that’s probably the situation @blocka is having to deal with.

    Hope this helps.


    @mike, that would be great for initial setup, but what about updates? Especially if you use a plugin which stores a pages ID in its settings. In that case when you push your pages up, the ID will likely be out-of-date.
    I think the root of this problem is mixing up structure and content.
    If we could define pages *in code*, and have them useable, by wordpress and plugins, as if they came from the database, that would help a lot.

    I have a wacky idea which involves the get_pages filter, which I have to think through.

    I’m already doing something similar to activate certain wordpress settings using the “pre” options filter.

    @blocka: That’s why you don’t use the $page->ID with this technique. Add the page and it will create it’s own ID. Of course you’ll need to fixup references to taxonomy, etc but it is doable.

    As for mixing structure and content, you are of course correct but since it’s not going to change for WordPress core (at least for the foreseeable future) then we just have to accept that fact and work around it.

    As for defining pages *in code* that is ironically *exactly* what I’m talking about, at least to initialize them. Your idea to *load* them from code is actually intriguing though. Hmm…

    BTW, the toolset I’m working on uses a simple tab-indented name/value pairs file format to store initial values, a format that any business person could author, and it loads the data from that format. It’s still a ways from being complete enough to release but hopefully one day soon…

    Hope this helps.


Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Syncing production and development databases’ is closed to new replies.