Pathauto in Core

I definitely agree with this. Wordpress has had it included since back when I actually used it. It's also just an extension of the path aliasing features Drupal already provides, so it's not that random of a feature to include.

+1 here

+1

+1... but it would need a significant usability re-jig first.

we can't seem to get token in and pathauto depends on token. this is unlikely unfortunately.

-1

I don't think this needs to be in core at all.

A know a number of people who use Drupal for small sites. They don't use it, they don't need it. It's not hard to download and install if you do need it.

Plus if it's not in core it can be updated on a more regular basis.

Why should core hold the burden of SEO? What if SEO changes in 2 years time and this is no longer relevant (OK, not likely, but I'm sure you see my point)

Getting pathauto into core requires more than just copying it and token module into core. It would require tweaking and refactoring that are a lot of work, and the end result would be more stagnant. (Yes, core is quite stagnant. :-) )

The standard for adding things to core is "can this not be done in contrib in a clean way?" Pathauto is perfectly clean (more or less) in contrib, so there's no need for it in core. The standard for removing things in core is "is anyone actually still using this?" :-)

Core is not, not really is it intended to be at this point, a production ready system out of the box. That is by design.

FYI, webchick recently wrote http://drupal.org/node/278173. Gives a few hints on this kind of recurring questions.

Now that token is in core, I don't see why this should be "won't fix" or "by design". Looking at usage statistics, Pathauto is set to be the #2 most popular contrib module. This tells you something about how core this feature is. However, realistically this looks like something that could only be taken up during the D8 release cycle due to code freeze.

Core is still not expected to a be a complete production ready system out of the box. That's what install profiles are for. Pathauto is quite easy to implement cleanly in contrib, and it should stay there.

Still perfectly fine to leave this open for D8. We might very well have a framework and product then.

@ Dave Reid: agree

Still perfectly fine to leave this open for D8. We might very well have a framework and product then.

+1

Subscribing

FWIW, I think pathauto is framework, not product. Crafting your own URL is as basic as crafting your own title and content.

Are we still interested in doing this for D8? Not much time, but I bet it's doable by feature freeze if somebody wants to pick this up and run with it.

I chatted briefly in IRC with davereid and cweagans today...

If we do want to get Pathauto in core, the next step would be to get the UI from the contrib Tokens module into core, because without that, there will be no friendly/usable way to discover/enter tokens to make up your pathauto patterns. There is also some validation in the Token UI that we would need.

Another prerequisite is Transliteration -- #567832: Transliteration in core -- which has a viable patch, and will hopefully be added to D8 core shortly.

Another is a way to figure out which entity types are actually "public-facing" -- see #1332058: Need a way to distinguish "public/final" URIs for entities from admin and redirected ones

And Pathauto itself would need some rewriting for:
- All entity types
- CMI (configs vs. variables)

Dave says that is most of it... I will add this to the issue summary.

Create an issue summary with task list etc.

Issue summary is updated... Any takers on those tasks?

If we do this, then I'd strongly suggest to take over how Wordpress does it:

In words:

- URL alias base patterns are defined administratively, using a suggested default for user-definable parts.

- Content authors are only able to customize the user-definable parts. (The "Edit" button in the screenshot turns only the highlighted part into a text input field.)

- If at all, only (super-)admins should be able to override the entire URL alias. (but TBH, I'd rather skip this for core)

Also:

- Pathauto's entire URL character replacement customization UI should be left out of core. Ship with sane defaults instead.

Since this is more of a tracking issue...

Also updated the issue summary to include adding some default settings to Standard.profile

add link to token UI issue

YES PLEASE.

RE #21 - that sounds like a pretty good idea actually. In WordPress, in the admin UI for setting up the patterns, they have a concept of "URL slug", which is the part (normally made from the post title) that you can edit on the post editing screen. (At least, it used to be called "url slug" a while back). And I am *not* suggesting we adopt that particular term "slug" necessarily, but the idea would be that in the admin UI you could set up a pattern like, for article pages for instance (this would have actual tokens in it of course):
article/[created date Year]/[URL slug from title]/(some suffix)
and then only the "slug" part would be editable by users, and furthermore the prefix/suffix of that pattern would be shown to them on the screen when editing so that they would know what they were getting.

So... if we were to adopt this idea: For the admin UI in setting up the patterns, I think we would need a special "token" for the "url slug" part, and its name should convey that it's normally derived from munging/url-safe-making/transliterating the entity title but can be overridden by the user. Maybe [overrideable-title]?

Regarding not having a UI for defining your own character overrides... I don't think we can necessarily agree upon what are "sensible" defaults -- that seems like it would lead to endless bikesheds, like "hyphens are better/worse than underscores" -- and maybe in some languages underscores would actually be more sensible, or for some sites they may already have a lot of underscores for some reason and want to stay consistent? I think that UI is necessary. At least, I've nearly always in using Pathauto found I wanted to tweak it somehow when building sites for clients. Personal preferences... :)

