I have a site which has been coded to take advantage of relative paths
which was coded this way to ensure the code was portable and could
be placed on any server in any directory with little or no config..

On my previous server the absolute path was something like

/home/myaccount/public_html/

All our code was stored in the above folder in a folder called 'Test' so the
full path would have been /home/myaccount/public_html/test/

There was an alias setup so that when linking from index.php i could simply
use '/news/article.php'

On *Mosso, i see the abosulute path is something like:

/mnt/Target01/my_user_prefix/myUrl/web/content/

However i cant link in the same manner..

To rewrite all my links to abolute paths is a nightmare as you can imagine, and mosso will not setup such an alias..

Does anyone know of a way around this? I.e. perhaps a config file which i could emulate an alias to the
test directory so i would not have to insert code / rewrite the entire site?

Who is Participating?

If you have access to the .htaccess file I mentioned earlier, you can specify PHP ini settings for that directory within the .htaccess file as follows:

php_value ini_directive value

So if you wanted to, you could, say, specify

php_value auto_prepend_file filename.php

to prepend the given file to EVERY PHP file opened under that directory as though it were included via an include() statement on the first line of the file. Doing so you could conceivably trap calls to include() and redirect absolute URLs to the appropriate ones. I've never done it, though, and it seems like it'd probably be more effort to implement and debug properly than just changing all the filenames, which could be done fairly easily using the find / sed method. There are Windows ports of both utilities, so you can download all your files locally, run sed on them, and upload again without needing access to a command shell on the server.

I'm not understanding entirely... /news/article.php is an absolute link. Or was it actually /home/myaccount/public_html/test/news/article.php?

This is a *nix box, right? If you're willing to play a little bit with sed, you can rewrite all the urls in a jiffy.

For instance,
sed -i 's:/news/article\.php:new_path/news/article.php:g' some_file.html
will search the file some_file.html for the regular expression "/news/article\.php", and globally replace all instances it finds with the text "new_path/news/article.php", saving the changes to the document.

To accomplish the same thing for all html files in the folder tree, use
cd /mnt/Target01/my_user_prefix/myURL/web/content/
find . -name '*.html' -print | xargs sed -i "s:/news/article\.php:new_path/news/article.php:g'

You can repeat that command as many times as you want for *.htm, *.php, *.asp, whatever.

But this will replace ALL instances, so if you have any links to other sites that include /news/article.php, they'll get changed, too.

You DEFINITELY need to backup your site before attempting to do this, though.

tar cfpz backup.todays_date.tar.gz *

will get the job done on the backup. And if something gets messed up on the site,

tar xfpz backup.todays_date.tar.gz

will fix the problem.

This is assuming you have access to a command shell and the sed and tar programs, of course.

0

moconnAuthor Commented: 2006-05-02

Hi there,

Thanks for your reply..

Unfortunatly we do not have shell access to our server..

We just need a simple elegant solution which involves changing as little code / files
as possible..

As such we created a site using relative paths which could be transferred to any folder and would work instantly as long as we could point the domain to the correct folder. This allowed us to have a test / production and live environment on the same server and easily test each.

As such we created a site using relative paths which could be transferred to any folder and would work instantly as long as we could point the domain to the correct folder. This allowed us to have a test / production and live environment on the same server and easily test each.

I must be misunderstanding something, still... Lemme talk my way through it, and you correct me if I get something wrong.

You have three versions of your site that run concurrently.

In /home/public_html/test, you have a development version, accessible logically via www.example.com/test/. On the old site, this was accessible via test.example.com
In /home/public_html/old, you have legacy code, accessible logically via www.example.com/old/, and on the old site was accessible via old.example.com
In /home/public_html/, you have the live, public site, which is accessible via www.example.com/.

You have certain things within each site version that you need to link to:
/home/public_html/news/*, replicated as /home/public_html/test/news/*, and /home/public_html/old/news/*
/home/public_html/include/*, replicated as /home/public_html/test/include/*, and /home/public_html/old/include/*
/home/public_html/phpbb/*, replicated as /home/public_html/test/phpbb/*, and /home/public_html/old/phpbb/*

And you want to be able to link to each resource in such a way that when you've reached a stable code version in /test/ you can copy the live version to /old/, and the /test/ version to / and have everything still work, right?

If not, all is not lost. If your webserver is running Apache and has .htaccess files enabled, you can specify rewrite rules in a .htaccess file to solve this problem. Specifically, something similar to the following lines, when placed in the /home/public_html/.htaccess file should solve your problem:

Also, the rewrite stuff given above only works dealing with URL rewriting. For PHP include statements, I don't believe there are any transparent config changes you can make to convert absolute to relative. Since absolute PHP include() paths are relative to the system root rather than the document root, you're going to have to change all of them anyway, since your document root has changed. This will be true regardless of whether the logical structure of your site has changed relative to your document root. Relative PHP include() paths should work as before without any modification, so long as your logical site structure hasn't been modified.