[calandar] AJAX navigation in month view

I thought we already had an issue about this, but I can't find it, so we'll make this a feature request.

I'm hoping someone will dig into this and provide a patch.

You need to try to figure out what the Views ajax code is doing and use that. The previous patch used code that had nothing to do with Views so I doubt it's usable.

Also look at #339295: Minor fix to allow multiple ajax-paged views on a page since it's possible that may be an issue that will affect this, since we grab block and embedded view information from a querystring in the url.

updated the version to the current one, as the issue still exists

I'm pretty sure the views module uses AJAX just for pagination, and this is a bit different from normal pagination. I can't think of a good way to make Views 2's ajax support work for calendar, at least not in its current form :(

Is there any chance that the new (2.x for D6) Calendar module can be updated to include its own ajax again? It seems like it would only require a theme update...

Here's a small patch for starters. It works with the Calendar block display of the calendar view when you set Use AJAX to yes (override the default setting). It doesn't work with the page display but I'm sure it won't take much to fix that.

There's not much to it - the js include bit in theme.inc and a new js file which attaches a js method to the next and previous links in almost exactly the same way as a regular views pager which by some fluke seems to work. I've tested that it works independently of other AJAX views on the page including other calendar block displays.

I'll try to improve on what's here - but this patch should serve an immediate need.

Andy

provided patch works for me and serves my immediate need :) Thanks

subscribing

The upcoming block has no pagination ajax or read more link .. am I the only person getting this?

Patch from #6 works but as he said, calendar page view doesn't work

This would be extremely useful. I don't know anything about Views AJAX but I was wondering if a better solution for this might be turning « prev next » into a pager? Because views already supports AJAX on pagers.

I can't get this to work - question - all you need to configure (besides applying patch) is setting Ajax for JUST block to 'yes'? Or should I set it to yes on the 'date browser' attachment as well?

seems patch from #6 doesn't work with the latest dev release of calendar module. patch applies but block is still "unajaxified"

:(

ha! found the "bug" - patch creates the ajax_calendar_views.js in calendar module root directory and looks for the file in "js" subfolder...

great! hope this patch becomes comitted to cvs an gets "in" the module...

now only the monthly/weekly/... view needs to be "ajaxified" :)

thanks for the patch!

Calendar AJAX views work great once the ajax_calendar_views.js file is in the js directory.
Tested with pages with daily, weekly and month views and months in blocks.

#6 is broken for full page views at least. It will navigate one month, but navigation links are broken after that. Also the patch is rolled wrong -- relative paths aren't right

Planning on working on this today

subscribe

Any news on the patch? :)

Doesn't look like it

OK so maybe I didn't work on it the day I thought i was, but I did today:D

This patch is the same as previous patches plus a fix to jcalendar.js to use drupal behaviors. This allows it to re-apply on ajax updates.

The bummer is that this requires a date api patch to make it work. Here's the issue: #538300: Date Navigation preview should not trigger views "embed" URL

Both patches applied (against latest dev of calendar and date) and all works for me ... blocks pages, embeds (with some caveats on embeds)

Oops, here's the patch.

Thank you for the patch. I am, however, seeing 2 problems:

1) I have a mini calendar block displayed on my pages. Ajax generally works fine on it. BUT, when it's displayed on a page that is ITSELF a calendar view then using the mini-calendar's ajax controls results in unexpected behavior.

For example: consider a calendar view that displays events from a specific day (/calendar/2009-07-09). The mini calendar month block on that page initially renders just fine, but it seems as though the previous and next navigation javascript is being generated using the date being shown in the main portion of the page rather than the date for the mini-calendar block. The actual LINKS for previous and next are correct and if I turn off javascript then all works as expected, but if I allow the ajax behavior to occur then, instead of getting the previous or next month in my mini-calendar block, I instead get a header indicating the previous DAY (July 8, 2009) and no calendar content. The same thing happens if I attempt to use the mini calendar on a page that's showing a year view (/calendar/2009).

2) Even when the mini-calendar's ajax nav works there's an issue with the calendar's header link. It's supposed to link to whatever month you're viewing but instead it always links to the current month. The problem seems to be that the $view->date_info->url variable is populated incorrectly (seems to always pull from the default view arguments rather than the mini-view argument). I wouldn't be surprised if this argument conflict is what's causing #1 as well. EDIT: in fact, with a bit more investigation it appears that, in javascript, the wrong view_path is being ascribed to the ajaxView object for the mini calendar. The correct view_args are coming through, but the wrong view_path. It would seem that that is what needs fixing.

BTW: I'm rather new to Drupal so I apologize if I'm using incorrect terms anywhere here. Also, what do you mean by "embeds" when you say "Both patches applied (against latest dev of calendar and date) and all works for me ... blocks pages, embeds (with some caveats on embeds)"?

Many thanks.

Yeap that's definitely broken. I don't have much time right now .. but could you help me by determining if the problem exists without ajax loading enabled?

If I disable ajax then problem #1 is fixed but problem #2 still applies.

I can fix problem #2 fairly easily by making some alterations to the theme_date_nav_title function. $view->date_info->url is sent to that function with the url arguments *from the main calendar view* still intact but the function treats it as though it's coming WITHOUT any arguments, let alone the mini-cal arguments. But fixing it in theme_date_nav_title isn't going to be the solution; I'm looking further upstream to see where the $view->date_info->url is being populated as it would seem as though fixing it in the view object should probably fix it downstream when the javascript gets created. I'm assuming the basic problem is that the calendar view object is created and automatically pulls its arguments from the url if they're available regardless of whether or not it's a mini calendar. So we need to make the mini-calendar view ignore the regular calendar view url arguments somehow. I'm rather new to all this so it's slow going for me to figure this out and I'm not yet sure if it's the Date, Calendar, or View module that's the offending party.

subscribe

subscribing

subscribing

subscribing

Here is a client side solution to ajaxify the "next/prev" links for all calendar views.

It is a work in progress but should work without any modifications to your code.

To use this code you can include it as a js file in your theme, or put it in the header of the default calendar view with full html input format.

<script type="text/javascript">
$(document).ready(function() {
$.ajaxSetup ({cache: false});
// Display animated loading gif during the load event
var loading = "<center><img class='loading' src='/sites/dev/js/ajax-loader.gif' alt='loading...' /></center>";
function nextLoad(){	
	// Get the nextURL from the pagers next link 
	var nextUrl = $(".calendar-calendar .date-next a")[0].href;  	
	// Identify the content/container you wish to replace
	$(".view-calendar")
	// Add the loading image
	.html(loading)
	.css({ opacity: 0 }).fadeTo("normal",1)
	// Load the nextUrl + return the specific content by specifing the css class or id + bind the click function tp the newly loaded content
	.load(nextUrl+ ".view-calendar .calendar-calendar", bindClick );
};
function prevLoad(){	 
	var prevUrl = $(".calendar-calendar .date-prev a")[0].href;  
	$(".view-calendar")
	.html(loading)
	.css({ opacity: 0 }).fadeTo("normal",1)
	.load(prevUrl+ ".view-calendar .calendar-calendar", bindClick );
};
function bindClick(){
	$(".date-prev a").click(function(){  							 
	prevLoad();
	return false;
	});
	$(".date-next a").click(function(){  
	nextLoad();
	return false;
	}); 
};
// Append the click function to the on the initial page load
bindClick();
});
</script>