Ok, the first step towards that should be this:

1. Converted path into a field/widget.

Works very nicely, enables URL alias support for any fieldable entity. Will obviously trigger test failures, since there is no "default path field" being installed and attached to content entity types yet, and tests are not updated either.

Instead of working on that, the next step should be to get the field's per-instance settings working; i.e., administratively configuring the base alias pattern + separate "slug" default pattern.

It appears this is going to do the work proposed at #1751210: Convert URL alias form element into a field and field widget so I'm closing that issue.

1. Added base pattern and default alias field instance settings + field/widget processing.

Proof:

sun: thanks for the patches! But at BADCamp today a bunch of us are talking about what UI we actually want for Pathauto in Core, the tokens, etc.... so rather than waste effort, maybe hold off for a bit? Also, this is currently a meta-issue, so we should spin off a few sub-issues to divide this effort up (once we figure out what we want to do).

And... I just was talking to moshe and we came up with another ToDo task, which has been added to the summary...

jhodgdon, ry5n, tedbow, tkoleary, Bojhan, and I all thought through adding pathauto to core and made some mockups based on those talks.

I'll let the other people comment on specifics :)

Heh. You seriously should have tested the patch before discussing that. ;) The administrative UI is way simpler than that. :)

1. It's a field.
2. If you do not add the field to your entity, you don't get a URL alias widget.
3. It works for all entity types across the board.
4. There is no massively overwhelming "configure path patterns for all entity types" UI.
5. The field [instance] can be configured to set a "prefix" (the non-customizable part) for an entity.
6. Once tokens are implemented/supported, the field [instance] allows to (optionally) set a default pattern for the customizable part of the alias.

That said, all in all, the results of your discussion are merely more complex than it has to be, so the code changes are completely in line with those considerations in #30, just much simpler. ;)

...speaking of KISS, I've been mainly blocked and busy with battling entity field query, kernel, and dependency injection container problems, in trying to keep on using the new DrupalUnitTestBase for some new Path module field tests, and will resort to a regular web test now to keep this issue moving. ;)

OK, here are the promised "more information" comments... in no particular order:

