pbarkley
Posts: 37
|
| Posted: 08/19/2010, 11:42 AM |
|
This should be a common programming task, but I don't see the property I'm looking for in the documentation or the forums. I have an application that needs to run on my development machine locally, and then be promoted to a test area on the server, and finally to the production environment. The concept of different servers (Server1, Server2...), all using the same named connection (i.e., Connection1), but in fact each with different connection information, works great. When you change servers and publish the project, the code is set to connect to the right place and the files are moved where they need to be.
My problem is this. There are certain things that need to happen differently in test versus production. For example, the system sends email notifications, and during test I don't want orders going to the people who are going to process them; the emails need to go to the tester. Similarly, on my development machine the emails go to me. I obviously could change the code by hand every place where it needs to change before publishing to a different server, but that's kind of silly given that the system runs off the multiple server concept already.
How do I check a runtime property in PHP to determine any one of the following:
-- server name (e.g., "Server1")
-- server path
-- server URL
-- connection database or connection ODBC connection name
Any of those, in my case at least, will be different and will let me branch the code appropriately. Sorry if this is obvious, but I don't see it!
Thanks.
|
 |
 |
rho
Posts: 85
|
| Posted: 08/19/2010, 1:33 PM |
|
You can get information about the server in the PHP server variable $_SERVER. See http://www.php.net/manual/en/reserved.variables.server.php for more information about the various values.
Hope this helps
Cheers, Rob.
|
|
|
|
pbarkley
Posts: 37
|
| Posted: 08/19/2010, 1:49 PM |
|
Duh! Sorry, I was fixated on doing this with CCS run time properties and going, gee, I don't see any properties for server info. Of course this is the perfect answer, get the information from PHP like any other PHP program would--thanks so much, Rob!
|
|
|
|
datadoit
|
| Posted: 08/19/2010, 7:18 PM |
|
For our projects, I like to call a function upon login that sets the
environment:
//Determine whether we're on a local development machine, test machine
//or production machine.
function GetEnvironment()
{
if ($_SERVER['HTTP_HOST'] == "127.0.0.1" OR $_SERVER['HTTP_HOST'] ==
"localhost") {
$Environment = "Development";
}
else {
$Environment = "Production";
}
CCSetSession("Environment", $Environment);
}
Then whenever you need it, grab that session value. Whenever your test
environment changes, make the single change in this function.
|
|
|
|
pbarkley
Posts: 37
|
| Posted: 08/19/2010, 7:48 PM |
|
datadoit, I like that idea a lot, too. I think I may do something similar, except that I'm going to set three environments, Developer, Test, and Production. That has the obvious advantage of just doing the job once and then using the results wherever you need them. Nice.
However, that brings me to something I need to add to my original prematurely optimistic reply to Rob. While $_SERVER works great to get the server name, in my case that wasn't quite enough because the test environment runs on the same server as production--I know, that sounds like a terrible idea, but this is not an application likely to crash a production server in test mode. So if the server is localhost, I know it's in Developer mode, but if it's on the production server, I really also need to know the database, since one is called, say, "client" and the other one "clienttest".
After some more digging around--I'm pretty new to this--I found the variables used in common.php and I was able to check them in a diagnostic like this:
echo $CCConnectionSettings["Connection1Local"]["Host"];
echo "<br>";
echo $CCConnectionSettings["Connection1Local"]["Database"]; exit;
Took me a while to figure out how to get the syntax right for the nested arrays--I have no idea why there was a need to nest them in the first place, and the syntax looks "wrong" to me (not much experience in these technologies), but the diagnostic above works. From there it was just a matter of checking the contents of those variables. Oh, and adding of course in the section where I need it:
global $CCConnectionSettings;
One thing I forgot to mention in my original post is that I like to REALLY put a strong tag at the top of all the screens to let people know they're in the TEST MODE and therefore hitting the test database. Since the programs are otherwise identical, it's easy for someone to forget which one they're running--I don't want complaints that someone changed the data but the program isn't "taking it" because they're looking in the wrong, non-updated version.
I hope this helps someone else out there who needs to do a similar thing in the future, and I appreciate your help, Rob and datadoit. (I've been lurking for a few weeks using the forum resources to get started in CCS.) Once I got the hang of it, CCS makes deploying to all three environments very easy, and IMO there really isn't any excuse for not having multiple environments unless the production system is not very heavily used or no one really cares what blows up. I find the additional test environment essential because sometimes there are issues on that production server that I don't have on my localhost, and I want to find them in test mode, and not production. For this particular series of applications, having a different database on the same MySQL on the same server works out great. No angry phone calls and surprises when I make a change. 
Regards,
Paul
|
|
|
|
rho
Posts: 85
|
| Posted: 08/19/2010, 9:33 PM |
|
Hi Paul,
Another tip (as used in our projects): store the - per server - settings in a database table so you can configure it easily for various server types. Determine the server you're on and then look up the settings in the table. For example, when sending mail - based on the setting in the configuration table - the email is send to a test address instead of the (given) address.
Your code should take action according to the settings in the table. This way it is easy to add other servers (for example if you're working on multiple development servers) - without modifying your code.
If you really want to take a stab: split the server data in two tables: one table for the specific server settings and another table for the server type settings ("the server is of a specific server type") . You can then easily add a new server of type "Development".
Cheers, Rob.
|
|
|
|
pbarkley
Posts: 37
|
| Posted: 08/20/2010, 9:47 AM |
|
Yep, that's an excellent way to do it. Normally I make as much stuff as possible data driven, but here I've been under some time constraints, and I'm an outside developer--in this case just one person working on software for a client where an internal developer had done some unusual things over the years. He did pretty good work, but working by himself as a young programmer he was not exactly team development oriented, because he didn't need to be and he didn't know any better. After he left, they hired my company, and we mostly do ASP.NET. I don't do ANY programming now, and haven't in 15 years, but this new client didn't warrant hiring a PHP/MySQL programmer, and I figured I could probably come up to speed quickly since I do have many years of experience in development, just not on any of these technologies, and none of it recent. And I was interested in doing more hands on coding for a change.
I was quite mistaken in my optimism of course. This has taken me probably not one, but two orders of magnitude more effort than I expected. Of course we're not billing out the wasted time because of my ignorance. Anyway, I'm gradually moving the client toward the concept of not just messing around with the production systems but setting up test areas for each system, etc., and in fact the current CCS project is to put an administrative layer on one of their systems so they can stop relying on me to update new products, inventory levels, etc., all of which their internal guy was just jamming in the database! So we're kind of easing into the concept of them taking charge of their own data and not paying through the nose for clerical activity. I have a long list of things that I'd like to add to their systems to make them more self-reliant, and over time I think we'll get there. The data driven email and bcc addresses are one of them for sure. That's not really good for MY business, but it's certainly the professional way to do it, and we'll eventually get the client in excellent shape.
Regards,
Paul
|
|
|
|
|
