Skip to content
This repository was archived by the owner on Oct 8, 2021. It is now read-only.

Static Base Href Value #4456

Closed
lthurston opened this issue May 25, 2012 · 33 comments
Closed

Static Base Href Value #4456

lthurston opened this issue May 25, 2012 · 33 comments

Comments

@lthurston
Copy link

I made some changes to JQM 1.1 core to handle an I was having with a mobile site. The problem was that the base href value specified by the originally loaded page needed to remain the base href value for all pages on the mobile site, no matter what the URL of the AJAX-fetched page. Really, that's the reason why the base tag exists, and on this site (built in TYPO3) all links on all pages are going to be relative to this base href value.

So I made some minor changes:

  • added a new config value that gets set on mobileinit: $.mobile.staticBaseHref
  • modified the condition that wraps the section of that rewrites src, href, etc values on the page after the AJAX request so that if $mobile.staticBaseHref is set, no rewrite of these values takes place
  • in the click event handler for links on the fetched page, I prevent the baseUrl value from getting set to getClosestBaseUrl($link) if the $.mobile.staticBaseHref value is set

With these two minor changes, the mobile site works flawlessly without modifying the base href or URLs in the DOM. I can't help but wonder if I'm missing something here, if there's some problem that my solution might cause. Does anyone have any insight into this? It seems like a simple solution that many others might find useful, and I'd love to share it.

thanks,
Lucas

@lthurston
Copy link
Author

Here's a gist with a diff; it offers more insight into what I did: https://gist.github.com/2791063

@toddparker
Copy link
Contributor

@lthurston - Thanks for sharing that gist, I'm sure this will be helpful for some folks. We normally need to manipulate the baseHref to deal with pages from different directories being pulled into a starting page. In your case, are all pages in a flat list and that's why you don't need this feature? Curious why the current behavior would be an issue if all pages are siblings - seems like the base href would just remain the same on each page.

@johnbender - do you have an opinion on this?

@lthurston
Copy link
Author

@toddparker - In my case I have a series of URLs like:

domain.com/mobile
domain.com/mobile/page1
domain.com/mobile/page2
domain.com/mobile/page3

For all pages the base href is "http://domain.com/", but JQM expects the base href for mobile/page1 to be "http://domain.com/mobile/", which breaks all images and links. If JQM respected the base href value on the page it fetched via AJAX, everything would work fine. My solution of setting the static base href for all mobile seemed like an easier and quicker one to implement.

Note that this would be a problem even if I had the mobile site at domain.com/. It might not be immediately obvious because the problem would start only occurring when I get to the two-segment URL paths:

domain.com - would work
domain.com/page1 - would work
domain.com/page2 - would work
domain.com/page2/page3 - wouldn't work, because JQM would set the base href to domain.com/page2

If there's a better way to solve this problem, I'd be happy to help implement it another way. I'd love to get a solution to this problem into a future release.

@AlexHowansky
Copy link

I've just encountered this issue as well, and would welcome Lucas' solution -- it's exactly what I need. In my case, my pages are not in a flat list, and JQM does not correctly adjust the href to match. Specifically:

I'm using a combination of static and AJAX loads for my app. My index page loads a number of static JQM page divs for the most common content, and then menus or buttons therein can initiate AJAX loads of other lesser-used JQM page divs. My page addresses are of the style /module/action, so they might look like:

/client/sites
/system/summary
/system/details

Unfortunately, I can not assume that the app will be always running directly in the web server's document root, so I can not use absolute addresses. So, I define the base href accordingly:

<base href="http://domain.com/path/to/app/" />

Within the index page is a link to the system summary page. That link would be written as:

<a href="system/summary" data-role="button">System Summary</a>

Here, JQM correctly makes an AJAX request to http://domain.com/path/to/app/system/summary to fetch the new page content. However, what it also does at this point is rewrite the base href to:

http://domain.com/path/to/app/system/

Now, let's say that the page we just rendered contains another link:

<a href="system/details" data-role="button">System Details</a>

Clicking on this button will result in an AJAX hit to an invalid URL, one with the "system" path doubled:

http://domain.com/path/to/app/system/system/details

My first thought was to write the HTML for this link as relative to the "page" it's on:

<a href="details" data-role="button">System Details</a>

