$_SERVER["PHP_SELF"] helps a little.

$_SERVER['PHP_SELF'] only relates to the main script, not the currently included file. It's useful, but a completely separate issue.

There is, as far as I can see, no way to get the non symlink resolved path of the currently included file.

If there is no security issue, Why don't PHP make life easier ?

I have the same problem with PHP. I have a slave site that shares most (but not all!) code with a master site using symlinks. The code consists of CLI scripts, web pages, and includes (one of which is a common include for setting up the include_path and error handling). It is critical that this include_path refers to paths in the slave site even though the real common include resides in the master site. I can't achieve this using __FILE__ unfortunately due to the symlink resolution problem. It would be nice to have an alternative to __FILE__, perhaps __LINK__, with unresolved symlinks. Please PHP developers add this!!! PHP needs it so much and it must be a very simple thing to add.

In the mean time, I've created a function in the common include that jumps though hoops in order to set the include_path correctly by using argv[0] in CLI scripts (and traversing up until a htdocs dir is found) or else $_SERVER['DOCUMENT_ROOT'] in web scripts. It's horrible, but the only solution I've found so far.

Another vote for this. The current implementation does not seem like the proper way to treat symlinks, and it makes sharing included files between directories very difficult.

I understand that changing this now has the potential to cause breakage in scripts that depend on the current behaviour. But there really does need to be a way for a file to find its own effective location.

+1 for this. I encountered this issue today and was hoping that there's a better 
way not to resolve symlink in __FILE__. As suggested above, perhaps __FILE_LINK__ 
that either return the symlink path or false if none.

I agree. Hosting multiple PHP systems based on the same installation is no easy task, when __FILE__ is used in conjunction with symlinks. Very frustrating. I vote for a new contant; __FILEPATH__ which does not resolve symlinks.

I think I have a resoulution ... use $_SERVER["SCRIPT_FILENAME"] instead of __file__. It should work the same way, but is absolute path, not resolved. It works for me fine :-)

$_SERVER["SCRIPT_FILENAME"] cannot be used in place of __FILE__ as it does not 
resolve the path of an included file.

Eg,

// file1.php
include 'file2.php';

// file2.php
echo $_SERVER['SCRIPT_FILENAME'];

Executing file1.php will result in "/path/to/file1.php"

I'm another +1 for this, causing me some real headaches because for deployment I store multiple versions of a site with the latest been symlinked to for apache.

There are modules in the application which are licensed and use the file path as part of it's verification. When we deploy, the path is seen as changed and the modules get disabled. :-(

+1

If you're on an enviroment with bash available, you can use this snippet to get 
__FILE__ without resolving symlinks.

It's a small hack, but it should be pretty safe.

<?php
$output = array();
exec('pwd', &$output);
define('__LINK__', $output[0].substr(__FILE__, strpos(__FILE__, 
DIRECTORY_SEPARATOR)));
?>

I tested monsen.dag's suggestion and it produced a completely different result than expected. Also, defining a constant will only apply once, not to the *currently executing file*, which is the great advantage of __FILE__. This suggestion does not provide a solution of any kind as far as I can tell.

+1 too. I really need this feature.

In windows 7 realpath for a file that is accessed through a mklink folder does return the link path not the absolute one.

So nothing is being done about this issue?

It seems to have been an issue for at least 6 years without
a adequate solution. 

The behaviour of the __FILE__ constant seems in violation 
of convention and what developers would expect from it.
This bug (yes, bug) prevents us from keeping code (like 
wordpress and a theme) in their own repositories in e.g.
Git (cannot checkout sub-folders - git submodules would 
only work if you didn't want to keep theme build, 
documentation etc. files versioned in the repo). 

I really don't get why this behaviour is not at least configurable.

What is the use case of resolving symlinks? 
I suspect no one would be able to find a use that couldn't
be done in a better way.

After 4 years of bug report, this issue still remains.  Unbelievable.  It's such 
a small change to make the behaviors more consistent (and correct), and helps 
simplify developer's life.

No flamebait here, but no wonder PHP is like a dead language, with most people 
move on to other languages, Python, Ruby, to name a few, while those who are 
stuck with PHP for Wordpress and other sites, suffer.

@alex at wordnik dot com

It is required as part of the require/include_once function. Sources file paths 
are always resolved. It is not a bug but a design choice, which allows many 
optimization.

That being said, anyone using symbolic links in prod across different sites 
should reconsider this choice as well.

Let close this bug and mark as duplicated.