Hope this helps, it's a short-term solution, but adds a powerful level of interaction, and doesn't break the calendar for users without javascript enabled.
Enjoy!

Nice! Other than being a bit slow to load (but that's probably just my server), it works like a charm. Thanks for this!

subscribe

Nice script, just remember to change the jQuery selectors if you intend to use it on another view, and also upload the gif loader.

subscribe

According the the console:

XHR finished loading: "http://www.unca.org/home?mini=calendar-date%2F2009-10.view-calendar&_=12..."

But, nothing happens. The view of the calendar stays exactly the same. Am I missing something?

This is still, overall, a feature request. Not a support request.

I think that this is issue with classes. Check HTML and see what class is on calendar. On my setup I located that "views-calendar-date" is correct class instead of "views-calendar". Hope this helps.

Subscribe

I'm not sure, but latest js script basically loads full new page but because of the script it looks like page haven't been reloaded?

That's correct -- full new page is loaded in background.

subscribing.

subscribing.
Currently the block from the event module is clearly a better choice, but the event module itself doesn't work with CCK Date field and iCal parser :(

Is there a way to avoid load the whole page? For instead, load the calendar only. Please help. Thanks.

I think if you load the data from the Views AJAX url, you can avoid loading the whole page...

http://www.example.com/views/ajax?[params]

Then you get a JSON response though... Good luck trying to figure out what variables to pass and how to parse the JSON.

Subscribing

I had the same problem, and the patches submitted were too inelegant for my tastes or didn't work. #43 - earthday47 was on the right track. After setting up a normal, dummy view with ajax pagination support and watching firebug's console, it's actually pretty straightforward. I didn't even have to look at any views code, php or ajax. Without further ado, my own solution.

1) Properly scoped - will not mess with other calendars (or anything else)
2) Actually uses ajax - it uses Views' own ajax endpoints and interfaces, unlike the solution above that loads a whole page
3) Uses the Drupal JS object properly for it's own variables
4) Tested in FF and IE8: It's all JS (and mostly jquery), so I assume it works everywhere else too
5) Assumptions: you are using a month view, it's initially loaded with the date argument "Now",you haven't messed with the stock CSS classes the calendar normally has, and you of course have JS and jquery enabled
6) How to use: make a template override file for the overall view (e.g. views-view--events-calendar.tpl.php) and paste this in, and enable ajax for your view (it also works if you have any other ajaxified views on the page... as long as the proper views JS variables exist, it will be ajaxy).

Unfortunately, because it uses PHP tags, I can't put it in a code tag, because either the forum thinks it's PHP and displays it out-of-flow, or all the formatting gets ruined if I use > and the like, so you'll actually have to look at the file (horrors). I'd give you a patch file as well, but I'm not on a *nix machine at the moment. Comments included for clarity. Enjoy.

TODO:

- Rummage through that huge $view object and find out what arguments were actually used to construct the current view, and make the JS account for it instead of assuming it is initialized to this month, and that way we don't need to keep a parallel set of JS variables to keep track of where we are
- Find where in the $view object we can find out what kind of display this is (month, week, whatever), and mangle the previous and next parameters accordingly instead of assuming it's a monthly calendar
- Include a spinner for ui niceness

Kudos gestahl, nice job!
There's just one thing I had to change in the script:

Drupal.settings.ajax_path should be Drupal.settings.views.ajax_path

This is to be changed both in the initial if statement and in url: Drupal.settings.ajax_path.
There's a 3rd occurrence in url:ajax_path. This is to be changed too in Drupal.settings.views.ajax_path

That's about it.
Thanks

Subscribing

#45 is awesome! The only problem I currently have is I have my $scripts output at the bottom for performance... so if I use this as a views template, jquery is not yet loaded and thus no dice.

I'm going to try and rewrite/modify and see I can get it as a drupal_add_js. Yes, I know that means there can be scope issues... but I only need this for one display, so I'm fine with hard coding the jquery selector.

Here is an update/modification to #45 that can be added as a drupal_add_js. Please note that lines #4 and #5 have to be modified to your particular view. For me, I know exactly what view I'll be using in this particular page and it works every time. Your mileage may vary.

Thanks to gestahl for doing all the heavy lifting. I just applied some spackle...

Oops. I had to "alerts" still in this file. Here is the file without them...

Slightly enhanced it so it works with the block view as well, also if there is multiple views with ajax feed.
(the customization at the end of the file now)
if you put it eg. [..]/calendar/js/
you can add this line on the top of "calendar.module"
drupal_add_js(drupal_get_path('module', 'calendar') . '/js/calendar_ajax_add.js');

Still TODO:

- Rummage through that huge $view object and find out what arguments were actually used to construct the current view, and make the JS account for it instead of assuming it is initialized to this month, and that way we don't need to keep a parallel set of JS variables to keep track of where we are
- Find where in the $view object we can find out what kind of display this is (month, week, whatever), and mangle the previous and next parameters accordingly instead of assuming it's a monthly calendar
- Include a spinner for ui niceness

Sub

Today i had two hours to play with it, so now it recognizes the different calendar views and the types in a basic way (and except the weeks) but still long way to go, because it still ruins the links (Year Month Week Day on the top) like the previous versions.

Ok should work now for all kind including weeks.
Should work for the default calendar views (i havent tested if you clone them, but even if doesnt work should be easy to add them as well)

you just need to add this line to eg. the calendar views header (in the Views edit screen) or any other place:
drupal_add_js(drupal_get_path('module', 'calendar') . '/js/calendar_ajax_add.js');
and copy this attachment accordingly.

#54 works weel for the prev/next navigation links.
Is this possible to add AJAX to the Year, Month, Week, Day links, too?

subscribing.

#54 works indeed, but I noticed it seems to break everything javascript related on the admin side of my site (not on the public side, though). Or am I doing something wrong? I just copied the js file to the modules/calendar/js directory, and copied the drupal_add_js line to the beginning of calendar.module.

Subscribing

@54
and copy this attachment accordingly.

What exactly does that mean? If someone could make this a little bit clearer....

Thanks for working on this rather important issue (special props to @radicsge). This functionality NEEDS Ajax, can't believe nobody pressed for this before.

I have converted the @radicsge solution in a formal patch.

I added
- some Drupal styling to the js
- added namespace functions
- load js as drupal.behavior
- visual indicators of ajax loading.

Now the js is loaded in the calendar theme if the view has ajax active, and adds the views name as a setting to be used by the js.
Original patch only worked if your views was calling a views with the name calendar.

I have tested with years, months, weeks, days, in page and in blocks, and it works fine.

Thank you @radicsge

