if-then-else patterns

This is an interesting idea for a feature. Thanks for submitting it.

It is not possible now. It also would be pretty complex from a UI perspective because you would define multiple weighted options for the alias and pathauto would try one, then the next, then the next, etc. So, I'm updating this to 6.x-1.x-dev (it would really be 6.x-2.x but we don't have a dropdown for that now).

Also, this isn't a priority for me, but if someone else wants to work on it they should be very careful about how this impacts the UI for the most common case (i.e. for the user who just wants one pattern per node type).

I agree, this would be an awesome thing to have. I was thinking that perhaps implement something like MusicBrainz' Picard's scripting language for titles (which in turn is based on foobar2000's Title Formatting). We already have the text and the variables (tokens), so we'd "just" need to find a way to implement some functions.

Also, if we noted this in the documentation, we wouldn't have to change the UI. Users could just enter paths as they used to, but power users would be able to enter advanced, conditional patterns.

Also, changing the title back, as this is more in line with what I wrote above, as well as what the original poster meant, if I read correctly. Feel free to change the title back, Greg, if you think this is some devilish trickery that we should stay the h* clear of. :)

Not to mention that that particular syntax is confusing, as variables (tokens) and functions (... also tokens?) are indistinguishable from each other.

Also, I'm not sure how Pathauto translates the patterns to strings, but... if this is done by Token, then this should really be a feature request there, no? If not, then just forget about this comment. =)

Well, I don't plan to work on this so it's up to the implementer to determine how it's done, but...IMO building our own programming language is almost always a bad idea. I'd either prefer to do this in PHP some way OR use weighted patterns.

But, like I said, I'm not working on it and therefore my opinion only matters as co-maintainer and a potential committer...

This is something I've also thought about a while ago, and which not only Pathauto would profit from: think about formatting messages (e-mails) where the passed context object has or has not set first and last name, for example. "Hello [firstname] [lastname], ..." will look ugly if any of the two values isn't set. Thus, I'd say move it to the Token queue.

Token has to support this idea, but the patterns and the logic of which patterns to use at which point are determined by the calling module and not Token module. AFAIK, Token module has all the functions it might need to properly support this kind of behavior. If that's not the case, please open a specific bug in the Token queue for how Token can better support this.

How about allowing (optionally, through a configuration) the ability to use php code and tokens together, like Automatic Nodetitles does? The configuration would transform the textfield to a textarea - something like that?

If you need php code, put it in a module. There's no reason a module can't do that.

PHP in the interface is something I strongly opposed. I made the tokenSTARTERKIT so that people can easily learn to build tokens to provide if-then-else patterns (and more!) in their custom tokens.

@greggles: cool - looking @ #437842: create a token starterkit module and documentation so people know how to use it now - will check that out...

Before I saw your reply, I tried out Custom tokens which solved my immediate need... But I'd prefer to get a better handle on making tokens for our modules - just haven't done that yet. Thanks :)

Should I mark this 'by design'? Or do you want to keep the original issue active as a backburner idea?

I think so, yes.

I needed something similar to the OP and here is what I did:

File: pathauto.module
Changes/additions around line 419 ...

change:

pathauto_create_alias('node', $op, $uri['path'], array('node' => $node), $node->type, $language);

to:

$newPath = pathauto_create_alias('node', $op, $uri['path'], array('node' => $node), $node->type, $language);	
if(!(is_array($newPath))){
  $newPath = pathauto_create_alias('node', $op, $uri['path'], array('node' => $node), NULL, $language);
}	

File: pathauto.inc
Add a case to the switch statement around line 318 to keep from overwriting existing aliases that you actually want to keep...

insert:

case PATHAUTO_UPDATE_ACTION_DELETE:
  return array('0' => 'do not update alias');

The end result is that if a node matches a pattern for its type, it uses that - otherwise, it falls back to the default pattern. For example, I have my "Basic Page" pattern set to create an alias based on the menu settings, but if a page does not have a menu setting, then it falls back to the default pattern for nodes.