Hi all I have run into an issue with a site that I am in the process of revamping. When I try to use the commerce fancy attributes module to display small boxes for colors the current implementation of the modifications done to radio elements hoses things. Is there a way to bypass having a field run through the bootstrap_form_element function by the form id or something else? What I should get is something like:

<div class="form-item form-type-radio form-item-attributes-field-color">
  <input id="edit-attributes-field-color-50" class="form-radio ajax-processed" type="radio" checked="checked" value="50" name="attributes[field_color]" style="display: none;">
  <label for="edit-attributes-field-color-50">Avery MarshGrass </label>
  <div class="description">
    <div class="term-50 description-selected">
      <div class="field field-name-field-image field-type-image field-label-hidden">
        <div class="field-items">
          <div class="field-item even">
            <img class="" width="20" height="20" title="Title" alt="ALT" src="image_url"/>
          </div>
        </div>
      </div>
    </div>
  </div>
</div>

But I am instead getting:

<div class="form-type-radio form-item-attributes-field-color form-item radio">
  <input id="edit-attributes-field-color-50" class="form-radio ajax-processed" type="radio" checked="checked" value="50" name="attributes[field_color]" style="display: none;">
  <label for="edit-attributes-field-color-50">Avery MarshGrass </label>
  <p class="help-block"></p>
  <div class="term-50 description-selected">
    <div class="field field-name-field-image field-type-image field-label-hidden">
      <div class="field-items">
        <div class="field-item even">
          <img class="" width="20" height="20" title="TITLE" alt="ALT" src="IMG_URL">
        </div>
      </div>
    </div>
  </div>
  <p></p>
</div>

One thing to notice is that there is a div that is being dropped completely it is the one that is after the label that is setup as a div class=description which is what the attributes module uses for targeting in is javascript to toggle products.

Help please?

Comments

Christopher Riley’s picture

Christopher Riley CreditAttribution: Christopher Riley commented

Bump

markhalliwell’s picture

markhalliwell
Primary language English
CreditAttribution: markhalliwell commented
Title: Incompatibility with commerce fancy attributes? » Compatibility with Commerce Fancy Attributes
Component: Code » Miscellaneous
Category: Support request » Feature request

I'm not entirely familiar with this module. Adding "whitelisted" elements/ids is something that I do not entirely agree with. Either the theme or module should be fixed.

markhalliwell’s picture

markhalliwell
Primary language English
CreditAttribution: markhalliwell at Tag1 Consulting commented
Status: Active » Closed (won't fix)

No activity/interest

philsward’s picture

philsward CreditAttribution: philsward commented
Related issues: +#2257929: Bootstrap 3 support

This should be fixed by bootstrap. Bootstrap is removing the 'description' class, used by Fancy Attributes. Instead of overwriting what another module inserts, Bootstrap should be smart enough to include the classes that are injected by other modules and pass them along.

Whether the Bootstrap code is right or Fancy Attributes code is right, doesn't matter. Bootstrap has completely disregarded what other modules are doing by outputting it's own instructions.

markhalliwell’s picture

markhalliwell
Primary language English
CreditAttribution: markhalliwell at Tag1 Consulting commented

has completely disregarded what other modules are doing

No it's not. It's just not adding the "default" class core uses; which has no inherit value in Bootstrap.

If a module is building it's CSS/JS around what core spits out, then they're doing it wrong.

It should be providing (adding) its own module specific classes/data attributes so that they can be targeted by the module.

philsward’s picture

philsward CreditAttribution: philsward commented

@markcarver then what's the point of core spitting them out if no-one uses them? That just seems redundant and stupid, but I digress, I'm not a coder.

That said, the "only" themes that will cause problems, are the ones overriding the forms... which is what bootstrap is doing. 90% of the other themes out there, don't touch forms, therefore don't touch the core classes.

markhalliwell’s picture

markhalliwell
Primary language English
CreditAttribution: markhalliwell at Tag1 Consulting commented

It's not "redundant and stupid". Core themes use the description class to target and style form descriptions.

A some contrib themes use this selector as well, which is perfectly fine if they chose to theme around this assumption.

Bootstrap does not. It has no description class styles.

It uses help-block.

markhalliwell’s picture

markhalliwell
Primary language English
CreditAttribution: markhalliwell at Tag1 Consulting commented

That said, the "only" themes that will cause problems, are the ones overriding the forms...

That right there should tell you how fragile the module is then. If it were constructing its render arrays properly and injecting module specific classes/data-attributes to target, this wouldn't be an issue.

90% of the other themes out there, don't touch forms, therefore don't touch the core classes.

99% of the "other" themes are basically just shells for custom CSS and a few preprocessing functions.

This is a base theme, the #1 base theme for that matter. It's entire purpose is to integrate the external front-end framework (Bootstrap) with Drupal.

Drupal (mostly < 8.x) makes a LOT of assumptions regarding markup/classes, etc.

So yes, the majority of this theme does "override" what core assumes we "need" and replaces it with what Bootstrap will actually support.

philsward’s picture

philsward CreditAttribution: philsward commented

After thinking on it a bit, I can see your point of view and yeah, it does make more sense.

On the flipside, there are only a handful of themes (frameworks) that need and do override that level of core. So... I can also see the other side of it as well.

Just because bootstrap doesn't use Drupal's core classes means the port of it doesn't need to respect core?

In honesty, most of this is over my head, so I'm trying to understand it. At the end of the day, I have my workaround and the module in question has more detailed info on how to resolve it, so win win I suppose :-)