Token UI 2.0

subscribe

subscribe

[subscribe]

Some sort of autocomplete-driven browser seems like another possibility, but it could be inflexible and may not be appropriate for novice use since it requires needing to know some component of the machine name before typing.

We are going one step further, completely removing the themed tree and rendering these in a popup. While the server settings / resources are massively high, speed is an issue and this reduced the load time by about a 1 second. The token table by itself is 478KB.

Is there anything that I can do in the meantime to fix unresponsive jquery issues when the token tree gets too big? I just installed the rpx/janrain engage module and it completely killed some pages with token options. Im assuming its related to this issue?

Just a note that we are trying to get a token browser in core for Drupal 8 on this issue:
#514990: Add a UI for browsing tokens

if there is some configaration to let us to decide which way we display the token list ( token_tree or token_tree_link),
it is will be great!

I am really experiecing a tough time to change all the token list to ajax by coding...

Thanks for your attention.

@zterry95: I definitely favour the idea! Unfortunately by default, Token outputs huge nested tables without letting the administrator decide whether he/she wants to risk a memory exceeding: #1836264: Huge nested table trees displayed in field settings lead to "allowed memory size exhausted" errors - display should be AJAXified.
For some reason, unfortunately Dave Reid said he "just fundamentally disagrees" with changing Token's default behavior, and using Token tweaks instead: http://drupal.org/node/1842738#comment-6741198. I'm curious about the approach, but I didn't get an answer.

This, this, this...

Use AJAX when a user wants to view nested tokens (get deeper in the token tree) - then we will only have to load the first level of tokens by default. Getting further will require relatively small request each time.

Use AJAX when a user wants to view nested tokens (get deeper in the token tree) - then we will only have to load the first level of tokens by default. Getting further will require relatively small request each time.

Sounds like this: https://www.drupal.org/project/hierarchical_select

Hi all, did you end up anywhere with this? I'm super grateful for the improvement in the token module whenever that was (couple years ago?) to switching to a token-browser-dialog instead of when the page with a form is rendered, but, it's extremely frustrating waiting for the token browser to load, and sometimes it simply doesn't work in some of my VMs -- I could go on, but I know I'm preaching to the choir :) Anyway, just curious if any of you got anywhere, even if just locally (or on some other related issue that simply didn't get linked to from this one), on this issue. Thank you!

Had a short chat with @Berdir today about this, summary:

1. Starting point should probably be finding a well maintained JS library that is accessible and supports AJAX - if that can be found then this might be fairly easy to solve
2. One potential issue is that libraries are not allowed to be committed which we will probably face if updating the library used here. We would need to update how we go about including it.
3. A quick search brought up a few options that have not yet been fully researched (in no particular order):

• https://github.com/jdl/jquery-lazy-tree-table
• https://www.jqueryscript.net/tags.php?/tree%20view/
• https://www.jstree.com/ | https://mtyka.github.io/code/2012/10/02/lazy-loading-with-jstree-and-aja...

That's as far as we've got.

Re #16.2 I propose including whatever we choose in the module's composer.json file and put installation instructions for non-composer users on the project page.

That won't work for JS libraries, it'll need to be an example composer.json file like File Entity Browser does, and/or plain installation instructions.

jstree might work reasonably well and supports JSON, which could be useful with the community's move to using JSON for more things. It does seem to tick a lot of boxes.

As identified by apmsooner, v4 of jsTree is removing the jQuery dependency:
https://github.com/vakata/jstree/issues/1904

That sounds promising :)

That was 2017 and v4 is not yet released, last release in 2020. not very promising?

The maintainer's last comment was in February of this year:

I am struggling with time for jstree - I did nudge the repo a bit in 2023, so I expect to be able to find more and more time for jstree, but it is not as much as I want it. v4 lacks all the plugins of v3 and is not yet thoroughly tested, but it looks promising - I hope to reenable plugins one by one in the upcoming weeks / months.

I know, but we're talking about something that could also get into core. The chances of getting a library maintained by single person who barely has time for it (which is perfectly understandable) into core seem _very_ slim :)

This should not include general coding standards cleanup, removal of legacy hooks and so on, makes it way harder to keep two branches in sync and review this.

@berdir,

I was just knocking it out cause it has to be in a new version anyway because of the core 11.3 dependency and it was pretty out of date and hard to follow without being properly typed and such.