It only works with all the displays of the same views in a page. (only it's attached to a view) if you have in a page different calendars from the same view it works fine.
But if you have calendars from different views in the same page, it only works with the calendars of first defined view.
The javascript have some issues attaching to different views.
Probably the code would require more work but it is a good starting point.

Please test it

@jcmarco:
Applied the patch, but the next/prev links not works. I get the animated loading icon, but I think that the AJAX url is wrong:
http://localhost/?js=1&view_name=calendar&view_display_id=calendar_1&vie...

(I run Drupal in a subdirectory.)

Yeah, this goes very much in the right direction.

Findings: Works great as long as only one item of the view is displayed. If I have a calendar block on a page displaying the day view (for example) both fail to use ajax. Not sure if that is what is meant in #59. I expected them to do fine but that may have been a misunderstanding of the above post.
So this is a great step forward.

Sadly ajax is still not working if I display the block in a panel. There is a related issue about panel problems: #395936: Date browsing doesn't work indside a panel pane

So if we could get ajax to work in panels this would be extra-great.

I made a clean up at the code and fix and simplify some parts of the patch.
I have tested this version with two different views and two different displays, I mean 4 views with calendars, and in a panel, plus a side block with a calendar view.
All of them worked together and fine.

Please test it.

Well, I don't know what to say about this patch...

This thing is totally rockin', LeBron-like-unstoppable, sunny-day-after-weeks-of-rain GREAT!

Confirmed that: Various display of various views on the same page work fine.

AND: Ajax for blocks in panels. Even with various displays of various views.

jcmarco,

thank you very much!

@jcmarco: Thanks for the work. I apllied the patch and I have the following problems:

1) My Drupal installed in a subdirectory. I'm using the calendar in a panel.
The following code set ajax_path to '/' in my case. This is wrong and the real path is the Drupal.settings.views.ajax_path value.

var ajax_path       = (Drupal.settings.views.ajax_path[i] ? Drupal.settings.views.ajax_path[i] : Drupal.settings.views.ajax_path);

So I changed this to:

var ajax_path       = Drupal.settings.views.ajax_path;

2) The calendar works if I only use the prev and next links.

3) If I change to week / year view, then the ajax functionality goes away and the whole page reloaded.

4) If I use prev/next ajax links and AFTER click on a week view, the page is filled with an ajax json response.

For example the week view link was before the next link clicked:
http://localhost/matine3/programok?mini=calendar%2F2010-W18

And after I click on the next link the week view's link changed to:
http://localhost/matine3/views/ajax?js=1&view_name=calendar&view_display...

If I click on this link I get the json result.

4) If I use prev/next ajax links and AFTER click on a week view, the page is filled with an ajax json response.

Confirmed. Firefox fills the screen with the response. If I use IE 8 it tries to download the "AJAX" file...

3) If I change to week / year view, then the ajax functionality goes away and the whole page reloaded.

Scanning through this issue: Was that the scope of this patch? Or is it only aimed at the navigation links?

subscribe

subscribe

The problem in #64 under 4 definitely needs to be addressed. I love this patch already because it adds this valuable feature but normal users are very likely to encounter the problematic behavior.

To reproduce simply use the prev/next links and click on Day, Week or Year afterwards. Kaboom!

If someone drives this home loads of good karma are waiting. ;)

subscribing

I am sorry but I am quite new at this kind of missions.
What do i need to do with the patch?
Atach it where?

Thank you

@ 70

http://drupal.org/patch/apply

Hi,

This line is supposed to test whether the ajax_path is an array or not, though it is wrong

var ajax_path = (Drupal.settings.views.ajax_path[i] ? Drupal.settings.views.ajax_path[i] : Drupal.settings.views.ajax_path);

the correct line would be:

var ajax_path = ((Drupal.settings.views.ajax_path instanceof Array) ? Drupal.settings.views.ajax_path[0]:Drupal.settings.views.ajax_path);

since if you have more then one view with ajax behaviour the ajax_path will be array if there is only one,
then it is a string.

subscribe

@72

Is this change supposed to fix the issue with the ajax response described in #64 (4)?

this patch address the #64:1 and 4
also has a bugfix, I can fix 3 but not sure is it a proper fix so i prefer not to do.

Thank you for tackling this. Looking forward to test the patch.

As about problem #3 I don't think this should be done in this patch. It seems to me like an added feature and should be done separately.

Ok, did some testing. Applied the patch against the latest dev. Using js and css aggregation.

1. Ajax seems to work and I definitely don't get the problem with the ajax response on screen. The former is true for the calendar views and the latter for all circumstances i tested so far.
However the problem are calendar blocks (see point also point 2). Calendar blocks seem to be ajaxing fine but when they are at the bottom of a site they kick me back to the top after loading. This wasn't the case with the old patch.
Something else "suspicious": With the old patch I get the "ajax-wheel" after clicking a link (in FF) but now the browser tab indicates a new page load. In addition the browser chronicle shows new page visits for every supposed ajax job. This isn't the case with the old patch either.

This makes me think that the ajax only seems to be working properly.

2. This patch definitely does not work with multiple calendar blocks on the same page/panel. It "syncs" them so that all calenders change the month when I click on a navigation link.

about 1, i need more help, because it does work for me :| (do you have a link? or can you give me a more detailed description? you can send me by mail as well.)
about 2, it is not related with the patch, since they have the same name it would be very hard to distinguish them. Instead you should make a new block calendar in views and use that then it should work.

and thanks for testing!

Sorry, but I am working on local installs to test this out. I hope I can give you something useful nevertheless.

