I must say that the 4.6 to 4.7 series move has been the biggest, in terms of time spent anticipating when to upgrade and dealwith all the accompanying problems, that I have seen here since I have been a member. I have been fiddling with 4.7.0 from the beginning of it's first beta all the way to now. What a ride. I lost track of the changes and bugfixes. It's awesome software. However, one particular thing that is irking me now are relative paths. Earlier I knew where I stood. You plug in your base url into the settings page and boom...everything worked. Even with legacy data. Not so in 4.7, at least with egacy data.

As can be seen here: http://drupal.org/node/51382, here: http://drupal.org/node/13148#comment-77673, and here: http://drupal.org/node/51612 this is an ugly little problem.

Two immediate issues I have. First, all internal links created by users pointing to other internal pages are broken. Nasty.Second, when the source code of each page is viewed in a browser, you get Login instead of Login, which I natrally do not want. In other words, the folder where things live is being shown.

I have read all about this in the changelogs, particularly for themes. Can someone PLEASE tell me how to just get things working(just the links and paths).

Bèr Kessels has been kind enough to offer this patch "phptemplate_engine_add_base_url_0.patch" here http://drupal.org/node/51612. Only problem is, I do not know what is meant by putting the "base tag" on the "page.tpl.php" page. So I can't even test it. What exact tag and where exactly on this page? Any help would be appreciated. My prediction is people with reams of legacy links who upgrade to 4.7 will be very unpleasantly surprised, unless of course, an easy to implement solution is there. From all the posts I've read, and I've spent many, many hours(yes, I'm embarassed!) on this, there is not yet one available. Any
help is appreciated. Am I missing something?

thanks,

larry

Comments

tvst’s picture

you can go into your theme file and add the following line inside your "head" section:

[base href="http://www.your-url.com/" /]

and substitute the square brackets for angle brackets. drupal isn't letting me add angle brackets, even if it's inside "code" statements, it's complaining that it's suspicious data. :-/

tvst’s picture

if you're using a php template theme, the file to edit is "page.tpl.php"

larry’s picture

I put that within the header in page.tpl.php page and it solved one problem...internal links work. However, the actual base_url is still weird when viewed within source code in a browser. It's as if the base_url is working, but the relative path is not being shown. The top level directory is still being shown. Any ideas on how that is solved? I just don't want my directory structure being shown. By the way, do you know of an "official solution", I'm just curious. However, I'm VERY grateful for your help. Your solution solved my internal links problem very nicely.

thanks again,

larry

--There are no Kangaroos in Austria--

tvst’s picture

First, you should put this in your page.tpl.php instead of what i said earlier:

<base href=" <?php print $base_url . $base_url_path ?>" />

It's just a bit cleaner.

Secondly, I'm not sure what you mean by "still weird when viewed within source code". Can you give an example?

I think (don't know for sure) the "official solution" is not to use relative URLs. The problem is that while module developers can easily adapt to the new way of things, the same does not happen for users. So, maybe someone should make a filter that translates relative urls to absolute.

larry’s picture

The new code does not work. Actually, I saw the above code in another posting and tried it to no avail. Is it correct? I placed within the head tag on the page.tpl.php page. It destroyed the url and the css sheets were'nt read and nothing worked.

What I mean about "weird within source code" is the paths presented are NOT relative and the top level directory is shown. An example is, right click your mouse (or keyboard) now, choose "View Source" and click. Within this source code the paths are not relative as with earlier Drupal versions. The top level directory is visible instead of ONLY the url path. Thanks again for your reply. Incidentally, why did the developers drop the base tag? I've read much about this but have not seen this question answered.

thanks,

larry

--There are no Kangaroos in Austria--

larry’s picture

I've been fiddling around trying to figure out exactly what I feel my problem is. My conclusion is that in earlier versions of Drupal if your base url was a sub-directory such as "foo/bar/drupal" then this entire path would be treated as the base url within setting.php and relative paths would appear AFTER this base url path without revealing it, as in 'a href="user/login"', where "user/login" is the relative path. Now however, with 4.7.0-beta5 this would be 'a href="foo/bar/drupal/user/login"' because the base url lives within a sub-directory. If, you put drupal within, say, htdocs, without any sub-directories being used...everything is as in earlier Drupal versions. I suspect the new "base_path" that is being used is responsible...I'm not certain though. Regardless, without placing the additional code, the first example NOT the second, within the page.tpl.php, internal links don't work. Is this normal, expected behavior?

cheers,

larry

--There are no Kangaroos in Austria--

tvst’s picture

"The new code does not work. "
oops, i see what i got wrong. those variables aren't mapped into your template. the line below should work:

<base href="<?php print $base_path ?>" />

- - - - - -

"why did the developers drop the base tag?"
all i know is what they are saying here

- - - - - -

"i've been fiddling ..."
is see what your issue is. you do not want people to see the absolute path at all, in any link. the solution i have is not very advisable, since it involves changing a core function, but here it is:

go into common.inc and modify the function base_path() (around line 1123) this way:

function base_path($allow = false) {
     return ($allow)? $GLOBAL['base_path'] : '';
}

and anywhere you DO want the absolute path, you should use base_path(true). for example, you need to do so in phptemplate, line 187:

'base_path'     =>      base_path(true),
Kobus’s picture

Using Beta 5, if I do this, the following happens:

?php // $Id: phptemplate.engine,v 1.29 2006/03/01 14:33:18 dries Exp $ /** * @file * Handles integration of templates written in pure php with the Drupal theme system. */ function phptemplate_init($template) { $file = dirname($template->filename) . '/template.php'; if (file_exists($file)) { include_once "./$file"; } } function phptemplate_templates($directory = 'themes') { return system_listing('^page\.tpl\.php$', $directory, 'filename'); } /** * Declare the available regions implemented by this engine. * * @return * An array of regions. The first array element will be used as the default region for themes. */ function phptemplate_regions() { return array( 'left' => t('left sidebar'), 'right' => t('right sidebar'), 'content' => t('content'), 'header' => t('header'), 'footer' => t('footer') ); } /** * Execute a template engine call. * * Each call
... *ad infinitum*
-- Kobus

larry’s picture

Hello tvst,

I appreciate all the solutions you're offering. I tried this:

<base href=" <?php print $base_path ?> " />

and it also did not work.

For the life of me, I don't know why. Your solution in the common.inc is interesting. I see why you don't advise it and I certainly agree. However, it sheds some light on how the new $base_path works. Besides, when 4.7.0RC is finally released, everything will probably have changed again.

Thanks for the explanation link. I've seen that earlier, however it raises more questions than it answers. Do you have any idea why the code snippets you so kindly provide are not working within my setup? Do you have these snippets working with beta-5? I am certain your code works, I'm just trying to find out what I am missing on my end. It will be interesting to see what happens when drupal.org is upgraded to 4.7.0 and what solution they use.

cheers,

larry

--There are no Kangaroos in Austria--

tvst’s picture

If you right-click and choose "view source", do you see the base element anywhere? what does it say? I don't have a 4.7 installation to tinker with (and I'm too lazy to set one up :)....

