"Previous" - "Next" link display
RWWood - August 1, 2008 - 11:44
| Project: | Event |
| Version: | 6.x-2.x-dev |
| Component: | User interface |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Description
I'm running Drupal 6 on a local Apache server with php5.2. After first installing the Event module and setting up the mini-calendar in the sidebar, there was only a link for the previous month, but not for the next month. I created an event two months into the future, and now there is a link for the next month, but not one for the previous month. This currently being August, I can go forward to September, October (when the event is), and November. but I can only navigate back from November and no further.
The same problem exists on the main event calendar for the month, but with some strangeness on the weekly view, sometimes being able to navigate backwards.
Thanks.
rww

#1
#2
Some code was added to _event_nav() to suppress the next-month and previous-month links in the sidebar mini-calendar if there are no events in any later months or previous months respectively. What the original reporter describes is a confusing feature rather than a bug.
Now here's the bug: If you use the links to go back and forward, you get the link settings for the month you started out in and not the month you are currently viewing. Say you have events every month from January through May, none after May, and it's July. You have no "next" link. Use the "previous" link to go back to March. You are now viewing the March sidebar mini-calendar and there are events in April and May, but you still have no "next" link.
To make everybody happy, I recommend two things which are both easier said than done:
* Fix suppression of next/prev links when viewing a different month in the sidebar mini-calendar.
* Make any suppression of next/prev links an optional configuration setting.
For users, as a temporary workaround to disable the suppression, go to line 1744 in event.module where this line is:
if (($dir == 'prev' && event_is_later($date, $range)) || ($dir == 'next' && event_is_later($range, $date))) {and change it to this:
// if (($dir == 'prev' && event_is_later($date, $range)) || ($dir == 'next' && event_is_later($range, $date))) {{ // Open the branch so all edits are in one chunk
You will have to redo this every time you update the module to a new version, at least until the root issues are addressed.
#3
After your explanation, I understand the "why" of the problem, however I think there's a practical point that's missed in the decision to suppress the "next-prev" links on the mini calendar. Suppose I just want to check what day next month (or two months in the future) the fifteenth falls on for the sake of planning an event. I have no way to navigate to that month.
My suggestion would be that the coding be done in such a way that the links are always available, whether there are events in the next or previous months or not. Perhaps the css could be modified so that the links indicated there were (or were not) events in the subsequent or previous months. Example: the link is black for no future events, red for events in the next month, and blue for events in any future month other than the one that immediately follows the current month.
My 2¢
rww
#4
I have tried out the quick fix in #2 for a site I'm building, and it indeed works. However, it has one side-effect in that the site now can generate effectively an infinite number of calendar pages into the past and future, whereas it could not do so before due to the links disappearing outside of the existing event range.
This isn't a practical problem with humans, but with a spider or web-crawler program which was not aware of the now-modified Drupal behaviour this could result in it following generated calendar links arbitrarily far into the past or future, with a potential impact on the site, either by falling into an infinite loop and thus generating excess load, or by cutting off after a certain fixed upper limit of pages were read and thus not indexing other pages on the site which one might want indexed.
Given the legitimate use case in #3, one compromise is to extend the displayed range by a year into the past or future and then suppressing the links. This can be done inserting the following at line 1754 in the 2008-09-06 dev code:
$range['year'] = (string)((int)$range['year'] + (($dir == 'prev') ? -1 : +1));Change the +/- 1 to larger values if you want a wider range. However I suspect this fix may not work in the admittedly rare boundary case when there are no events in the system as then the range is empty. If so, fixing that is left as an exercise for the reader ;-)
#5
i thought this was fixed with some recent updates??
#6
Is this still an issue? Also: There's no patch
#7
I think it's more of a confusion issue due to unexpected behaviour. The behaviour is by design, but I don't know whether this ticket should be closed out as such because there is an issue of user confusion around it. When I first saw this, I wasn't sure what was happening and I went into the code to get something I was happy with. RWW thought it was a critical bug.
Here's the situation as I see it. Somebody thought suppressing the links was a good idea or else the code wouldn't be there in the first place. Liberation has a very good point in favour of link suppression, that being that webcrawlers could go into an infinite loop without it. Others of us find it confusing and/or would like to browse out a few months beyond the first or last event. The best policy going forward is as of yet to be determined. I personally favour something along the lines of Liberation's proposal.
#8
but this is a problem for all calendars whether its on the index or on the calendar proper...
spiders could crawl till 2020+
#9
Liberation,
How would you implement this fix in the D5 version of events? The function is nearly identical, but using this fix in the 5.x-1.0 version of event causes a "warning: Cannot use a scalar value as an array" message.
Thanks.
rww
#10
Re #6, attached is a patch implementing #4 as shown for D6 dev.
Re #9, the $range datatype possibly changed in some way between versions, so you'd have to debug what's happening and then alter the code accordingly.
#11
what happens when you want to go back and check the events?
its only 12 months a year and 30 days a month.
you have more data then that surely !! can this be optional?
#12
I don't understand your comment, can you clarify please.
The patch extends the available range for calendar browsing to one year before the earliest event and one year after the latest event in the system. No events get lost or cease to be visible, as far as I can see.
#13
LETS say you run indymedia sites, and people go back and check events from previous years.....
they are essentially lost if you cant link to them, unless there is manual link syntax....
edit: why not make it stop when there is NO event...why go beyond that? ;)
#14
As per #2 it would indeed be better better to have the +/- one year extended navigation facility above as administrator controllable.
Therefore, I have added to the event administration interface Event Overview section a checkbox entitled Extended Calendar Navigation which controls whether it is operative or not. The default is off, to continue the existing policy unchanged.
An improved patch with this facility is attached.
#15
Should this patch work in 5.x-1.0? I tried it there and got the following:
warning: Cannot use a scalar value as an array in C:\xampp\htdocs\sites\all\modules\event\event.module on line 1600.
That references
if (variable_get('event_navigation_extended', false)) {
$range['year'] = (string)((int)$range['year'] + (($dir == 'prev') ? -1 : +1));
}
#16
It is not warranted to at all, see my second comment in #10.
You or someone else will have to find out what's happening in 5.x. I recommend the PHPEclipse debugger, see http://drupal.org/node/75242#comment-945405 .
#17
I am not a big friend of extra admin options.
How abotu we add a sign that signifies "stop" instead of no navigation at all?
See screentshot.
#18
The »| sign has a title tag which says: No more events.
#19
I went for »« instead of »| |«
Marking fixed.
--project followup subject--
Automatically closed -- issue fixed for two weeks with no activity.
#20
Automatically closed -- issue fixed for two weeks with no activity.
#21
On my new install of D6.8, Event 6.x-2x-dev, dated 12/26, none of the patches listed in this thread fixes the initial problem. The "previous" link is showing on the calendar block and allows me to navigate more than 12 months into the past, but the "next" link is greyed out. Apparently there were some changes made to the code after the proposed solutions that keeps them from working.
Thanks.
#22
RW: Blame me for not reading the report well and mistaking your problem for my own. Correct me if I'm wrong, but I think you're looking for the earliest month in the browseable range to be the minimum of the first event and the current month, and the last month to be the maximum of the last event and the current month. I'm attaching a patch that should do that. I haven't tested it, but try it and see if it works.
#23
I'm not sure what you described is what I'm looking for. Basically, I'd like users to be able to look at a calendar for any month either one year into the past or into the future. IE, today is 1/1/09, I should be able to follow the prev/next on the calendar block to either 1/1/08 or 1/1/10.
That's what the hacks in #2 and #4 did, but the module code has been updated and those hacks no longer work.
Thanks.
#24
Add Liberation's logic to my #22 patch right after $today is declared:
$today['year'] = (string)((int)$today['year'] + 1 * (($dir == 'prev') ? -1 : +1));
#25
That takes care of "un-greying" the 'next' link on the calendar block, but it's still possible to navigate farther into the past or future than 1 year from today's date.
Thanks.
rww