Using "progressive disclosure" for alias patterns

subscribing

I've postponed #283131: two aliases for one object (node, user, taxonomy...) pending this feature being added.

How do you like this approach? I exploded the configuration page to general configuration and automatic path alias configuration (instead of "Automated alias settings" I have now "Alias configuration" and "Automated aliases" tabs).

Settings under Alias configuration:

* General settings
* Punctuation settings

(as it was on the old page, i just separated it)

Automated aliases tabs has the categories, and a small selector form above that routes gives the form according to which category you want. Its not ajaxified, but could be. Dont forget to clear your cache when enabling the patch for the new menu entries.

I am not really sure against which branch i should write this patch, i did it for 6--1, is that the one you roll from to 6.x-2.x-dev? or HEAD?

6.x-2.xis from HEAD which is ideally what this patch should be against. 6.x-1.x and 6.x-2.x are fairly similar, though, so a reroll shouldn't be hard.

Rerolled. I also removed the nasty drupal_goto, and am changing $form_state['redirect']. Probably some form rebuild could be used, i am not sure.

I don't like the approach in #7. That convention isn't used anywhere else in Drupal, and makes it more difficult to look at settings from different modules. For example, it's common to set up users with users/[name] and a node for them at users/[name]/[title]. This UI would require changing one setting, saving, and viewing the other setting without being able to refer back.

It was suggested on IRC that vertical tabs is a much better UI for this problem, which makes a lot of sense to me. Here is an initial patch which simply vertical-tabbifies (meow?) the settings form. I'd like feedback on the following changes:

1. Splitting out the General and Punctuation settings into their own tab, similar to how #7 does it.
2. Changing the vertical tabs so that in the case of nodes, there is one tab per node type. We should make it easy for modules to expose multiple tabs of settings.
3. The type of text we want to include (if any) in the tab summary. The attached mockups take a "is anything here" approach, though I'm open to other suggestions.

1. seems good.
2. bad (we would repeat the replacement tokens on teach tab? ouch)
3. not sure this is the right approach, so I'm not sure this is worth debating.

The idea behind "progressive disclosure is that we only show the number of settings fields necessary for the site. A very simple site might just have 3 settings boxes because they use 1 pattern for all nodes, 1 for all users, and 1 for all terms. Simplified.

sun complained in irc about forms leading to forms. I don't entirely understand this complaint, but if we want to get rid of that we can change this to be a link to "add new pattern" which then shows a form. The form would be:


Pattern type:
[Dropdown: User, User tracker, Default node, Page node, Book node, Forum node, Default term, etc...]

Pattern:
[textbox]

This needs a revamp for the very-soon D7 branch. My idea (from IRC):
(04:01:58 PM) davereid: Crazy idea, store pathauto path settings in table {pathauto_pattern} instead of variables..
(04:02:32 PM) davereid: Columns object (node/taxonomy), subtype (node-type/vid), language, and pattern
(04:03:28 PM) davereid: To fetch pattern for a french story node, SELECT pattern FROM {pathauto_pattern} WHERE object = 'node' AND subtype IN ('story', '') AND language IN ('fr', '') ORDER BY subtype DESC, language DESC
(04:04:13 PM) davereid: If a specific french story pattern is not found, it would fallback to the generic french node pattern, and then the generic node pattern
(04:04:14 PM) davereid: Hmm
(04:05:22 PM) davereid: Instead of having our crazy wacky variable_get stuff.
(04:06:05 PM) davereid: And we don't have to show all the freaking textfields for every possible pattern

I can mockup an interface for it since it would completely change how we administer the path settings.

Here's a working mockup interface in D7. Oooooh.

Beauty if storing these in the DB is all we need to get the pattern for the current node/user, etc:

function pathauto_pattern_load_by_entity($type, $subtype = '', $language = '') {
  return db_query("SELECT pattern FROM {url_alias_pattern} WHERE object_type = :type AND bundle IN (:subtype, '') AND language IN (:language, '') ORDER BY bundle DESC, language DESC", array(':tpye' => $type, ':subtype' => $subtype, ':language' => $language))->fetchField();
}

$pattern = pathauto_pattern_load_by_entity('node', $node->type, $node->language);

