Down arrow icon won't display on Select2 drop-down element with Bootstrap theme

Are you using the Bartik theme? Is this a custom theme specific issue?

The Bootstrap theme needs to be adjusted to support the Select2 library that Webform 8.x-5.x and other modules use. I'd suggest asking the D8 Bootstrap maintainers to add this, as a starting point: https://github.com/select2/select2-bootstrap-theme

@CatherineOmega That information is super helpful.

I think this is a gray area relating to who should fix the problem.

The Webform module is implementing the Select2 element and we are probably obligated to fix Select2 Bootstrap integration issues. The Webform module is downloading the Select2 library and should just download and attach the Select2-Bootstrap library when the Bootstrap theme is enabled.

Now, that I know the issue, I should be able to easily fix it.

BTW, the Webform module is about to reach 15 external libraries which I think is a record.

I am seeing duplicate down arrow.

The attached patch includes the https://github.com/select2/select2-bootstrap-theme which does not solve the problem. The issue is coming from the bootstrap theme.

I am going to try a different approach to fix this

The attached patch does fix the Select2 and also the ImageSelect element down arrow icon issue with some other minor Bootstrap issues.

I changed my mind about supporting Bootstrap because it has 21840 D8 installs and @markcarver has enough on his plate maintaining this theme.

Hopefully most Bootstrap related fixes can just go into css/webform.theme.bootstrap.css.

I committed the patch. Please download and review the latest release.

The Webform module is downloading the Select2 library and should just download and attach the Select2-Bootstrap library when the Bootstrap theme is enabled.

Webform shouldn't be implementing external FE libraries like this at all, especially considering there's an effort already underway to implement select2 in core.

If this module wants/needs this library now, then it should focus its efforts into helping port the existing 7.x select2 module and then add it as a dependency.

That being said, I honestly don't know why select2 is being considered for core. https://www.drupal.org/project/chosen is, and always has been, the forerunner in this type of FE enhancement.

---

The bottom line is: if a user wants additional FE tools like this, then it should be left to FE/developer to implement these... not a module.

Especially considering that there are already Bootstrap specific plugins to handle these types of enhancements which are far preferable than select2 or chosen:

https://github.com/silviomoreto/bootstrap-select
https://github.com/truckingsim/Ajax-Bootstrap-Select

I am completely open to leveraging other contrib module. For examples, IMCE is now handling all asset management for the Webform module.

At the same time, I want the Webform module's UX to be as rich as possible without requiring a half-dozen contrib modules. Every external library required by the Webform module is well managed and can be download using one drush command or loaded via a CDN. As other contrib modules are ported and the Libraries API module has a stable release, the Webform module will integrate and leverage these new tools.

I want the Webform module's UX to be as rich as possible without requiring a half-dozen contrib modules.

You're already requiring half-dozen libraries aren't you? What's the difference?

Regardless, explicitly relying on anything inherently creates conflicts and ties a user/developer into using this module's specific chosen (no pun intended) modules/libraries.

I understand the desire to have the UX be "rich", but webform shouldn't be authoritative in the FE libraries it implements. Instead, it should support the possibility of external solutions (e.g. this module will work better if you use X module/library).

There is a reason why these are called modules. They should be designed in a modular fashion. It shouldn't be bundling other projects into itself.

IMCE is now handling all asset management for the Webform module.

This honestly makes no sense. IMCE is a WYSIWYG editor which, inherently, conflicts with the bundled core CKEditor WYSIWYG editor.

This is just another example of forcing a user to conform to a specific plugin rather than providing support for additional functionality.

Why not just use existing core File APIs for asset handling? Or help https://www.drupal.org/project/media or something similar?

The level of customization available within the Webform module's API, allows absolutely every aspect of a webform and elements to be tweaked.

I am taking a different approach to what the out-of-the-box UX should be for Webforms for D8. I do see Webform 8.x-5.x as a more of a product than a module.

@markcarver You are making a very fair argument that the Webform module's out-of-the-box assumptions should be easy to disable and swappable.

You are making a very fair argument that the Webform module's out-of-the-box assumptions should be easy to disable and swappable.

It should be made, from the group up, with the assumption of no FE enhancements of any kind. These should only be layered on top as extra supported functionality, nothing more. This has been a "best practice" of Drupal (in regards to FE compatibility) for a very long time.

There a 10s of dozens of "select" plugins out there in the FE world, all claiming they're the best. The reality is, however, what is "best" depends on how the FE (theme) of a site is built. This is particularly true when using an external framework like Bootstrap that has existing specific markup/classes/components etc.

I get the "out-of-the-box" desirability. It's often missing in a lot of modules. However, when it comes to a Drupal site, there are way too many opinions on how any FE related aspect should be done.