- In order to get this in before the end of the month, we think we just want to continue to use basically the existing contrib Pathauto functionality. Basically, you can set up patterns for entities (by bundle) -- but we want to have a more sensible default setting of content-type/title for nodes (and just title for Page set up in the default install profile).
- We want you to be able to disable auto paths by bundle, and this setting would be on the bundle config page.
- We want you to be able to set up a default on/off setting and pattern for each entity type, and this setting would be on the Path module config screen in a tab (like Pathauto does now).
- We think this feature should be part of the core Path module, but in a separate include file. It will just be active when you save/update an entity item (and on admin screens), and it will (as it does now) just be adding an alias to the alias table, so this should not add a lot of weight to what gets loaded in core.
- For setting up patterns, we will need a UI for entering tokens. We propose using core autocomplete to get an effect similar to what you see in the Rules UI now (there is no mockup -- it's too dynamic to make a mockup easy). A drag/drop interface could be possible in contrib or in the future, but we think it's too ambitious for right now.
- Since actual entity machine names would be exposed to the admin user in this scheme, we will absolutely need to make these conform to our naming standards for UI elements. Meaning "NO NODE". I think there is an issue about this that we need to reopen, that someone said was recently marked "won't fix"... will need to find that and reopen it.
- We want to change the name of the "URL Aliases" page (admin/config/search/path) to "Pretty URLs".
- By default, you'd get the ability to customize the core entities Node, Taxonomy, and User, and no other core entities. Not sure yet about contrib entities (defer this argument for now).
- If there is an alias, and you visit a page that has that alias via the basic URL (such as node/34 instead of article/my-trip-to-tahiti), it should 301 redirect you automatically to the alias (REALLY bad for SEO if not).
- Current Pathauto has quite a few configuration settings (punctuation, lower-casing, etc.). We haven't yet discussed which of these we need and how to make that screen more usable, but it would be an additional area at the bottom of the proposed "Pretty URL Settings" mock-up shown above.

I will update the issue summary eventually but I wanted to get these notes down so they don't get lost.

sorry, I cross posted. sun: feel free to re-assign to yourself.

1. Added field instance settings handler to automatically strip leading/trailing slashes from prefix.
2. Added NullWidget to work around Field API/UI limitation of requiring a widget for all fields.
3. Removed token blocker/dependency by negating the "automatic" setting/feature.
4. Renamed path field data column from 'alias' to 'value'.
5. Renamed default field widget to 'Permalink'.
6. Added path field CRUD operations tests.
7. Fixed bogus source path value in hook_path_delete().

sun: the functionality and user interface plans above have been vetted by several members of the community at BADCamp. We'd like to go forward with them. Would it be OK if we take over this issue and work on these plans? Or would you like to adopt the proposed user interface here? We spent several hours getting these ideas vetted and reviewed by the usability folks, and we do think this is a good idea... We can provide more specifics if you need them...

--jhodgdon and cweagans

re #35: Can you explain why we should go with that plan, instead of a modern, field-based approach?

Additionally, I'd like to know why we'd want to aim for an end-user interface that is known to overwhelm ordinary content authors and thus inherently leads to problems/errors. End-users do not know of the fully envisioned URL alias pattern for a particular content, so they enter completely arbitrary values as URL alias, which in turn breaks any "clean URL" pattern that URL aliases actually try to accomplish in the first place.

The mockups in #30 do not show any kind of separation between an administratively set up prefix and a user-provided suffix/value for a particular alias. From a UX perspective, that looks just simply wrong to me (since we know better).

The concrete proposal here is:

1. Add the field to any entity:
   

2. Edit the path field settings:
   

3. Later: Enable automatic aliases:
   

4. Add or edit an alias-field-enabled entity:
   

KISS? :)

That said, due to the large amount of blockers and dependencies outlined in the OP, I'm mainly focusing on the "non-automated" aspects right now; i.e.:

1) Turning the user-facing URL alias functionality into a field that can be attached to any entity bundle.

2) Implementing the prefix/custom separation for the field/widget.

