One of the prime usability problems encountered in previous tests was that when people created a node, they often ignored the menu vertical tab and instead wanted to put the item in the menu on the menu administration UI. However, figuring out the content path on the menu admin UI is impossible, so people need to go back and figure out the path first. This is very painful.
@tkoleary proposes this design to have a "link" field which works (at a minimum) as a node autocomplete and a separate path field that allows people to specify a specific path:
Implementing this specifically would require more intricate autocomplete behaviours, where the autocomplete has effect on a separate field. (Ignore the layout of the form fields for this issue).
The menu/multi path autocomplete (mpac) module implements similar functionality for Drupal 6 and 7: http://drupal.org/project/mpac
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | Nodeautocomplete.png | 30.15 KB | gábor hojtsy |
| #1 | Nodeautocomplete2.png | 42.76 KB | gábor hojtsy |
| #1 | node-autocomplete.patch | 3.51 KB | gábor hojtsy |
| Pathautocomplete.png | 34.24 KB | gábor hojtsy |
Comments
Comment #1
gábor hojtsyThe attached first patch implements functionality more like the mpac module (http://drupal.org/project/mpac) as a start (because that provides us an easy avenue to discuss the feature and can be a base for refinement). So the path field becomes an autocomplete which takes node title fragments as well:
This admittedly get a little confusing when an option is selected, since then it is copied as a path and the node title is not visible anymore. Also, if there are nodes with the same title, they appear the same.
The same feature is added on the path alias and shortcut addition/editing forms.
The patch is based off of user/autocomplete and the mpac module's code. It is more flexible than the user autocomplete (it takes fragments of node title at any position vs. user autocomplete which just takes the start of the string). It is also less powerful than the mpac module (it does not take path aliases or menu items). If we want to combine this with more types of items, we'd need a broker module to handle this, which maybe at this point would be system module and hooks would provide various results (more complex than mpac module).
Feedback welcome!
Comment #2
wim leersNice start :)
Your last paragraph makes a lot of sense; ideally we'd support this for more than just nodes (which would be confusing to users since it's so limited in scope). The first thing that comes to mind is that every Entity that is accessible through an URL should be "autocompleteable". If others think that makes sense, I think the next step could be to let
EntityInterface(orContentEntityInterfacenot only extendComplexDataInterface,AccessibleInterface, andTranslatableInterface, but also a newAutocompleteInterface? Though in that architecture, it might be hard for the path module to also be integrated?Comment #3
wim leersRelated to all entities having URLs: #1803586: Give all entities their own URI.
Comment #4
Bojhan commentedThis is a duplicate, http://drupal.org/node/1123662