• I am new to all of this and after getting our first site up in the development enviroment, I went to make it public and ran into an interesting issue, that I am not sure I understand completely and could use some advice on resolving.

    Development – We do this from a Users system connected via a putty tunnel mapping 127.0.0.1:1080 —> Host IP:80. An having the document route for virtual host be /usr/local/www.

    Test – We went to make this site available from a Public IP but under and alias URL, updated the Virtual server definitions and changed the document route to /usr/local/www/data/wordpress (Using FreeBSD Jails). Nothing worked, I had to rerun some of the setup and it looks like I may have to modifiy the posts.client_database table field GUID as it seems to be set to http://127.0.0.1:1080………

    Production – Not sure what will be required when we get this far..

    ————————
    What is any thing is orng with our methodology and is there a change control / promotion process that I am missing or should I just write a sql update to change the gui as needed and contunue don ths road ??

    TIA..

Viewing 2 replies - 1 through 2 (of 2 total)
  • The above link: http://codex.wordpress.org/Moving_WordPress does not adequately answer your question, and it seems that almost all the responses provide this same answer given over and over again. Unfortunately, the codex article only addresses the simplest of WordPress installations.

    The issue is a best practice approach to a site design methodology that is typically used in most commercial site deployments. Like you, we are seeking recommendations to successfully migrate complex WordPress sites within a domain from the development environment (subdomain) to a “staging” (testing) environment (another sub-domain) and then to the production (live site) environment (production domain). It would appear that this is still a critical weakness in the WordPress platform as of Version 3.1. There are no documented best practices, there are no utilities or scripts published and WordPress incorporate “absolute” or hard-coded URL links in several places that make migration very, very, frustrating. In a typical commercial environment the site specific variables and links are actively referenced (called) via a global variable declaration file and a dynamic variable declaration file. Until this capability is incorporated to support advanced user needs … the developer is stuck manually editing each and every config file, theme and content file.

    If anyone has found a best practice approach to address this site development and migration issue… Please, please reply. Other post of this nature have simply been closed without any answers and marked as “unresolved”.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘Development VS Test VS deployment —’ is closed to new replies.