Improve the Browse available tokens link

This makes sense to me.

I'm actually wondering if a custom form element could be created to make it also more flexible. I'm thinking sort of a split button style where a settings subform expands where you could modify some of the properties that would influence performance while browsing. It doesn't have to be saved anywhere although a global token settings form could be helpful to replace what token_tweaks module was doing.

• recursion_limit: This is currently hardcoded to 3 and restricts being able to see anything any deeper. This could be a dropdown ranging from 1 to x(whatever max makes best sense).
• global_types: This could be a checkbox
• entity_types: optionally limit via checkboxes

The subform could trigger an ajax event that updates the browser link itself. I'm doing something similar in a custom form but it would be nice if token module supported this so it could be used anywhere.

@apmsooner: Your suggestion sounds very interesting!

I am not a fan of the Token modal, which I always need to resize. I would much prefer an expanding form, directly on the page, to allow immediately scrolling down through the available tokens with the mouse wheel, or even arrow keys?

Adding Token settings to define depth, default expanded level (1,2,3, etc.) and the other options you mention would be great, and prevent much clicking, dragging, and scrolling ...

Perhaps you can share a GIF to help visualize it?

@ressa, I actually created a custom form element for a feature in my own module that does what I described. You could copy it to your own local and just change the namespace if you wanna try it out: https://git.drupalcode.org/issue/custom_field-3476033/-/blob/3476033-enh.... The annotation provides a useage example.

Let me know what you think.

I should clarify, i didn't do the button thing. I was looking at the drupal DropButton class but its not setup to render anything in the dropdown other than links. A custom element that could do that would be ideal so the button would replace browse tokens link and the dropdown could have settings like my custom element is providing. Additionally, i agree... I find having to resize the modal a bit annoying also. It would be nice if the browse tokens link could receive params to set dialog size and we could do basically the same as these other settings.

Thanks for the link @apmsooner. I misunderstood your description, and thought there would be no modal, and that it would be more "form-like", directly in the page.

I did try to clone and run custom_field-3476033, but it looks normal to me ... or do I have to do something extra? I still do think a short GIF or movie would be helpful to visualize it -- for me at least :)

I was picturing something along these lines, as seen in the media file, and images below.

Token form collapsed

Token form expanded

@ressa, no i meant literally copy that file down into your own module /src/Element. It still uses the modal but the form element provides a few settings that ajaxify the params in the token browser link. Attaching a screenshot for a little more clarity.

Thanks for clarifying so fast @apmsooner.

I do think a non-modal form, directly in the page would be more user friendly, as I outlined in comment #4.

What do you think about my suggestion in #7? Is it possible?

It seems like it could be feasible. The files to look at are:

https://git.drupalcode.org/project/token/-/blob/8.x-1.x/token.pages.inc?...

And the controller that actually builds the tree:
https://git.drupalcode.org/project/token/-/blob/8.x-1.x/src/Controller/T...

I think instead of having it open a dialog, it would just replace a div via ajax with the tree. I think a form element that supports that wouldn't be too difficult to do, just a matter whether the maintainers want to entertain having it in the module. I don't mind the modal but the ability to pass size options to the dialog would be nice.

It's actually pretty simple to override the dialog options. Surprised theres honestly not a settings form in Token module to handle these things. It would be a pretty simple thing to provide a little more flexibility.

$dialog_options = [
      'dialogClass' => 'token-tree-dialog',
      'width' => 800,
      'height' => 600,
      'position' => ['my' => 'right bottom', 'at' => 'right-10 bottom-10'],
      'draggable' => TRUE,
      'autoResize' => FALSE,
    ];

    $element['token_tree_link'] = [
      '#theme' => 'token_tree_link',
      '#token_types' => $element['#token_types'],
      '#recursion_limit' => $element['#recursion_limit'],
      '#global_types' => $element['#global_types'],
      '#text' => $element['#text'],
      '#prefix' => '<div id="' . $wrapper_id . '">',
      '#suffix' => '</div>',
      '#options' => [
        'attributes' => [
          'data-dialog-options' => json_encode($dialog_options),
        ],
      ],
    ];

Thanks for a fast response and taking a closer look and sharing the code. It sounds great that it might not be too difficult to go from modal to an expandable form element.

I am not much of a coder, and I attempted to update token.pages.inc with the code you shared and failed ... perhaps you can share the necessary changes as an attached patch file? Or even an MR? I would love to see it in action!

You write you don't mind the modal, but would you prefer an expandable form element, if it was possible? I agree that having it as an option under Token settings wold be nice. I would set the new expandable form as the default going forward, while of course allowing those who still want the modal to switch to that.

@rkoller: Perhaps you can weigh in, looking at it from a usability perspective? My hunch would be that an expandable form element would be more accessible, and making Token browser comply more easily.

I don't think that's what this issue is about, it's about making the existing behavior accessible, not add features to it or replace it with a completely different UI. It really does need to be done, be it a modal or not, but I don't think that's the issue for it.

in almost all cases, the available types are expected to be provided by code. It must match the token types that are actually available on the corresponding token replace call. You can't just wish taxonomy term tokens into existence when configuring a node pathauto pattern. There might be some exceptions where that's useful but I would that outside of the general help page, those would be very, very rare.

Also, the recursion limit can't just be extended, already the current hardcoded limit tends to quickly result in absolutely massive server and browser resource usage. The only proper fix for that is completely replacing it with an ajax-powered, lazy-loading token UI that loads child tokens as you expand elements.

@berdir, no worries I can do what I need in my own module. Sure, I guess this is about accessibility rather than functional so carry on.

@berdir Thanks for weighing in. I guess changing the interface from modal to expandable form will affect other areas such as tests, which could make this issue balloon ... so let's keep it focused as stated in the Issue Summary.

@apmsooner I am still interested in trying your method, if you don't mind sharing a patch? I have created 📌 Token browser as expandable form, replacing modal Active where you are more than welcome to share the code for expanding form in the issue's Gitlab branch :)

I agree with @berdir, I would consider the option of adding a drop button and providing some flexibility about the scope within the modal out of the scope for this issue. definitely an interesting idea, to provide a certain degree of flexibility to the user, but as i've already mentioned on #3489325-3: Token browser as expandable form, replacing modal → , and that also resonates with the points @berdir made, it might be the better choice to first come to a consensus about into which direction the token ui 2.0 should head ( 📌 Token UI 2.0 Active ). As soon as the general direction is agreed on it might be easier to iterate on questions like if and how such a drop button functionality would make sense to include (but i would move it to a followup issue either way). And as suggested in #3489325-3: Token browser as expandable form, replacing modal → as a start for token ui 2.0 i might add the topic to the shortlist for the weekly ux meetings as well as bring it to the a11y office hours. just to get some more perspectives, ideads, and input on a viable initial general direction?

@apmsooner I got great feedback from @rkoller in 📌 Token browser as expandable form, replacing modal Active , and I updated my proposal based on that. If you have time, feel free to check out the issue.