A module should not be in the business of trying to theme or provide UI enhancements. It should only provide the fundamental API(s)/functionality (which in this case is: user configurable forms). If it does need to provide themeable aspects, it should be done in a way that allows a theme to override/extend as needed.

@rdw99, This issue (and commits) just add a lot of custom overrides that should really be implemented in a sub-theme.

However, I suspect what is really going on is that you're having a font/styling issue (maybe even a file/perm issue).

---

@jrockowitz, a module shouldn't be adding theme specific hacks into its codebase. It should be abstracting its code and allowing it to be extended from the bottom up.

To give an example, I just recently did #2803407: Refactor form element and JS to work with any theme. They kept trying to add Bootstrap specific selectors to their JS.

Instead, I refactored the whole thing to only be responsible for what it was trying to accomplish.

In a subsequent Bootstrap related issue, I was then able to extend a specified selector so it'd work in the [base] theme: #2862588: Support Image Widget Crop.

The same goes for CSS/FE libraries. A module shouldn't be implementing it (unless it's truly of their own creation, e.g. Views UI, CTools, features, etc.).

By binding these external libraries into this module, you're shifting the responsibility of compatibility to yourself and this honestly isn't your problem.

Nor is it really mine. Not all code "works together out-of-the-box", especially when jQuery/JavaScript/external frameworks are involved.

It's the responsibility of the site developer/builder to figure out what it is they need/want and to figure out any incompatibilities along the way.

There are enough blogs, tutorials and stackexchange questions floating around to answer almost any question.

---

I really believe this issue should be reverted.

All existing "FE enhancements" this modules implements should either be:

a) moved to respectable sub-modules that depend on the necessary external libraries/modules

Or more preferably:

b) removed them entirely and let these kinds of enhancements be implemented on the FE

---

Webform (as a standalone API) has never had any "FE enhancements" before nor has it really needed it.

There are plenty of additional contrib modules that extend the capability of webform as needed.

I didn't meant to mark as "Fixed", it's really supposed to be CNW.

By binding these external libraries into this module, you're shifting the responsibility of compatibility to yourself and this honestly isn't your problem.

I am okay taking responsibility for these external libraries. Especially if it helps with the overall UX. I am actively using Select2 within the Webform admin to make the UX considerably better. Trying to get Select2 to work with Bootstrap is becoming a slippery slope, which happens sometimes.

Webform 8.x-5.x is a completely different approach to previous versions of webforms. Please allow me some freedom here to experiment while this module is still in beta.

I am okay taking responsibility for these external libraries.

Let me see if I can't explain this in a very different way because I don't think you fully understand how much of a slippery slope you're actually going down (ignore if the version aren't actual release versions, this is just an example):

User installs Webform that comes with:
-- select2 (version 1.0.0)

User installed select2, but then forgot about it and left it enabled:
-- select2 (version 2.0.0)

User installs an admin theme that contains:
-- chosen (version 2.0)
or
-- selectize.js (version 1.0)

Default theme
-- Bundles bootstrap-select (version 1.0.0)

Can you tell what "wins" here?

Answer: all of them (depending on theme).

They're all loaded, competing for bandwidth and, depending on how they handle selects, events/DOM manipulation in JavaScript. Stepping over each other and likely causing some serious issues on the page. God forbid you have more than a few of em.

---

Please allow me some freedom here to experiment while this module is still in beta.

I'm really not trying to squash your ideas of experimenting here.

Experimenting is perfectly fine.

I'm just being realistic and trying to share my expertise in this topic.

I'm a FE developer.

I maintain the #1 most installed base theme on d.o.

I also maintain a slew of other FE related projects, including jQuery Update.

Suffice it to say: I actually understand the deep and convoluted complexities of Drupal + jQuery + JavaScript.

Bundling 3rd party libraries that aren't a direct implementation of said library as a specific Drupal module (e.g. chosen, select2, image_widget_crop, etc.) for the sake of "Better UI/UX" is a never the correct approach and has long been considered "Bad Practice™".

This kind of approach:

• Duplicates effort/code
• Bypasses existing projects that have, more than likely, have API in place to help deal with the complexities of that particular library + Drupal integration.
• Bypasses people familiar with said library (and likely JavaScript) to handle the oddities that come with ensuring "compatibility"
• Restricts existing sites from using said module because they already implement similar functionality via a different library and it's incompatible with the assumptions of said module.

I'm not saying you or someone else cannot use select2.

In fact, I'm saying the opposite.

A user should be able to implement whatever FE "select" enhancement library they need/want.

There are tons of libraries and modules that a user can install if that's what they desire.

The project page can even say: "It's highly recommended you install the select2 plugin/module as it this module was built with that in mind."