Hmm....in order to generalize this its going to make a lot of sense to add something like 'aliasable' to the entity info for nodes, taxonomy terms, and users. Other things that have entity info but should not be fieldable are comments, files, and taxonomy vocabularies.

In screenshot_030.png URL alias pattern field could be an auto-completion field which suggest available tokens :)

Yeah we don't have any way to autocomplete or browse tokens in D7 yet. It's mostly just a mock-up.

See #514990: Add a UI for browsing tokens

I was thinking about this the other day and wondering about the pattern edit screen.

If we have checkboxes for content types or something that is a real pain. Example:
1. I have a pattern that applies to blogs and stories
2. I have a pattern that applies to events
3. I edit the events pattern to make it also apply to blogs
Expected behavior:

(who knows!)
* It could give me a warning that I already have a pattern for blogs and so...something.
* It could just move the blog setting from the pattern in 1 to the pattern in 2.
* something else?

I was thinking about draggable matchups on the overview page as the main mode of interaction. So that you see a list of patterns and you can drag content types between them. Then we have it degrade in some other way.

Yeah it'd be interesting to play with making it two seperate actions: creating a pattern, and assigning it to types. The main problem I see with that is with the interface in #11 we can show the specific tokens that apply to the specific object/bundle, as well as offer a preview for what a generated URL alias looks like (if user is creating an article alias and their is an existing article node to use for the preview).

Lovely.

Hmm....in order to generalize this its going to make a lot of sense to add something like 'aliasable' to the entity info for nodes, taxonomy terms, and users. Other things that have entity info but should not be fieldable are comments, files, and taxonomy vocabularies.

I disagree. Every entity that has a 'path', resp.

#525622: 'as link' formatters need a generic way to build the url of an 'entity'
#699440: Add bundle support to entity_uri callback to remove performance overhead of forum_url_outbound_alter() (regression from D6)

possibly needs aliases. On top of that, we have stuff like Forum terms. Weird concept.

If we have checkboxes for content types or something that is a real pain.

Agreed. Why not KISS? One pattern == one type (and optionally one sub-type), just as it is now?

By default, non-deleteable default entity patterns. But anything on top should be bound to a specific bundle, if existent.

I disagree. Every entity that has a 'path', resp.

Yeah I think I wrote that before the entity path/uri callback patches landed. :) Thanks for the input!

The special case of forum aliases remains though... but then again, does that really have to be separate?

Trying to recall my first impression, I think I was confused first, because I didn't find the form field for the Forum term pattern. Only by looking around I recognized the separate section.

Food for thought.

Postponed for 7.x-2.x.

Vertical tabs are cool.

For the node types, it would already bring a huge benefit to put the labels left of the field, instead of on top. Ideally converting this to a table layout.

[forget this one]
On a site I am working on, I just noticed at some content types a label text saying
"Default path pattern for Event (applies to all Event node types with blank patterns below):"

I don't know why this is happening, but it does not seem reasonable to me. What is "all Event node types" ?
[/forget this one]

Other ideas that come to mind:

My idea is to have a dropdown of options (and possibly a second one for languages), which you can choose, and it would then be added to a list you could fill out.

http://drupal.org/project/multicrud
for a table where a user can add arbitrary number of rows at the bottom, with no waiting for ajax / ahah.

This would allow us to add a nearly limitless amount of further options to automatically create aliases for, while the admin page would still only be cluttered by the options actually in use.

http://drupal.org/project/crumbs
This module has a system of "hierarchical overrides". I am not 100% happy with the solution, but I think I am trying to solve a very similar problem. So

I think vertical tabs look really cool too!

PS/kinda-off-topic: I just wanted to say that I've noticed that the patterns tab page causes my browser to peak high CPU usage. Anyone else noticing this? Would the v-tabs approach perhaps resolve this??

Testing the new wiki summary feature

Whoa, 6 years passed. Would be nice to have this in 8.x finally. :-)

What i'm missing in screenshot_29 is visual hint that "All" is a fallback of more specific patterns.
* All languages is a fallback of a specific language (per bundle)
* All bundles is a fallback of a specific bundle

In case it's a big list - and it will be in real multilingual bigger sites, we need filters for language and type at least.

Correct, this was only a quick mockup so we can definitely improve it, and I think filters would be great. Probably by type and language would be good starts.