CiviCRM Community Forums (archive)

To partially answer my own question, I found where it happens, in civicrm.config.php:

    /**
     * We are within the civicrm module, the drupal root is 2 links
     * above us, so use that
     */
    $currentDir = dirname( __FILE__ ) . DIRECTORY_SEPARATOR;
    if ( file_exists( $currentDir . 'settings_location.php' ) ) {
        include $currentDir . 'settings_location.php';
    }

    if ( defined( 'CIVICRM_CONFDIR' ) && ! isset( $confdir ) ) {
        $confdir = CIVICRM_CONFDIR;
    } else {
        // make it relative to civicrm.config.php, else php makes it relative
        // to the script that invokes it
        // simple check to see if this is under sites/all or just modules
        if ( strpos( $currentDir, 'sites' . DIRECTORY_SEPARATOR . 'all' . DIRECTORY_SEPARATOR . 'modules' ) !== false ) {
            // seems like this is in drupal5 dir location
            $confdir = $currentDir . '..' . DIRECTORY_SEPARATOR . '..' . DIRECTORY_SEPARATOR . '..';
        } else {
            $confdir = $currentDir . '..' . DIRECTORY_SEPARATOR . '..' . DIRECTORY_SEPARATOR . 'sites';
        }
    }
 
    if ( file_exists( $confdir . DIRECTORY_SEPARATOR . 'civicrm.settings.php' ) ) {
        return $confdir;
    }
 
    if ( ! file_exists( $confdir ) && ! $skipConfigError ) {
        echo "Could not find valid configuration dir, best guess: $confdir<br/><br/>\n";
        echo "If this is a standalone installation (i.e. not a Drupal or ";
        echo "Joomla module) and you'd like to re-initialize it, ";
        echo "<a href=\"../install/index.php?mode=standalone\">click here</a>.\n";
        exit( );
However what I'd really like to know is what I can do about it, as in get the script to use the logical working path (as reported by `pwd`) instead of the absolute physical path (as reported by `pwd -P`). I guess it's all in the '__FILE__', but don't really know much at all about how this works, how PHP handles it and what, if any, alternatives there may be. Short of hard-coding the path.

Any clues?

TIA,

Ronald

P.S.: Found this in http://au.php.net/manual/en/language.constants.predefined.php :
__FILE__  The full path and filename of the file. If used inside an include, the name of the included file is returned. Since PHP 4.0.2, __FILE__
always contains an absolute path with symlinks resolved whereas in older versions it contained relative path under some circumstances.I guess it's a pointer, though not one I'm happy about. Is there a way to retrieve the path with symlinks intact?

Piotr,

Thanks for your tip - I tried it but it did not get me much further.

What you need is a settings_location.php file in your $civicrm_root with the following contents:

Code: [Select]

<?php
define('CIVICRM_CONFDIR', '/path/to/sites');


I take it that $civicrm_root would be something like /path/to/drupal-site/sites/all/modules/civicrm and placed the file there. Unfortunately CIVICRM_CONFDIR was still undefined in civicrm.config.php. It seems that this file is also read from the physical location where civicrm resides, i.e. with all symlinks resolved, because putting the file there (into the physical location of the civicrm code) did get past that error (producing another one). However this approach would not solve my issue because it obviously doesn't cater for the code being used in multiple locations.

This way you can have multiple CiviCRM instances inside one CMS (it sounds like the thing you’re looking for).

Not quite the thing I'm looking for, I'm just trying to use the same code in multiple CMS. As in running multiple instances of Drupal (all of course linked to the same code base), and using civicrm in more than one of them, via symbolic links to its code base. If that makes sense.
If not, I'm happy to draw it up - it's been working very nicely in every other respect so far and really seems like an elegant way to manage versions and modules, just having the trouble with imap2soap now.

Anyway, again many thanks for your suggestion.
Any other ideas, anyone?

TIA,

Ronald

Hi Piotr,

Thanks again for your comments.

Yes, it does make sense – and sorry for misreading the original post.

:-) I'm not sure whether my initial post was all that clear, so thanks for getting me to clarify that. ;-)