missing } in compound statement
calendar_ajax.js line 132 (actually in an aggregates js file but after disabling aggregation it showed this line. Not able to recreate with no aggregation on now so it is a bit strange.

I get this during usage of navi links.

If I let firebug stop the script when it breaks the problematic code seems to be line 27 (or 29 sometimes):

jquery not defined

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
2<html xmlns="http://www.w3.org/1999/xhtml" lang="de" xml:lang="de">
3
4<head>
5<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
6 <title>read more test | HouseOfStudents</title>
7 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
8<link type="text/css" rel="stylesheet" href="http://fonts.googleapis.com/css?family=Lobster|Vollkorn|Yanone+Kaffeesatz" />
9<link rel="shortcut icon" href="/acquia-drupal/sites/all/themes/acquia_marina/favicon.ico" type="image/x-icon" />
10 <link type="text/css" rel="stylesheet" media="all" href="/acquia-drupal/modules/acquia/admin_menu/admin_menu.css?7" />
11<link type="text/css" rel="stylesheet" media="all" href="/acquia-drupal/sites/default/files/css/css_8f272623a60b1b1c92380df252b9a1ff.css" />
12 <link type="text/css" rel="stylesheet" media="all" href="/acquia-drupal/sites/all/themes/fusion/fusion_core/css/grid16-960.css" />
13 <!--[if IE 8]>
14 <link type="text/css" rel="stylesheet" media="all" href="/acquia-drupal/sites/all/themes/fusion/fusion_core/css/ie8-fixes.css" />
15<link type="text/css" rel="stylesheet" media="all" href="/acquia-drupal/sites/all/themes/acquia_marina/css/ie8-fixes.css" />
16 <![endif]-->
17 <!--[if IE 7]>
18 <link type="text/css" rel="stylesheet" media="all" href="/acquia-drupal/sites/all/themes/fusion/fusion_core/css/ie7-fixes.css" />
19<link type="text/css" rel="stylesheet" media="all" href="/acquia-drupal/sites/all/themes/acquia_marina/css/ie7-fixes.css" />
20 <![endif]-->
21 <!--[if lte IE 6]>
22 <link type="text/css" rel="stylesheet" media="all" href="/acquia-drupal/sites/all/themes/fusion/fusion_core/css/ie6-fixes.css" />
23<link type="text/css" rel="stylesheet" media="all" href="/acquia-drupal/sites/all/themes/acquia_marina/css/ie6-fixes.css" />
24 <![endif]-->
25 <link type="text/css" rel="stylesheet" media="all" href="/acquia-drupal/sites/all/themes/acquia_marina/css/local.css" />
26 <script type="text/javascript" src="/acquia-drupal/sites/default/files/js/js_2e67efbe74e94d73b7d08f4969ff0c3c.js"></script>
27<script type="text/javascript">
28<!--//--><![CDATA[//><!--
29jQuery.extend(Drupal.settings, { "basePath": "/acquia-drupal/", "admin_menu": { "margin_top": 1 }, "fivestar": { "titleUser": "Eigene Bewertung: ", "titleAverage": "Durchschnitt: ", "feedbackSavingVote": "Bewertung wird gespeichert...", "feedbackVoteSaved": "Die Bewertung wurde gespeichert.", "feedbackDeletingVote": "Bewertung wird gelöscht...", "feedbackVoteDeleted": "Die Bewertung wurde gelöscht." }, "lightbox2": { "rtl": "0", "file_path": "/acquia-drupal/(\\w\\w/)sites/default/files", "default_image": "/acquia-drupal/modules/acquia/lightbox2/images/brokenimage.jpg", "border_size": 10, "font_color": "000", "box_color": "fff", "top_position": "", "overlay_opacity": 0.8, "overlay_color": "000", "disable_close_click": true, "resize_sequence": 0, "resize_speed": 400, "fade_in_speed": 400, "slide_down_speed": 600, "use_alt_layout": false, "disable_resize": false, "disable_zoom": false, "force_show_nav": false, "loop_items": false, "node_link_text": "View Image Details", "node_link_target": false, "image_count": "Image !current of !total", "video_count": "Video !current of !total", "page_count": "Page !current of !total", "lite_press_x_close": "press \x3ca href=\"#\" onclick=\"hideLightbox(); return FALSE;\"\x3e\x3ckbd\x3ex\x3c/kbd\x3e\x3c/a\x3e to close", "download_link_text": "Download Original", "enable_login": false, "enable_contact": false, "keys_close": "c x 27", "keys_previous": "p 37", "keys_next": "n 39", "keys_zoom": "z", "keys_play_pause": "32", "display_image_size": "", "image_node_sizes": "()", "trigger_lightbox_classes": "", "trigger_lightbox_group_classes": "", "trigger_slideshow_classes": "", "trigger_lightframe_classes": "", "trigger_lightframe_group_classes": "", "custom_class_handler": 0, "custom_trigger_classes": "", "disable_for_gallery_lists": true, "disable_for_acidfree_gallery_lists": true, "enable_acidfree_videos": true, "slideshow_interval": 5000, "slideshow_automatic_start": true, "slideshow_automatic_exit": true, "show_play_pause": true, "pause_on_next_click": false, "pause_on_previous_click": true, "loop_slides": false, "iframe_width": 600, "iframe_height": 400, "iframe_border": 1, "enable_video": false }, "CTools": { "pageId": "page-7f40249dc1a002f1506349e1097930d3" }, "cron": { "basePath": "/acquia-drupal/de/poormanscron", "runNext": 1275563467 }, "user_relationships_ui": { "loadingimage": "/acquia-drupal/de/sites/all/modules/user_relationships/user_relationships_ui/images/loadingAnimation.gif", "savingimage": "/acquia-drupal/de/sites/all/modules/user_relationships/user_relationships_ui/images/savingimage.gif", "position": { "position": "absolute", "left": "0", "top": "0" } }, "calendar_ajax": { "calendar_event": "ajax_calendar", "calendar_date1": "ajax_calendar", "calendar_datexy": "ajax_calendar" }, "views": { "ajax_path": [ "/acquia-drupal/de/views/ajax", "/acquia-drupal/de/views/ajax", "/acquia-drupal/de/views/ajax" ], "ajaxViews": [ { "view_name": "calendar_event", "view_display_id": "calendar_block_1", "view_args": "2010-06", "view_path": "node/115", "view_base_path": "calendar-eventdate", "view_dom_id": 2, "pager_element": 0 }, { "view_name": "calendar_date1", "view_display_id": "calendar_block_1", "view_args": "2010-06", "view_path": "node/115", "view_base_path": "calendar-date1", "view_dom_id": 4, "pager_element": 0 }, { "view_name": "calendar_datexy", "view_display_id": "calendar_block_1", "view_args": "2010-06", "view_path": "node/115", "view_base_path": "calendar-datexy", "view_dom_id": 5, "pager_element": 0 } ] } });
30//--><!]]>
31</script> 

On my other install line 30 (guess this varies from time to time about a couple of lines):

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
2<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
3
4<head>
5<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
6 <title>seite2</title>
7 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
8<link rel="shortcut icon" href="/sites/all/themes/acquia_marina/favicon.ico" type="image/x-icon" />
9 <link type="text/css" rel="stylesheet" media="all" href="/modules/acquia/admin_menu/admin_menu.css?I" />
10<link type="text/css" rel="stylesheet" media="all" href="/sites/seite2.localhost/files/ctools/css/4a1151955127fcbf185c57db56546d18.css?I" />
11<link type="text/css" rel="stylesheet" media="all" href="/sites/seite2.localhost/files/ctools/css/0fcbbd4247d141e23faf6b77920f87bd.css?I" />
12<link type="text/css" rel="stylesheet" media="all" href="/sites/seite2.localhost/files/css/css_af1db58f2721b0b8013073adef918b95.css" />
13 <link type="text/css" rel="stylesheet" media="all" href="/sites/all/themes/fusion/fusion_core/css/grid16-960.css" />
14 <!--[if IE 8]>
15 <link type="text/css" rel="stylesheet" media="all" href="/sites/all/themes/fusion/fusion_core/css/ie8-fixes.css" />
16<link type="text/css" rel="stylesheet" media="all" href="/sites/all/themes/acquia_marina/css/ie8-fixes.css" />
17 <![endif]-->
18 <!--[if IE 7]>
19 <link type="text/css" rel="stylesheet" media="all" href="/sites/all/themes/fusion/fusion_core/css/ie7-fixes.css" />
20<link type="text/css" rel="stylesheet" media="all" href="/sites/all/themes/acquia_marina/css/ie7-fixes.css" />
21 <![endif]-->
22 <!--[if lte IE 6]>
23 <link type="text/css" rel="stylesheet" media="all" href="/sites/all/themes/fusion/fusion_core/css/ie6-fixes.css" />
24<link type="text/css" rel="stylesheet" media="all" href="/sites/all/themes/acquia_marina/css/ie6-fixes.css" />
25 <![endif]-->
26 <link type="text/css" rel="stylesheet" media="all" href="/sites/all/themes/acquia_marina/css/local.css" />
27 <script type="text/javascript" src="/sites/seite2.localhost/files/js/js_e1e845e4c998e4c5f08d92f3725ade38.js"></script>
28<script type="text/javascript">
29<!--//--><![CDATA[//><!--
30jQuery.extend(Drupal.settings, { "basePath": "/", "admin_menu": { "margin_top": 1 }, "CTools": { "pageId": "page-f09681ab8c1160b52bf053152bd2c157" }, "calendar_ajax": { "calendar_date2": "ajax_calendar", "calendar_date3": "ajax_calendar" }, "views": { "ajax_path": [ "/views/ajax", "/views/ajax" ], "ajaxViews": [ { "view_name": "calendar_date2", "view_display_id": "calendar_block_1", "view_args": "2010-06", "view_path": "test", "view_base_path": "calendar-date2", "view_dom_id": 1, "pager_element": 0 }, { "view_name": "calendar_date3", "view_display_id": "calendar_block_1", "view_args": "2010-06", "view_path": "test", "view_base_path": "calendar-date3", "view_dom_id": 2, "pager_element": 0 } ] } });
31//--><!]]>
32</script>
33</head> 

Please advise me what to look for and I can help.

About 2): I am using blocks of different views. Sorry if I wasn't clear. It was working with the old patch so the new one seems to make some changes in this regard.

