I upgraded to 2.8. Yay! :). However, found that none of my directory/glossary pages were working.
I did debugging, and it seems to be in ajax_views.js. On line 116, the extend function is used to merge information into viewsData:
$.extend(
viewData,
Drupal.Views.parseQueryString($(this).attr('href')),
// Extract argument data from the URL.
Drupal.Views.parseViewArgs($(this).attr('href'), settings.view_base_path),
// Settings must be used last to avoid sending url aliases to the server.
settings
);
However, the final "settings" has views_args in it already, so even though Drupal.Views.parseViewArgs returns the correct argument for the url ( say: "A" in this case ), it is overriden to empty string "".
For a quick fix I added this to the click function:
$(this).click(function () {
$.extend(viewData, Drupal.Views.parseViewArgs($(this).attr('href'), settings.view_base_path));
Attached is an initial patch until I can look deeper for the correct fix, or perhaps this is already fixed in the dev version?
Comments
Comment #1
dawehnerDebug, should be removed :)
I'm on crack. Are you, too?
Comment #2
Souvent22 commentedYou are correct. I thought I already had. apologies. Updated patch.
Comment #3
Coupon Code Swap commentedahhhh. perfect! i wasted a bunch of time trying to debug this myself. should have just looked here first :)
Comment #4
Souvent22 commentedLike some feed back from the maintainers on this as they probabley have a better picture of the overall arch./conventions they like to stick to. But, should we move the assigning of the args and base-href to the location my patch suggests? This would also allow in theory other jquery functions to manipulate the hrefs/achorlinks providing a bit more flexibility and methods of extending the base core?
Or, should I look further up the ladder as to why view_args comes in pre-set.
Asking as instead of assuming what the correct frame work is here, especially with views 3 on the horizon, etc. best to ask :).
Comment #5
dawehnerUpdate status.
I can review the error, the patch was broken.
Here is a new version, it fixes here the stuff.
Comment #6
cha0s commentedWorks here, thank you.
Comment #7
merlinofchaos commentedOk, committed to all branches.
Comment #8
Souvent22 commentedThanks merlin:).
Comment #9
daniel wentsch commentedHello guys,
I just applied the patch from #5, but no luck: neither the (unchanged) default glossary view nor my custom one works. Tried both in Garland and my custom theme.
Clicking on a letter brings up the spinning wheel but doesn't change the view. With AJAX disabled everything works as expected.
According to Firebug "view_args" stays always the default one ("a" for the default glossary), I suspect it should change to the letter clicked, right?
Checked in FF3.5 and Opera 10.10. Also verified that the patched ajax_view.js got loaded correctly, caches are cleared etc.
Any ideas? Possibly a conflict with other modules? The site I'm working on is multi-lingual using i18n.
Other modules installed are: admin menu, cck (plus filefield & imagefield), panels, ctools, custom breadcrumbs, devel (deactivated for testing), drupal for firebug, imagecache/imageapi, google maps location, menu editor, nodewords, language sections, fckeditor, menu block, menu breadcrumb, imce, pathauto+token, text resize, transliteration, backup & migrate.
Regards,
Daniel
PS: deactivating "admin menu" and "drupal for firebug" didn't help neither
PPS: on another drupal installation (on another server) everything works, even without patching ajax_view.js o_O
PPPS: exporting a working glossary view from another Drupal site and importing it to my current site doesn't work neither :/
4PS: the site on which ajax glossary worked was still using views 2.7. Now it makes a little more sense, but still doesn't work.
5PS: update to views-6.x-2.x-dev (from Jan 18th) doesn't help neither. Going crazy soon :(
Comment #10
cha0s commentedwentsch, can you show us a site where you are seeing this behavior?
Comment #11
daniel wentsch commentedI'm sorry, but unfortunately it's a development site that's not launched yet and I'm not allowed to make the link public :(
Comment #12
dawehnerThen try to reproduce this error on a clean site. Then you can publish a link to this site.
Comment #13
daniel wentsch commentedOkay, I think I'm close to the root of the problem.
The problem is connected to the use of path prefixes for languages. When I changed settings to the default language to have no path prefix, AJAX paging works for the default language but the problem remains on other languages that use a path prefix.
This seems not to be a new issue: http://drupal.org/node/333163
Although back then another version of i18n (i18n-6.x-1.0-beta6) seems to have fixed it. Today, using i18n-6.x-1.2 the problem is just the same. Confusing.
Comment #14
digidoo commentedI applied the patch #8 which fixed ajax paging for the default language, but still having problems when switching the language (path prefix in use) as described in #13.
You may check it out yourself at www.tie-netherlands.nl. Go to Archives->Glossary and then switch language to Nederlands.
Comment #15
udig commentedsubscribe
Comment #17
gmreed commentedSubscribing (?) - I see that this issue has been automatically closed. Can anyone tell me whether there has been any resolution? I am developing a site and experiencing the same problem as described in #13 and #14 (and demonstrated at the linked site).
Comment #18
merlinofchaos commentedYes, in #7 I committed the patch, which went out in Views 2.9 and later.
Comment #19
nicholas.alipaz commentedI am not really sure where the issue is but I still see this issue in 2.x-dev and 3.x-alpha3. Can someone confirm this?
Comment #20
merlinofchaos commented'needs review' means there is a patch attached. You did not attach a patch. What you meant was 'active'.
If you are experiencing a problem, rather than re-opening a closed issue with an incorrect status, you should open a new issue and attempt to describe the problem completely, preferably with instructions so that someone can duplicate the issue and investigate it.
Comment #21
nicholas.alipaz commentedhhmmm, sorry. I reopened as needs review since there was already a patch in this thread that seems as though it did not correctly fix the issue, and henceforth it "needs to be reviewed again." I will however open my own ticket if that is what you prefer. Thanks and sorry for any confusion.
Comment #22
merlinofchaos commentedThe patch in the ticket had already been committed. Patch review, in our workflow, is a very specific term, where we are reviewing a potential patch for inclusion. Problems with patches are bugs -- and from the sound of it, it's not clear that your bug is actually related to the patch. File the new issue, hopefully we can get it figured out.
Comment #23
Marko B commentedI have problems here that are similar, probably same origin.
http://drupal.org/node/1160412