Changes in base href in 4.7: usability issue for Drupal?

That would have been Morbus at http://drupal.org/node/13148#comment-69231.
--
Tips for posting to the forums.
When your problem is solved, please post a follow-up to the thread you started.

I have been testing the base element for a few days now.

In page.tpl.php of my theme, I put in the header :

<base href="http://www.myWebSite.com/" />

About the issues you report.

1. Named links don't work indeed. After adding back the base element in my Drupal 4.7.4 installation, I realized that all collapsible fieldsets (such as in the node edit page) make use of the "href" node attribute in DOM scripting. To make the fieldset title "clickable", collapse.js creates a link element, and assign to its onclick property the function that will make the fieldset collapse. Instead of adding an onclick event-handler property to the existing element. The code is like this, in collapse.js :

a = document.createElement("a");
a.href = "#";
a.onclick = function() { ...

In Internet Explorer 7, even when you set the event-handler to false, the link is still followed in its non-Javascript usual way, after the function assigned to the event-handler is invoked. As a result, when you try to open and close the collapsable fieldsets, you are redirected to the web site home page : http://www.myWebSite.com/#

I fixed collapse.js because it's bad practice anyway to add an href attribute just to make the pointer cursor appear when you are hovering over the element... Here's what I did (I don't think it's the absolute best fix though, the best would be to avoid the creation of that anchor element) :

a.href = "#";

a.className = "clickable";
a.onclick = function() { ...

And my stylesheet, I added :

.clickable {
cursor:pointer;
}

Now, about the so-called limitation here of having to put : href="node/6/#", instead of href="#" when trying to access some IDed element on the same page, I find it a non-issue.

2. As far as the second problem you mention, I am not aware of experiencing it so far.

What I know, though, is that the base element is XHTML-strict compliant. So the argument that the removal of the base element is necessary to be more W3C-compliant is wrong.

I'm not sure if this is related, but I added some content to my site today (running 4.7 RC2) and the log entry in Drupal, under Details, lists the link to the content as:

Location: /node/85/edit

Clicking on that link, of course, doesn't work..... not sure if it would work without the "/" in front (which Drupal added automatically), but without the base url kicking in it sure isn't working now......

You could use a subdomain instead. Or you could make a script based on the update.php script that changes your links later. Or you could simply avoid adding links by hand and use some output filter.
--
Drupal services
My Drupal services

Many people are bound to build their new, 4.7 production site in a different location than the intended place in the domain and then move it.

Sigh:(

This is exactly what I was planning to do. Looks like more work in the offing unless some kindly soul comes up with a neat solution.

That's what I've been doing. I believe that's how WordPress used to handle it too.

Actually, there is a great way to rewrite arbitrary subdomains to subfolders that comes in real handy if you want to stage a bunch of websites in subdirectories of a single domain but maintain their DocumentRoot portability.

The following technique (attributed to Andreas Friedrich over at webmasterworld) will rewrite...

subdomain.example.com/path --> example.com/subdomain/path

# Rewrite <subdomain>.example.com/<path> to example.com/<subdomain>/<path> 
# 
# Skip rewrite if no hostname or if subdomain is www 
RewriteCond %{HTTP_HOST} . 
RewriteCond %{HTTP_HOST} !^www\. [NC] 
# Extract (required) subdomain (%1), and first path element (%3), discard port number if present (%2) 
RewriteCond %{HTTP_HOST}<>%{REQUEST_URI} ^([^.]+)\.example\.com(:80)?<>/([^/]*) [NC] 
# Rewrite only when subdomain not equal to first path element (prevents mod_rewrite recursion) 
RewriteCond %1<>%3 !^(.*)<>\1$ [NC] 
# Rewrite to /subdomain/path 
RewriteRule ^(.*) /%1/$1 [L] 

*Of course for this to work you will need to have a DNS record for each subdomain. A wildcard ( *.example.com) is usually the easiest way to cover everything.

-zach
------------------------
harkey design