About 2, it is my mistake, this patch should fix it.
About 1, if the error is "jquery not defined" than it is not related with this patch. This compressed file:
/sites/seite2.localhost/files/js/js_e1e845e4c998e4c5f08d92f3725ade38.js should contain the jquery. It should be the first. You can check. If not there check without compression.

(Compressed js also works for me.)
Let me know how can i help more.

It looks more ajaxy on a new site now although I still have my doubts. No "ajax-wheel" and my browser notes new site visits. The original patch in #62 worked this way.

However the calendar blocks of different views still are sync'ed. Different displays of different views are working fine though (calendar block A + month view B).

Firebug sees a break: missing } after function body (calendar_ajax.js?7 [line 132])

I hope my other installs are simply to messed up to work properly but I don't want to test it on my "best" install (near production site). Thanks for your efforts!

edit: I'll give it a new shot tomorrow on a cleaned up system. Somehow js aggregation is totally messed up on my local installs....

hi!
It would be good if you send/post the content of the calendar_ajax.js even as a txt file.
To me it seems the cause of no "ajax-wheel" and page refresh is the broken js file, but then it is not clear how it is ajaxy otherwise.
What is strange that i also test on FF and Opera and nothing come up in the firebug for me. BTW to test it is enough if you copy the calendar directory and apply the patch (it onyl changes one file and create another) if doesnt work just delete the dir and copy back the original calendar dir.

I attached the calendar_ajax.js.

I am going to test it some more this afternoon. Those local installs of mine are acquia stack multisites, so if something is severly messed up there it is likely to affect all my installs. So I am going to check on a different system.

This isn't working on my other system either. Reverted back to the calendar version with the patch by jcmarco and ajax is fine (apart from the known problems).

Some testing by someone else would be nice....

seems to me you miss like 5 lines from the end of the file
after the return false;
can you please verify this to me?

Just patched again to see if something went wrong but everything seems ok. I confirm that calendar_ajax_js ends after return false; .

Thx for your endurance!

np at least we hopefully getting closer!
then try to add this line to the end of your js file after return false:
});$(view_scope + ' .calendar-calendar .date-next a').addClass('calendar-ajax-processed');}}

it is originally in the patch so I dont know what went wrong.
Ic it is my unexperience to create patches i will attach the correct one

So the problem was that i didnt create a new patch when i added a change but rather edited the patch by hand but didnt increased the number of lines of the new file. So as i've added 5 lines, the last 5 was skipped. It is my fault then. Thanks really for your endurance as well, on my mistake!

Hopefully it will work this time.

Awesome. Patch applied nicely and seems to work as advertised. I am going to try and break it but so far it looks good.

Again: Some review from someone else would be nice.

#88 is working.

It is the only one to work with my settings.

A very small thing : the ajax whell would be better placed if she was before the >>
I mean, I don't like having the wheel moving the nav link during loading.

Anyway great job.

Three people have it working, no one complained. I am setting it to RTBC so that the maintainers notice this great improvement.

i'm number 4: nice patch!
plz commit to DEV :-)

I am sorry because I arrived late to the party.
Hopefully this time we were able to solve this feature.

The #88 patch has problems with IE. There are some know issues with commas.

There are no more changes than the IE fix, but this patch works great.

patched by hand in my stable install, works perfectly !
exactly what i needed
great job, thx

tried #88 and #93 and next and previous buttons still don't work

Patch is working fine (still). I cannot judge the changes made due to IE but I have trust in jcmarco. Because the last patch was rtbc and this one still works I am going to bump this back to rtbc.

@#95
Did the patch apply cleanly? Are you patching the latest dev? Have you flushed the caches? I seriously doubt that the patch is broken when we have constant replies that it is working nicely.

Two things that may be causing it -
AJAX needs to be "Yes" in the View itself.
Theme Developer usually interferes with the Javascript, try disabling it if it is on.

Problem - and a solution.

First let me say, the patch in this thread is AMAZING - Major kudos to everyone who worked on the javascript.

BUT it does NOT page correctly in this scenario: Calendar block, month view, and the 'mini' query parameter is sent.

Example:
url http://example.com/?mini=calendar/2010-08
shows August, but the view_args variable will read '2010-06' (current) and NOT '2010-08' like it should.

Which is a bummer since I'm using that query string all over the place.

I have a solution, but it's pretty hacky and probably won't meet everyone's needs. What I did was extract the 'mini' value from the href, and then grab the last part of the string. That's the date (2010-08). First I overwrote the view_args variable, but that doesn't work because the url doesn't refresh after the AJAX response, so it would just return the same month no matter how many times you click. So I actually inserted a new variable on the first load called 'loaded', and then checks that on subsequent paging.

Drupal.behaviors.calendarAjax = function(context) {
  // check only with the views that has the ajax option set on
  // this function only exists if there is some calendar with ajax on
  $.each(Drupal.settings.views.ajaxViews, function(i,settings) {
      // check if the calendar theme has added the views name and then add the ajax feature
      if ( typeof( Drupal.settings.calendar_ajax[settings.view_name] ) != "undefined"){
				query_string = getParameterByName('mini');
				if (query_string) {
					get_args = query_string.split('/');
					mini_date = get_args[get_args.length-1];
					if (Drupal.settings.views.ajaxViews[i].view_args != mini_date && !Drupal.settings.views.ajaxViews[i].loaded) {
						Drupal.settings.views.ajaxViews[i].view_args = mini_date;
						Drupal.settings.views.ajaxViews[i].loaded = true;
					}
				}
        Drupal.Calendar.makeCalendarAjaxy(i);
      }
  });
};

By the way, I had to introduce a new function, getParameterByName(), based on this website: http://stackoverflow.com/questions/901115/get-querystring-with-jquery

It really only works for my needs, I'm sorry. I'm sure there's a better way, but I'm not too familiar with the Drupal Javascript API.
I'm attaching my complete JS file, I hope this helps.

After 6 months of waiting, I want to see this done!

I have not the sufficient understanding to really help with earthday47's issue. But could it be that your problem is slightly out of the scope of the initial request for ajax support in the different displays? I.e. that the request is a kind of addition to the original ajax feature?

If so I would very much like if somebody with the sufficient understanding could set this back to rtbc and earthday's request could get an issue of its own.

I applied the patch in #93, but FF displays:

Drupal.settings.calendar_ajax is undefined
[Break on this error] if ( typeof( Drupal.settings.cal...ettings.view_name] ) != "undefined"){ 

Not sure if I'm using it incorrectly, or missed a step somewhere, but this is what I did and how my view is setup:

(1) cd sites/all/modules/calendar
(2) wget http://drupal.org/files/issues/calendar_ajax_2.patch
(3) patch -p0 < calendar_ajax_2.patch
(4) Added: drupal_add_js(drupal_get_path('module', 'calendar') . '/js/calendar_ajax.js'); to the header in my view
(5) Set Ajax to "Yes" for my view

Attached is the export for my view, in case I'm missing something...

I'm a little confused as well as this is a pretty long thread and the instructions are probably spread out across many posts. (and installing the patches didn't seem to enable ajax). I'm not sure if I'm working with the correct ones or if its not working from some conflict.

I want ajax on the wizard created *view name* calendar-block-1 which is of a type "Calendar Navigation" (generated) and seems to attach "calendar" month view. I only care about the next month arrows without reloading. Is patch 93 to enable ajax on the side block or was it an earlier patch. In the settings, do you turn on ajax for the calendar navigation or the attached block?

So finally after weeks of living good with the patch in #93 I seem to have found a flaw.

When using the week display hitting the previous or next link once works well but the second hit produces the dreaded ajax response on screen. From time to time the display changes unmotivated to the month view and the next hit on previous/next kills it.

This only happens to the week display, all other displays are working fine and the links can be used endlessly.

This is happening on different installs and with different user roles.

to make clear which display I mean I have attached a pic.

Sorry to digress, but I found another minor bug.

The Javascript does not rewrite the views_arg to have a zero-padded month. That is, it returns 2009-7 instead of 2009-07.

The errant code, around line 75 or so:

view_args_prev = '' + (prev_date.getFullYear()) + '-' + (prev_date.getMonth()+1);

I changed it to pad with a zero if necessary:

view_args_prev = '' + (prev_date.getFullYear()) + '-' + ((prev_date.getMonth()+1) < 10 ? '0' : '') + (prev_date.getMonth()+1);

(views2 trick) For those that need something quick, just going to throw in a mention that if you surround a link in classes that views expects to be ajaxified and the view is set to use ajax, it'll try to ajaxify it.

With calendar, sometimes need to have the correct view_name and view_display_id in the url also though, but that was only for when I needed the block day box links to update an attached view, not for prev/next.

Ie, all I did to ajaxify a block calendar next/previous link was copy date-navigation.tpl.php into a theme surrounded the links like so:

 <span class="attachment"><span class="views-summary"> <?php print l('« ' . ($block ? '' : date_t('Prev', 'date_nav')), $prev_url, $prev_options); 

?>
since it looks for .attachment .views-summary a to ajaxify.

This isn't to replace the patch or anything, just mentioning it :)

I tried to apply patch in #93 (with change in #104), but it doesn't work for me - nothing is ajaxed. Probably I've done something wrong. I tested it in Firebug console and found no errors. Please, can someone provide us with clear instructions, so I can test it again?

http://drupal.org/node/620014

Don't forget to clear the caches after applying the patch.

Bizarrely, applying path of #93 wrecks my whole (fresh) install, with:

Fatal error: require_once() [function.require]: Failed opening required './sites/all/modules/calendar/theme/theme.inc' (include_path='.;C:\php5\pear') in C:\wamp\www\sandbox\drupal\calendar\sites\all\modules\calendar\calendar.module on line 38

@108
Patching the file changed the permissions on theme.inc. Just make sure to reapply the permissions the file had before. Just look at the surrounding files.

@109

I'm on Windows. There are no permissions.

Go to the file in question and right click on it. Hit "Properties" or whatever it is called in english (I am German and it is called "Eigenschaften"). Second tab should be security and there you can see info about permissions/ownership. ;)

begtodiffer:

If dddave's suggestion doesn't work then simply copying the file to a different filename, deleting the original, then renaming the copy back to the original filename should do it. If you used cygwin to apply the patch you can get funny permissions (I haven't fully figured it out) that will get reset by doing the above steps.

Thanks, copying the file and renaming seemed to have done the trick.

However, now I have a problem similar, but not identical, to that expressed in #22. I start with a month view in my block (which is what I am after), but clicking on next/previous changes it to a day view. In my case, this happens on all pages (not just calendar pages).

In Views, i have Calendar Block and Block View set to use Ajax - no others.

Any ideas?

I've spent all night and day trying to get this to work to no avail. I'm running Drupal version 6.19 with all modules up to date on a IIS server (which I have no access to apart from ftp). Use AJAX: is set to yes in Views and I've tried the latest stable and development versions of the calendar module and I've applied the patch from #93 (amongst other from this thread) but nothing seems to work.

When I click the button to change to the next month an new page is generated with no AJAXness. AJAX is working on other parts of the site such as the pager on a news teaser.

Anything else I can try to get the calendar block to use AJAX?

I shall have to assume that this module is critically flawed when it comes to AJAX i think.

subscribing

Thanks for the great tip on #105...worked like a champ!

which one is the final patch now for that issue ?
is it already included in the current dev version that one can download ?

Patch is in #93. It is not included in the current dev as far as I know. Sadly the maintainers are ignoring this bug. Anyways: It would be great if some js wizard could tackle the outstanding issues so that we could present a RTBC patch. Sadly I am not able to help coding here. :(

Subscribing

I re-rolled the awesome patch at #93 adding the support for multiple views arguments.

Currently the calendar_ajax.js can manage only the first argument (the prev/next date to be shown) on prev/next buttons clicks.

The extra arguments are needed, for example, when you have an Organic Group calendar block showing on the calendar block only the events for that group. In that case the view behind the calendar will have a second argument taking the nid of the current group.

The patch add the support for more than one argument in calendar_ajax.js

Looking forward to test it over the weekend.

I did some improvement to the patch and fixed a little bug. New version of the patch attached.

@kongoji
Your patch seems to work as advertised. Would you mind addressing the outstanding problem mentioned in #102?

when will those patches be integrated into the latest dev version ?

re#125
Never unless we can present a rtbc'ed patch. This issue has so far gotten zero attention from the maintainers. KarenS is a darn busy drupalista and I doubt that she has the time to dive into this stuff, especially with D7. So we need some coding ninjas to tackle the outstanding issues so that we can present a patch which is ready to include.

This version should fix also #102 problem, but it needs testing.

Massive! I did a quick test and it seems to work flawlessly. #102 seems to be no issue anymore and I couldn't find any other leaks on my multiple calendar displays. I am going to give it some more testing tomorrow.

Two questions about your patches: I am using cygwin and normally I don't have problems applying patches. For your patches only the first hunk applied well but for the second cygwin asked specifically for the file to patch (calendar/theme/theme.inc) which I had to provide manually. After doing so this part was applied. Which p-option should I use to apply the patch in one go? I am not a code guy (obviously) so please bare with me.

My second question might be related to first one but your latest patch created a completly new FOLDER called calendar inside the original calendar folder. The newly created folder contains a subfolder /js which contains the calendar_ajax js.file. Is this because I did not apply your patch correctly or might your patch need some refinement?

Anyways: Many thanks for your effort so far. I hope this massive issue can be "fixed" soon.

I guess your are running the patch from inside the calendar module's folder.
Try do this:
1) go to your drupal installatation folder
2) go to sites/all/modules folder or to what is equivalent in your installation
3) copy here the calendar_ajax_4.patch file (NOT inside calendar module's folder)
4) with cygwin run patch -p0 < calendar_ajax_4.patch

Let me know if it works.

