Is <base href tag necessary?

I never knew "base" has such a sordid history.

I was running into weirdness with internal anchor links. Things just weren't behaving nicely at all. I did some research and found suggestions that it is difficult - to say the least - to use them if the <base href= tag is used on the page. The advice that came up several times was to not use the tag, as it just isn't that useful.

So on a whim I tried it. I just commented out that code. I see no ill effects, but what track am I walking into here? Sure it was there for a reason.

s_mack:

I never knew "base" has such a sordid history.

I was running into weirdness with internal anchor links. Things just weren't behaving nicely at all. I did some research and found suggestions that it is difficult - to say the least - to use them if the <base href= tag is used on the page. The advice that came up several times was to not use the tag, as it just isn't that useful.

So on a whim I tried it. I just commented out that code. I see no ill effects, but what track am I walking into here? Sure it was there for a reason.

Without knowing the context this isn't a particularly easy one to answer. However for the sake of discussion lets assume that the HTML in question is something to be sent as email - Eg, an order confirmation.

If all of the links in the email are absolute, there is no problem.

If some of the links are relative, and there isn't a base href tag then the email links can't/won't work, because the client software doesn't know what these links are relative to.

In other words, in HTML formatted emails, if relative links are used, then the Base Href must also be used.

When it comes to webpages on a website, then the relative links on the page are relative to the site they are on, No base href needed (except in very specific circumstances), and as a general rule it is best to NOT use them (at least in my personal opinion).

So, quick summary...
HTML formatted Emails. Use relative links and base Href, or absolute links and no base href needed.
HTML Webpages - No base href needed.

Cheers
RodG

I was referring to webpages. The default template uses it. The template I purchased uses it. I just didn't know why.

So thanks.

It's useful for a number of situations. For example, if you move your code to a subdirectory, you just change your includes/configure.php file, and this code means that all properly constructed links (built using zen_href_link) will still work and you won't have to update your code to include "subdirectory_name/".

I get that... but then why do my links all work now that I've removed the base tag?

Right now my site is residing at https://www.mydomain.com/test

I plan to move it to https://www.mydomain.com/shop

I ASSUMED that when I removed the base tag that none of my links or images would work sine (I figured) they would all be relative to a now undefined base... but some stackoverflow post I read said it should work, so I tried it. It works. Why? And if it does work, then why wouldn't it work once I switch directories? I haven't hardcoded "test" into anything.

Did you read the post by rodG??

rodG:

So, quick summary...
HTML formatted Emails. Use relative links and base Href, or absolute links and no base href needed.
HTML Webpages - No base href needed.

Yes (obviously. I responded to it) and then I read the post by swguy. Am I to take it one is implicitly correct and the other talking out his hat? I thought he deserved more respect.

s_mack:

Yes (obviously. I responded to it) and then I read the post by swguy. Am I to take it one is implicitly correct and the other talking out his hat? I thought he deserved more respect.

As has been the case in the last couple of posts, the quoted text in this post is not clear about who is being discussed as being implicity correct and who is considered to be talking out his hat.

The additional information provided by swguy is not incorrect, but mostly from a different perspective. It would appear that swguy is striving to encourage the continued use of zen_href_link as with it or "properly" formatted relative links and as rodg stated, the base href tag would not be needed when the content is accessed from a webpage. But, the code is there because links are not always properly formatted by those that modify the their site and by it being present it adds a level of assistance in maintaining continuity and functionality.

So the real question is what problem are you trying to solve that seems to imply that the base href tag is getting in the way of things? Ie. what is the reason to remove the <base href tag that is in the includes/templates/YOUR_TEMPLATE/common/html_header.php file?

anchors. Attempting to use a relative link to a named anchor would take me back to the main index page rather than stay at the one I'm on. I couldn't figure out why then I found a lot of posts stating that named anchors are not really compatible with base href.

Advice by some (in fact many) is to never use relative urls. Always absolute. I don't quite buy that, as it makes moving a site a nightmare. Others said to just ditch base href and all is good. Unless I'm missing something, that seems to be the case.

s_mack:

