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.

  • 1
    Simple solution to your problem is a Linux VM with Samba running on a Windows host.
    – treecoder
    Commented Nov 16, 2011 at 14:46
  • Yes, it can be done, but several stuff you must consider. Check answers for more info. Its one of those things developers have to do, due to resources, not because they like it.
    – umlcat
    Commented Nov 16, 2011 at 17:36

7 Answers 7


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).

  • 1
    For strings where you might run into newline issues, PHP also includes the PHP_EOL constant which uses the correct newline character for the current platform. Commented Nov 12, 2011 at 5:09
  • 5
    People actually use backslashes in their paths in PHP/Windows? Even if i hadn't first used PHP on Linux, i'd avoid backslashes just because they're for escaping stuff.
    – cHao
    Commented Nov 12, 2011 at 5:19
  • 2
    Shouldn't it be "classes\\myClass.php"?
    – luiscubal
    Commented Nov 12, 2011 at 16:17
  • @luiscubal Yes since I'm using double quotes... Thanks for spoting that, edited to single quotes.
    – yannis
    Commented Nov 13, 2011 at 3:19
  • 3
    The Case Sensitivity and File Encoding are the two that always cause me trouble between Windows/Linux.
    – Rangoric
    Commented Nov 13, 2011 at 5:23

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:

  • the temp directory is in a different place
  • file and directory permissions are different
  • the system() function changes radicaly
  • The user name that Apache runs as changes
  • Things that work under Windows XP may fail under Windows 8.

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.