Please see attached image as illustration of my case:
- edit the office hours, one line per day
- save the data, view mode is OK
- edit again, and see that lines are shifted: the not-used 'more hours' are now filled with data of next day, etc.
- save without changing, and see that new viewmode reflects the wrong edit-data.

CommentFileSizeAuthor
#6 office_hours_1119152_1.patch210 bytesJerome F
ScreenHunter_8.jpg87.41 KBjohnv

Comments

johnv’s picture

johnv
Primary language Dutch
commented

It looks like functionality has shifted from function office_hours_field_widget_form(&$form, &$form_state, $field, $instance, $langcode, $items, $delta, $element) to _elelemt_info(), loosing the $delta info in the process.

Ozeuss’s picture

Ozeuss commented
Status: Active » Needs review

Thanks,
http://drupalcode.org/project/office_hours.git/commit/2ca1b9e

Adapted the $items array to accommodate correct date. Please review.

johnv’s picture

johnv
Primary language Dutch
commented

I havne't set up git yet. Would you mind to provide a patch/zip? thanks.

Jerome F’s picture

Jerome F commented

You can just clic on the diff link next to each file in the page to get the patch. 

office_hours.elements.inc 	diff | blob | blame | history
office_hours.module 		diff | blob | blame | history
office_hours.theme.inc 		diff | blob | blame | history
johnv’s picture

johnv
Primary language Dutch
commented
Status: Needs review » Needs work

OK, I didn't notice the links before. Thanks for the tip and the patch.
- Edit&Save in Nodes is now OK;
- Edit&save in Content type - Field settings (Edit tab) gives a Notice: Undefined variable: days in _office_hours_arrange_items(). An extra declaration removes the warning: 

 function _office_hours_arrange_items($items) {
+  $days = array();
   foreach ($items as $item) {
     $days[$item['day']] = $item;
   }
   return $days;
}
Jerome F’s picture

Jerome F commented
StatusFileSize
new office_hours_1119152_1.patch210 bytes

Just a little patch to test what johnv suggested in #5 as it did remove the notice :
Notice: Undefined variable: days in _office_hours_arrange_items() (line 331 of (...)/sites/all/modules/office_hours/office_hours.module).

appart from that, the git version in #2 seems ok to me for saving hours in standard content type.
But once I edit the node the weight modifications are lost, so if I put sunday at the end of the list, on save it's ok, on edit it's back to weight 0 so in firts position (back to default). Being able to put sunday at the end is a standard use case in France for example.

(things get even worse if the field is used with Profile2 profile types, see: http://drupal.org/node/1126386)

johnv’s picture

johnv
Primary language Dutch
commented

Jerome, IMO I'd rather not have the weight handles on the edit page. I believe OO uses the default/system first-day-of-week . You can set it here: admin/config/regional/settings
Can you change to order in D6, too?

Jerome F’s picture

Jerome F commented

@johnv: are you sure OO uses the default/system first-day-of-week? you're right it was set on sunday but when I changed it to monday it didn't refresh the field. So I created a new OO field to test that and it's also set on sunday though I am now on monday.
Appart from that I don't see why we would need the handles either.

johnv’s picture

johnv
Primary language Dutch
commented

Jerome, indeed, the first-day-of-week isn't working, as reported in #1115868: First day configuration. It's not possible..
A short recap:
- patch #2 is committed as Office Hours 7.x-1.x-dev (2011-Apr-10)
- patch #5 /#6 is now in #1171772: Undefined variable: days in _office_hours_arrange_items()
- First-day-of-week is not working: see #1115868: First day configuration. It's not possible.
- Edit-page shows weight handles, which should either - be removed - be able to set the first-day-of week. This is outside fo this issue. A new issue should be created for this.

johnv’s picture

johnv
Primary language Dutch
commented
Status: Needs work » Fixed

Closing this issue, since a) initial issue is resolved, b) main patch #2 is committed, c) all other issues are reported elsewhere

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.