My apologies if this is by design, but in the current beta, the missing base href statement in the header is causing problems with using relative links to file names. I've experienced this with Bluemarine and another PHPTemplate theme. For instance, a node with URL http://example.com/node/3 rewrites relative filename of some.tag in an a href statement in the body of that node to http://example.com/node/some.tag. Same problem happens with URL aliased nodes.

Comments

killes@www.drop.org’s picture

killes@www.drop.org commented

Charlie, did you update your theme? Can you reproduce this with a standard theme?

cel4145’s picture

cel4145 commented

I just started building a brand new site, so I began with the 4.7 beta 6 download. No modifications to the standard Bluemarine theme, and it seems to be happening with all themes. (see following example for Bluemarine).

I've worked around it by adding in the base href statement in the theme template for antique-modern that I'm using. If it would help, contact me and I'll send you the URL and the root admin access to the site so you can take a look. 

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">

<head>
  <title>Home Page | Site</title>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<style type="text/css" media="all">@import "/misc/drupal.css";</style><link rel="shortcut icon" href="/misc/favicon.ico" type="image/x-icon" />
  <style type="text/css" media="all">@import "/themes/bluemarine/style.css";</style>  <script type="text/javascript"> </script>
</head>
deekayen’s picture

deekayen commented

A lot of discussion went into making it "by design": http://drupal.org/node/22218#base

cel4145’s picture

cel4145 commented

Okay. So then is Drupal supposed to correctly append user posted URL's in a node body with the correct path anyway?

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Status: Active » Closed (works as designed)

No... stuff in a node body is user-contributed content, which Drupal won't touch. A workaround for your situation may be to just add the <base> tag back in at the theme level.

Marking this "by design" since it is now. :\

cel4145’s picture

cel4145 commented
Status: Closed (works as designed) » Closed (fixed)

This will create a major usability issue for people who upgrade sites. For instance, anyone who has been using the upload module and then choosing to not list the attachments because they want to imbed the links in as hyperlinked text in the body or make an image display will have all of those links break.

Better be a warning in the upgrade file.

Marking closed.

gerhard killesreiter’s picture

gerhard killesreiter commented

Actually there is a database update which attempts to fix these paths. function system_update_178()

If this doesn't fix everything, please tell us.

cel4145’s picture

cel4145 commented

What does a user do in 4.7 when one wants to link to a file that has been uploaded? Use absolute URL's? That's a problem.

Personally, I don't understand the advantage of not having the base statement, but can see all kinds of problems with not doing so.

killes@www.drop.org’s picture

killes@www.drop.org commented

I think you need to prefix your file paths with /, ie /files/my_file.tex

WRT the base_href issue: I fully agree with you.

cel4145’s picture

cel4145 commented

thanks. that works.

i hope the payoff is worth it for this change. i can't even imagine how many support problems this will cause.

killes@www.drop.org’s picture

killes@www.drop.org commented

Probably a lot. I will leave these for the people who wanted this change...

cel4145’s picture

cel4145 commented
Status: Closed (fixed) » Active

I'm opening this back up since now it seems to be causing a problem for drupal.org since the upgrade. For example, try the links in the instructions at the top of the create book page and forum topic. Check the drupal.org admin logs page there are a lot more.

This should have been fixed by the upgrade script, right? The upgrade script will need to parse and look for all relative links without a "/" in front in any user/admin entered text that could contain HTML--nodes, user profiles, explanation or submission guidelines for content types, blocks, localization files, menus, etc. Is it doing this already and are certain things just being missed? If so, we should use Drupal's admin logs to tighten this up.

Steven’s picture

Steven commented
Status: Active » Fixed

Drupal.org contains some hacks where we use HTML when we shouldn't. The upgrade script only does nodes and comments. I manually fixed those links. It is IMO not the end of the world.

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)