This works OK if I navigate to the system/summary page and then hit the details link. However, this doesn't work in the case where I request the system/summary subpage directly (i.e., without first clicking through from the index page.) There, the base href never gets rewritten to add "system" to the end, and the AJAX request ends up going to an invalid URL, one without "system" anywhere in it:

http://domain.com/path/to/app/details

Thus, I would like JQM to leave the base href alone, so that every link in the app can be specified relative to it, and not relative to whatever pseudo-page JQM thinks it's on.

FWIW, my current solution is to have the app serving the HTML automatically figure out its base href and then prepend that to all links, making them absolute. This works but is rather inelegant.

@johnbender
Copy link
Contributor

@toddparker @AlexHowansky @lthurston

Ok, I'm going to dive into this finally. It might be a while until I've collected all the relevant information, including a quick consult with @jblas, but hopefully I can address this issue this week.

More soon.

@AlexHowansky
Copy link

Great, thank you!

@lthurston
Copy link
Author

@johnbender Awesome, let me know if there's anything I can do to help. Although I kind of think the base href should change based on the value in the header of the page fetched by AJAX, having the option of setting a static value from the first page requested serves as a reasonable override of the default behavior. Nevertheless, I'd be happy to take a stab at pulling it out of the AJAX response if that's how you would prefer to see it work.

@johnbender
Copy link
Contributor

@lthurston

We have a host of other related issues that I'm going to start looking into in tandem with this one. Generally I'm going to take the time to grok everyone's complaints with the base tag support and try to sort something out. For further reference: #3978 #3745 #2652

Keep an eye on that first for general information.

@lthurston
Copy link
Author

@johnbender Thanks, will do.

@ghost ghost assigned johnbender Jun 19, 2012
@johnbender
Copy link
Contributor

@AlexHowansky @lthurston

#3978 (comment)

I've added the option $.mobile.dynamicBaseEnabled to a branch that's available for preview. If you set that to false inside a mobileinit callback jqm will leave everything alone so your initial base href value will be respected for all links in all pages.

I've got a little bit of testing in there but more is needed, so your help would be greatly appreciated.

Also, I should note that in my reading of your issues this would provide a solution though that could be wrong and ultimately we want to support the definition of base href values in the pages loaded via ajax (my next step).

@lthurston
Copy link
Author

@johnbender We'll take it for a spin and let you know if it works.

@lthurston
Copy link
Author

@johnbender It looks like this solution doesn't work in our case. In the site I'm implementing this on, the homepage of the JQM site is in "mobile/". The base href value, however, is simply "http://domain.com/". Links to internal pages all begin with "mobile/" (for example "mobile/page1", "mobile/page2"). When I click one of these pages, I see the request for the page is to "http://domain.com/mobile/mobile/page1". So the URL on the link is still being concatenated with the href value of the link.

@lthurston
Copy link
Author

@johnbender That last sentence is wrong. It should say: The href value of the a tag is being concatenated on the relative path of the current page (or so it seems).

I'm looking into this a bit more now.

@lthurston
Copy link
Author

@johnbender Sorry to spam you, I should have got this all into one message.

It looks like the call to getClosestBaseUrl() on line 4115 still returns "http://domain.com/mobile", to which "mobile/page1" is appended. So, the link ends up being incorrect.

This is the part of the code where, in reviewing my solution, I check to see if $.mobile.staticBaseHref is defined and if so I use it as the base url. Alternatively, with your approach, you could get the base href value from the DOM and stick it into the baseUrl variable at that point, if $.mobile.dynamicBaseEnabled is set to false:

            if(!$.mobile.dynamicBaseEnabled) {
                var baseUrl = $('base').attr('href');
            } else {
                var baseUrl = getClosestBaseUrl( $link );
            }


                //get href, if defined, otherwise default to empty hash
            var href = path.makeUrlAbsolute( $link.attr( "href" ) || "#", baseUrl );

That code change makes it all work for me.

@johnbender
Copy link
Contributor

@lthurston

I'll have to take a closer look at this since we use that helper in 4 or 5 places and I'd prefer that the logic was centralized there so we don't make this mistake in many possible places.

More soon hopefully.

@lthurston
Copy link
Author

@johnbender

Makes perfect sense to me. Let me know what you come up with and we can test some again.

@johnbender
Copy link
Contributor

@lthurston

I just pushed a commit to that branch and it should be up to date in the link I provided previously. If that works for you I need to devise a test for it and then we can merge it after 1.2 release.

