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

dawehner’s picture

+++ ajax_view.js	(working copy)
@@ -122,6 +122,8 @@
+                console.log(viewData);

Debug, should be removed :)

I'm on crack. Are you, too?

Souvent22’s picture

StatusFileSize
new486 bytes

You are correct. I thought I already had. apologies. Updated patch.

Coupon Code Swap’s picture

ahhhh. perfect! i wasted a bunch of time trying to debug this myself. should have just looked here first :)

Souvent22’s picture

Like 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 :).

dawehner’s picture

Status: Active » Needs review
StatusFileSize
new493 bytes

Update status.

I can review the error, the patch was broken.

Here is a new version, it fixes here the stuff.

cha0s’s picture

Status: Needs review » Reviewed & tested by the community

Works here, thank you.

merlinofchaos’s picture

Status: Reviewed & tested by the community » Fixed

Ok, committed to all branches.

Souvent22’s picture

Thanks merlin:).

daniel wentsch’s picture

Hello 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 :(

cha0s’s picture

wentsch, can you show us a site where you are seeing this behavior?

daniel wentsch’s picture

I'm sorry, but unfortunately it's a development site that's not launched yet and I'm not allowed to make the link public :(

dawehner’s picture

Then try to reproduce this error on a clean site. Then you can publish a link to this site.

daniel wentsch’s picture

Okay, 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.

digidoo’s picture

I 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.

udig’s picture

subscribe

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

gmreed’s picture

Subscribing (?) - 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).

merlinofchaos’s picture

Yes, in #7 I committed the patch, which went out in Views 2.9 and later.

nicholas.alipaz’s picture

Status: Closed (fixed) » Needs review

I 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?

merlinofchaos’s picture

Status: Needs review » Closed (fixed)

'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.

nicholas.alipaz’s picture

hhmmm, 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.

merlinofchaos’s picture

The 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.

Marko B’s picture

I have problems here that are similar, probably same origin.

http://drupal.org/node/1160412