"Next Page" in Table Bumps Me Back to Site Frontpage

Status
Not open for further replies.
EDIT - I just worked out why the behaviour described below happens (I gave myself the clue by thinking I might fix it using a BASE HREF). It's because when you enable SEF, it then inserts a BASE HREF into the head section of the doc pointing at the root of the site. So this means we'll have to somehow modify our pagenav links to include the complete path, instead of just being #next, etc.

Looks like another SEF issue. Which SEF component do you use, or is it just the built in Joomla core SEF?

Next time Rob gets online I'm going to force him at gunpoint to help me work on some of these SEF issues. I can see where the problem is happening, but I don't understand why its happening. Basically, wherever we are using an A HREF link to trigger a form submission (like the pagenav stuff for tables), if SEF is enabled it insists on using the link defined in the HREF, rather than the target of the form itself.

So in your case, even tho the form says:

Code: 
<form action="[url]http://proposalcafe.com/component/option,com_fabrik/Itemid,212/"[/url] method="post" id="fabrikTableForm" name="fabrikTable">
... which would work with SEF disabled, as soon as you enable SEF, it decides that the pagenav links, like:

Code: 
<a href="#next" class="pagenav" title="next page" id='table_11_nav-next'"> Next&nbsp;&gt;</a>

... should apply to just the site index instead of the target of the form, even though they are triggering a form.submit(). And I still don't understand why the bahaviour changes by enabling SEF.

This might be possible to solve using BASE HREF, but that would still fail if we have more than one table on a page. Changes to the way IE7 handles BASE HREF (for once they are strictly following the "official" standards) mean that you can't change the BASE HREF inside the body, you can only do it once in the HEAD section.

So I'm still trying to work out how to avoid this. One way I found was to remove the HREF from the A tag, but then the links don't appear as links, just words. They work, but it's not very pretty.

-- hugh
 
Hi Hugh,

It's been awhile ... I hope you have been well.

It makes me feel really bad that I didn't understand any of your answer but I feel a little better that you are still scratching your head on this one. grin

I discovered something else today that is probably being caused by the same thing. I am using another component (Bookmarks) to manage lists of links. I have one list (Proposal Services) that has enough links that it has spilled over to a second page. When I click on "Next" to go to the second page, it doesn't bump me back to the site front page but it does reload the first page of links.

By the way, I am using sh404 SEF.

Thanks for the reply.
 
LOL! I don't understand myself, sometimes.

The problem is the BASE HREF. If you look at the source of your page, you'll see a BASE HEF directive in the HEAD section. This basically tells the browser where relative links should go. Which is OK, except it also seems to change the behaviour of the form.submit() command in JavaScript. Without a BASE HREF on the page, when you click a link which calls some JS that then does a form.submit(), it will use the forms target submission URL as the base. That's how our pagenav works.

But when you have a BASE HREF, and click the same link, for some reason it then uses the URL associated with the link, rather than the target of the form, when JS does the form.submit. Which is wrongheaded, in my opinion. The form.submit() is supposed to simulate clicking the forms submit button.

Basically, I think we'll have to change from using <A HREF="#next"> type links on the pagenav, to some CSS styled div that looks like a link.

-- hugh
 
hi

i don't have a sef site set up to test this on, but I've committed some changes that might fix this.
The navigation links were being observed by the javascript table class, so that each time they were clicked the form was submitted. However, those events weren't being stopped so were propergating to the links href, which in turn redirected you to the home page.
As i said ive not tested this but let me know if it works

Rob
 
Tested, seems to work now.

It even makes sense. I now understand why the behaviour changed with SEO enabled, why it worked without SEO and broke with SEO, and why the fix works. Wow! Enlightenment.

Thanks, Rob.

-- hugh
 
Hi Rob and Hugh,

I updated all my files (using SVN) but I am still getting the same problem. When I click on the link for page 2 of the table, it bumps me back to the site's frontpage.

I would be glad to let either of you use my site for testing. Just let me know what I need to do.

Thanks
 
Thanks Hugh,

I have "side-stepped" the problem by increasing the number of records to display in the table to 50. Now, in effect, I no longer have a Page 2.

Whenever you can get a minute to take a look at the site, I would appreciate it.

Also, I will passing by you next week on my way to Memphis. If you happen to see an old-timer that sorta looks like Santa waving, that will be me.
 
This is weird. If I put a breakpoint in this function:

Code: 
 fabrikNav: function(limitStart){
     this.form.limitstart.value = limitStart;
     this.submitfabrikTable('');
     return false;
 },

... in table.js, which is where we added that 'return false', it works just fine. As soon as I turn the bp off, it does the home page thing. It also doesn't work in IE.

On my test server, it works with or without a bp in the code, on both FF and IE.

I notice that you have rokzoom loading with it's own version of mootools, and an error being generated in mootools, tickled by something our slimbox.js is doing when it loads. Might not be anything to do with it, but if I have sufficient access to your site, I'm going to try turning rokzoom/mootools off for a minute, see if that helps.

-- hugh
 
Hey again,

If you don't still have access to the site, let me know. Also, if you want to get rid of the mootools/rokzoom files, that will be fine. I am not using rokzoom on my site.

Thanks
 
I fixed a bug in your template, which would (as far as I can tell) have been preventing you from changing menu types. If you look at your template HTML, you'll see where I've set ...

$mtype = $menu_type;

The rest of the HTML refers to $mtype, not $menu_type. As such, it was including rokzoom and mootools even when your menu type didn't require them.

Unfortunately this hasn't fixed the problem, and I still have no clue why this is failing. Like I said, if I put in a break point on the "return false;", it works just fine ... and we've now tested this fix on at least four servers that I know of with no problems.

I'm about to try switching back to the default template, see if that works.

-- hugh
 
OK, I finally fixed it. I added some more 'return false' lines, in the event binding, in addition to the stuff Rob added to the the fabrikNav functions. I have no clue why other test sites work without that and yours doesn't, but we now seem to have a working solution for (hopefully) everyone.

I haven't committed the changes to SVN yet, but your site has the modified table.js.

Please confirm that it works for you and doesn't seem to cause any other issues, and I'll commit the changes.

-- hugh
 
Status
Not open for further replies.

Useful links

  • Create a Fabrik Account (Downloads)
  • Create a Forum Account
  • Fabrik Wiki
  • Fabrik 4 Changelog /Install /Upgrade
    • We are in need of some funding.
    More details.

    Thank you.

    Members online

    Total: 65 (members: 1, guests: 64)
    Back
    Top