2009/2/17 Paul M Foster <paulf@xxxxxxxxxxxxxxxxx>: > On Mon, Feb 16, 2009 at 08:49:06PM +0000, Stuart wrote: > >> 2009/2/16 Paul M Foster <paulf@xxxxxxxxxxxxxxxxx>: > > <snip> > >> > >> > Agreed. But here's the real reason, in my case. We develop the pages on >> > an internal server, which has the URL http://pokey/mysite.com. When we >> > move the pages to the live server at mysite.com, all the URLs would have >> > to be rewritten. Ugh. >> >> My advice would be to stop coding and sort this out as soon as >> possible. > > You think? ;-} > >> If your development server has a different layout to your >> live server you're simply asking for trouble, especially since you're >> using a front controller pattern (as evidenced in another thread). > > Not so much. We've structured our backups and live servers this way for > a number of years without incident. Paqes for clients are normally > statically built in Dreamweaver, with possibly a modicum of PHP to > handle forms. Internal company pages are built by me and reside only on > internal servers. This is the first client project where we're using a > front controller, etc. Not encountering a problem for "a number of years" does not mean you're not going to have problems in the future. I know a lot of people who don't backup their data, some who justify it by asserting that they've not had a problem so far. Maintaining identical development, staging and live environments is one of the key components of reliable, repeatable and streamlined development, testing and deployment, but if you're happy with what you've got then by all means continue as before. I was just offering a best practice suggestion that would solve your current problem and likely some you'll encounter in the future. >> It's simple to fix this. Add a hosts entry for mysite.local pointing >> at pokey's IP. Change the server software so it has a virtual host for >> mysite.local pointed at the mysite.com directory in the existing web >> rooot. > > Which works up until the point where you go live with the site, and > forget to revert the hosts file, so you can't get to the live site. And > after you do revert the hosts file, you again have the same problem with > the base URL for the production site being different from the > development/backup site. > > Virtual hosting is beyond my Apache expertise, and again, would mask > live sites we host. No it wouldn't. If you care to read exactly what I wrote, you put the development site under mysite.local rather than mysite.com. It won't mask or hide the live site and it won't have any negative impact when you put it live unless you've used the domain name in links. > In addition, pokey's IP is not exactly fixed. It's served up by DHCP > from an internal DHCP server. It's generally the same, but I wouldn't > want to rely on that in a hosts file. Most DHCP servers can reserve an IP address for a specific MAC address such that that IP always gets given to that NIC. >> This is not difficult and will allow you to solve both of the problems >> you are currently asking this list about. > > Actually, Ashley's <base> tag solution resolves the problem. However, > I've moved on and dropped the front controller concept for this project. > Instead, I'm opting for a snippet of PHP at the beginning of every > "static" page built in DW which calls in the values necessary to > populate the sidebars of the pages. That's completely up to you, I'm just trying to help. > Really, Stuart, you should try not to be so annoyed at people who don't > appear to know as much as you believe you do. ;-} I'm not annoyed, I'm mildly frustrated. You did not respond to my initial suggestion in the other thread but continued to discuss the problem with others. I apologise if my tone came across as annoyed, but it's polite to respond to others when they communicate with you. Good day to you sir ;-) -Stuart -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
