-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Static Base Href Value #4456
Comments
Here's a gist with a diff; it offers more insight into what I did: https://gist.github.com/2791063 |
@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? |
@toddparker - In my case I have a series of URLs like: domain.com/mobile 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 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. |
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:
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:
Within the index page is a link to the system summary page. That link would be written as:
Here, JQM correctly makes an AJAX request to
Now, let's say that the page we just rendered contains another link:
Clicking on this button will result in an AJAX hit to an invalid URL, one with the "system" path doubled:
My first thought was to write the HTML for this link as relative to the "page" it's on:
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:
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. |
@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. |
Great, thank you! |
@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. |
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. |
@johnbender Thanks, will do. |
I've added the option 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). |
@johnbender We'll take it for a spin and let you know if it works. |
@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. |
@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. |
@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 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. |
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. |
Makes perfect sense to me. Let me know what you come up with and we can test some again. |
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. |
Just checking in to see if you've had a chance to try out the modifications I've made. |
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:
Lucas Thurston |
It's working in my development environment. Has anyone else watching this ticket had an opportunity to test it out? |
@johnbender Looks like this didn't get into 1.2. What version are you now expecting this to get merged into? |
Too easy to click "Comment & Close"… :) |
@johnbender - Is this still on your radar for 1.3? |
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 |
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:
|
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. 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". |
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. |
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. |
concerning broken relative paths for images. the quickfix for me was -var newPath = path.get( fileUrl ); line 848 |
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 |
This has been merged into master. |
Woot! Thank you! On Apr 10, 2013, at 12:39 PM, John Bender notifications@github.com wrote:
Lucas Thurston |
Definitely let me know if you have issues, it's tough to test. |
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:
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
The text was updated successfully, but these errors were encountered: