Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Is it fine to code PHP on Windows and host it later on a server running Linux? Can there be any problems in the migration of such a project?
I would think that there really can't be any problems, especially since I am a beginner in PHP and I won't use any of the advanced functions that may be OS-specific. However, I would like to make sure since I really don't like Linux at all.
Some pointers:
Filesystem case sensitivity
If your file is called HelloWorld.php this:
include "helloworld.php";
is legit on Windows and will work. But Linux filenames are case sensitive, you can have files called HelloWorld.php, helloworld.php, hEllOwOrlD.php in the same directory. So you should develop on Windows as if you were developing on a case sensitive filesystem: use exactly the correct filenames, directory names, extension names - .php is also different from .PHP.
Directory and path separators
In Windows we say:
include 'classes\myClass.php';
But in Linux we would say:
include 'classes/myClass.php';
PHP is smart enough to not care, both separators work in both systems. But you should be consistent and go with the slash (/) everywhere as it's also the norm on most systems. There is a nifty predefined constant DIRECTORY_SEPARATOR that translates to the correct one, if you want to go that far:
include "classes" . DIRECTORY_SEPARATOR . "myClass.php";
The same goes for the path separator, which is semicolon on Windows, colon otherwise. So to be safe you should do:
set_include_path(get_include_path() . PATH_SEPARATOR . $path);
when in need of a path separator. Although most people think that since PHP doesn't mind which separator you use it's ok, but there is one important catch: The separators will be the system specific ones when you ask the system for directories or paths. So let's say you want to explode the include path into its parts:
$includePath = get_include_path();
$pathParts = explode(";", $includePath) // Will only work on Windows
$pathParts = explode(":", $includePath) // Will work on other systems but not Windows
$pathParts = explode(PATH_SEPARATOR, $includePath) // Will work everywhere!!!
File encoding and delimiter
You should set your IDE to set file encoding for all your scripts to UTF-8 instead of Cp*, and the file line delimiter to Unix ("\n" instead of "\r\n"). In most cases it won't really matter but you should be consistent and the best way is the Unix way (which works fine on Windows but not vice versa).
You cannot run strftime() with %e in Windows environment, as is noted in the manual page:
Not all conversion specifiers may be supported by your C library, in which case they will not be supported by PHP's strftime(). Additionally, not all platforms support negative timestamps, so your date range may be limited to no earlier than the Unix epoch. This means that %e, %T, %R and, %D (and possibly others) - as well as dates prior to Jan 1, 1970 - will not work on Windows, some Linux distributions, and a few other operating systems. For Windows systems, a complete overview of supported conversion specifiers can be found at » MSDN.
There won't be any problems running the code. If you do edit the files saved on Windows in Linux you might notice that the end of line characters might be different but it won't hurt anything. If it does bother you configure your windows IDE/editor to use Unix end of line.
Set yourself up with a Linux testbed. It could be a virtual Linux computer running under Windows, it could be a dual-boot computer, it could be a friend's system. Then, every once in a while (e.g. Monday mornings), port your code over to the Linux system and test it.
The other answers handled the primary problems you will face, but there are numerous smaller gotchas, like:
Yes, there are ways to carefully work around all of these differences, but were you careful to use the work-arounds? Of course not - you coded and it ran so it must be OK.
Don't put anything on a host computer until it has been tested on a similar operating system.
I have no experience porting from Windows to Linux, but I have some experience porting from Linux to Windows and more experience porting from Linux to OS X. It can be done, but the keys are is testing, testing, and testing.
Even though I'm fairly comfortable on the Linux command-line and with Linux editing tools like vim, I do most of my PHP development on a windows machine.
I have a virtual server on the internet (runs me about $20 a month) that I use as a development server, and I connect to it using FileZilla. FileZilla downloads the files I'm editing to a temp directory and keeps track of saves and when I save it throws it back up on to the dev server, and I test it from there.
It's a little cumbersome, but allows me to do the development pretty much anywhere; using FileZilla and a simple editor on a thumb drive I can even connect from another computer and make changes. All the testing is always on the Linux server, so I catch any problems I might have caused out of the box - fewer unpleasant surprizes when I throw the code onto the server.
You could do the same thing with a cheap hosting account (although depending on what sort of application you're developing you might run into performance issues since cheap hosting accounts are typically fairly underpowered) and other many FTP applications also have the edit-and-upload functionality.
Yes, it can be done, but several stuff you must consider. Check answers for more info.
Its one of those things, sometimes developers have to do, due to resources, not because they like it.
You may have a local web server (apache, cherokee, even M$), in your PC, and PHP server installed. And your PC, may not have a Internet connection, or only can connect for short periods of time.
Later you can update a real website, updating your file to the real server, with ftp tools, with the same PC or another PC, connected to the internet.
As most folks said there really should not be issues. That said, VirtualBox makes it really, really easy to stand up a linux virtual machine that you can test your codebase on to make sure it does work in the production environment without having said production environment handy.
