Somehow I seem to often be in the position where I need to make changes to large, complex, high-traffic sites - changes to the live site that is... Yes, they should have dev/staging servers, but they don't, and I'm not in a position to make them set it up...
So changes must be made with a minimum of disruption to the site. Usually the best way to do this is to make a test copy of the page that's going to change and work with that - so that if you break something it doesn't affect the live page. But in some cases this isn't feasible - for one large site a change will involve a cascading set of php files and smarty templates - and I'd have to make copies of all of those, plus change the includes in the right place etc. to make it all work. Then undo all that to make the changes live...
Not the best way to set up a system, but that's a topic for another day. So how to minimize disruption?
One way I've alluded to before - take advantage of Firebug by putting the new section or widget or whatever into a div or table or whatever that's set to display: none - that way this possible screwed up code won't show up because it's hidden on the client-side. It's still generated by the server, but it won't affect layout etc of the live page. Then you can use Firebug to make it visible (set it to display: block;) and see how it looks.
It can also be tricky to output error messages when debugging changes. Obviously you don't want them showing up to users. Sometimes you can just put them in as commented out html and view the source to see them, perhaps because they're coming from deeply buried php code and won't actually make it to the browser. In this case, sometimes you can dump them into a variable in the templating system. Smarty is great for this - you can put them in something like 'aaaaaa' and then set smarty to show it's debug screen only for your IP address. Then you can look on that debug screen for your 'aaaaaa' var and see what's in it.
Perhaps those tips can help someone out there make the best of a bad situation - this is why staging servers should always be available, but in the real world that's not always an option!
So changes must be made with a minimum of disruption to the site. Usually the best way to do this is to make a test copy of the page that's going to change and work with that - so that if you break something it doesn't affect the live page. But in some cases this isn't feasible - for one large site a change will involve a cascading set of php files and smarty templates - and I'd have to make copies of all of those, plus change the includes in the right place etc. to make it all work. Then undo all that to make the changes live...
Not the best way to set up a system, but that's a topic for another day. So how to minimize disruption?
One way I've alluded to before - take advantage of Firebug by putting the new section or widget or whatever into a div or table or whatever that's set to display: none - that way this possible screwed up code won't show up because it's hidden on the client-side. It's still generated by the server, but it won't affect layout etc of the live page. Then you can use Firebug to make it visible (set it to display: block;) and see how it looks.
It can also be tricky to output error messages when debugging changes. Obviously you don't want them showing up to users. Sometimes you can just put them in as commented out html and view the source to see them, perhaps because they're coming from deeply buried php code and won't actually make it to the browser. In this case, sometimes you can dump them into a variable in the templating system. Smarty is great for this - you can put them in something like 'aaaaaa' and then set smarty to show it's debug screen only for your IP address. Then you can look on that debug screen for your 'aaaaaa' var and see what's in it.
Perhaps those tips can help someone out there make the best of a bad situation - this is why staging servers should always be available, but in the real world that's not always an option!
Comments