web address != to physical directory, install problem

raeky -- on Jul. 31 2004

I'm trying to install YACS but I can't seem to configure it. I have it installed in the subdirectory 'blog' in my ftp, but that directory maps to the sub-domain http://blog.raeky.com.

YACS at install translates its physical directory on the system correctly, but it generates the urls as http://blog.raeky.com/blog/ which is invalid. I never get past the control/configure.php page.

Most systems use seperate variables for the physical server directory of the files from the accual web address for the urls. Is YACS normal in this way? All I find is the $context['path_to_root'] variable that seems to do both, since my install is a bit different, the same variable won't work.

Any suggestions?

Page bottom

Bernard from nearby-an-airport Associate, 6696 posts	on Jul. 31 2004 Raeky, YACS already has two different variables to address this issue. `$context['path_to_root']` is used to handle files. Its content is computed automatically by locating the file `shared/global.php` relative to the current working directory. `$context['url_to_root']` is used to build web references. You can set its value in the main configuration file, from the script `control/configure.php`. When the web address and the physical directory are different, like in your case, you should specify the web address during the setup process in the main configuration panel. By default the default web address is `/yacs/`. In your case it should be changed to a single slash `/`. Hope it helps. By the way, the home page of your site is really funny.
Raeky 5 posts	on Aug. 1 2004 The problem is the 'control/configure.php' won't ever submit. The html configure.php generates has a form action of: action="/blog/control/configure.php" It should be '/control/configure.php' Can it not use the $_SERVER["SCRIPT_URI"] variable to determine how to reference it's self? Personally this dosn't seem to be to hard of a task for a php script to know that, I've written quite a few. Modifying the '$context['url_to_root']' variable in configure.php causes include errors, so '$context['url_to_root']' is definitely being used for location to files, not just building urls. Yea, my avatar in that game is a little different looking.
Raeky 5 posts	on Aug. 1 2004 I found the problem. When the configure.php file is loaded $_REQUEST has these varibles set: [PHP_SELF] => /blog/control/configure.php [PATH_INFO] => /blog/control/configure.php [SCRIPT_NAME] => /cgi-bin/php [REQUEST_URI] => /control/configure.php This PHP install is running as a cgi script, not an apache mod. The first 3 are used in the following snipit of code from 'shared/global.php' // the url to be used for self-referencing in forms if(preg_match('/\\.php$/', $_SERVER['PHP_SELF'])) $here = $_SERVER['PHP_SELF']; elseif(preg_match('/\\.php$/', $_SERVER['PATH_INFO'])) $here = $_SERVER['PATH_INFO']; elseif(preg_match('/\\.php$/', $_SERVER['SCRIPT_NAME'])) $here = $_SERVER['SCRIPT_NAME']; $context['self_url'] = $here; In the 'control/configure.php' the form action is set via `action="'.$context['self_url'].'"` The `$context['self_url']` is equal too `[self_url] => /blog/control/configure.php` Given all the variable values above `preg_match('/\\\\\\\\.php$/', $_SERVER['PHP_SELF'])` will evaulate as true, and 'self_url' will be set to the value of `$_SERVER['PHP_SELF']` The PHP documentation on the predefined variable PHP_SELF is: " The filename of the currently executing script, relative to the document root. For instance, $_SERVER['PHP_SELF'] in a script at the address http://example.com/test.php/foo.bar would be /test.php/foo.bar. " This obviously isn't accurate when your useing a subdomain, because it maps relative to the document root, in this case the document root is is / and the script is running at /blog. But because of the sub-domain mapping that isn't the url to access the files. I belive a safer version of self-discovery for the 'self_url' would be to use the following predefined variables: [SCRIPT_URL] => /control/configure.php [REQUEST_URI] => /control/configure.php Variables that shouldn't be used, because they are useless for CGI installs of PHP are: [SCRIPT_NAME] => /cgi-bin/php [SCRIPT_FILENAME] => /cgi-bin/php A clue that php is being run as CGI: [GATEWAY_INTERFACE] => CGI/1.1 A clue that a sub-domain is being used: [HTTP_HOST] => blog.raeky.com [SERVER_NAME] => www.raeky.com [SCRIPT_URI] => http://www.raeky.com/control/configure.php And on a side note the editing of these comments has some other bugs. I tried to use the php block to highlight the bit of code I quoted but when I enclosed the code in the tag it just deleted it. Also your not stripping the slashes when you display the text in the edit box. "preg_match('/\\.php$/')" that phrase when you edit the text and save, it will contiune to add slashes (you can see above an example of it with a few edits in, lots of slashes).
Raeky 5 posts	on Aug. 1 2004 Gah... this is hopeless... YACS isn't designed to run on a subdomain. You use `$_SERVER['SERVER_NAME']` everywhere. As I established above that isn't a variable one should use, since its not always accurate. Quoted from PHP manual: " 'HTTP_HOST' Contents of the Host: header from the current request, if there is one. " If this variable exists it should always be used over 'SERVER_NAME'.
Bernard from nearby-an-airport Associate, 6696 posts	on Aug. 1 2004 " 'HTTP_HOST' ... If this variable exists it should always be used over 'SERVER_NAME' " Until now I was relunctant to use HTTP_HOST because it is mandatory only for HTTP 1.1 compliant agents, and because it is set by the browser itself. Since your last comment I will: replace in all scripts all references to $_SERVER['SERVER_NAME'] to $context['self_name'] (about 340 code changes) set $context['self_name'] in shared/global.php with $_SERVER['HOST_NAME'], if it exists, or with $_SERVER['SERVER_NAME'] Please let me a couple of days to achieve this and to test these changes at some up and running sites.
Bernard from nearby-an-airport Associate, 6696 posts	on Aug. 2 2004 Also, regarding your suggestion for $context['self_url'], i will test following update of shared/global.php during coming days: // the url to be used for self-referencing in forms if(preg_match('/.php$/', $_SERVER['SCRIPT_NAME'])) $here = $_SERVER['SCRIPT_NAME']; elseif(preg_match('/.php$/', $_SERVER['SCRIPT_URL'])) // not SCRIPT_URI !!! $here = $_SERVER['SCRIPT_URL']; elseif(preg_match('/.php$/', $_SERVER['REQUEST_URI'])) $here = $_SERVER['REQUEST_URI']; elseif(preg_match('/.php$/', $_SERVER['PHP_SELF'])) // for PHP as CGI $here = $_SERVER['PHP_SELF']; $context['self_url'] = $here;
Bernard from nearby-an-airport Associate, 6696 posts	on Aug. 2 2004 Raeky, Unfortunately you are the very first person able to explain me so clearly what issues are with virtual hosting. Please be assured that I will do my best to adapt YACS to your needs.
Raeky 5 posts	on Aug. 2 2004 Not a problem, I have a billion other things to do. But I'd like to get YACS running someday. Thanks for your time in fixing these problems. Another option that alot of php systems use is to just have two variables that the user can set in the config file.. one to absoulte path to files and another to absolute uri for the root. If they exist then you could just skip all the self-discovery code and use what the user supplied. Usualy these optional variables are commented out in the config file and the user can uncomment and set them if they have trouble with the self-discovery.
Bernard from nearby-an-airport Associate, 6696 posts	on Aug. 2 2004 " I'd like to get YACS running someday. " Raeky, would you like to go to scripts index, download the archive posted today, and check it please? If this release suits you, I will make it the next official archive for YACS new installations. Thank you for your feed-back.
Lasares from L'Île-Bizard à Montréal, Québec 697 posts	on Nov. 21 2006 I am commenting on an old post, but I have a problem that is somehow similar. I installed yacs at the root of a subdomain (say subdomain.domain.com) and when I access it trough the web (typing http://subdomain.domain.com), I do get the index.php page, but without any formating. And nothing else works either. This is because yacs is looking for the skin at "/subdomain/skins/joi/joi.css", whereas it should be looking for it in "/skins/joi/joi.css". Same with all the other files, obviously because it is the "path_to_root" that is incorrect. I don't master all the intricacies of this, and I probably did something wrong in the installation (altough I got it right the first time, when I installed yacs in another subdomain). My question is : can I do something (like manually alter a file ) to get everything going or do I have to reinstall ? Thanks for your advice.
Bernard from nearby-an-airport Associate, 6696 posts	inspired from Lasares on Nov. 21 2006 Lasares: Yes, you have to change the 'url_to_root' parameter, through some manual edit of the `shared/parameters.include.php` file.
Lasares from L'Île-Bizard à Montréal, Québec 697 posts	on Nov. 21 2006 Bernard : Done, I am closing this line, keeping with the French one at Comment modifier 'root_to_path' après l'installation Thanks Edited by Bernard on Nov. 22 2006

12 comments

Rate this page
Posted by Raeky on Jul. 31 2004, edited by Bernard on Jul. 31 2004, (popular)