sangamreddi’s picture

Even i am having the similar problem. If you find a solution post it here, me do the same too.

edit: I forgot to add some info, the issue being discussing here http://drupal.org/node/13148

Sunny                      
www.gleez.com | www.sandeepone.com

tvst’s picture

i need an example of a page where this isn't working. i just want to look at the source, and see if there's anything out the ordinary. because i believe page.tpl.php uses the $pase_path variable somewhere else, so if this isn't working then that shouldn't work either. and the rendered page's source will tell me.

larry’s picture

Hello tvst,

I'm still plugging away. I greatly appreciate your efforts (and curiosity needed to solve a problem!) at putting this issue to rest. Right now, I'm running 4.7.0-beta3 and have not upgraded to beta5 because of this issue. My beta5 setup is on a computer behind a rather large university firewall. What's interesting about this is that when the drupal base install is in the 'htdocs' directory, everything is as normal. In sub-directories...the problem starts. Do you believe it's due to the scrapping of the '$base_url'? If you like, I can email you a copy of the source to look at. Thanks again.

cheers,

larry

--There are no Kangaroos in Austria--

tvst’s picture

"If you like, I can email you a copy of the source to look at"
Sure, you can do that. My address is thiago at the domain varal.org.

"Do you believe it's due to the scrapping of the '$base_url'?"
No, I don't think that has much to do with it. If you look at the source for the phptemplate engine, you'll find that line 187 says

'base_path' => base_path(),

which means that the variable $base_bath should be available for use within your *.tpl.php files. Why exactly it isn't working can only be told by looking at the html output.

It could be that the core function base_path() is broken, but I find that very hard to believe. It could also be that more than one base tag is being printed out, and the second one is the one that ends up being valid. Of maybe it's a third alternative where I have no idea what the deal is :)

"I greatly appreciate your efforts"
well, i *am* going to have to upgrade soon :)
plus, i have to wait for people to help me solve my own upgrade issue, so this is a good pass-time.

tvst’s picture

well, i haven't gotten an email from you so far, so i just wanted to confirm that you, in fact, didn't send one.

or hopefully beta 6 fixed your issue

larry’s picture

Hello tvst,

I sent an email to you...actually a rather long one. I'm going to send it out again now. Thaks for posting here as I was wondering what was wrong.

cheers,

larry

--There are no Kangaroos in Austria--

larry’s picture

Confirmed sent. Hopefully this one will get through!

larry

--There are no Kangaroos in Austria--

notsleepy’s picture

I don't get why the base tag exists at all. Why aren't all url's just relative starting with / ?

If that were the case then I could just point my browser to :
http://mywebdesignersmachinename and see how his work is coming. Currently because of the base tag all css and images are referencing localhost. And when we deploy it to the live server it'll have to change again.

Ariadoss’s picture

<base href="<?php print base_path() ?>" />

I just tested this on an upgrade from 4.7 beta to 4.7 RC2, and even though the actual HTML output doesn't look correct, it works, it solved my theme problem when the URL was deeper than one level on my personal Drupal installation at http://danilo.ariadoss.com/

Edit:
Nevermind, I think it would be better just to specify the path as per the directions on this page:
http://drupal.org/node/22218#base