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

federiko_’s picture

Priority:Critical» Normal

I'd really enjoy this feature too !!

MrSasquatch’s picture

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!

wusel’s picture

I agree to the new priority.

TheEdonian’s picture

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.

wusel’s picture

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

That is not good.

Wusel

waltercat’s picture

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?

ExTexan’s picture

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

_vl_’s picture

StatusFileSize
new527 bytes

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

MrSasquatch’s picture

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

wusel’s picture

@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

johnheaven’s picture

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.

bszk’s picture

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 ";
  }
  }
romansta’s picture

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]);
?>
highfellow’s picture

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.

highfellow’s picture

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.

highfellow’s picture

StatusFileSize
new2.34 KB

Sorry, forgot to attach the file.

sassafrass’s picture

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
highfellow’s picture

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

sassafrass’s picture

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

:(

highfellow’s picture

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
lukasss’s picture

works great number 18, I have added format_date:

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

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.

masterperoo’s picture

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.

nerdoc’s picture

patch #18 does apply, but creates an error when viewing the month view of the calendar. In this view the $view->style_options array does not get a 'calendar_type' key, just add a
dprint_r($view->style_options) before the $period = $view->style_options['calendar_type'];. It looks like this in month view:

Array
(
    [name_size] => 3
    [with_weekno] => 0
    [multiday_theme] => 1
    [theme_style] => 1
    [max_items] => 0
)

So this assignment to $period can not not work. I would change the line to:

$period = array_key_exists('calendar_type', $view->style_options)?
    $view->style_options['calendar_type'] : False;

Then everything works as expected. Could that be a bug in the calendar module? Why is calendar_type not assigned in any case?

jadgsam’s picture

Thanks for this patch it is very appreciated by the final users.
One question to highfellow, is there a way to make it work but with weeks starting on Sunday?

izmeez’s picture

Version:7.x-3.4» 7.x-3.5
Status:Needs review» Needs work

Thanks, but no cigar:-(
The patch in #18 applies to 7.x-3.5 without any errors but it needs work.
As stated in #25 it does not work correctly with weeks beginning on Sunday.
And fails with url's that use a single digit week e.g. 2014-W1 to W9 inclusive.

tim-diels’s picture

This also doesn't work when using AJAX pagers. For the rest it seems to be working correctly to me.

PhilY’s picture

#18 works fine with Calendar 7.x-3.5, thank you.
Any news about single digit week numbers?