Ok, that was easy. ;)
Most patches I apply have to be put inside the module which is going to be patched or at least this is the way I did it.

So far your patch seems to be working absolutely great. Would love to her some feedback from other people.

edit: Using the patched version on a really ajax-heavy testinstall and so far it is working without issues...

Folks,
this issue is 130+ long. Could somebody please test this awesome patch and report back?

For all those not cool with testing patches:
http://drupal.org/node/620014 and #129

This patch applies nicely and can be tested withing minutes. Simply create multiple calendar blocks to see if you can change the month independently. After that go onto a calendar page and go nuts by clicking the nav links and changing from day to month to week display. This doesn't take more than 10 minutes to test out.

We need feedback!

2 years old today!

Functionally, the patch works well - good work! (Hint: you need to toggle the default "Use Ajax" setting on your calendar view for it to work.). The only problem I found was that calendar popups don't work after an ajax next/previous - but that's a problem with the jcalendar.js script as raised in this issue - #415264: Change $(document).ready() to a Drupal.behavior.

Also, the patch file itself does not conform to standards: you should patch from within the calendar module folder and patch against the dev version. I have re-rolled the patch from #127 according to the instructions here - http://drupal.org/node/92594/cvs-instructions/DRUPAL-6--2.

Apply this patch from within the calendar module folder.

I have re-rolled the #127 patch with the right Drupal patch format.

I also have cleaned up existing changes in the theme.inc that was forcing the use of full url in the date_real_url() that now seems unnecessary.

Right now the patch only load a js when the views has the ajax format, so it doesn't make any change to the existing calendar module, perhaps this way the maintainers are less afraid to commit changes in the existing module.

This patch works perfectly with the next/prev links in blocks or page view, with years/months/weeks/days displays.
The only pending feature, for a next issue, would be to make work the display links or month,week, day links into the calendars, but that seems less daunting that this first ajax feature.

Tested patch in #134 and it is no good. On first glimpse all is ajaxy and fine but when you are in a calendar display and hit the next/previous link and AFTER that change to another display (e.g. from week to month) the screen is filled with an ajax response.
Changing the displays without usage of the next/previous links works fine, multiple displays and calendars also.

So this patch reintroduced the bug fixed with #127 in a much grander scheme. /(

tested #133

Patches clean against the dev version.

Test results:

Firefox: Rocksolid, zero noticeable mistakes.
Seamonkey: Rocksolid, zero noticeable mistakes.

Internet Exploder 6: garbage ain't enough to start and trying to explain how bad it just is and would be an insult to the word 'garbage' itself.
Internet Exploder 7: seems to do a bang up job also.
Internet Exploder 8: You really have to enable all 'known to man' caches including block, else you will experience an error (file download, not loading) when clicking on a day number when viewing a month. After enabling the block cache this seems fixed.

{ "status": true, "display": "\x3cdiv class=\"view view-calendar view-id-calendar view-display-id-calendar_1 view-dom-id-1\"\x3e\n \n \n \n \x3cdiv class=\"view-content\"\x3e\n \n\x3cdiv class=\"calendar-calendar\"\x3e\n \x3cul class=\"links\"\ etc etc etc

Safari: same problem as IE8, enabling block cache also fixes it. The file is not downloaded here as it is with IE8, but displayed in the browser itself.

Much love to all you people, this is a great patch, keep it up!

Tested on various installs and I still get the ajax response as soon as I switch the display after using the nav links (from week to day for example).
Caching the hell out of it doesn't help. So I stand by my word that this patch is actually a regression to the patch in #127.

@dddave, which patch are you testing now? AllRob tested #133 which is functionally identical to #127. Is there any reason not to go with that patch?

I did not test the patch in #133 because I assumed that it in fact is only a reroll correcting some formalities. I did test out jcmarco's patch which I find to be a serious step back. Did you test jcmarco's patch? I am confused that it seems to work (sort of) for #136 when I cannot get it to work correctly in any of my testinstalls.

To clarify: Patch #127 (and assumingly #133) awesome; patch #134 needs work.

subscribing

subscribe

Hey, I tested the patch in #133 tonight and couldn't get it to work - if I hit the back arrow on the block view, it would flash back a month, then return to the original month, and then none of the links would work. I'm not sure if it matters, but I've got a very customized calendar view, including even an extra argument from a custom module. However, for me #133 still needs work.

So, after that didn't work, I tried hefox's suggestion in #105 and it worked perfectly. In fact, I liked it so much that I made a patch for the date module, because I think it should be this way out of the box: #1005968: Ajax for date navigation attachment views. I am not sure if this addresses all of the concerns raised on this page, but to me -- and I say this with the utmost respect for all the people who have spent so much time on this -- it seems more appropriate for a view to use views's inbuilt ajax integration if possible.

I'm hoping someone can give that idea a short test. Patch is attached to the date module issue linked above.

As a little follow up, if you want those year/month/week/day links on calendar page views to work with ajax as well, you could apply similar logic to calendar-main.tpl.php. I've attached a patch, but in contrast to the patch for date module above, I'm not at all sure from a UX perspective if this is how I'd want the calendar module to work out of the box; it seems to me that ajax for anything more than the prev/next links is going overboard. But then, I guess I probably wouldn't enable ajax on the page view in any case, so maybe this should be the default after all. Anyway, here's an option.

Oh, by the way this won't affect the prev/next links by itself - you still need the date module patch I posted in the issue linked above.

dnotes' patch works great, it's the classic "egg of Columbus", and it could be (I guess) the best way to fix the issue and to let module mantainer commit the patch and fix the issue.
As far as I saw, there is only an issue with the switching between visualization types (Year, Month, Day, Week).
The ajax switching between calendar pages works very well.

subscribing

I applied both patches to the latest dev of calendar and date 2.7 respectively. What works nicely is the normal ajax switching on calendar blocks (using the arrows wo go back and forth between the months).

That said: On all other occassions (changing the display type Year/Month/Week/Day and using the nav links on full displays) I get the nice ajax wheel but after that nothing happens, i.e. the display doesn't change.

Tested with FF and IE.

Do these patches need a reroll due to the updates in calendar and date or is this patch simply not working?

Applied #134 against 6.x-2.4 cleanly. Seems to work well.
in modules/calendar:
patch -p0 < calendar_ajax_5.patch

Applied #134 and #143 patchs and work fine with 6.x-2.4

Thanks guys, great job.

I applied patches from #134 and #143, but also needed to patch the date module with the patch linked in #142. Now it works better, but changing between month/week/day views doesn't happen magically with AJAX. Do I need to change something? I changed the AJAX setting to "Yes" in the views settings for the default display (meaning all calendar views).

See my post in #146.

Those patches don't work for the whole stuff. In fact they are a major regression in functionality to the patches we had before.

Hmm, so the previous solution doesn't work with blocks? That's the most important part I need for now.

I noticed that on a multi-lingual site changing month with AJAX works in default language (English), but not on the other languages. Maybe the language prefix which comes from i18n module messes something up?

subscribe

+1

#142 works great! Tks @hefox and @dnotes!

#142 working as needed!

since #142 is only a tpl change, while it doesn't get commited, instead of appling the patch in date module own files, i just copied that date-navigation.tpl.php into my theme and used the changed version in my theme folder.

Thanks hefox and dnotes

subscribing...

We are successfully using patch from post #21. However, in IE7 there is an issue with calendar_ajax.js. IE 7 is not very good with trailing commas, so the view is not working. The following patch cleans up the js/calendar_ajax.js file. Again the original file is created by running calendar-339279-2.patch, I haven't tested it against newer patches, it may or may not work as is, but it would be easy to apply same changes.

#142 is working in IE7 and uses views's inbuilt ajax integration like dnotes has mentioned above.

Noob here that just came across the "no AJAX" calendar issue.

Is the Date patch (Dec 23, 2010) necessary with the newer Date 6.x-2.7 (2011-Jan-03) version? (I know, wrong module area, but related)

With the #143 patch to Calendar (Dec 23, 2010), is the patch necessary with the Calendar 6.x-2.4 (2011-Jan-03)?

If the patches are not necessary anymore, is this still an issue? I'm not getting any Views AJAX functionality with the newest green releases (not dev). Should I install the latest dev releases for this functionality?

As I'm not yet completely comfortable with patching I'll just wait I guess, really dampening my expectation of the calendar block though. On to the next...

Thanks for everyone's effort!

Successfully applied #142 and manually made the changes in #143 (it wasn't actually patching for some reason...). Works on the page view, which is what I'm using.

On my site I have this and an "upcoming events" display inside a Quick Tabs block. Works fine as long as AJAX is off for the QT block but doesn't function when turned on. It's also fine in IE7 when I load the calendar view directly, but not when loading the QT block.

Edit: enabling "Optimize JavaScript files" resolved the issue with IE7. Yay limits.

Edit2: in response to #159, I found both #142 and #143 were necessary for Date 6.x-2.7 and Calendar 6.x-2.4.

Buff! There is a lot of work from many people on this issue.
I was testing the #142 and #143 from @dnotes and it really makes its job.
As I guess that new features are always against dev release and considering that there are confirmation from many users, I change the status to reviewed and tested by the community and hopefully the module maintainer consider adding this small change in the theme template that adds more views compatibility to this module. ( we could even consider this issue as a bug report as it fixes a wrong views integration)

I rerolled last dnotes patch with last dev release and I this require to patch the date module as well #1005968: Ajax for date navigation attachment views

Hello,
first of all thanks to everyone who has worked on this.
I have applied patch #133 against 2.4 version and tested it. It provides ajax previous/next navigation, both in block and page, as advertised. So far, I have not been able to break it. The only minor problem that I have found is that at the calendar page, the year/month/week/day URLs are not "clean" any more . I don't know if this is normal, but it is not a big issue anyway.
As there is enough confusion already and many different patches, I would suggest that the "ajax year/month/week/day links" are tested as a seperate issue and we focus on "ajax prev/next navigation"-only in this one.

subscribe

Thanks for all your work!
I updated date to actual dev and applied patch mentioned in #142. I also patched #133 against calendar 2.4 and I can confirm that everything seems to work perfectly fine (block and page ajaxing). However, ajax navigation does not work when the calendar view is in a panel.
Do you have any ideas?

edit: it seems as panels doesn't render the view completely with all its containers as on the views page.

I.e is <div class="view view-calendar view-id-calendar view-display-id-calendar_1 view-dom-id-1 views-processed"><div class="view-content">....</div></div> missing. So I better look in the panels issue queue for a solution.

edit edit: I got it working. Look here for a little howto.

sub..

nvm

...subscribing. What about 7.x?

Subscribing

Subscribing (would be great in 7.x)

trying to make sense out of this thread and all the patches. this is what i have:

latest -dev of calendar

#127 - (running out of modules folder; which is wrong way to make a patch file) hunk #1 failed, other 3 pass, tried anyway - ajax works for prev/next BUT... i am able to get the AJAX response to eventually show as page reloads (see below)

#133 - (run from calendar folder as it should be), all hunks pass - same results as with #127.. mostly works but i can get it to fail.

my setup, possibly more than could be expected to work??

- Views3
- latest -dev of calendar

using qtabs, no ajax
tab1 - calendar view, view has ajax enabled
tab2,3,4 have other views with exposed filters, ajax is enabled

- page loads with qtab #1, prev/next works fine (uses ajax)
- switch to tab2, 3, or 4 and back to tab1
- prev/next still works fine
- switch to tab2, apply an ajax exposed filter
- switch back to tab1
- first prev/next uses ajax and works correctly
- second prev/next fails and loads page with ajax response on whitescreen

using patch on the date module from issue linked in #142 (and no patches to calendar) and my test case works.. :)

are you using V6.x or 7.x? it does not seem to work for 7!

Of course it is not working in 7 because this is about the D6 version. ;)

