Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I am using the latest and greatest -dev's, I have set up my sites date/timezones properly (I believe).
When I am on the Month view I see the correct month, but when I click Week (just tried this today, August 18th), I get a URL like /week/2011-W32 and see "Week of July 31 2011". If I click Day, I see "Sunday, July 31 2011"
Today is August 18th.
Did I mess up some little dumb setting somewhere? Any help is appreciated.
Comment | File | Size | Author |
---|---|---|---|
#39 | 1253482-39-calendar-year-month-week-day-links-to-today.patch | 629 bytes | izmeez |
#19 | remove_date_arg_if_views_default_arg_was_used-1253482-19.patch | 882 bytes | mshepherd |
Comments
Comment #1
jennypanighetti CreditAttribution: jennypanighetti commentedI'm having this same issue. Today is the 20th and when I click "Week", it goes to Week 32 (July 31st). When I click "Day," it goes to August 1st!
I realize this may not be a Calendar bug, it may be a Views bug. Going to /week or /day knows what the correct week and day are, but it's incorrect when using the *pager* links at the top.
Comment #2
zkrebs CreditAttribution: zkrebs commented@ #2, same for me. If you go to the URL /calendar/weeek or /calendar/day provided by the default view, it works, but the pager itself appears to be broken. Is there a pager setting somewhere in the GUI that I missed configuring?
Comment #3
fultonchain CreditAttribution: fultonchain commentedReplicated and subscribing.
Comment #4
flightrisk CreditAttribution: flightrisk commentedSame for me, I think it is a granularity issue, as soon as you go from a less focus granularity to a more focused one (like from week to day) it goes out of sync. So if you go to week display, for example, it starts the week on the first day of the week, a Sunday. So while today is September 2, a Friday, you've altered the search to start on the first day of that week. So when you go to day view, you are now looking at the 28th, not today's date. And it seems to remember the last date it was on the last time you clicked on that display.
Interestingly, if you make the links from a menu yourself and use the vanilla paths (/calendar/week, calendar/day) instead of the links the module wants with one more level after them (/calendar/month/2011-08) it works properly. So until it is fixed, maybe you can disable the code that displays the other displays and use your own tabs to display whatever views you want. Karen is working on this section of code and creating new tabs instead of the ugly text links, so maybe she will get all that working soon.
Comment #5
crifi CreditAttribution: crifi commentedI also have this issue! In month view everything is okay, in week and day views the issue appears.
Comment #6
zkrebs CreditAttribution: zkrebs commented#4 - how do I remove the pager at the top? I agree, I'd like to replace them anyhow.
Comment #7
jennypanighetti CreditAttribution: jennypanighetti commentedWell, since I don't need these links, I turned them off by commenting out where the calendar links are added to the page. In calendar/theme/theme.inc, line 63, just comment out $vars['pager_prefix'].
Note, this is in the dev module as of August 20, NOT the most recent one, since that sounds like it has even more problems......
Comment #8
chefnelone CreditAttribution: chefnelone commentedsame problem here
Any patch to fix it?
Comment #9
mwagenkn CreditAttribution: mwagenkn commentedsame here and subscribing..
Comment #10
humansky CreditAttribution: humansky commented+1
Comment #11
kyuubi CreditAttribution: kyuubi commentedBump
Comment #12
codesmithSubscribing
Comment #13
Valeratal CreditAttribution: Valeratal commentedSubscribing
Comment #14
kristiaanvandeneyndeSubscribing
Comment #15
kristiaanvandeneyndeI managed to locate the issue.
When supplying a date argument, the $view->date_info of the calendar has four properties to base the tab links on (day, week, month, year) that seem to fall back on the first item of that view.
Example:
The month view of September 2011 has:
This is all dandy, up until the point where you expect it to go to the current month, week, day, etc..
The problem lies with the fact that even when you don't supply a date argument in the URI, Drupal still supplies one behind the scenes.
So what Calendar should do is check the URI for date arguments. If none are present, it should figure out you want to view the current day, week, month or year with the tabs and thus not add any date arguments to their links.
Instead, it thinks your viewing just any random year, month, week or day and supplies links to the first 'item' of each type. Just like the September example.
Updated status to major since no author has replied in a long time.
Comment #16
mshepherd CreditAttribution: mshepherd commentedAnother example:
Navigating to /calendar/month correctly displays the current month (October).
However, the Month, Week, Day, Year links look like this:
So Month links correctly, Week links to W39 (this is week 43) and Day links to 1st October (this is 26th October). Year links correctly to 2011.
Comment #17
mshepherd CreditAttribution: mshepherd commentedI've done a little more digging on this and I think the problem is tied to the date_pager_url() function called in theme.inc and from the date_views module which is part of date api. Whether the function is at fault or we're passing it bad data, I don't know.
More about date_pager_url() http://api.lullabot.com/date_pager_url/7
[Edit: This was a red herring. But a step along the way of working out what was happening.]
Comment #18
mshepherd CreditAttribution: mshepherd commentedI think current behaviour is correct if there is a valid date argument (contextual filter) present in the URL - perhaps apart from /year/YYYY which seems inconsistent.
However, the behaviour when no contextual filter is present in the URL is odder. Views provides a default contextual filter of the current date, which it does correctly. Then the links work as above.
However if no contextual filter was present, it seems more logical for these links to be without contextual filters also. So on a page /month, the links should just be to /month, /week, /day and /year
Any thoughts?
[edit: the same conclusion that @kristiaanvandeneynde came to above]
Comment #19
mshepherd CreditAttribution: mshepherd commentedA patch that checks whether views supplied a default argument (i.e. there wasn't one in the URL) and removes the date element from the month, week, day and year links if that's so. It leaves links alone if a date argument was already in the URL
This does not change the behaviour of the calendar if there is a date argument present in the URL.
Comment #20
kristiaanvandeneyndeWill test and review this patch as soon as I'm back in the office.
Currently on vacation :)
Comment #21
kristiaanvandeneyndeTested, seems to work perfectly for me.
Updated to critical seeing as maintainer still hasn't replied yet.
Comment #22
LIQUID VISUAL CreditAttribution: LIQUID VISUAL commentedSame problem. Once in year view, day month and week links do not go to day, moth, week for current date.
Comment #23
chemicalroman CreditAttribution: chemicalroman commentedI have exactly the same problema. Links of month and day in year view go to December of that year.
Comment #24
kristiaanvandeneyndeJust to reiterate: until the patch supplied above by @mshepherd is committed, you can apply it yourself to fix the problem.
Comment #25
d.cox CreditAttribution: d.cox commentedpatch @ #19 works for me +1
Comment #26
KarenS CreditAttribution: KarenS commentedThat patch will not work at all correctly if you try to use the back/next navigation. You end up with links back to the current date no matter where you go in the calendar. So if you navigate forward several months, into the next year, then click on a link, it will take you back to today in the new view.
The intention of these links is that they will keep track of where you are and take you to the appropriate place in the new view. They do this by populating the links on the first page, then replace the values that need to be replaced based on where you have moved in the calendar.
With the patch above, the replace does nothing because the values are missing, so the links are always the same: month, year, day, week, with no dates.
There obviously is some problem in the logic, but this isn't the right way to fix it. Unless we want to give up on having the calendar keep track of where you are and always snap you back to 'today' when you switch between year, month, week, and day. Google calendar keeps track of where you are, and that's what I'm trying to model this after.
Comment #27
KarenS CreditAttribution: KarenS commentedActually, the patch works if you are using the 'clean' option for the pager links, but not if you use the 'pager' option, so it still isn't a fix.
Comment #28
katrialesser CreditAttribution: katrialesser commentedHow do you tell if it's set up to use the 'clean' or 'pager' options for the pager links? If this will work for me, I'd like to try applying the patch...but i'm on windows, so it's difficult to apply a patch (if anyone knows an easier way, PLEASE let me know) but I'd like to make sure the patch will work for me before I go through everything to apply it...
Thanks!
Comment #29
flightrisk CreditAttribution: flightrisk commentedOk 6 or 7 months now on this issue. What is the status of the calendar working properly? Karen, I know you are busy, can you let us know the plans for working on this module? With all due respect for your hard work, it took 4 or 5 months for you to reply here about this issue (December 20) and it has been almost a month and a half again with no word from you. If we just knew what was going on (or not) with development, that would be great.
Comment #30
KarenS CreditAttribution: KarenS commentedI didn't have anything to respond to, I said the patch wouldn't work and was hoping someone would figure out why. Since no one did, you had to wait until I had time to get back to this.
I decided the first step was to figure out why $argument->is_default wasn't reliable when used with a pager format and just made a commit to Date to make it work consistently for all formats:
http://drupalcode.org/project/date.git/commit/4aa1144
I'm not sure the rest of the patch is what we want anyway, but I think that was a good change to make.
The links are attempting to keep track of where you are as you click around and provide links to relevant locations on the other views based on that. This is the way that Google Calendar works -- you don't go back to 'today' if you click around in the month view and then switch to a week view, you see a week that is a part of the month you're looking at. This works fairly well when you move to views that are bigger (from a day to a week) and doesn't work right if you move to views that are more narrow (from a year to a month). The original logic was to keep track of the current day as the first day of whatever view you were looking at, but that clearly isn't working well enough. So I have to see if there's a way to make it smarter and I guess if I can't it will just have to go back to 'today' every time you switch a view.
Comment #31
KarenS CreditAttribution: KarenS commentedI decided to just give up on trying to do this intelligently and went back to everything just goes back to 'today' when you switch from one view to another.
http://drupalcode.org/project/calendar.git/commit/1bc60b3
Comment #32
LIQUID VISUAL CreditAttribution: LIQUID VISUAL commentedKaren - THANKS!!! cb
Comment #33
katrialesser CreditAttribution: katrialesser commentedI'm sorry, I don't quite understand commits. How do we use the two above commits to fix this, at least to go to the 'today' setting, like Karen says in #31...?
Please please explain, thank you!
Comment #34
arlinsandbulte CreditAttribution: arlinsandbulte commentedgirlwithquestions: the commit is just a piece of information showing what was changed in the code base stored at drupal.org.
To get the latest version of code, just download the -dev version from the project page.
Comment #36
Wappie08 CreditAttribution: Wappie08 commentedHi there, I just experienced similar problems with a live D6 site. Have a calendar week view and the top link for next week in 2012-W52 points to 2012-W1 instead of 2013.. (exactly like http://drupal.org/node/1407020#comment-5519776 which was directed to this thread).
Cannot seem to fix it and installed latest devs (date + calendar), any ideas
Comment #37
my-family CreditAttribution: my-family commentedI experienced the same as described in #36.
Comment #38
happyblitz CreditAttribution: happyblitz commentedcalendar 6x - 2.4
file: calendar/theme/theme.inc
add this lines to get current date links
before:
Comment #39
izmeez CreditAttribution: izmeez commentedIn comment #31 @KarenS changed status to Fixed with a commit and the comment
However, current calendar-6.x-2.x-dev does not do this instead going to the first of the month which is not helpful.
The suggestion in comment #38 fixes it to behave the way KarenS described.
Attached is a patch with that suggestion for anyone who is interested.
Comment #40
izmeez CreditAttribution: izmeez commentedComment #41
izmeez CreditAttribution: izmeez commentedUnfortunately, while this does work to go to "today" when clicking on day and week rather than the first of the month, it breaks the calendar block where navigating with next and previous to different months and then clicking on the month name to go to a large calendar of the month does not display a large calendar of that month but rather one of the current month.
Comment #42
izmeez CreditAttribution: izmeez commentedChanged title to be more specific.
Comment #43
apadernoI am closing this issue, since it's for a Drupal version no longer supported.