| Project: | Drupal core |
| Version: | 9.x-dev |
| Component: | token system |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | JavaScript, Usability |
Issue Summary
Problem/Motivation
We have the ability to do token replacements in Core. But we don't have a token browser. It's currently provided by the Token contrib module (http://drupal.org/project/token). Without a token browser, there is no way for users setting up tokens to discover what tokens are available to them.
Proposed resolution
Add something similar to the browser from the contrib Token module to core.
Design considerations
- Efficient (code/load time - current treeTable implementation of the contrib Token 7.x module breaks with lots of tokens)
- Accessible (current TreeTable implementation is not!)
- Usable
- Efficient to find the token you are looking for ("scannable")
- Search capability - which may or may not be different from autocomplete
- Hierarchical structure of tokens reflected in hierarchical-looking UI (intuitive)
- Screen real estate (keeping mobile in mind too!)
- Maybe different modes depending on the scope of the token list?
- Flat list if there are only a few
- Tree list and/or hierarchical autocomplete and/or search if the list is longer
- Not loading the entire list initially if it's really long (page load time)
- Reusable UI pattern that can be used in Rules, Panels, Blocks, Layouts, Views, Etc. for both tokens and "token-like things".
- Naming conventions / standards for "token-like things"
Scope for this issue
This issue will be limited to building a tree-based token browser.
We'll spin off other issues as necessary to deal with:
- Autocomplete
- Search
- Token naming
- A UI that changes based on the size of the list (flat -> tree etc.)
Remaining tasks
1. Make a patch that adds the browser similar to the contrib Token module to core. However, it shouldn't actually *be* that browser, since it's not efficient/scalable and is also not accessible.
2. Make sure there are tests for it.
3. Make sure it is accessible.
4. Make sure it is usable.
User interface changes
Core would have a token browser, which would be displayed whenever tokens are usable in the admin UI.
API changes
None.
Original report by eaton
Many different parts of the Drupal admin interface use placeholder tokens inside of a longer stretch of text to represent "some value that will be replaced later." Sending out welcome emails to users is a common case: core allows admins to enter the text of the mail, with placeholder tokens like %user-name and %site-url.
Token module is a popular contrib module that offers similar functionality to modules that need placeholders/wildcards for other purposes. Modules can provide new tokens, like "[og-name]" for "The name of the organic group that a node belongs to" or [site-slogan] for "The site slogan the admin entered on the site settings page. Users can then use those placeholder tokens in any token-enabled field (like pathauto's configuration page). Token module is being proposed for inclusion in Drupal 7 core, because its centralized 'registry' of placeholder tokens is useful all over core and contrib.
The challenge (and it's a tricky one) is how to properly explain to users what tokens are available to be used and what they mean when they are presented with a field that can "accept" tokens. Several solutions to this exist right now, and some brainstorming has been going on for the Pathauto module, but ironing it out for core would be very beneficial.
Right now, in Drupal 6, token module provides a helper function that just spits out a table of all the tokens that are available. This is less than ideal, because with a number of token-providing modules installed, the list can get really really long. Some modules (like pathauto) manually build their own lists of tokens broken up by the 'kind' of token. (Node related tokens, user related tokens, etc.)
Some existing links include:
http://groups.drupal.org/node/19500
http://www.flickr.com/photos/mverbaar/3595675392/in/set-72157619245872526/
What are the essential 'bits of information' that might be conveyed for tokens?
1) The 'token type' -- node, user, etc.
2) The token as it is used by a module -- for example 'title' or 'uid' or 'mail'
3) The user-friendly name of the token -- for example "Node title" or "User ID"
4) An optional extended description of the token -- for example, a fully formatted date demonstrating how the 'date' token will appear
5) The token as it can be entered by a user -- for example [user:name]
6) The token as it can be entered if chained with another token -- for example [node:author:name] instead of [user:name]
In the quick omnigraffle mockup below, I've listed an example of the sort of things that might be commonly entered into token-enabled fields. The fields themselves don't have to do anything special with the tokens -- they just need to have some way of presenting the 'possible' tokens. Some existing ideas include: a collapsible browsable list of tokens, grouped by token type (like 'node' and 'user' and 'site'). Auto-complete in the text fields themselves. A popup. Something made of magic.
Any thoughts? Anyone? Beuller?
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| tokens.png | 24.99 KB | Ignored: Check issue status. | None | None |
Comments
#1
Whoops. Should have titled this properly.
Also, the existing issue for adding tokens to core lives at #113614: Add centralized token/placeholder substitution to core
#2
Placeholder for an actual comment. Or Subscribing
#3
Popup modal dialog FTW.
#4
After chatting with Bojhan, here's one proposal for how tokens could be presented in the UI...
#5
So a update, I think one problem I did find is that - with descriptions (which is fine), is this interaction is unprecedented - so one behavior we should try to mimic is that of collapsing. I see a certain problem, with beign able to drill down but not beign able to move up quickly, so I think exposing the other tokens might be valuable - but this is by no means a set opinion.
#6
So it's basically a generic combined tree/table control? How many levels we need? Can we do it based on existing fieldsets http://groups.drupal.org/node/19500#comment-76033 or should we create a new UI element?
#7
kika, the tricky parts are:
Together, those pieces make it a bit of a doosie. The following rough mockup also reflects some of the stuff Bojhan and I were discussing...
#8
- Correct, this is hybrid "tree/expandable table" control then. It would be nice to have it as genric UI element.
- what are the proposed actions user can to with this widget? Perhaps I am mis-reading the mocks but the tokens 1.0-style guidance "here are the codes you can insert into a text field: [author-name], [node-title] ..." are lost in the new UI. How the user should know he needs to mash together active tree elements [node:author:last-login:short] in order to get the preferred token code? Or is there a planned JS trick to automatically paste the complete token code to the textfield from the active row?
#9
That's what I was thinking.
If we want to take a brutal shortcut route, we can just ignore any token 'chaining' entirely and only show top-level tokens, using a display style that mirrors token 1.x. ultimately, something like this is necessary to support the chaining...
#10
subscribing
#11
Introducing a new tag for feature freeze: API clean-up.
#12
Yeah the mockup in #7 is heading down the right path. If we take a shortcut and don't provide a way to see chaining it will drastically decrease the number of users who will realize this new ability exists.
#13
Wondering if there is any movement on this? / subscribing.
#14
Task #1: #675492: Allow exchangable ACDBs for autocomplete. Please review!
#15
Why not do it like Facebook's @mention UI? No list below the text field at all -- just start typing and it autosuggests.
#16
subscribe
#17
Moving on up.
#18
#19
@#8 "Or is there a planned JS trick to automatically paste [...] to the textfield [...]?"
@#9 "That's what I was thinking."
two points:
1- downgrade gracefully when JS is disabled (therefore design without entirely relying on JS: autocompletion, onclick events, etc)
2- if a page with 10-15 textfields/textareas provided by the same module wishes to show up only ONE table of tokens (since it might be huge):
2a-- to which textfield/textarea will be the token pasted?
2b-- forced to use one huge table for each tiny textfield?!
another important point:
3- Note that collapsible fieldsets lost their collapsibility within vertical tabs (and BTW lost their titles as well)
I truly believe that the better approach should be find out a logical (human readable) way to display that bunch of data
I also believe that it can be implemented in contrib (kind of
token_uiortoken_helpermodule) AND IF it is ready before D7 release it might even get into core (a couple of theme functions won't hurt anyone IMO, otherwise long live in contrib apply for D8)#20
Currently I have no solution for this
but this was my first shot
the algorithm to build this table was:
1- in this case the consumer module only matters about [comment:*] and [site:*] tokens (the old D6 scopes for 'comment' and 'global')
2- fetch all the tokens
3- pick selected types and bundle them in an array ready for theme('table', ...)
4- for each one see what chains they have and take note of the type and the key of the chain (i.e. for [comment:parent:*] take note that the chain is 'parent' but its type is 'comment')
5- pick those chains and bundle them in another array ready for theme('table', ...)
6- for the current chains at hand repeat 4-5-6 until all chain's keys have been marked as considered
7- output the table of 'Tokens' with token like this [comment:cid], [comment:parent:*] to remark what is a chain an what's not (also prepend to chain descriptions the bold word 'chains')
8- output the table of 'Chains' with chain fragments like this *:parent:cid, *:node:created:*
the result is that chains that appeared first are nearest the top while, lets say for instance, date chains appear bellow node chains (depending on the case they might be even, but it is just an example)
#21
I think the planned jQuery UI 'Tree' element would be good for us here. :)
#22
#735354: User token types should *not* be nested is a big blocker for any kind of token UI or browser so it could use a quick review.
#23
temporary you may use the type name as the group name, e.g "Comment tokens", "User tokens", and would have "Current-user tokens"
that's how I didn't hit that one
<?phpforeach ($token_list as $type => $tokens) {
$rows[] = array(array('data' => drupal_ucfirst($type) .' '. t('tokens'), 'class' => 'region', 'colspan' => 3));
?>
so, it is not so blocker that issue, you may work and enhance the section header later on
#24
Here's a *working* token UI I'm developing for Token D7. Work in progress of course, but feedback is welcome. :)
#25
Here's a *working* token UI I'm developing for Token D7. Work in progress of course, but feedback is welcome. :)
EDIT: Thanks Guru Mediation. :P
#26
Live demo up at http://www.davereid.net/d7/examples/token, will post a token issue patch shortly. It's currently blocked since there isn't any good jQuery tree/table plugin that is also licensed with GPLv2. I contacted the author of the one I liked best to see if he would dual-license MIT/GPLv2.
#27
Really like this, it'd look great with a slide effect similar to the default way we display fieldsets.
#28
I really like how TreeTable looks and functions. As an added bonus, it's actually not that bad when JavaScript isn't available too. Can't click on the text to copy in the token, obviously.
I looked for a similar solution that uses jQuery UI and found jQuery UI Tree, which unfortunately doesn't look as nice. But, it would be nice to have something that is future proof through the upgrade to jQuery 1.4 and jQuery UI 1.8.
..... What does SimpleTest use? We have something similar to this effect there, don't we?
#29
Dave Reid is my hero.
I think there's a lot of polishing that can be done with the UX here, but this kind of browser interface is a huge boost.
#30
Ehh, how is it diffrent from what I purposed in #5? Eitherway, this is not Drupal 7 stuff obviously.
#31
Bojhan: The difference is that Dave made an implementation of it.
#32
Got a response from Ludo, the author of the treeTable jQuery plugin and he's open to dual licensing his plugin with MIT/GPLv2.
#33
By the way, you're free to relicense MIT to GPLv2 yourself, MIT is fully compatible with the GPL and specifically allows you to sublicense work covered by MIT (IANAL).
Great work! The tree table looks very smooth in the demo and perfectly suited.
#34
Didn't know that, but I'd also feel much better just having the authors permission and approval, plus its fun to let someone know that you really like and appreciate their work. :)
#35
@Rob Loach : Well if I could, I would :). Eitherway good work, I do think putting the arrows inside the table will make more sense.
#36
I've made an official patch against the Token module for D7 and it wouldn't be too hard to do the same against core, although I want to know for sure before I put effort into that.
Follow #738372: Token UI browser + jQuery treeTable for all the patchy token UI goodness.
#37
This is no longer a microproject or related to D7UX anymore.
#38
I am interested in taking this on. Would this mean moving Token module into core?
Or would this just be added into token.inc?
#39
tagging, I know this one will be involved.
#40
I thought core already had a browser built-in?
#41
RE #40 - Where? There are only a few token functions in token.inc to do replacement, and no UI is provided. That's why there is still the contrib Token module.
#42
I have just added an issue summary, since there wasn't one and I believe the current idea would be to adopt the Token contrib module's token browser (which was discussed above and then adopted into the contrib module as noted in #36 above). So, anyone want to make a patch that takes the contrib Token module's UI for tokens and puts it into core?
#43
Another proposal
Explanation:
#44
@Gaelan: Do we have time to build something like that? How about we start with patching it with Dave Reid's popup token browser from the Token module?
#45
@DaimenMckenna: I guess we might not. D9 maybe?
#46
It's too bad if D8 doesn't have a token browser because we don't have time to work on your proposal when there is an already working implementation somewhere else (that has it's own set of issues but working nevertheless).
I don't have time to work on it but would be happy to review a patch for this.
#47
I am working on this.
#48
Here is a preliminary, completely untested patch. What I did is to take the bits of the Token contrib module that are related to the token browser UI, and ported them (hopefully) (somewhat) to Drupal 8.
A couple of notes:
- The theme functions need to be converted to Twig presumably.
- There was some caching stuff that I ripped out because caching is different in D8. There are @todo notes in there to indicate where this needs to be put back in.
- I am not sure how to test it. The existing Token contrib module does a bunch of form alters to use tokens... where do we currently want to use it in core?
- There are two PNG files in the patch. I'm not sure that will work, so I also attached them separately.
This is probably about as far as I can take it at the moment... setting to "needs review" so at least the patch will not drop totally into obscurity. If someone has an idea for where this should be used in Core, I could add it there and see if it actually works, and perhaps even add a test... at least for the non-dialog method of displaying tokens. I don't think we can easily test a pop-up dialog using our testing framework.
#49
Dave Reid in IRC suggested adding this to the user email settings form in Core. So I did and it works pretty well! Here's a new patch (was missing a function from the Token project and now it has this added to user.admin.inc).
Things to fix:
- Needs caching as noted in @todo comments.
- Do we need token validation or is that a different issue?
- No tests.
- I noticed that the first time I clicked a token to insert it into a field, it went where I expected (where my cursor was). But then if I clicked another token, it went to the end of the textfield, not where my cursor had been. I don't know how to fix this. daveried wasn't aware of this being an issue in the d7 Token project but it's exactly the same JS code so I expect it is.
- I wasn't sure whether this should really be a separate module or part of system.module... if separate (as in this patch), maybe it should be enabled by default in standard.profile?
Anyway, this is probably ready for a review. nod_ might work on the JS bug?
#50
Couple of questions
The real question around the JS is do we want the tableTree plugin in core? It has perf issues for big tables (on desktop!) so we can't use it as-is, it'll be terrible on mobile.
I'd argue that we'd want a proper list instead of a table, that would make the JS pretty trivial and that'd scale much better. Also this stuff needs to be able to work on mobile, the current table will likely be problematic.
All in all, it's possible to get the JS in shape and in time, need some UX love and fixing the perf issue somehow.
#51
RE #50 -
- We could call the module Token UI, but we have other modules that provide UIs that are not called "something UI", and we currently don't have a Token module, so I decided to go for the "one word if possible" philosophy of core module naming. But I don't care. The other question is, should it just be part of system.module or separate? I don't have a strong opinion.
- I personally think the "insert into field" functionality is a useful UI (minus the current bug that it loses your cursor position)... I have no idea about accessibility though, that's a good point. But having to copy/paste the tokens (or try to type them from a list) does not seem like a friendly UI to me.
- Without the expanding/contract/tree functionality, the full list of available tokens would be LARGE and take up a huge amount of screen real estate. So I think we do need the expand/contract capability.... Is there another UI widget we can use that will accomplish that? I don't know that the table functionality is necessary, so a different tree widget that uses text items instead of a table would likely be workable.
#52
The current name supposes you need to enable the token module to enable the token functionality. I don't care either way, just pointing out a possible misunderstanding.
Yep, copy paste kinda sucks for that, agreed. I don't see an issue adding the clicky thing after that got in initially and we figured out the a11y implications and probably other things we haven't thought about yet.
Oh yeah totally I do want collapsible things. It is a must have here. I'm questionning the library and markup we're using since right now it's too slow. didn't feel like a strong use case for a table either, which is why a simple nested list might be workable. Pinged Bojhan about it, hopefully he'll agree :)
#53
I do not see 3 days sufficient to fix or even attempt to fix the UX, this has gotten designs before those are implemented in the current token UI - and I consider that good enough to iterate upon (adding search, improving the "token" in a field alá facebook, fixing the descriptions). I am more concerned that we might end up exposing this everywhere, something I'd love to avoid.
I do not care if the markup is a nested tree, the only semantic reason I could see for a table is that we have data associated to rows.
#54
Another thing to consider with this patch: I took all of the UI components from the contrib Token module... I am not sure we actually need the hook_menu piece, which provides a pop-up window (I think we just want the expandable list/table piece, at least for now?) and the autocomplete (not sure exactly what that is being used for in contrib Token, if anything?)... so those (and accompanying functions) can probably come out of the patch, which will further simplify it.
#55
Bojhan/#53 - what do you want to avoid exposing everywhere? The tree table or the token browser?
#56
FYI the popup dialog is a replacement for the normal token browser that can *greatly* improve performance in many cases as the large tree is neither a) compiled, b) displayed.
#57
@jhodgdon what is the difference between the two, I guess I am just afraid to find a fieldset below every field :) that could potentially have tokens. However I am sure that worry can be mitigated by a nice toggle or something.
#58
@bojhan: Install the latest version of Token and Metatag on a D7 site to see the popup interface in action.
#59
Turns out we got time now. Better do it right from the start.
The more I see it, the more we need to have tokens in a modal all the time. A link below whatever textarea, input field. Like it's done for metatags in D7. But not the "end of page table" there is on the user page after this patch.
It'd solves the context issue of the "insert into textarea" thing and it'd makes the performance issue less bad.
@Bojhan now that we don't have to rush it as much, can we try out a few things (on g.d.o or something, not this issue) ?
#60
Yeah, this needs some design explorations first. Anyone up to laying out the problem space in a wiki post on gdo/usability? There's enough source materials in the first part of this thread to make a nice briefing of sorts: the problem, the challenges, the constraints and a couple of use cases should trigger some interesting sketches.
#61
Well, for as much as this can be split up in a plumbing part and a UI part it would be good to push forward getting the plumbing in place. We should not 'reset' the effort already put in here. As with the modal/dialog patch, it got committed without a first implementation. Maybe the same can be done here?
#62
@yoroy: We have time to at least decide the best approach to including this:
I'll be happy to help on the patch, but I'd like consensus on #1 and feedback on #2 before poking it with TextMate.
#63
Good, thank you. Both of those are code/architecture and should be hashed out in here then. Please continue :-)
#64
RE #62 item #1:
I think this should be its own module. In many/most cases, using tokens is a site set-up task, and like the Views UI, turning off the token browser module should be an option for an optimized production site (once you've set up the token-related stuff, you should be able to turn off the browser). Also, some people may simply not need the browser. However, I think we should turn on the module in the Standard install profile.
RE: Design...
- Are modal pop-ups accessible? If so (or if we can make them accessible), I think having a modal pop-up is a fine idea, and it would be easy to change the User Email setup to use them (provide a link). The code is already there... I agree that having a large area on every token-using form for the browser is ... clumsy at best. :) If people are interested in seeing the modal, I can make a new patch that uses the modal for the user email fields, and we can try it out. I can also provide screen shots. Let me know if this would be useful.
- I'm also wondering about the modal dialog... if I open the modal, insert a token or two, and then close it, and then I need some more tokens for another text field, could it remember the status (which items were open/closed)? That would be killer!
- Regarding what format is used for the actual browser section (whether modal or on the main page)... The tree table is nice, because it has columns (token/description), but if we had a flat list, I think that would also be fine (after all there are really only two columns that are relevant). So if a flat list tree browser is more efficient and we already have a JQuery library that does it (which??), re-jiggering for that would be fine. If someone points me towards which library, I'd be happy to work up that patch too and we can compare.
#65
Design:
1. Modal accessible, yes, in time. It will be made thanks to jquery ui work (they changed their roadmap to fix accessibility things for us).
2. Technically pretty easy. It's a UX thing though and the interaction need to be thought through.
3. I don't know of a library, Collapsible nested lists are pretty trivial to implement, maybe based on the collapsible.js thing since the accessibility has already been figured out for it.
As for the columns if the visual thing is an issue, we can make a lists look like a table, that was already done on the responsive table issue as a proof of concept.
#66
@nod_: could you better explain what you mean for "we can make a list look like a table"?
#67
By using the CSS
display:tableand associated display values (liketable-cell,table-row, etc.). As far as I know it's only a visual thing, I'm actually not sure how screen readers handle that.Unrelated: @falcon03 I'm really happy you're around making sure our stuff is accessible. It's awesome work, thanks! if something needs fixing feel free to ping me, I'll be happy to help out.
#68
nod_, Bojhan, jenlampton, and I have discussed the UI for this a bit in IRC and an etherpad. I'll add this to the issue summary too, but here are some notes:
Design considerations
- Flat list if there are only a few
- Tree list and/or hierarchical autocomplete and/or search if the list is longer
- Not loading the entire list initially if it's really long (page load time)
Other notes
- TableTree/current implementation is apparently not accessible -- see #922022: The token tree UI is not accessible to keyboard only users on the Token project 7.x
- Token project was exploring other UI possibilities but apparently didn't get too far -- see #1229568: Token UI 2.0
Plan
- Spin off auto-complete and search capaiblity to a separate issue.
- Spin off adaptable modes depending on size of token list to a separate issue
- Token naming should also be separate
- Make this issue only about building a tree-based browser for long lists of tokens
- Use an expandable list instead of the tableTree of the current patch. Core doesn't apparently have a current UI widget we can use for that. nod_ may write one or we could use an existing JQuery component?
#69
I did a search for jQuery tree libraries. It seems that the main actively-developed and available one for now is:
http://www.jstree.com/
(MIT/GPL licensed; accessibility unknown).
The jQuery UI people are also working on a tree plugin but they don't have it done yet apparently:
http://wiki.jqueryui.com/w/page/12138128/Tree
And I also found this one, which is basically an Aria-compatible enhancement of a UL list (sounds promising, and MIT licensed so that is OK):
download: https://github.com/filamentgroup/jQuery-Tree-Control/blob/master/js/jQue...
demo: http://filamentgroup.com/examples/jquery-tree-control/
info: http://filamentgroup.com/lab/jquery_aria_tree_control_from_book_designin...
nod_ also volunteered to write one but if we can use one someone else developed, that would probably be better?
#70
@jhodgdon: Good research! One thing to point out, though, shouldn't it be an expandable tree-table hybrid because it needs to show columns of data too (description, etc)? There's already work going on in a somewhat-related VDC issue: #1834576: Improve details on the Views listing page.
#71
RE #70 @DamienMcKenna - thanks for the link to that other issue. The TreeTable plugin that Token contrib is currently using is not workable (inefficient and not accessible) so we are looking into other possibilities, and right now probably it will be a list. Not sure.
#72
By the way I am working on the next iteration...
#73
#74
Here's a proof of concept patch, minus JavaScript... I need some help with that, not familiar with how Drupal does attach stuff?!? Anyway this patch will put up a nested UL list of tokens that you can browse. The links are not working either. I have to run out for a while but I thought I'd put it up in case someone can help with the JS.
#75
@jhodgdon: A list could work if there were appropriate tooltips to provide the detail listed in the current multi-column display. That said, we could conceivably handle it in two steps: 1. get a basic tree list in place, 2. improve the UI to show the other details.
#76
The last submitted patch, token-browser-proof-concept.patch, failed testing.
#77
RE #75 - missing information: The previous patch is only missing the token's name. I've added that now... could be formatted better but at least it's all there.
The other thing that was not working in the patch on #74 was the JS, which I have working now.
Here's another patch (proof of concept only!)... it does work this time!
#78
One note on the patch in #77 - the Tree JS thing is not very smart -- it couldn't handle having a DIV inside each level of the item lists. So I (temporarily) made a copy of theme_item_list that omits the divs except on the outer list (so the inner lists are just nested UL LI UL LI UL LI etc., not UL LI DIV UL LI DIV UL etc.).
That should be fixed in the JS, which shouldn't be very hard actually.
#79
I forgot, here's a screen shot of the pop-up dialog for the token browser.
#80
@jhodgdon: Nice work :) I'll give it a review later.
#81
I took a look at it (via the Menu -> Configuration -> Account Settings -> email message fields) and thought it was really quite nice.
My only concern right now is that with the default theme it takes up a lot of screen space so you don't have a lot of space left on the window to see around it. That said, I think it's definitely a step in the right direction.
#82
@jhodgdon: do you think the patch is ready for an accessibility review?
@nod_: oh, I didn't know this css capability! I'll look for a demonstration of this feature in action and I'll test it with my screen readers, although I don't think it is "parsed" as a table for accessibility...
Unrelated: thank you very much! Developers' availability is very important for me, since actually I don't have the needed skills to roll my own patches (especially for JavaScript, which I don't know at all ;))! Again, thank you very much!
#83
RE #82 - well, the patch is more of a "proof of concept" rather than a full patch, but ... yes probably an accessibility review would be useful since we attempted to use a tree plugin that said it was full ARIA/accessible. I am unsure about the dialog pop-up too -- if that is not accessible, we should start thinking about how to make it so and/or an alternative.
Note that the current patch lacks the capability of inserting the token into the field. It just lists the available tokens in a pop-up expandable dialog.
And it has only been added to the email section (vertical tabs) of admin/config/people. To test:
- Install the patch.
- Enable the new Token core module
- Navigate to admin/config/people
- Click the link where it says "Browse tokens that can be used in e-mail messages".
#84
I wonder if we could use a series of nested HTML5 Detail and Summary elements like we did to replace fieldsets.
#1168246: Freedom For Fieldsets! Long Live The DETAILS.
An example of nested elements: http://jsbin.com/egefop/14#html,live
#85
Hm. What is that "example of nested elements" link supposed to do? In my browser (Firefox 13 on Linux), it's just a paragraph followed by a single bullet list. Clicking the links does nothing.
#86
RE #84 - I made a patch for collapsible fieldsets, but my usual browser (Firefox 13 on Ubuntu, which is a bit out of date) doesn't support them, sigh. Guess it's time to update Ubuntu, which I've been putting off. [Aren't the new display elements supposed to give you something usable in all browsers though if yours doesn't support HTML5??!? Maybe that hasn't been done yet...]
Anyway, I also have Chrome available, which does support them, and they do seem to be a good choice for this. The patch is somewhat nicer (lots smaller!) and the UI seems OK to me. Here's a screen shot and a patch in case anyone else wants to offer an opinion. The token list is a bit bulkier than with the UL lists, but to me the distinction between the expandable items and token items is clearer. And there's no additional JS to load, since these display elements are in core.
#87
So... I would be inclined to go for #86. Any other opinions? The patch needs a bit of polish but it's not horrible as it is.
#88
I am a little bit confused, why we are changing UI's. I thought the idea was only to change the underlaying code.
#89
nod_ says that the tree table UI is not workable due to performance reasons, so we are exploring other options.
Also regarding the UI problem I'm having, I filed #1858600: "Filter log messages" details on Recent log messages page applies bogus floats if anyone is interested.
#90
The last submitted patch, token-browser-proof-concept-v3.patch, failed testing.
#91
The test failure is from #937284: DEADLOCK errors on MergeQuery INSERT due to InnoDB gap locking when condition in SELECT ... FOR UPDATE results in 0 rows.
#92
Things that will need to be fixed in this patch:
- Doing drupal_render() in the theme function is not going to work because it doesn't trigger the proper JS and CSS being added to the page.
- The theme functions need to be Twig templates.
- See #1858600-5: "Filter log messages" details on Recent log messages page applies bogus floats - the JS needed in some browsers for the details elements is being properly triggered in the dialog (whether it's a pop-up or in its own page).
- There are some additional @todo notes in the code about caching.
#93
Great progress here!
#94
Tagging it per Roy Scholten's request.
#95
Realistically I am not going to have time to work on this again until January at the earliest, sorry! Is there someone else who can pick it up from here and take it to completion please?
#96
#97
#86: token-browser-proof-concept-v3.patch queued for re-testing.
#98
The last submitted patch, token-browser-proof-concept-v3.patch, failed testing.
#99
Is someone going to take this over? Is it too late to get this into core anyway?
#100
Doing a little bit more research on 'drill-down' UIs and came across jQuery Mobile which supports the iOS 'Listview' display, which I think actually may fit very well for our purpose. A sample can be viewed at http://jsfiddle.net/YmcM4/3/embedded/result/ (you have to click the 'Run' button on the top left-ish to see it).
It's kind of nice since we get filtering ability, a very structured way of drilling into more specific tokens (and seeing if the current token offers sub-tokens). It could play well with AJAX since clicking on a list item could load the new "page" via AJAX and shove the generated output into the same request. It works well in a modal. I dunno. I might play with this a little bit more.
The potential problems I see with this so far is that it requires the entire jQuery Mobile library, and for desktop browsers, the UI doesn't really work in a non-modal context.
Available types (first page):
Current date tokens (incomplete):
Node tokens (incomplete):
#101
Looks awesome! If jq mobile the only thing that stops - we need it in core
#102
We don't have a good solution, so we've missed our window for D8 at this point. Let's continue to let contrib find the right UI and get it ready to merge into Drupal 9.
#103
@davereid: Maybe I'm the only one, but that UI doesn't look good to me :p
Also, #sadpanda :(
#104
I definitely need to reiterate that the UI in #100 makes sense only used in a modal, so imagine it in a modal only. :) And it also could play well with a theoretical autocomplete functionality that can be used in text fields since the same AJAX that is used to build the 'sub pages' dynamically could also be used to respond with JSON for sub-tokens.
#105
Given so much has changed in core's JS, are there any similar nested-tree UI widgets elsewhere in core? Maybe we should start there - find a UI widget that fits this use case and others, get it added to core and then add this use case on top of it?
#106
There are non in core that I know of. We would still need to find an external library and add it to core.
#107
I can discuss it with some of the Spark crew this weekend at the SprintWeekend in Boston, see if they have any ideas.
#108
FWIW: I've used http://www.jstree.com/ before and it was pretty decent.
#109
RE #108 - does JSTree satisfy the design criteria in the issue summary?
#110
The website has an unfinished jsTree v1.0 but on github there's a v2 in progress with lots of commits recently.