Given your investigation above – am I thinking in the right direction when I think that all this would work if civicrm.config.php instead of __FILE__ used something that does not resolve symlinks?

That's my impression, too - the proof is in the eating of the pudding but from what I can tell now it seems like that's exactly what I would need.

This way it could look at a different settings_location.php every time.

In fact I think if the other construct (__FILE__ replacement) was in place then the settings_location.php might quite possibly not be needed in the first place because civicrm.config.php would be seen in the right place.

I have looked around a bit at the PHP website and tried a few of the functions and variables that seemed related (like "PHP_SELF"), but the problem I ran into is that all of those I tried returned a symlinked path, alright, but unfortunately to the file that included civicrm.config.php, rather than to the latter. Now I manage to read PHP, mostly, and get a rough idea what the code does, but that's about as far as it goes, so I have no clue if there might be something better suited or how I could work around the problem.

I've been thinking whether something like this would work:
1. determine the physical path of the active file (the one that included civicrm.config.php)
2. compare the path with that from __FILE__ to determine the relative path between the two
3. determine the logical (symlinked) path of the active file, then
4. modify that using the relative path to the config file from step 2. to deduce the logical path

Because the files in question should all live in the same logical subtree, it might just work. Not sure how to get to the relative path (2.) and apply it (4.), though. It might be as easy as determining in step 2 how many characters to truncate from the end of the path and in step 4 just doing that, but I haven't fully thought through yet if that would work in all cases. (It would certainly not be a generic solution but perhaps work with the way the civicrm directories are organised, with civicrm.config.php at the root level.)

Or there might be a PHP standard function to return the symlinked path; surely I am not the first or only one who would like to use that value. (Or am I?  ;-)).

Many thanks,

Ronald

Hi Piotr,

Quote from: ronald on August 19, 2008, 05:19:06 am

I have looked around a bit at the PHP website and tried a few of the functions and variables that seemed related (like "PHP_SELF"), but the problem I ran into is that all of those I tried returned a symlinked path, alright, but unfortunately to the file that included civicrm.config.php, rather than to the latter.

Ah, I see. I played around with a trivial index.php that included another script that contained phpinfo(), and indeed __FILE__ resolves the symlinks, while all the other report the location of the index.php file (rather than the included script).

Quote from: ronald on August 19, 2008, 05:19:06 am

I've been thinking whether something like this would work:
1. determine the physical path of the active file (the one that included civicrm.config.php)
2. compare the path with that from __FILE__ to determine the relative path between the two
3. determine the logical (symlinked) path of the active file, then
4. modify that using the relative path to the config file from step 2. to deduce the logical path

From my scans of the phpinfo() output, the only method that returns fully-resolved path it __FILE__, which can’t be easily compared with SCRIPT_FILENAME (symlinked path), as the former represents the ‘innermost’ script, while the latter represents the ‘outermost’ (in our case it’d most probably be Drupal’s or Joomla’s index.php).

Ok, I was assuming that symlinked paths could always be dereferenced, somehow.
If one would dereference the "outermost" path with something like realpath, shouldn't it then be comparable with the result of __FILE__?

If there was an ‘outermost’ counterpart to __FILE__ (or an ‘innermost’ SCRIPT_FILENAME), you could indeed explode() the two on DIRECTORY_SEPARATOR and compare the two arrays in some sane way, but I couldn’t find either of these counterparts.

Not sure about the "exploding" - I'd probably just do a string comparison, hoping that in the case we're looking at one string would be a substring of the other, and the remaining part the relative path from one to the other. Of course that might be too simplistic but right now I don't see why it would be.
Strange, that "innermost" paths are only returned fully dereferenced (with __FILE__) while "outermost" only symlinked - I wonder why that is...   

Quote from: ronald on August 19, 2008, 05:19:06 am

Or there might be a PHP standard function to return the symlinked path; surely I am not the first or only one who would like to use that value. (Or am I?  ).

I tried googling for this, but didn’t find anything – the fact that there’s a PHP symlink() function (for creating symlinks) doesn’t actually make this any easier…

Yes, I encountered the same thing...   

Many thanks again,

Ronald

Hi Piotr,

