I have finished a full implementation of Calendar for a large organization with many calendars, and I'm very happy with it, except for one thing, and it's a show-stopper... No date/day numbers show up in week view! That's a serious problem because we find that most people in large organizations use week view so that they can see more detail. Everyone's complaining that they can't use this calendar system because there are no dates on week view. Seems like such an easy thing to do, compared to all of the other impressive complexity in the Calendar project. Am I overlooking something? Please help!!!

Comments

Priority:Critical» Normal

I'd really enjoy this feature too !!

Priority:Normal» Major

I just changed priority to major because there has been no response so far, and I really think that this is a major shortcoming of the calendar. It's hard to get stakeholders to buy in to Drupal as a replacement for our existing public calendars because everyone uses week view and they don't want to not have dates appear above each day in week view. Any assistance with this issue would be greatly appreciated. Thank you so much!

I agree to the new priority.

Status:Active» Needs review
StatusFileSize
new2.38 KB

I created a small patch that checks the url and adds the date to the weekview.
The calendar need to be in the root path for this to work. (I think)

Would love some feedback.

In my test, your patch also added the day-dates on the top of the months-view.

That is not good.

Wusel

Subscribing, this seems like a basic element that should be part of such a complex and highly used module. How do people use this if they can't see the date in the week view?

Plus 1. I'm also very surprised this feature is missing.

StatusFileSize
new527 bytes

I used the patch #4 and apply this patch to have a correct display in my case.

Any chance that patch will become part of the official release?

@TheSasquatch:

If you want to get this in the official release:
Set status (https://drupal.org/node/156119) of this issue to 'Needs Work' or 'Reviewed & Tested by the Community'.

Wusel

I just tried your patch in simplytest.me, but got the error "An error occured while patching the project."
Would be great to get this issue sorted.

Hi,
I implement this by modifying calendar.module and it seems to work.
The idea is to fix $translated_days if the view is for a week.
First I get the node_date_argument and use that to change the array $translated_days.
1) I didn't know how to get that argument out of the $view object so I parsed for it. I would like to know how to do that properly.
2) I decide if it is a week view if that arg has "00:00:00" in it.
Ultimately it would be nice to have this capability in the calendar module without having to hack at it.
Bill

My code in calendar.module:

  $z1 = preg_replace('/\n/', '', print_r($view    , true));
  $pos = strrpos($z1,"[:node_date_argument] => ");
  $z2 = trim(substr($z1,25+$pos,19));
  if(strpos($z2,"00:00:00")){ # must be the week view
  $z3 = date_timestamp_get(DateTime::createFromFormat('Y-m-d H:i:s', $z2));
  for($i=0;$i<7;$i++){
    $z3x = $z3 + 24*60*60*$i ;
    $z4 = date('M d',$z3x);
    $translated_days[$i]=$translated_days[$i]." $z4 ";
  }
  }

I patched calendar.module with #4 and #8.

But I also had to change the number of the pathargument in line 363, because I changed the default Url:

<?php
$dateurl
= explode('-W', $patharg[2]);
?>

StatusFileSize
new2.52 KB

I've written a new patch, based on the previous ones, that seems to work better:

- getting the week number from $view->args[0] works more reliably than using the path.
- it automagically detects whether it is a week view from the path, and only shows the week numbers when appropriate.
- I chose to use single day numbers rather than d/m/y.
- it should work even if you've put your views in a sub-path such as '/view/events/week'

It won't work if you use anything other than '/week' for the week display. I've only tested it with weeks starting on monday.

I've just re-done the patch so that it uses the calendar display type from the view, not from the path. It should now work whatever path you have set for your week view. (E.g. if you're using non-english path names). I haven't looked at weeks starting sunday. If you set 'use ISO-8601 week numbers' under 'Configuration » Regional and language', you should be safe.

StatusFileSize
new2.34 KB

Sorry, forgot to attach the file.

I tried the patch in #16 using

git apply --whitespace=warn calendar-weekview-dates2-1593626-14.patch

and got the following errors:

calendar-weekview-dates2-1593626-14.patch:49: trailing whitespace.
error: patch failed: calendar.module:356
error: calendar.module: patch does not apply

Issue summary:View changes
StatusFileSize
new2.34 KB

I've just uploaded another patch, which is done against the latest 3.x-dev version, and also fixes a small mistake in the previous one. https://drupal.org/files/issues/calendar-weekview-numbers-1593626-18.patch

I tried the patch in #18 against latest 3.x-dev version using:

git apply --whitespace=warn calendar-weekview-numbers-1593626-18.patch

and got the following errors:
calendar-weekview-numbers-1593626-18.patch:49: trailing whitespace.
error: patch failed: calendar.module:356
error: calendar.module: patch does not apply

:(

When I do it, it works OK:

[highfellow@web216 tmp]$ git clone http://git.drupal.org/project/calendar.git
Cloning into calendar...
remote: Counting objects: 7085, done.
remote: Compressing objects: 100% (3257/3257), done.
remote: Total 7085 (delta 5150), reused 5343 (delta 3785)
Receiving objects: 100% (7085/7085), 2.41 MiB | 865 KiB/s, done.
Resolving deltas: 100% (5150/5150), done.
[highfellow@web216 tmp]$ wget https://drupal.org/files/issues/calendar-weekview-numbers-1593626-18.patch --no-check-certificate
--2013-12-03 05:43:19--  https://drupal.org/files/issues/calendar-weekview-numbers-1593626-18.patch
Resolving drupal.org... 140.211.10.62, 140.211.10.16
Connecting to drupal.org|140.211.10.62|:443... connected.
WARNING: certificate common name `*.drupal.org' doesn't match requested host name `drupal.org'.
HTTP request sent, awaiting response... 200 OK
Length: 2398 (2.3K) [text/plain]
Saving to: `calendar-weekview-numbers-1593626-18.patch'
100%[======================================>] 2,398       --.-K/s   in 0s     
2013-12-03 05:43:19 (348 MB/s) - `calendar-weekview-numbers-1593626-18.patch' saved [2398/2398]
[highfellow@web216 tmp]$ cd calendar
[highfellow@web216 calendar]$ git apply --whitespace=warn ../calendar-weekview-numbers-1593626-18.patch
../calendar-weekview-numbers-1593626-18.patch:49: trailing whitespace.
warning: 1 line adds whitespace errors.

If I check the file after doing this, the patch has been applied. It also works OK with:
[highfellow@web216 calendar]$ patch -p1 < ../calendar-weekview-numbers-1593626-18.patch
patching file calendar.module

works great number 18, I have added format_date:

<?php
  format_date
(strtotime(date( "d M", strtotime($dateurl[0]."W".$dateurl[1]."1") )),'medium');
?>

Thank-you Highfellow. I applied the patch using the steps you outlined in #20 and got the same results as you did. Not sure why it didn't work before. I did not originally clone the Calendar project. I had just downloaded it from the project page. I also had not used wget to download the patch. I suspect it was the latter that did the trick. Thanks again.

There is an error in patch #18
when no argument is passed, default for today - 13/02... is week 7 (not 07):
first day

$dateurl = explode('-W', $view->args[0]);

returns $dateurl[1] as 7

date derivation further down works only if 07 is passed

<?php
     
switch ($day) {
        case
'mon':
         
$weekdate = date( "d", strtotime($dateurl[0]."W".$dateurl[1]."1") );
?>

obviously this will work after week 9 each year - say in 2 weeks.