A suggestion for workinprocess module for website developers.

I've been working with localserver applications for the past few months and have experienced a myriad of issues.

Yesterday, I lost a website on a localserver applications that took several months to build. Now I've got backups, but I've still got issues.

Working with the MySql and webserver issues is an area of it's own is why I address this request here. It might very well be time to give localservers a hard look for the amount of work they actually create. They no longer make you more efficient, it's just they allow you to build and maintain sites while you have your production site on the web.

Things have changed. The speed of data transfer is greatly improved, bandwidth is much cheaper and webserver costs are down considerably. I can build a site as fast now online webserver as fast as I can on a localserver in most cases. The issues with localservers are growing, because of local computer security issues. Firewalls, and UAC in VISTA, virus and spyware scanners,etc. I could really go into this. LOL

--------------------

We need a module for Drupal, a module I believe you could build. We need a tool to build workingsite on the same webserver as the actual production site resides.

An example:

mydomain.com/carsite/
mysqldb = carsitedb

mydomain.com/carsiteinprocess/
mysqldb =carsiteinprocessdb

The final production site would be on the same server as your work in process of the same site.

----------------------------

This can be done now of course, except the internal linking within the Drupal application has link calls and referrals that would have to be altered as well as the Mysql database calls and referrals. This could be a real problem sorting it out.

----------------------

I think it might be accomplished through some method of alias management similar to path alias/pathauto.

Effectively, the module would allow the same calls and referrals for links and mysql inside the workinprocess site as the production site.

Yet, the domain pointers as far as using the site from the webworld would be different. Developers would access the alias of the site, by that I mean the domain.com would be the same. The drupal folder would be installed in a folder called something like domain.com/carsiteinprocess/

The drupal installation could not be installed at the root level. The drupal production site would have to reside in a folder of it's own, and the the workinprocess version of the production site would reside in a folder of it's own.

When the workinprocess site was ready to migrate to the production site the alias would be disabled, the workingprocess folder with the workinprocess verison of the website would copy itself. The copy would change to the name of the production site and would migrate/transfer over and form revised version of the production site. This way the developer could always have a site as workinprocess and a production site on the same server all the time.

All the links and referral coding to links within the production and working site would be the same, just those calls and referrals for access from the web would use alias to the workinprocess site.

All the problems of maintaining localservers would be done with, along with all the issues associated with localservers.