@johnbender
Copy link
Contributor

@lthurston

Just checking in to see if you've had a chance to try out the modifications I've made.

@lthurston
Copy link
Author

Hi @johnbender

I have been told that it does work, but I haven't had a chance to double check myself. I'll get back to you as soon as I can.

On Aug 28, 2012, at 10:12 AM, John Bender notifications@github.com wrote:

@lthurston

Just checking in to see if you've had a chance to try out the modifications I've made.


Reply to this email directly or view it on GitHub.


Lucas Thurston
Cast Iron Coding, Inc
lucas@castironcoding.com
http://castironcoding.com
aim: ciclucas
skype: ciclucas
office phone: 503.841.5669
direct phone: 503.928.7462
fax: 866.285.6140

@lthurston
Copy link
Author

@johnbender

It's working in my development environment. Has anyone else watching this ticket had an opportunity to test it out?

@lthurston
Copy link
Author

@johnbender Looks like this didn't get into 1.2. What version are you now expecting this to get merged into?

@lthurston lthurston reopened this Oct 7, 2012
@lthurston
Copy link
Author

Too easy to click "Comment & Close"… :)

@toddparker
Copy link
Contributor

@johnbender - Is this still on your radar for 1.3?

@johnbender
Copy link
Contributor

It's done in a branch but I was waiting on a base tag test that @scottjehl was working on at the summit.

That is, I broke something in the branch. I can look into this soon. Would like to get it into 1.3

@scottjehl
Copy link

Oh? Okay, well I can look at that test if we want to pursue this.

Do we think static base hrefs are common enough to support them with a global option in the framework? Do we get many issues around base conflicts?

On Dec 6, 2012, at 1:51 PM, John Bender wrote:

It's done in a branch but I was waiting on a base tag test that @scottjehl was working on at the summit.

That is, I broke something in the branch. I can look into this soon. Would like to get it into 1.3


Reply to this email directly or view it on GitHub.

@pillex
Copy link

pillex commented Dec 21, 2012

yes please!

i'm waiting for this since i tested jQM and my first thought was: unusable, cant't handle even the most basic feature of any internet software - clicking a link leads to nowhere.

after lengthy frustrating testing found: it's your base-tag stupid.

which was even more frustrating, because it meant, you have to re-write 1000s of lines of code to make your site work with jQM. instead made a custom jQM, which worked for me.
#5083

if it's not going into 1.3 please at least make a big warning sign into any docs and release notes: "not intended to work with base-tags".

@johnbender
Copy link
Contributor

@toddparker

This is on my radar but I suppose we need to figure out the priority. I had a branch with this working, but @scottjehl told me that relative paths for images were broken when I merged it.

Need to come up with some tests first I guess.

@lthurston
Copy link
Author

I agree this is an annoying roadblock and I think it should be considered a high priority. I don't know why working with base tags would be even slightly controversial, especially considering how few lines of code need to change in order to implement this. That said, I understand there are many, many requests like this and appreciate the development team's efforts on this project.

If there's anything I can do, I continue to make myself available to assist.

@pillex
Copy link

pillex commented Dec 21, 2012

@johnbender

concerning broken relative paths for images. the quickfix for me was

-var newPath = path.get( fileUrl );
+var newPath = path.get( $('head base').attr('href') );

line 848
https://github.com/jquery/jquery-mobile/blob/1.2.0-rc.2/js/jquery.mobile.navigation.js

@johnbender
Copy link
Contributor

@lthurston

Thanks for your patience. It's generally been a push and pull of effort for value. The vast majority of users don't make use of a static base in their websites so the value is low. That said it's back on my todo list and hopefully we'll be able to get this in before 1.3

@johnbender
Copy link
Contributor

@lthurston

This has been merged into master.

@lthurston
Copy link
Author

Woot! Thank you!

On Apr 10, 2013, at 12:39 PM, John Bender notifications@github.com wrote:

@lthurston

This has been merged into master.


Reply to this email directly or view it on GitHub.


Lucas Thurston
Cast Iron Coding, Inc
lucas@castironcoding.com
http://castironcoding.com
aim: ciclucas
skype: ciclucas
office phone: 503.841.5669
office extension 206
fax: 866.285.6140

@johnbender
Copy link
Contributor

@lthurston

Definitely let me know if you have issues, it's tough to test.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants