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
this is not the official way to handle things, but
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. :-/
oh, and
if you're using a php template theme, the file to edit is "page.tpl.php"
I appreciate your help...
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--
Two things
First, you should put this in your page.tpl.php instead of what i said earlier:
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.
The new code does not work.
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--
sub-directories appear different
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--
a few things
"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:
- - - - - -
"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:
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:
No go...
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
thanks for your new solution...
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--
Not sure why this doesn't work
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 :)....
No ideas
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
does anyone have a link?
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.
unfortunately my site is not yet on the web
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--
"If you like, I can email
"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.
no emails...
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
no, no, no...
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--
just sent out...
Confirmed sent. Hopefully this one will get through!
larry
--There are no Kangaroos in Austria--
I don't get why the base tag
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.
It works perfectly fine in RC2
<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