These two changes are huge improvements on their own. Apparently, the main changes are working already (the images in #36 show the actual output). If desired, I can move forward with this independently from the "automatic alias" improvements in #1751210: Convert URL alias form element into a field and field widget, since the automated stuff will have to happen "on top" either way.

I think a viable option may be get Drupal 8 to use the field system for path aliases and modify Pathauto to work with it in contrib and target D9 for inclusion. I am worried there is too much to cover and too much work that will possibly be regressed from the contrib module.

sun: your plan goes well beyond the scope of "get pathauto in core" without actually solving "get pathauto in core". What I mean by that is that you seem to want to rearchitect the system currently known as the core Path module, without providing the ability in Drupal 8 for site builders to specify automatic URL aliases (your last comment, at least, says that you won't make the deadline on this part).

But the ability to have automatic alias settings *is* the functionality that people use Pathauto for, and the reason that a large portion of the core dev community thinks having pathauto in core is a good idea. The usability folks helped us design this UI today, and reviewed/tweaked it before we uploaded the screen shots to this issue. And it's narrow enough in scope that we can get the auto-patterns functionality into core before the deadline.

There are some 400,000 users who use pathauto with its current UI. Plus it's on Gardens, with that same UI (that's another 20,000 or so users, probably). This functionality is obviously needed, and even with the current UI people somehow manage to make it work.

So... If you want to rearchitect stuff, please do, but please file a different issue because it doesn't solve the problem posed of this issue.

I just updated the issue summary with a couple of notes on use cases.

re #39:
I think that is a strange and unfair interpretation of what I said. It also does not answer a single of the questions I've raised.

But anyway. I will move my work to #1751210: Convert URL alias form element into a field and field widget and get that done for D8. If there are any usability concerns, ideas, or improvement suggestions for what I'm proposing, please get involved over there. I will copy explanations and screenshots to set up an issue summary shortly. (Until then, #31 and #36 in here present the solution.)

Sorry, the proper status here is active now.

Thanks! That does seem like a more appropriate issue for what you're working on.

Add use cases to summary and tweak task list

I just updated the issue summary to reflect having #1751210: Convert URL alias form element into a field and field widget as a prerequisite.

@cweagans Please don't say vetted, I reviewed and gave some suggestions. We are working towards a good solution, which requires a few iterations over the design which is fine, that is a normal process.

The approach sun outlines is more KISS, its almost worth considering. But from my point of view, the most common usecase will be to configure all the URL patterns at once and then forget about it. All other usecases, like doing bulk updates or doing it per thingie is less prominent.

I just posted a simple UI prototype on #1751210-10: Convert URL alias form element into a field and field widget for the basic path widget, which says that if the URL alias for entities becomes a field called "Pretty URL", then without Pathauto functionality, the basic widget is just a text entry field, and the widget is called "Pretty URL entry" (it just allows you to enter a path alias).

Then if you have Pathauto functionality, you have a second available widget called "Automatic pretty URL". This widget has a setting that lets you set up a pattern, and when editing a node, the widget will show the URL it is going to generate, or if you check the "Override" checkbox, it will let you enter your own URL. I'm not a mockup expert, to say the least, but here are some rough sketches (note: the X in the checkbox is meant to be a checkmark):

update with reference to aliases as a field issue http://drupal.org/node/1751210

add link to field tokens issue

I just updated the issue summary with a new table of what needs to be done when. Any takers? :)

Update the tasks with which need to be done when and which depend on others

add depenency

Issue summary updated with status... Hopefully this qualifies as "in progress" for the "finalize features" phase of development?

I second that initiative, hoping that moving Pathauto into core will provide i18n taxonomy options to the patterns dialog and will build up necessary tokens at the same time.

Is this happening for D8 after all?

For sure, it is not. I am a bit hopeful for Drupal 9 however.

update status

Is it possible to dump what we have into a Pathauto 8.x repository?

Feel free to open a new sandbox and dump any code in there, then link it back to this issue.

RE #53 - as far as I know, the only progress that was made in the form of actual code was on the token-related stuff (token browser #514990: Add a UI for browsing tokens), and also Transliteration got into core, so that will no longer need to be a dependency (I think/hope?).

