Fix remove_button plugin when settings.maxItems=1 #1151
Conversation
- keep the button element inside the 'item' element. - allows to use a custom CSS class for the remove-button element, when settings.mode='single'.
|
Changes Unknown when pulling be2715a on Pictor13:master into * on selectize:master*. |
- when removing an item the 'item_remove' event was triggered just with setting.mode 'multi' and not with setting.mode 'single'.
+ Merge branch 'master' of https://github.com/selectize/selectize.js + change bugfix (SHA: afd0c9c) The fix was wrapping the content into an additional <span> element. * that way the previosly used markup breaks, making the 'data-value' attribute to be added to the created span, instead that to the element with class 'item', as it was before. * additionally, this was making the 'singleClose' and the 'multiClose' plugin functions to generate not the same markup. + fix bug in 'remove_button' plugin 'item_remove' event was not triggered by clear(), when setting.mode was 'single'. + support custom class in 'remove_button' plugin
|
Changes Unknown when pulling e106436 on Pictor13:master into * on selectize:master*. |
|
Indeed, you must not change the dist folder, and only put your changes in the To get this merged:
Thanks! |
- the remove-button plugin was splitted in two functions (for 'multi' and 'single' mode). This led to divergence in behaviour, fixes, and triggered events (856307c). This commit unifies the code, congruently with the rest of the codebase, making the behaviour again more stable and similar, regardless of the mode (single/multi). - the remove-button plugin, when in 'single' mode, was not able to trigger the 'onDelete' callback, preventing from doing checks on the values; while that was possible just witht he 'multi' mode. Now both modes are able to trigger the callback.
|
Changes Unknown when pulling 9836eff on Pictor13:master into * on selectize:master*. |
Error solved by, changing the syntax addoption.
… nested highlight <span>'s
|
@joallard I was able to revert the changes to the dist folder to the v0.12.4. But I already pushed all the single commits to my remote origin; squashing them would mess up the history (am I missing something here? Is there another way?). Please let me know how to proceed. |
|
Ouch. I thought I'd check it out myself and do some Git-fu on it, but it's really tangled up bad. Which commits are yours? Some commits that were already in the master branch were re-added to your branch, another merge with master was made, then there's the weird commit on the tip (the "restored" one). If you need help visualizing, I use |
|
Ok, I tried again ^^ I close this one; correct pull-request is here #1311. Didn't have the time to fix my fork master yet, so for now there is just a new fix branch. Current upstream/master has been integrated into the fix branch on my fork, and the commits with the fixes have been added on top of that (hopefully in a more clean and less messy way than with this pull-request). I think now should be clear and ready to be merged without issues. Sorry for the initial mess with my contribution, and the terrible delay in fixing it. |
As explained in the comments here #848 (comment), I fixed the library in the case the setting maxItems is equal to "1".
All the test pass correctly.
Please evaluate if merging this pull-request, after verifying that nothing else breaks (everything seems fine to me).
Moreover, it still has to be compiled!. I didn't do it because the compilation also changes other parts of the code that I am not sure are supposed to be changed (and I wonder also why those changes happen; different dependencies versions maybe?).
An example is that the Line 1133 is changed to
and am not sure what makes the change (grunt task?) and why.
Maybe you can take care of compiling and making a new release?
Please take a look at it.
Thank you.