Pathauto in Core

Reviewed with @Gábor Hojtsy. The status is still the same as after #92; next step is to create a plan on how to make this happen.

Should we start a new META in the core queue (not ideas) to be the implementation plan?

Sounds like ✨ Add a UI for browsing tokens Needs work is the key blocker? That'll be useful without pathauto, too, and will be a huge effort on its own.

Are there any other obvious other steps that will need their own issues, or is it pretty "simple" [sic] after the token browser is in? 😅

Is creating the plan issue and fleshing it out enough to call this "proposed plan" fixed?

Thanks!
-Derek

See #91, that's mostly still true, there is is only one change since then and that is that entity bundle conditions got into core and pathauto was able to remove the dependency on the ctools module.

My opinion of #91 is also unchanged. The token API has been at a standstill for a decade in core at this point. Getting token UI, field/menu/... tokens into core would absolutely be useful and I'm +1 on that. Pathauto I'm unsure. There are fairly large and complex issues in the queue about supporting other routes, sub-paths, pattern fallbacks.. I would assume that getting it into core would require a lot of tedious architecture discussions. Lets talk again when/if most of token.module is in core.

Thanks for the input! Makes sense. I remember reading somewhere that "@Berdir is always right". 😉

In that case, do we need a full meta plan for "Token UI in core" as the next step? Or is that the entire scope of ✨ Add a UI for browsing tokens Needs work already?

There are some long-standing token core issues like ✨ Add support for typed data selection Needs work and #2164635: Automatically expose typed data to token API → which are probably orthogonal to token browser but would help consolidate/modernise the token API in general.

Reading #87 I wonder if we (also?) need a meta plan for moving the non-UI parts of Token Module into core (e.g. the "advanced tokens", etc). Does such a meta already exist? If not, would it be helpful to start one?

Thanks,
-Derek

There's some kinda meta - #1222592: Architecture RFC: Field token architecture →

Also a lot in related ones in #2233353: Convert Token API into plugins →

Might it be worth having a separate issue for #87, as dww suggested, separate to whatever is done in the other two architecture issues?