What I am saying is: you can't force a people to use a specific library and expect it to succeed in Drupal.

Drupal + jQuery + JavaScript just doesn't work that way.

This isn't an opinion. It's a well documented fact and why these libraries exist as standalone modules.

@markcarver I respect what you do, I respect your opinion, and I will gradually work to resolve these FE conflicts and assumptions over the next few months.

I was not asking for respect.

I was simply rebutting your prior comments which implied that this type of experimenting is OK in this module, it's not.

This issue still needs to be reverted because there should not be Bootstrap specific code in a non-Bootstrap specific module.

I set this issue to CNW and not fixed so you can get to it when you can, but not forget about it.

I am not trying to pressure, just a little OCD about module/theme responsibilities and d.o issue metadata/states is all.

For some reason this exchange triggered a lot of anger in me and I will strive to be civil.

First thing. I do agree that bootstrap specific stuff should not be in webform. BUT..:

I want to say I support 110% what @jrockowitz is trying to do in making the Webform module a very slick and seamless "product" (there is a reason non-drupal form builders are so popular) while making it extremely easy to customise. Forcing the user to have to architect a slick interface using cobbled together contributed modules that imperfectly interact with each-other is what makes it often not the ideal UX or multiplies the build time. Having the maintainer of Webform choose to better integrate with a particular front end library as a Default allows him to make a slicker interface that just providing generalised tools wouldn't. It's the combination of both extensibility and care for the default experience which makes a great product/system. As a side note, Webform/YamlForm has had the best on-boarding I have ever seen in Drupal with on-page docs, online-docs, inline video documentation! seriously, every modules should do that!

Good sensible defaults is something Drupal has been lacking for way too long. Only recently it seems the core UX efforts have started to tackle some of that. The D8 accessibility efforts are also to be commended on requiring better defaults.

@markcarver :

This issue still needs to be reverted because there should not be Bootstrap specific code in a non-Bootstrap specific module.

I understand where you are coming from in the separations of concerns and I agree with it in general but I'm frankly disappointed in some of your comments and how you come across. While I respect your contributions to Drupal and Bootstrap I feel you came across a bit like a jerk and bully in this issue.

I appreciate immensely that @jrocowitz actually does something about a problem and tries to fix it and make the module work better in a very timely manner.

I was simply rebutting your prior comments which implied that this type of experimenting is OK in this module, it's not.

I'm really not trying to squash your ideas of experimenting here.

Frankly I this this is exactly what you are doing. Discouraging experimentation and development. Webform/YamlForm has been usable for a along time due to rapid integration of pragmatic features that are needed in the real world with real clients who have real deadlines. All these libraries, while at first feels like a lot, makes the whole thing seem seamless.

I think experimenting with new features or UI enhancements is exactly what is needed (especially in a beta module). Even though it might not be the correct choice in the long term for maintainability. I agree that separation of concerns is important but it is often a huge barrier to rapid innovation. Decoupling can be refactored later on.

Just brandishing the Default Drupal Contrib Answer^tm "You should contribute to this other project instead" is highly counterproductive when you are trying to develop at a rapid pace and generate new ideas in your own space. Otherwise you are bogged down by conflicting goals and different speed of involvements from other contributors/maintainers. Jacob has had the fastest turnaround time and update rate I have ever seen in Drupal and I believe it's in part because he lives and breath the new Webform module and can iterate rapidly.

In closing I would say that I agree all these libraries should be optional and or completely decoupled eventually. But on-boarding must not suffer. Webform 8.x-5.x feels like a breadth of fresh air compared to so many other modules with "Programmer Art" UX.

Better UX is what makes clients love our work instead of suffering it.

For some reason this exchange triggered a lot of anger in me and I will strive to be civil.

Now you know how I felt when I first saw this issue.

Good sensible defaults is something Drupal has been lacking for way too long.

I agree and am not disputing that. There is, however, the correct way to go about it in Drupal (especially when involving FE JS libraries).

I feel you came across a bit like a jerk and bully in this issue.

I'm sorry if your @jrockowitz felt this way. This was never my intent. I will not, however, allow myself or others sacrifice "Best Practices™" for the sake of expediency.

As a member of this community I cannot, in good conscience, be silent when I see something that is horribly wrong in code; regardless if I maintain it or not.

