Closed (fixed)
Project:
Block Class
Version:
4.0.x-dev
Component:
User interface
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
21 Apr 2022 at 08:20 UTC
Updated:
15 Nov 2025 at 04:29 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
chris matthews commentedComment #3
anchal_gupta commentedHi,
I have tested this issue according to the given description but that problem is not reproduced in my system.
The class Autocomplete widget is working fine and I also test ids and attributes it's also working Fine.
Could you please provide more detail? It would be helpful.
I am testing this issue in the Drupal 10.1 version
Testing Steps:





1. Install the Block class module.
2. Go to Administration » Structure » Block Layout.
3. I add a new class "block--images" to block 1 and attach the screenshot.
4. then I add another class "block--map" and "block--gmap" in block 2 the list of the available classes is not empty.
5. Then I go to the block3 configuration the list of the available class have shown all the classes then I add the "block--images" and save.
Comment #6
pooja_sharma commentedAdded changes in MR 21. Please Review.
Attached Screenshots for reference
Issue replicate when exact existing class name type/paste, which should not occur as per User experience, it creates kind of confusion that this class not exist.
I tried to check in core default link field or any other field which is searchable & if you try to paste/type exact "string" then still that string visible in the list
Comment #7
kopeboyI noticed on a fresh Drupal 10.3.1 install just to test this module that searching for an existing class would not show it in the autocomplete 😅
Like say I created class1 and class2, then while typing class in the autocomplete I would see both class1 and class2, but as soon as I also type the 1 in class1, class1 would disappear from the selection list 🤨 Weird.
Fortunately I applied MR!21 as a patch (even to the 2.0.11 version) and it solved the issue. Thanks!
Comment #8
kopeboyFYI I noticed that the latest version of this module (v4, now stable) doesn't have this issue.
Comment #10
dydave commentedComment #14
dydave commentedThank you very much for reporting this issue and for providing a solution in the code, it's greatly appreciated!
Thanks to #6 I was able to reproduce the behavior described in the issue summary.
I have tested the changes from the merge request and they also seemed to implement the correct behavior.
However, when I started investigating the code changes from the MR, I thought I might want to look for an equivalent example from Drupal core and found:
\Drupal\block\Controller\CategoryAutocompleteController::autocomplete()https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/block...
I thought: we migth as well align the module on the current implementations of autocomplete callbacks in Drupal core (similar types of fields), since the user experience and interactions with module's form fields would therefore stay consistent and would most likely be easier to maintain.
The autocomplete callbacks for CSS classes, Attribute keys and Attribute values were fully refactored based on:
CategoryAutocompleteController::autocomplete().I copied the function over, adapted it slightly, then kept the same callback functions but simplified.
I then looked into the
BlockClassHelperService::blockClassFormAlter, which brought me to make the following changes:- Removed unused services dependencies: I was wondering why there were so many dependent services and started searching for the properties in the class file. Then, found many properties and injected services were not used, so they were all removed with their associated code.
- I was a bit stumped to see example images in the repo, weighting almost 500KB, with almost no importance for module's features, included in the repo and thus downloaded with every single package request... 🤦♂️😖
These images were removed and uploaded in Block Class Project page files, hidden on the page, but with a URL on Drupal.org.
Took the opportunity to rework and simplify a few description texts at the same time.
After doing several round of tests locally and since all the tests of the MR were passing 🟢, I went ahead and merged the changes above at #13.
From my perspective, there is still a very important amount of work on the module 4.0.x branch to actually become stable...
It really feels like a very basic initial version that would need a significant amount of work and time to be improved so its features actually become exploitable to all users.
Let's try to keep improving overall module's code as we work on pending tickets.👍
Feel free to let us know at any point if you have any questions or concerns on any aspects of the latest code changes or the project in general, we would surely be glad to hear your feedback.
Thanks in advance! 😊