Quote from: ronald on August 20, 2008, 07:43:20 am

Ok, I was assuming that symlinked paths could always be dereferenced, somehow.
If one would dereference the "outermost" path with something like realpath, shouldn't it then be comparable with the result of __FILE__?

Ah, you’re right – but you should not compare dereferenced SCRIPT_FILENAME with __FILE__, you should compare it with non-dereferenced itself (this way you’ll get two paths to the same file, one symlinked, the other absolute).

This might be another way to get the same result. I was thinking about comparing the dereferenced directory paths of the two files to get the relative path between them, which should be the (string) difference of those two paths. And then applying that difference to the non-dereferenced path to deduce the unknown other non-dereferenced path.

I get the feeling that an example would help. 
And also I should have noted that I implied that we look at the actual directories the files reside in, i.e. the paths without the actual files.

So what I have in mind is something like this (in fact this is a simplified version of my working setup):
~/repository/civicrm/with/subdirectories
~/drupal-site/sites/all/modules/civicrm -> ../../../../repository/civicrm
So as civicrm.config.php resides in the civicrm root, __FILE__ returns
/path/to/home/repository/civicrm/civicrm.config.php,
and php_info returns for example (it actually does for me)
/path/to/home/drupal-site/sites/all/modules/civicrm/extern/soap.php.

Dereferencing that path would yield
/path/to/home/repository/civicrm/extern/soap.php

Now reducing the strings to directory paths would give
/path/to/home/repository/civicrm
and
/path/to/home/repository/civicrm/extern
so the first one is completely contained in the beginning of the second, and the second is seven characters longer.

Taking the non-dereferenced directory path
/path/to/home/drupal-site/sites/all/modules/civicrm/extern
and shortening that string by seven characters gives
/path/to/home/drupal-site/sites/all/modules/civicrm
which is exactly what I need.

As I said, this may well be too simplistic, but right now I don't see how it could fall over (given the limited application to the structure of the civicrm tree).

Quote from: ronald on August 20, 2008, 07:43:20 am

Not sure about the "exploding" - I'd probably just do a string comparison, hoping that in the case we're looking at one string would be a substring of the other, and the remaining part the relative path from one to the other.

I haven’t really thought this through, but if you want to create a relative path, don’t you need to know how many directories you stripped (so you can create the ../../.. part of the path)?

I guess you would if you wanted to traverse that path in the other direction. However I just don't want to go there in the first place, if you know what I mean.

The idea is my head is:

1. explode() the paths on DIRECTORY_SEPARATOR,
2. remove the common initial elements from the two arrays,
3. for either array, the number of elements – 1 is the number of .. elements you need to add to the beginning of the other array to get a relative path,
4. after adding this many .. elements, implode() the other array on DIRECTORY_SEPARATOR.

Does this make any sense?

I guess it does, though as someone not well-versed in PHP I'll have to make a few assumptions to follow you.
For example about what exploding and imploding does. Do I understand it right that exploding splits a string into an array? And implode assembles an array into a string with the given delimiter between the elements?

Still, wouldn't it make sense to rather just omit the subdirectories that are traversed by the inclusion, rather than climbing up (or down, depending on your paradigm) into them, and then back with ..?

I'm just asking - in the end I don't really mind which method to use as long as it works. Still can't quite believe that one would have to jump through all those hoops in order to have a kludge for a non-dereferencing version of __FILE__.

Anyway, what do you think?

Many thanks again,

Ronald

Hi Piotr,

You should definitely trust your feelings.

Now that's sound advice - and quite unexpected in a software forum! 

Ah, I get it now. I’m running a developer setup where the Drupal installs live under /var/www, while the CiviCRM codebases live under /home/shot, so I was assuming situations where symlinked and dereferenced paths do not necessarily have anything in common.

As I see it that should work just the same, with something like
/var/www/sites/all/modules/civicrm -> /home/shot/whatever/civicrm
or
/var/www/sites/all/modules/civicrm -> ../../../../home/shot/whatever/civicrm
and the same method as before.
The thing that matters is if the physical directory from where the inclusion is made is a subdirectory of the physical directory where civicrm.config.php lives; not whether the physical and logical civicrm root directory paths have anything in common at all.