It does look like the Path as Field issue might get done before D8 release too, since the Multilingual people want it too (#1751210: Convert URL alias form element into a field and field widget). But nothing has been done on the actual Pathauto functionality yet.

...linking #1726734 as a related issue.

Yeah, more than 50% of the Drupal sites out there use it, but still we have to wait till D9 to see it in core :/

...glad we've laid the path for it though (pun intended).

klonos: Please remember that the number of sites using a module has almost never been the leading factor in whether or not something gets into core. "Does it make sense as part of the core framework" is the question, and usage stats are only part of that. (That's why xmlsitemap is not in core, for instance, nor IMO does it have any reason to be.)

1. I never suggested that usage was a/the leading factor (still, you have to admit that if more than half the sites made with Drupal use a certain module, that alone says a lot).

2. I really fail to see how the ~100k reported sites of xmlsitemap compare to the near ~500k reported for Pathauto (that's 1 in every 8 vs. 1 in every 2 Drupal sites). This effectively puts us in a situation where we "force" half of the people using Drupal to go find, download, install, keep up to date a contrib module.

3. Just for the record... Views (that is now officially part of D8 core) has a smaller usage count than Pathauto ;) ...scratch that.

The reason that Pathauto did not get into core in Drupal 8.x is not that someone decided it was a bad idea, but that we, as a community, did not get all the work done that would have been necessary to get it into Core. I do not think anyone objected to the idea that Pathauto *should* be part of core (although it's possible they would have, if the work had gotten closer to completion). But it just simply didn't get done, due to lack of resources/effort/commitment.

I've never been in favor of pathauto in core and still am not. :-) That said, I was only noting that popularity doesn't imply something gets into core (or doesn't). It's a much more involved and multi-faceted question.

Let's get back to that question in Drupal 9.

...up to date usage stats.

Planning to work on pathauto for D8 at DrupalSouth Sprint, sandbox: github.com/larowlan/pathauto

Sounds like you should take a look at
#1980822: Support any entity with path.module
which has replaced
#1751210: Convert URL alias form element into a field and field widget
and comment there if it needs mods so that Pathauto can work better.

thanks

updated issue summary with new issue for the path widget

Planning to work on pathauto for D8 at DrupalSouth Sprint, sandbox: github.com/larowlan/pathauto

Looks like there may be some overlap happening here. @Berdir has been doing a bunch of work on Pathauto in https://github.com/md-systems/pathauto. I think it's quite a bit further along than the previous version, so anyone looking for the latest should probably check over there.

I'm not sure why the port isn't on drupal.org. The issue for D8 Pathauto is at https://www.drupal.org/node/2168193.

Cleaned up introduction in IS.

Missed a closing tag.

Maybe we want to re-evaluate this and push to include pathauto in Drupal 8.3.x core as experimental module.

Anyone have thoughts on the best way forward here? I must say that it is a bit sad to be in 2016 and still not have Pathauto in Core. While I'd love for Pathauto to be dropped into Core quickly and marked as experimental I'd say the real approach here should be integration into Path module itself. Dependencies to getting this in might be worth revisiting.

A fleeting tweet of frustration that Pathauto still isn't in core, followed by being told to do something, brings me here to simply ask - "How is Pathauto not in core? But much larger, and obscure projects are going in?"

I am not a core dev, but I am willing to test, and blow up sites with patches. What now?

I think the idea of Pathauto in core is sound. After "Idea" comes "Plan". So next steps would be to revisit the "Remaining tasks" section in the issue summary. Probably best to create a new plan/meta issue for that (example: #2811175: [plan] Add layouts to Drupal).

This also needs people willing to work on it to make it happen of course.

Code architecture wise: have we explored well enough the spectrum between "bolt it on, as is" and "blending it into path module"?

This idea can probably marked RTBC, then I can fix this one and we can move on to creating a plan.

I'm hugely, hugely +1 for Pathauto in core. It is a decade overdue.

However, I think it should wait on the good work that is currently underway to modernize the underlying path alias system. (I think the plan is to make them into content entities, but I'm not sure.) I'll dig up a few related issues soon. In the meantime, those of us who'd like to see Pathauto in core should probably throw our resources in that direction to accelerate it.

I'm also in favor of merging Pathauto directly into the Path module. I think users would find it annoying to have to install two modules, with confusingly similar names, in order to get the feature they flat-out expect to have in a CMS (i.e., SEO-friendly URLs).

However, I think it should wait on the good work that is currently underway to modernize the underlying path alias system. (I think the plan is to make them into content entities, but I'm not sure.) I'll dig up a few related issues soon. In the meantime, those of us who'd like to see Pathauto in core should probably throw our resources in that direction to accelerate it.

Given that we will leave the existing APIs in place there is at least for me no reason to wait for that particular change.

The two main path alias issues are #2856363: Path alias changes for draft revisions immediately leak into live site and #2336597: Convert path aliases to full featured entities, both have quite big implications for storage), they don't really affect the pathauto UI, token browsing or anything like that though.

Webchick and I used this issue as an example to test our "ideas template", adding this to the top of the issue summary.

A very basic canonical redirect in Drupal core might also be worth considering, with an option of automatically redirecting URLs like node/8765 to the alias of that node, but perhaps that should be in its own issue?

I have yet to build a Drupal site, without the Pathauto and Redirect modules.

#83

I have yet to build a Drupal site, without the Pathauto and Redirect modules.

very true.

i think these two tools are even more important with Workflow (in core) and issues related to issues like #2858434: Menu changes from node form leak into live site when creating draft revision

I think we've estapblished by now that pathauto is *very* welcome in core. Now, it needs a plan and a team to make it happen :)

Canonical redirect is #2641118: Route normalizer: Global Redirect in core but that's not really related to this issue.

I'm maintaing the token and pathauto modules in contrib and they're both stable and I think working pretty well.

However, getting it into core is still a huge amount of work. I'll try to keep this short (I'm very bad at keeping things short), here are some things that can be worked on/need to be figured out:

* Token in core is *very* badly maintained, it is one of the systems that has seen the least amount of improvements over the D8 cycle. As result of that, Discussions and work has started in contrib to implement alternative token systems, rules has it own API, in simplenews we've been discussing using Twig instead and so on. One thing to figure out if we want to consider a completely new API in core that e.g. depends on typed data for traversing data structures and doesn't need the considerable amount of glue code/complexity.

* A lot of the more advanced tokens in the token module could easily be moved to core in separate issues, anyone can start with that any time. We might need to make sure that there are no problems if core starts defining tokens that token.module defines as well.

* We will need a scalable and accessible token UI, work was happening on that in core a few years ago as well, but it will likely need to be redone from scratch because the one in token.module is pretty bad and I don't see how that could pass the accessibility/usability gates in core. And scalable because the current UI eventually kills the server/browser if you have enough fields.

* The current issue summary says that the 80% use cases can be covered with a few very simple cases. I'd be -1 on getting a minimal system into core that does support just that, most sites eventually have some more complicated needs: menu hierarchy based tokens are very common, as well as taxonomy term references including their hierarchy and so on.

* Speaking of menu hierarchy, token currently requires a bunch of crazy tricks to properly handle that, so that's something that could/should be improved in core as well.

* Pathauto currently depends on ctools due to two things, one is a pretty easy to duplicate API function that could also move into core, the other is #1932810: Add entity bundles condition plugin for entities with bundles. Helping with that would also mean that pathauto contrib wouldn't have a ctools dependency anymore.

* The path api/storage changes are of course related, but I think actually not too relevant for the main functionality, which is generating aliases. The only thing we need there is to figure out handling of duplicates and looking up existing aliases/routes.

* Bulk generation and deletion is a more related to that, as it does some illegal queries (joins between entity tables and path table) and needs a bunch of path storage API extensions. Maybe that stuff can be kept out of core, e.g. by moving the functionality that we want to move into the path module or a new module and keeping the additional things in contrib.

That's likely not complete, but there should be enough to find something for everyone who is interested to contribute, architecture discussions, small patches moving specific tokens into core, designing a token UI, defining what exactly should be in core, ...

There was an informal poll over Twitter about features people would like to see in Drupal 9.1 https://twitter.com/webchick/status/1235689652838776832 (there will be a formal poll not over (just) Twitter coming later this month), and this was one of the most highly requested features. Just leaving a note. :)

There has been a lot of work done on path aliases lately in support of Workspaces. I'm curious if that does anything to make this easier.

>There has been a lot of work done on path aliases lately in support of Workspaces. I'm curious if that does anything to make this easier.

No, almost completely unrelated, that was storage refactoring, while that required quite a lot of changes in pathauto, it doesn't simplify anything in regards to this issue.

The primary blocker is still having a token browser (with acceptable UX and accessibility, the current token.module implementation is not going to be acceptable) and moving lots of additional tokens into core, because without that, pathauto is just no fun. There has been absolutely zero progress on token API/UI in core in years. Plus some extra dependencies that currently require us to depend on ctools, like #1932810: Add entity bundles condition plugin for entities with bundles that I've been trying to get into core for forever.

That said, as token and pathauto maintainer I'm not convinced at all that it makes sense to have pathauto in core. Yes, it is a module that almost every site needs, but it's just a UI and some automatisms with very little need for other things to tie into it. There's always going to be that one extra feature that many sites need, but I think core should focus on having critical components, storage, API's and so on that many other things need to integrate with. Should core have better tokens, a token UI, entity bundle conditions, .. yes, absolutely :)

From #86:

I think we've estapblished by now that pathauto is *very* welcome in core. Now, it needs a plan and a team to make it happen :)

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 #514990: Add a UI for browsing tokens 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 #514990: Add a UI for browsing tokens already?

There are some long-standing token core issues like #2002254: Add support for typed data selection 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?