IF you have similar problems in D7 please open a new issue and simply link to this one for reference.

The configuration I'm using is following:

Views 6.x-3.0-rc3
Calendar 6.x-2.2
Date 6.x-2.x-dev

The patch calendar_ajax_5.patch (http://drupal.org/node/339279#comment-3756404) is almost correctly done except of one thing. Drupal.settings.views.ajaxViews and Drupal.settings.views.ajax_path used to store items with different indexes.

Attached is patch(calendar_ajax_5.1.patch) you can apply after calendar_ajax_5.patch is set. This will make your calendar ajax work.

PS: the code also should work with calendar 6.x-2.4 + calendar_ajax_5.patch.

(i can confirm ajax navigation in All date views works in Drupal 7 with current dev versions of date 2.x and calendar 3.x modules, just edit the view and enable ajax, but again, this classic is about Drupal 6)

And i tested #142 and #143, on top of what i already have. Some minors, but seems to work. Will test some more if time allows it.

Did this issue stall or does the patch just need more testing?

I would like to resolve this issue, but I am very confused about which patch is the correct one:

#161 is a very nice, small, low risk patch (it only adds a couple of classes to the output)
#134 is more involved...
#174 appears to modify #134 (both needed?)

Which one should be tested & applied?

@arlinsandbulte, I've tested #134 and it worked very well except of trouble with indexes which is being fixed by my patch #174.

So I'd say #134 + #173 is way to go further.

So... where does #161 & related #1005968-6: Ajax for date navigation attachment views fit in?

I applied #134 + #173, but no succes.

Drupal 6.26
Views 3
Calendar 2.4

Would really love to get this working.

I tried #133 and #134 but no luck then i tried the patch from https://drupal.org/node/1005968, it worked fine for me in block view.Thank you.

My Configuration

Drupal 6.26
Views 2.16
Calendar 2.4
Date 2.9

For those using Drupal 6.46 LTS and anyone else interested, attached is a combined patch for calendar ajax navigation that applies to D6.46 LTS for php 7.2 and consists of:

The ajax calendar navigation tplphp fix which is just a two line patch from comment# 143 that was re-rolled in comment #161 however that need -p0. The ajax_5 patch in comment #134 plus the modification ajax_5.1 in comment #174.

I hope no one minds, I am changing the issue meta data to move this to the Drupal 6 LTS queue where it might get reviewed and committed.

Thanks to everyone who has contributed to this issue.

I am wondering if I should have left this in the Calendar issue queue?

I decided to change this back to the Calendar issue queue and hope the Drupal 6 LTS maintainers will see it.

Since the Ajax patch works, even though it still needs review, I am adding it as a candidate for the next release of calendar.

I am closing this issue, since it's for a Drupal version no longer supported.

The patch in #182 is the combined patch and still works with 6.59 without problems.