Quote from: ronald on August 21, 2008, 08:33:43 am

I'm just asking - in the end I don't really mind which method to use as long as it works. Still can't quite believe that one would have to jump through all those hoops in order to have a kludge for a non-dereferencing version of __FILE__.

Having been working with PHP for the past eight years or so, this doesn’t surprise me very much, unfortunately. (That’s why I write my PhD in Ruby.)

BTW: It seems getcwd() returns __FILE__’s directory (without the need to strip off the file name).

It does return a directory, but that of the active file including civicrm.config.php rather than __FILE__’s.
That can be had with dirname( __FILE__ ), as demonstrated in that same file.

I’m not having the best of my days today, but it does seem you got it more or less nailed (at least for your case).

... good one (I don't feel much different right now)...

Can you try hacking civicrm.config.php’s conf_init() (and, perhaps, utilising Drupal’s includes/bootstrap.inc’s conf_path() – we seem to do this in drupal/civicrm.module) to get it working for you, and if it does, open an issue and attach your patch?

Now that's daunting!
I have a good idea of the functionality I want, but never written a line of PHP other than an echo here or there, and you're saying I should modify two core pieces of both civicrm and Drupal and submit my changes as a patch?
I might be able to work out how to retrieve the paths and manipulate the strings but am only thinking in the context of my own use-case - no idea what would be involved to make this generic.
And then, how probable is it that the maintainers of the code actually want the stuff to work "my" way?

Oh well. On we go to eat our own dogfood, I mean make our own catfood, um, cheezburger?   

How's this:

replace line 58:

    $currentDir = dirname( __FILE__ ) . DIRECTORY_SEPARATOR;
with

    /**
     * Determine physical location of this file
     * as well as physical and logical location (with symlinks)
     * of the including file; set default to physical location
     */
    $physConfDir = dirname( __FILE__ );
    $physCurrentFile = getcwd();
    $logCurrentFile = dirname( $_SERVER['PATH_TRANSLATED'] );
    $currentDir = physConfDir;

    /**
     * Check if we're included from a subdirectory
     */
    $pathMatch = strpos( $physCurrentFile, $physConfDir );
    if( $pathMatch === FALSE ) { // looks odd, stay with default
    } else {
        if( $pathMatch == 0 ) {  // we're included from a subdirectory
            $relPathLen = strlen( $physCurrentFile ) - strlen( $physConfDir );
            $currentDir = substr( $logCurrentFile, 0, ( strlen( $logCurrentFile ) - $relPathLen ) );
        }
    }
    $currentDir = $currentDir . DIRECTORY_SEPARATOR;

If that code is acceptable for a patch is another question, but it seems to work for me.
Now I'm getting my next error, but I guess that's something for another thread.

Cheers,

Ronald

[Edit] P.S.: I now notice you asked if I could utilise Drupal's conf_path() to do my task.
I think I cannot, firstly because I don't have the slightest clue what that function does and how it does it, even after staring at it for some time. Secondly, wouldn't using that function require Drupal to be active in order for the fix to work? Is that something I can assume? I guess not - the imap2soap script, for one, is not called from within Drupal, and then there's the civicrm standalone (though that's not covered by my fix above, either, but could be made to). Or am I missing something?

The thing that matters is if the physical directory from where the inclusion is made is a subdirectory of the physical directory where civicrm.config.php lives; not whether the physical and logical civicrm root directory paths have anything in common at all.

This is what I meant – in my case, civicrm.settings.php files live in /var/www, while the checkouts live in /home/shot. But I agree, they may as well live in /home/shot, if only civicrm.config.php finds them.

I have refined my code to also double-check that indeed the last bit of the logical path matches the last bit of the physical path that has been determined to be the relative path between the included and including files. And submitted as issue CRM-3444.
I hope you're proud of me.

I’m very, very proud – I know how it feels to patch a core file of an application in a language you’re not really familiar with.

I appreciate the patch very much – at the moment, our trunk’s civicrm.config.php is a bit broken, but once it’s fixed I’ll be more than happy to apply the patch.

Thanks a lot for the discussion and the resulting patch.