Problem/Motivation

Views' "Add field" forms have default configurations that are not optimized for working with fielded views + Fences. There are several checkboxes that need to be toggled for every field that is added to a view. It would be very nice if Fences changes the default configuration when you add a field to a view.

Greg tried using a simple form_alter, but changing the #default_value actually means that the field will always have that default value even if you specifically change that toggle in the UI while editing the field. In other words #default_value is acting like #value for these forms.

fences_form_views_ui_config_item_form_alter()
fences_form_views_ui_edit_display_form_alter()

Here's the list of things we want to change the defaults for:

  • Turn off "Create a label". We almost never want the field's label.
  • Style settings:
    • Turn on "Customize field HTML". We don't want the default Views wrappers.
    • Set "HTML element" to "- None -".
    • Turn on "Customize label HTML".
    • Set "Label HTML element" to "- None -".
    • Turn on "Customize field and label wrapper HTML".
    • Set "Wrapper HTML element" to "- None -".
    • Turn off "Add default classes". We don't want Views' field classes because the field's classes are enough.
    • Turn on "Use field template". Otherwise Fences' configuration isn't used.

Proposed resolution

Muck around with HOOK_form_views_ui_add_item_form_alter() to see if the configuration defaults can be inserted into the View object before the views_ui_config_item_form form and the views_ui_edit_display_form form are displayed.

User interface changes

Makes Views' default configuration options be Fences-friendly, but let administrators change the default configuration options.

Original report by stevector

This was brought up on the last day of the sprint. Right now Fences automatically checks the "Use field template" box every time a field config form is opened. This is done in a form_alter and it does not remember if that box was previously unchecked. I think this can be fixed by using a submit handler on the add form. I spent some time trying to get that to work and failed. I'm recording it here as an issue to keep track of this need.

CommentFileSizeAuthor
#6 1300576-6-views-defaults.patch3.57 KBjohnalbin
#5 1300576-5-views-defaults.patch3.18 KBjohnalbin

Comments

johnalbin’s picture

johnalbin
they/他
Primary language English
Location Taipei, Taiwan
commented
Priority: Normal » Critical

Wait… so you mean when you add a field in Views, that Views actually adds the field and then displays the options form for that field?

Do you know the hook for altering a field on a View when it's added?

stevector’s picture

stevector
he/him
commented

This is what I was trying to work with. I think the submit function needs to alter the View object so that the fields have that flag set before the next form, views_ui_config_item_form, is generated. I don't recall exactly where I was going wrong. Maybe we should talk with Earl about this.

 /**
  * Implements hook_form_views_ui_add_item_form_alter().
  *
  * Put a flag on the view object
  */
 function fences_form_views_ui_add_item_form_alter(&$form, &$form_state, $form_id) {
   dsm($form);
   dsm($form_state);
   $form_state['view']->fences_set_field_api_classes = TRUE;
   $form['#submit'][] = 'fences_views_ui_add_item_form_submit';
 }
 
 function fences_views_ui_add_item_form_submit(&$form, &$form_state) {
   dsm($form);
   dsm($form_state);
 }
agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

Trying to understand exactly what the intent is with Views.

What are the requirements?

  • To be able to change the default tag on each field?
  • To be able to change the default tag on the entire View content?
johnalbin’s picture

johnalbin
they/他
Primary language English
Location Taipei, Taiwan
commented
Title: Fences should only check "Use field template" when adding a field » Optimize Views' default field configurations to be Fences-friendly
Category: bug » feature
Priority: Critical » Major

I edited the issue description above, Ken.

Because the form alters were causing critical UI issues, I've commented them out for now. So bumping this back to "major".

Steve, yeah, after I posted my comment above I found the HOOK_form_views_ui_add_item_form_alter() and was dsm'ing it to hell. Still haven't found the magic bullet.

johnalbin’s picture

johnalbin
they/他
Primary language English
Location Taipei, Taiwan
commented
Issue summary: View changes

Add issue summary

johnalbin’s picture

johnalbin
they/他
Primary language English
Location Taipei, Taiwan
commented
Status: Active » Needs work
StatusFileSize
new 1300576-5-views-defaults.patch3.18 KB

Here's a patch that gets closer to where the problem occurs. But it still doesn't actually work. :-p

johnalbin’s picture

johnalbin
they/他
Primary language English
Location Taipei, Taiwan
commented
Priority: Major » Normal
StatusFileSize
new 1300576-6-views-defaults.patch3.57 KB

Fixed it!

Well… I fixed the fences_form_views_ui_config_item_form_alter() part. I added a temporary property to the View when the fields are added. And then use that property to tell if the field is "new" when its options form is displayed. Here's the patch I committed.

There still remains the fences_form_views_ui_edit_display_form_alter() form alter. :-\

johnalbin’s picture

johnalbin
they/他
Primary language English
Location Taipei, Taiwan
commented
Priority: Normal » Major
Status: Needs work » Fixed

We were trying to uncheck the "Provide default field wrapper elements" box on the Field row settings form. That setting is going to require a different strategy then we used above. If we are building a fielded view, we may not actually go into the Fields Row Options form. We need to alter the View to have a different default for its row_options.

I can't tell which properties of the View I need to alter. I see these, but I think there are similarly-named properties elsewhere in the View:

$view->display_handler->options['defaults']['row_options'] (boolean)
$view->display_handler->options['row_options'] (array)

Actually, thinking about this some more… we are already removing Views' wrappers and just using Fences' wrappers around all field-api fields. Any other kind of field is just a "Views field" and, surely, that does need a default wrapper around it? Ok, I'm going to remove that form alter stub and close this issue.

Status: Fixed » Closed (fixed)

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

Anonymous’s picture

(not verified) commented
Issue summary: View changes

Update issue summary.