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?

The Ideas project is being deprecated. As discussed in a core committer meeting issues that are adding modules are being moved to the Drupal CMS project for discussion.

Pathauto is already in Drupal CMS.

For the record, I was never really in favor of adding this to core, but:

Moving a 17 year old issue with 100+ comments and extensive discussion to Drupal CMS and then closing it like this seems pretty strange. I don't think the recent changes in direction of Drupal core and existence of Drupal CMS means that we will never again add a new module to core. I suppose *If* we add something then building blocks like token/pathauto, or at least parts of it.

There was a recent slack discussion as well, where opinions varied as much as adding this to core to removing tokens completely as it's barely/not maintained there. Core has some limited usage of tokens as well though.

I'm not sure what we *should* do with this issue, I think I'd prefer having it as won't fix in core with a decision that we won't add this rather than the current state.

Apologies, I think I was trying to be a bit too efficient in handling these once they landed in the Drupal CMS queue. It certainly is a separate question as to whether it should be in core and there should be a 'final' answer from core documented in this issue.

For me personally, I don't think there is much of a conflict between pathauto being in contrib and the path/path-alias modules in core, they all build on top of each other relatively cleanly. Would it be good to improve/replace the token system and the token browser UI - either in core or contrib? Yes, but then pathauto could also integrate with the new version of that from contrib too. There are other modules either in core or contrib where being inside/outside of core makes things difficult due to duplication, but there's only one pathauto.

Tagging for product manager review. If there's no particular product manager interest in having pathauto in core, then we can just close this as won't fix I think as a 'final' decision - at least for the next five years or whatever. If there is some interest, we still might think it's not practical for other reasons (like the token UI), but then we should try to document the pros/cons a bit more per the discussion above. But I also think the primary maintainer having very little interest in moving the module to core counts against doing it too.