#1562 Hide fields in view_entry and force word wrap in Day view?

[Shawn M]

After much trial and error (and googling) troubleshooting why PHP sessions no longer worked, I took this opportunity to upgrade from 1.4.11 to 1.7.1. Two questions/issues came up:

1) view_entry shows a few extraneous fields that weren't visible before: start_date, end_date, areas, and rooms. Each of these fields contains a Yes or No, and the real fields with this data are shown underneath them (See screenshot). Is this a problem, and (if no) can they be hidden? They do not appear in edit_entry. The entry_field_order in my config.inc.php file is:

// Rearrange order of form fields in Edit Entry page:
// Valid entries in this array are: 'name', 'description', 'start_date', 
// 'end_date', 'areas', 'rooms', 'type', 'confirmation_status', 
// 'privacy_status', plus any custom fields you may have defined. Fields that 
// are not mentionend in the array are appended at the end, in their usual 
// order.
$edit_entry_field_order = array('name',
                                'description',
                                'start_date',
                                'end_date',
                                'areas',
                                'rooms',
                                'type',                 // renamed to "Group" using vocab override
                                'booking_type',         // our custom variable
                                'confirmation_status');

2) In day view, entries with longer words in the brief description/title are now wrapping in the cell, whereas they used to force the cell width to widen in order to accommodate. Is there a way I could change this back? (see screenshot)

[Campbell Morrison]

The problem with the fields is a bug. I'll take a look tomorrow.

To change the wrapping in the cell, try adding a custom CSS file with the rule:

.dwm_main a {
  word-break: normal;
}

[Campbell Morrison]

On the fields problem you can restore sanity by changing line 100 of functions_view.inc from

  $field_order = (isset($edit_entry_field_order)) ? $edit_entry_field_order : array();

to

  $field_order = array();

This will make the fields appear properly. The only problem is that they won't be in the same order as they appear on the edit_entry form, which is what the change in 1.7.1 was trying to achieve, but obviously there's a bug in there. I'll fix it properly over the weekend, but in the meantime the change above should get you going.

[Shawn M]

Thanks, Campbell. That line for functions_view.inc did the trick.

Setting the CSS Word-Break to 'Normal' also helps a lot. However, longer words are still hyponated and wrapped, or, when there's just 1 or 2 extra characters, clipped (similar to 'Overflow: hidden').

I think it's from differences in how column widths are set in the table. Something is causing room columns with no bookings to maintain an equal share of the overall width (where they used to shrink a little whenever a neighboring column required more space).

Is there any way to return to that type of fluid behavior using CSS, or would it be more complicated than that?

[Campbell Morrison]

You could try editing functions_table.inc and changing line 832 from

      $header_inner .= "<th data-room=\"" . $room['id'] . "\" style=\"width: $column_width%\">

to

      $header_inner .= "<th data-room=\"" . $room['id'] . "\">

[Campbell Morrison]

Actually, another way that doesn't involve changing MRBS code might be to add the CSS rule

#day_main th {
  width: auto !important;
}

[Shawn M]

I tried both of those changes, but they helped some columns and made others worse. I looked at a particularly busy day in the 1.4.11 installation and noticed the table expands horizontally when needed (and adds a scroll bar). Are the tables in 1.7 fixed, or would they do the same? I'll try to test a few other things (looking at 1.4 CSS for clues).

[Shawn M]

I figured out the CSS portion of my post---the culprit was how text was wrapping/breaking, not any of the table width settings. The code in my custom.css file is now:

.dwm_main a {
  display: block;
  min-height: inherit;
  word-break: normal;
  -webkit-hyphens: none;
  -moz-hyphens: none;
  hyphens: none;
}

Thank you for your help and pointers along the way, I appreciate it!

[Campbell Morrison]

Good, glad it's working now.

I have just committed a proper fix to the view_entry problem in the default branch in d21c01. The changes are quite extensive, so if you are happy with the temporary fix above that you already have then I'd stick with that.

[Shawn M]

Thanks again! I followed along with your changes (more for the learning exercise), which successfully removed the 'confirmation_status' boolean from view. However, when a confirmed entry is edited, the radio button automatically changes to 'tentative' now. This could just be on my end, but I wanted to point that out just in case.

As a side note:
The other boolean fields (start_date, end_date, areas, and rooms) remained after adding the changes. As a quick and dirty fix just to hide these from our end users, I added them as cases to be ignored in functions_view.inc (~line 122), which seems to work. Could doing this have unintended consequences elsewhere? I undid this to see if the status change was being caused by it, but it's still happening.

[Anonymous]

I've now fixed the problem with the confirmation status when editing an entry.

I think the other problems you are seeing may be because you haven't got all the new files. To fix the main problem I ended up changing about a dozen or more files in the default branch. And the default branch itself was alkready substantially different from 1.7.1. So the only safe thing to do is to upload the complete set of files from the default branch snapshot and treat it like an upgrade.

[Campbell Morrison]

Sorry, I hadn't logged in. That last post was from me.

[Shawn M]

Thanks again for your help! I'm going to wait until a future release before implementing changes (for reasons you've stated---I likely don't have all of the other code from prior fixes).

[Lance Jones]

Is there a way to hide a tentative booking so that it doesn't show up on the day, week and month views?

[Lance Jones]

I think I've done it:

/ booking confirmation status /
.tentative {background: none}
.tentative a {color:transparent}

[Campbell Morrison]

Yes, that will do it. Presumably you've put the CSS in a custom CSS file rather than editing mrbs.css.php - that way you won't have to reapply the changes when you upgrade to a new version of MRBS.

The only problem with hiding the tentative bookings is that it could be a bit confusing for users when they try to make a booking as the slot will appear to be free.