Problem/Motivation

Only tested this for classes, not sure if ids and attributes have the same behaviour...

I add a new class "block--images" to block 1. In block 2 I add another classes "block--map" and "block--gmap", but the list of available classes is empty. In block 3 I want to add the class "block--images" again, but in the available classes only "block--map" and "block--gmap" are listed.

Steps to reproduce

See above.

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

droprocker created an issue. See original summary.

chris matthews’s picture

Version: 2.0.0-beta15 » 2.0.x-dev
anchal_gupta’s picture

StatusFileSize
new193.52 KB
new196.73 KB
new207.44 KB
new157.61 KB
new213.26 KB

Hi,
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.
Block1
4. then I add another class "block--map" and "block--gmap" in block 2 the list of the available classes is not empty.
Block2
Only local images are allowed.
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.
Block3
Available class list

pooja_sharma made their first commit to this issue’s fork.

pooja_sharma’s picture

Status: Active » Needs review
StatusFileSize
new91.86 KB
new87.14 KB

Added 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

kopeboy’s picture

Priority: Normal » Major
Status: Needs review » Reviewed & tested by the community

I 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!

kopeboy’s picture

FYI I noticed that the latest version of this module (v4, now stable) doesn't have this issue.

dydave made their first commit to this issue’s fork.

dydave’s picture

Version: 2.0.x-dev » 4.0.x-dev

  • dydave committed bbce70b3 on 4.0.x
    Issue #3276398 by pooja_sharma, dydave: Refactoring of field...
dydave’s picture

Status: Reviewed & tested by the community » Fixed

Thank 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! 😊

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

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