anchors. Attempting to use a relative link to a named anchor would take me back to the main index page rather than stay at the one I'm on. I couldn't figure out why then I found a lot of posts stating that named anchors are not really compatible with base href.

Advice by some (in fact many) is to never use relative urls. Always absolute. I don't quite buy that, as it makes moving a site a nightmare. Others said to just ditch base href and all is good. Unless I'm missing something, that seems to be the case.

Well, not sure if I fully invoked anchors or a variation on them, but one of the plugins I pushed Checkbox TextBox Icon Product Checkout, used a variation of the anchor process I thought in order to return back to the same location on the page after making a selection up or down and the page reloading... I don't recall if I had to make the same edit or if I came up with an other functional method. I may have "cheated" and only had the base href not show on specific pages... Not sure...

s_mack:

anchors. Attempting to use a relative link to a named anchor would take me back to the main index page rather than stay at the one I'm on. I couldn't figure out why then I found a lot of posts stating that named anchors are not really compatible with base href.

Advice by some (in fact many) is to never use relative urls. Always absolute. I don't quite buy that, as it makes moving a site a nightmare. Others said to just ditch base href and all is good. Unless I'm missing something, that seems to be the case.

Well, not sure if I fully invoked anchors or a variation on them, but one of the plugins I pushed Checkbox TextBox Icon Product Checkout, used a variation of the anchor process I thought in order to return back to the same location on the page after making a selection up or down and the page reloading... I don't recall if I had to make the same edit or if I came up with an other functional method. I may have "cheated" and only had the base href not show on specific pages... Not sure...

s_mack:

Advice by some (in fact many) is to never use relative urls. Always absolute. I don't quite buy that,

I don't buy into that one either. Where possible I always use relative URL's.

s_mack:

as it makes moving a site a nightmare.

Exactly.

There is also the added argument (quite valid) that absolute URL's require the browsers make an additional DNS lookup for each request, and therefore they are much less efficient to use than the rels. This was more of a concern in days gone by, but I'm one of those that subscribe to the principle that just because CPU power and memory resources are almost limitless these days, it is no excuse for sloppy inefficient programming.

Heck, I still use bit patterns and masking in a lot of my code for variable 'flags' (why use 8 bytes of data for 8 different variables when the same info can by handled in a single byte?). Clearly there is no compelling reason to skimp in this manner to save "thismuch" memory, but I do like my code to be as efficient as possible. :-)

I wonder how much memory (and bandwidth) I/we can save (across the entire globe) if no one used absolute URL's except where necessary?

s_mack:

Others said to just ditch base href and all is good. Unless I'm missing something, that seems to be the case.

I don't think I'd quite go THAT far either. I can't say I've ever created a site/page and intentionally added the base href (never found the need), but at the same time, if/when I come across it in existing (and fully functional code) I wouldn't just dive in and remove it either.

It may have been added by some automated process (WYSIWYG HTML Creation tool) , or someone copying and pasting from elsewhere, where it serves no useful purpose, but it may also have been added with good reason by a developer for a specific use case that I/we are unaware of, and as such the removal may bite in unexpected ways.

At the end of the day, as long as everything works as expected and intended, then by definition, it is the 'right' way. If it doesn't, then it is the wrong way. :-)

Cheers
RodG

In my readings, I found arguments that directly conflict your believe about extra resources. They say the opposite... that translating a relative URL with each and every call takes unnecessary cycles.

I really don't know, so I'm not arguing. Just saying it isn't that clear cut. They also make a lot of points about it killing people in terms of SEO as one goof can have tragic consequences. Again, I don't know. Nor do I really care. Google seems to find me just fine with no particular SEO efforts.

Anyway, I would like to hear from a devleoper on this because the base href code is in the default template and I'd like to know why. Again, removing it has not seemed to have any ill effect and it did resolve my anchor problem. An anchor problem I no longer have, mind you, since i've subsequently changed my mind on how I want to handle foot notes :)

So I could uncomment the base href tag if there's any compelling reason to do so.

As already mentioned, adding the base element just ensures any HTML compliant parser ĺsuch as a web browser) knows what base URL should be prepended to any COMPLETLY relative links (stuff like "image.jpg" and "stylesheet.css"). For web pages if all links to external resources are absolute ("https://example.com/image.jpg", "http://example.com/image.jpg", "//example.com/image.jpg") or SITE relative ("/image.jpg") it is not needed. For emails if all external links are absolute it is not needed.