The reality is: one day I'll likely have to use or encounter code from "insert project here" and end up having to completely refactor it so it's actually "theme abstracted" (#2803407: Refactor form element and JS to work with any theme).

I appreciate immensely that @jrocowitz actually does something about a problem and tries to fix it and make the module work better in a very timely manner.

I agree. I'm not disputing that. In fact, I was immensely shocked to see how quickly these "fixes" made their way in to such a popular project.

Frankly I this this is exactly what you are doing. Discouraging experimentation and development.

No I'm not. One can easily depend on an existing project to "enhance" whatever UX it deems it needs. The point is to not duplicate existing code/efforts.

I think experimenting with new features or UI enhancements is exactly what is needed

Then it should be done so in a dedicated issue/branch before making its way into the codebase. Furthermore, it would likely benefit from some reviews by people who specialize in UI/UX. This particular issue/topic would have come up almost immediately as a "fundamental design flaw".

Decoupling can be refactored later on.

Anything can be done later on, but it is often exponentially more difficult to do so in the future. It's better to architect something the proper way in the first place. Be mindful of existing projects and ways of doing things, especially when trying to integrate with an existing front-end framework like Bootstrap.

---

I think you're confusing my concern over implementing theme specific enhancements in a module as a "personal attack". It's not.

I'm sure @jrockowitz is highly competent and has made leaps and bounds in making this module better each and every day.

That was never in dispute.

What I was disputing was purposefully placing theme specific code (Bootstrap) in this module and the bundling of 3rd FE libraries.

I only ever wanted an acknowledgement and understanding of why bundling these libraries was a bad idea in the first place and the above commits reverted.

Debate on "Best Practices™" simply muddied the discussion.

I will undoubtedly get "this base theme isn't working with Webform" issues. That's a given.

What I don't want is: "this base theme doesn't work with Webform's select2 because we're using bootstrap-select" issues.

I think you're forgetting just how intertwined themes and JS components from modules are.

I really don't need an extra headache from a module that is "doing its own thing, damn others" kind of approach.

I mean, seriously... it's adding CKEditor, a library that is already in core...

It should be working with existing projects, not in spite of them.

Themes can easily extend/replace library assets in 8.x now.

I'd rather only have to target dedicated (official) libraries/modules rather than some duplicate definitions from this module too.

I believe @jrockowitz understands this. I was simply making sure.

@ptsimard Thanks for understanding and defending my work.

@markcarver I think you made a lot of judgments without knowing or asking about the background information around certain decisions. Obviously, I know there is the CKEditor in core and there must be some reasonable explanation to why I had pull down a second copy of CKEditor. I am not going to address the why here, because this ticket started out with someone asking for help and it was hijacked this "discussion".

I am most bothered by #26 because you basically are blowing off @rdw99 to continue to attack me.

@rdw99 Please feel free to open new ticket or contact me directly, so that we can work to resolve your problem.

I think you made a lot of judgments without knowing or asking about the background information around certain decisions.

They're not "judgements" and I don't have to "know background/decisions".

I have a very large comprehension of the intricate relationships between Drupal modules, themes and libraries.

My comments have only ever been based on empirical facts regarding the way Drupal actually works and the FE libraries that are currently bundled with this project.

I have never once said you can't still have select2 support. I have only ever said that it shouldn't be bundled and forced on people.

FE enhancements are a site/theme level decision that should be opt-in by downloading an appropriate module or implemented in a [sub]theme for said library.

It is not a module's place to arbitrarily implement a FE library, especially when some of these libraries have dedicated modules that already exist.

I am not going to address the why here, because this ticket started out with someone asking for help and it was hijacked this "discussion".

It wasn't "hi-jacked". I was invited to this conversation per the comment you made in #1943174-8: Better FAPI/Webform Support.

I understand you feel like I'm personally attacking you or somehow undermining all the hard work you've done.

I'm not. Please stop implying that I am.

You only have to tweak the code to add support for existing FE enhancement projects rather than forcing a specific one bundled with this project.

I am most bothered by #26 because you basically are blowing off @rdw99 to continue to attack me.

I'm not ignoring @rdw99. In fact, I actually addressed his weird "font" issue (which is likely some bad styling/file issues). However, the largest way I am addressing the problem is at a much higher level: don't put FE libraries in a module like this. Problem solved.

@rdw99's could then freely implement https://silviomoreto.github.io/bootstrap-select/, which would work just fine with the base theme and essentially do the same thing as select2.

If @rdw99 would like some guidance on how to implement it in a sub-theme, they can create an issue there and I'd be happy to help.

This, of course, would require Webform to stop bundling and forcing people to "use" select2.

---

It's clear that I'm no longer welcome in discussing proper solutions for this module.

I will no longer be commenting on this issue. It's blown into a raging cluster-@*!&.

Sorry for... whatever you think I did.... speaking facts I guess.

So, I guess... sorry you took the truth so personally.

@rdw99 I think the issue is the glyphicons are broken in your bootstrap.theme. If you switch back to the bootstrap theme, you should be able to inspect the broken icons and figure out what the broken icon's URL is pointing to. The issue might be as simple as your site is being served from a sub-directory.