changing the default link scheme... the end of ??

When [[~23]] link tags get parsed, they call modX::makeUrl with the default scheme of ’-1’ (URL is relative to site_url).

This is *why* MODx requires <base href="[[++site_url]]" /> (is it not?)

When modX::makeUrl is called with the scheme of ’abs’ (URL is absolute, prepended with base_url from config), the result is a "root relative" URL. My base_url is ’/’ (MODx is installed at site root) - so if I have resource 23 with an alias of foo/bar.htm...

[[~23?&scheme=`abs`]] results in /foo/bar.htm.

So...

if I could change the default scheme from ’-1’ to ’abs’... all my links would be root-relative... and (wait for it)... I would no longer need to use the <base href=[[++site_url]]> trick.

Right?

Right?

The base href requirement (and the subsequent ’anchors workaround’ requirement - http://www.modxperience.com/modxperi/experience/quick-tips/fake-anchors.html?quip_approved=0#quip-success-qcom) has been bugging the crap out of me lately, because it seems to be a nagging, annoying exception to the otherwise truthful & awesome claim that "MODx doesn’t dictate anything whatsoever about how you choose to write your HTML". Its the type of thing where, if I weren’t already sold on MODx and were evaluating it as a potential tool, I could easily see myself thinking "that’s lame" and moving on to the next CMS.

Am I missing something?

Are there downsides to a root-relative URL strategy? Downsides that would outweigh the benefit of being able to ditch "base href" and have proper anchor behavior without a workaround?

I’m submitting a feature request to add a system setting that dictates the default URL scheme used when parsing link tags. I think it would be nice to at least have this option.

That’s not a complete description of why we use the base tag in MODx. You can’t just get rid of the base href IMO; if you want your CSS and image paths to work when someone goes to a page not found 14 levels deep in folders that do not exist. IOW, if I go to foo/bar/food/beer/ and it doesn’t exist, I show the error_page and the browser believes the page to be located at foo/bar/food/, but this is incorrect. It is served from the site root. You have to tell the browser what the actual path is, and that path is always the index.php at the site_url.

TBH, I don’t understand why the base href is such a source of controversy. It provides a simple way, especially now that you can prevent it from caching, to keep your site completely portable. It informs the browser where it really is, despite the rewritten URL hierarchies.

Other than anchor tags ’problems’, what exactly are your gripes with using base href?

I’ve used some js if i needed page anchors. A jquery example:



I think it’s perfectly acceptable to use.

A related note on base href:
use like this:


see: http://stackoverflow.com/questions/1889076/is-it-recommended-to-use-the-base-html-tag/1889957#1889957

In most ways, I do think base href is a pretty nifty solution to a whole lot of things... and OpenGeek’s in-depth justification of it really helped me to better understand its role. I guess there are two things that have been bugging me... but I think I can get over both of them without abandoning base href entirely.

1. I’m dealing with a ridiculous "dueling top domains" issue that has been rubbing me the wrong way for years. We have one logical website spread across two domains. base href=site_url has bit me in the butt a few times with things like the same-host javascript/xhr rule. The solution is pretty clear... instead of site_url I just need to use the HTTP_HOST server variable.

2. The fact that base href prepends itself to #anchor links at all seems like a major misstep in how it was implemented/designed in the first place. I guess now that ’currentpage.html#myanchor’ doesn’t require a page reload in most browsers, it isn’t too big of a deal. My major freakout - and the catalyst for my holy war - was when I thought that screen reader users using the #skipnav anchor would be forced to load each page twice. As usual, I’ve let myself get worked up about something that isn’t really even accurate. So here’s a big Gilda Radner-style "nevermind".

Quote from: OpenGeek at Nov 16, 2010, 11:48 PM

TBH, I don’t understand why the base href is such a source of controversy. It provides a simple way, especially now that you can prevent it from caching, to keep your site completely portable. It informs the browser where it really is, despite the rewritten URL hierarchies.

I totally agree with the site portability ’feature’ of using base tags. I never understood the base tag before using MODx and now I count on it every time I move a site. Once you learn to work with it, the benefits far outweigh the negatives. Also, the ’negative’ side of using the base tag just means learning to do things a bit differently (ie [~21~]#anchor instead of just #anchor), not that anything is broken.

We have one logical website spread across two domains

One website spread across 2 domains is not logical, IMO. ha ha.

James

Quote from: jrotering at Nov 17, 2010, 06:19 AM

1. I’m dealing with a ridiculous "dueling top domains" issue that has been rubbing me the wrong way for years. We have one logical website spread across two domains. base href=site_url has bit me in the butt a few times with things like the same-host javascript/xhr rule. The solution is pretty clear... instead of site_url I just need to use the HTTP_HOST server variable.

site_url uses the http_host, so [[!++site_url]] is all you need to support accessing the proper files (assuming if the site is accessed with domain A that all links are then relative to domain A, and likewise with domain B). So long as you do not cache the site_url value on your pages, this should just work. If you have a common, shared path used by both domains, you can add a system setting to represent that.

Quote from: jrotering at Nov 17, 2010, 06:19 AM

2. The fact that base href prepends itself to #anchor links at all seems like a major misstep in how it was implemented/designed in the first place. I guess now that ’currentpage.html#myanchor’ doesn’t require a page reload in most browsers, it isn’t too big of a deal. My major freakout - and the catalyst for my holy war - was when I thought that screen reader users using the #skipnav anchor would be forced to load each page twice. As usual, I’ve let myself get worked up about something that isn’t really even accurate. So here’s a big Gilda Radner-style "nevermind".

lol -- these are definitely quirks of using our system, and it’s good to question why things are done so the full scope of the issue is revealed and alternatives can be found. I just wanted to make sure the why was clear for everyone before the exploration of alternatives took over.

Forgive my naivety but I’m a little unclear as to the benefit Base Href provides over simply using URLs from the root of the domain. i.e. "/css/styles.css" rather than "css/styles.css"?

I understand that the latter in that example would create problems on 404 pages, but it would work without issue with the prepended "/". From what I can see prepending links with "/" maintains portability and allows for the use of anchors (without hacks).

Does using Base Href preclude the possibility of using dynamically generated absolute URLs? Generally I prefer my internal links to be absolutely referenced to marginally hinder to scraper sites.

Whilst its possible to comment that adding Base Href isn’t a big deal, surely its an unnecessary additional step?

DM

Quote from: DangerMouse1981 at Nov 17, 2010, 11:30 AM

Whilst its possible to comment that adding Base Href isn’t a big deal, surely its an unnecessary additional step?

I explained, in detail below, why it is necessary.

Quote from: OpenGeek at Nov 18, 2010, 08:39 AM

Quote from: DangerMouse1981 at Nov 17, 2010, 11:30 AM

Whilst its possible to comment that adding Base Href isn’t a big deal, surely its an unnecessary additional step?

I explained, in detail below, why it is necessary.

Indeed - and as I suggested, if image and CSS paths are prepended with a simple "/" the browser will search out the files from the root of the domain, not relative to the current directory.

Does this strategy not work?

DM

Quote from: DangerMouse1981 at Nov 18, 2010, 11:08 AM

Quote from: OpenGeek at Nov 18, 2010, 08:39 AM

Quote from: DangerMouse1981 at Nov 17, 2010, 11:30 AM

Whilst its possible to comment that adding Base Href isn’t a big deal, surely its an unnecessary additional step?

I explained, in detail below, why it is necessary.

Indeed - and as I suggested, if image and CSS paths are prepended with a simple "/" the browser will search out the files from the root of the domain, not relative to the current directory.

Does this strategy not work?

DM

Certainly not if you develop or deploy in a subdirectory. Absolute paths ruin portability.