For the following examples the URL requested by a browser (or other reader) is "http://example.com/folder/index.php" and the base element is not specified. A link to "image.jpg" should result in the browser requesting "http://example.com/folder/image.jpg". A link to "/image.jpg" should result in the browser requesting "http://example.com/image.jpg".

Zen Cart out-of-box currently uses a mixture of COMPLETELY relative links and absolute links. Internally Zen Cart knows what the BASE path is to physical images and the website relative path used to access those resources. Those are the FS_* and WS_* defines respectively in the "configure.php" files. These are used when generating both COMPLETELY relative and absolute links.

Can you guess what would happen in the future if a page was added at "http://example.com/folder/category/my-product-name-456.html"? Zen Cart will still generate COMPLETELY relative links as "image.jpg". The broswer will request "http://example.com/folder/category/image.jpg". But the image is physically at "/username/public_html/folder/image.jpg" not "/username/public_html/folder/category/image.jpg"; resulting in the web server returning a "HTTP 404 - Not Found".

So including the base element helps ensure COMPLETELY relative links generated by Zen Cart are loaded from the correct location. If desired (to avoid having to specify the anchor with the page - such as "index.php?main_page=index#anchor"), one CAN remove the base href from the web page template without any major issues when NO URLs outside the installation root are used.

lhungil:

Can you guess what would happen in the future if a page was added at "http://example.com/folder/category/my-product-name-456.html"?

When would that come up though? Zen doesn't reference them like that, but rather: "http://example.com/folder/index.php?main_page=product_info&cPath=3&products_id=378"

So... are we talking about SEO friendly hacked url's? Is that when I'd run into trouble?

lhungil:

If desired (to avoid having to specify the anchor with the page - such as "index.php?main_page=index#anchor"), one CAN remove the base href from the web page template without any major issues when NO URLs outside the installation root are used.

So that would have been my other solution then, right? To specify the anchor links as you showed? I didn't know that. That would have been fine too and I'll keep that in mind, if I'm understanding you correctly.

Virtual URLs (aka "alternate", "pretty", "friendly", "short", etc) are one common case. Not all Virtual URLs are for "SEO friendly" purposes, some are to comply with requirements or overcome restrictions in external software. Some third party modules adding a "page" in a subdolder are another case. Basically any scenario where the URL could contain a "sub-directory".

I suspect the base element is there as a "safety" feature because some of the Zen Cart code and some 3rd party modifications generate COMPLETELY relative URLs. In my experience the core development team strive to ensure Zen Cart will work for ALL users in as many scenarios as possible, thus the base element is added by the default template.

If leaving the base element... When the anchor link is stored in the DB, specifying as ahown in the previous post will work (there are some other programmatic solutions as well). If in a PHP file, would recommend using the Zen Cart function to generate the URL and add the anchor afterwards (provides best long term compatibility).

NOTE: I am not one of the core developers and am not speaking on their behalf. I am providing an answer based on my experience.The other people who have responded are also very knowledgable and should not be dismissed (and many of them are experienced Zen Cart consultants and / or developers).

I have a better understanding now. Thank you very much.

s_mack:

In my readings, I found arguments that directly conflict your believe about extra resources.

I didn't state any belief. I stated a well known fact, namely, Absolute URL's require the browsers make an additional DNS lookup for each request, and therefore they are much less efficient to use than the rels.

> s_mack:

They say the opposite... that translating a relative URL with each and every call takes unnecessary cycles.

Are you getting your info from Wikipedia?

Yes, there will be/are few cycles of additional code that determines whether another DNS lookup is needed or not, but these few cycles are going to magnitudes less that the cycles needed to perform the lookups each and every time, needed or not.

Do these 'arguments' also claim that the cycles and processing needed to determine whether an item can be fetched from a cache is somehow more 'costly' than using the cache in the first place? I would hope not, yet, this is almost exactly the same situation.

Oh, and the cycles of which they are referring, are not unnecessary at all. I don't know where that came from.

s_mack:

I really don't know, so I'm not arguing.

Fair enough, I can appreciate that you wouldn't want to argue about something you don't know, but TBH, I thought you'd have a better understanding of how DNS and caching worked, and you wouldn't fall into the trap of thinking a few extra cycles of code being used to bypass 100's of possible cycles would actually have a overall reduction in efficiency.

s_mack:

Just saying it isn't that clear cut.

And I'm saying it IS clear cut. It is almost common sense if you sit back and think about exactly what we are discussing here.

s_mack:

They also make a lot of points about it killing people in terms of SEO as one goof can have tragic consequences.

Now this is one of the most ridiculous things I've read in a long time. I'm not even going to try to explain on how many levels this is so wrong.

s_mack:

Again, I don't know. Nor do I really care.

Do you realise that you are coming across as a troll? If you really don't know, and didn't care, then why take my words and throw them back at me with comments that some nameless people disagree with me?

People disagree with me all the time, but that doesn't mean I'm wrong.

The reason I'm even replying to your troll bait is because somewhere deep down in side I think you really are unsure about this, and being an educator, I'm happy to educate - as far as possible -

I'm also responding for the benefit of others that once had a very good understanding that a few cycles spent in one place to save a few hundred cycles in another place has a net gain.

s_mack:

They say the opposite... that translating a relative URL with each and every call takes unnecessary cycles.

Couldn't be more wrong if they tried.

s_mack:

Google seems to find me just fine with no particular SEO efforts.

In relation to absolute vs Relative URL's, Google (and all other SE's) really do not, (in fact cannot) make a rating distinction between between the two. All pages and sites are indexed and ranked using absolute URL's - The search result would be useless otherwise.
Think about it!

This is actually far more true now than it was 10-20 years ago - Here's why - Back in times gone by, the crawling and indexing of a site were performed simultaneously in a single pass of the bot. As such, the ranking algorithms were able to determine the difference between an absolute and relative link as both are/were possible in the same page and on the same pass. There was the opportunity to adjust the rankings accordingly. I don't know any that did though.

These days, almost all SE's use a two stage process - Stage one - is the crawling of the site, and stage two, determining the ranking. This ranking determination is based on the URL's and data stored on the SE servers, and the URL's stored there must be absolute - even if they were relative on the site itself. Again, think about it... If the SE's stored the relative URL's the search results would end up providing links back to Google itself, rather than the site where they were found.

s_mack:

Anyway, I would like to hear from a devleoper on this.

I'm a developer, I've given my input. Look what you've done with it though.

s_mack:

because the base href code is in the default template and I'd like to know why.

I've even answered this for you. You probably didn't realise it though because you've been too busy trying to dispute or find argument with almost anything and everything I've ever written.

I really don't know why I bother sometimes, other than it is one of the many things I've been trained for. ;-)

Cheers
RodG

Holy crap, calm the #$@# down man.

Who's the troll? Wow. Some insecurities going on there, or what?

Apparently YOU think it is MY job to take your word as gospel. You said one thing, I read another... that's all I was saying. There are sources after sources after sources suggesting your points are debatable, at the very least. But I'm supposed to just presume the guy in the shower cap knows everything.

Do you know more about DNS than I do? I'm gonna say probably. Do you know more than I do about SEO? I'm not sure, but you probably care more than I do. But I'll tell you one thing I know more than you: the purpose of a discussion forum. We're not here for the "educator" to espouse his lessons onto use like children. We're here to discuss. That's what it was. I was NOT in any way whatsoever trying to "troll" you, that's 100% on your own insecurities. Brought out, I believe, not by my comments at all but by how I may have valued lhungil's assistance to a greater degree than yours.

I'm a developerSo am I... so's the kid next door. OBVIOUSLY I meant a developer of zencart. Your response seemed... uninformed... to the fact the code in question was part of the core distribution. I wanted to hear from them if there was a missing bit of info as to whether or not it had to be there.

Bottom line. CHILLLLL. If you REALLY think that I'm a "troll" then walk away. If your pride got a little hurt, then say so and I could say I'm sorry (cause I really didn't meant anything). If its all just a misunderstanding... well, duck off a water's back (err)