What is the problem to solve?

Pathauto is used on almost 75% of all Drupal sites, and is essential for SEO-and-user-friendly URLs. It would be good to get it into Drupal Core if possible.

Who is this for?

  • Content authors
  • Site builders
  • Site owners

Result: what will be the outcome?

  • Site builders will no longer need to install an extra "top 5" module on the majority of their sites.
  • Drupal will ship with better SEO out of the box, which is important to site owners.
  • Content authors will save time in creating content because paths will be figured out automatically.

How can we know the desired result is achieved?

Pathauto module and Token no longer needs to be maintained in contrib for Drupal 8.

Problem/Motivation

Use cases:

  • URLs like node/8765 are unintuitive and provide no meaningful context. Core's Path module lets you create aliases, while Pathauto automatically creates SEO-friendly aliases based on token patterns.
  • A typical pattern for pages is /[node:title], and for other content types, /[node:type]/[node:title] (e.g. /article/how-to-program; /project/drupal.
  • Blog articles: people often want the year or some other date component in the URL, such as /blog/[date:YYYY]/[node:title].
  • Users and taxonomy terms: /user/[user:name] and [taxonomy:vocabulary]/[taxonomy:term-name].

These use cases cover most sites' needs.

Proposed resolution

Add the ability to have URL alias patterns to Drupal Core.

Remaining tasks

Here is what would need to be done to get Pathauto into core, along with some notes about when each item is needed (before the API/Feature freeze, or can it wait for clean-up phase):

What Status Pre-freeze? Dependencies Details
Transliteration DONE (followups coming) Yes None #567832: Transliteration in core
Token choosing UI preliminary patch, architecture/design in discussion Yes, at least basic UI None UI from the contrib Token module, or maybe a simpler UI that just lists possibilities. Otherwise there is no way to discover tokens in core in order to build up automatic URL patterns.. This probably needs to incorporate some validation steps from the contrib Token module too. Issue: #514990: Add a UI for browsing tokens
Path aliases for entities as a field in progress yes None Path aliases for entities will become a field. This allows PathAuto to be an alternative field widget. Issue: #1751210: Convert URL alias form element into a field and field widget, replaced by #1980822: Support any entity with path.module, which will hopefully accomplish the same thing? Not sure.
PathAuto as a widget not started yes Path aliases as a field, Token UI Design proposal is in #47. No issue yet.
Standard profile updates not started no PathAuto widgets and its dependencies Add PathAuto settings to standard profile to cover the basic use cases.
Entity field tokens discussion started; possibly not essential for PathAuto? Yes None Generic field tokens need to be in core so they can be used in patterns (in 7.x they are in function field_token_info_alter() in token.tokens.inc in the contrib Token project): #1499468: Field tokens in core

User interface changes

New UI for assigning automatic URL aliases to entity paths. New UI for tokens. Field for URL aliases for entities.

API changes

Some new tokens would be introduced (see Remaining tasks). No changes to existing APIs.

#1726734: Replace serial entity IDs with UUIDs in URLs, or even globally?

Members fund testing for the Drupal project. Drupal Association Learn more

Comments

Susurrus’s picture

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

jstoller’s picture

+1

Fintan Darragh’s picture

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

moshe weitzman’s picture

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

sparkguitar05’s picture

I think this feature really needs to get into Drupal core. One of the areas Drupal is lacking in is not being able to make SEO friendly URLs by default like EVERY other CMS out there.

tjharman’s picture

-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)

sparkguitar05’s picture

It's true that not everyone uses pathauto, but there are many many people that do. There are a few modules in core that I've never used and I rarely see used on other Drupal sites such as book and aggregator. And why should core hold the burden of forum? Most small sites don't need that module.

Just my personal opinion. Pathauto is used much more than some other core modules.

Crell’s picture

Status: Active » Closed (won't fix)

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.

sparkguitar05’s picture

Makes sense. Thanks for explaining everything.

yched’s picture

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

rickvug’s picture

Status: Closed (won't fix) » Active

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.

Crell’s picture

Status: Active » Closed (won't fix)

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.

Dave Reid’s picture

Version: 7.x-dev » 8.x-dev
Status: Closed (won't fix) » Active

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

Dave Reid’s picture

Assigned: Unassigned » Dave Reid
Issue tags: +pathauto
sobi3ch’s picture

@ Dave Reid: agree

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

+1

Taxoman’s picture

Subscribing

moshe weitzman’s picture

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

cweagans’s picture

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.

jhodgdon’s picture

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.

jhodgdon’s picture

Issue summary: View changes

Create an issue summary with task list etc.

jhodgdon’s picture

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

sun’s picture

FileSize
38.89 KB

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

pathauto-ux-wordpress.png

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.

cweagans’s picture

Title: Include Pathauto in Core » [META] Pathauto in Core

Since this is more of a tracking issue...

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

cweagans’s picture

Issue summary: View changes

add link to token UI issue

webchick’s picture

Priority: Normal » Major
Issue tags: +Killer End-User Features

YES PLEASE.

jhodgdon’s picture

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... :)

sun’s picture

Assigned: Dave Reid » Unassigned
Status: Active » Needs review
FileSize
15.95 KB

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.

gdd’s picture

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.

sun’s picture

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

Proof:

pathauto-widget-27.png

Status: Needs review » Needs work

The last submitted patch, platform.pathauto.27.patch, failed testing.

Anonymous’s picture

Issue summary: View changes

Adding task for including pathauto settings to standard.profile

jhodgdon’s picture

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...

cweagans’s picture

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

node-add-edit.png

content-type-config.png

pathauto-config.png

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

sun’s picture

Assigned: Unassigned » sun

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. ;)

jhodgdon’s picture

Assigned: sun » Unassigned

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.

jhodgdon’s picture

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

sun’s picture

Assigned: Unassigned » sun
Status: Needs work » Needs review
FileSize
21.92 KB
31.15 KB
  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().
cweagans’s picture

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

sun’s picture

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:
    pathauto-36-manage-fields.png

  2. Edit the path field settings:
    pathauto-36-field-settings.png

  3. Later: Enable automatic aliases:
    pathauto-36-field-settings-auto.png

  4. Add or edit an alias-field-enabled entity:
    pathauto-36-entity-add-edit.png

KISS? :)

sun’s picture

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.

Dave Reid’s picture

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.

jhodgdon’s picture

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.

Status: Needs review » Needs work

The last submitted patch, platform.pathauto.32.patch, failed testing.

Anonymous’s picture

Issue summary: View changes

add another todo

jhodgdon’s picture

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

sun’s picture

Status: Needs work » Needs review

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.)

sun’s picture

Status: Needs review » Active

Sorry, the proper status here is active now.

jhodgdon’s picture

Assigned: sun » Unassigned

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

jhodgdon’s picture

Issue summary: View changes

Add use cases to summary and tweak task list

jhodgdon’s picture

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

Bojhan’s picture

@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.

jhodgdon’s picture

FileSize
31.11 KB

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):
mockup of widget settings and widget on entity edit page

jhodgdon’s picture

Issue summary: View changes

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

jhodgdon’s picture

Issue summary: View changes

add link to field tokens issue

jhodgdon’s picture

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

jhodgdon’s picture

Issue summary: View changes

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

jhodgdon’s picture

Issue summary: View changes

add depenency

jhodgdon’s picture

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

moniuch’s picture

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.

klonos’s picture

Is this happening for D8 after all?

Dave Reid’s picture

Version: 8.x-dev » 9.x-dev

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

Dave Reid’s picture

Issue summary: View changes

update status

MustangGB’s picture

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

Dave Reid’s picture

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

jhodgdon’s picture

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.

jhodgdon’s picture

Issue summary: View changes

...linking #1726734 as a related issue.

klonos’s picture

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).

Crell’s picture

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.)

klonos’s picture

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.

jhodgdon’s picture

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.

Crell’s picture

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.

Crell’s picture

Issue summary: View changes

...up to date usage stats.

larowlan’s picture

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

jhodgdon’s picture

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.

larowlan’s picture

thanks

jhodgdon’s picture

Issue summary: View changes

updated issue summary with new issue for the path widget

catch’s picture

Version: 9.x-dev » 8.1.x-dev
Priority: Major » Normal
quicksketch’s picture

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.

Leeteq’s picture

geerlingguy’s picture

Issue summary: View changes

Cleaned up introduction in IS.

geerlingguy’s picture

Issue summary: View changes

Missed a closing tag.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

oriol_e9g’s picture

Version: 8.2.x-dev » 8.3.x-dev

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

rickvug’s picture

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.

catch’s picture

Title: [META] Pathauto in Core » Pathauto in Core
Project: Drupal core » Drupal core ideas
Version: 8.3.x-dev »
Component: path.module » Idea
HaloFX’s picture

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?

Anonymous’s picture

+1 for this, what's the blockers?

yoroy’s picture

Status: Active » Needs review

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.

phenaproxima’s picture

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).

Anonymous’s picture

Thanks @phenaproxima - the memories are beginning to flood back now as I looked into this a year or so back and the discussions then were how to best approach the UI side of things as quite rightly creating strings of tokens isn't a simple thing to get right - it's essentially a gui for writing code.

From what I've seen of the couple of links I followed from the summary here not much has moved on that front in the last couple of years, perhaps there's more been going on wrt the underlying api improvements but not sure where those discussions are going on so if you do manage to dig anything out that would be great.

With the advent of experimental modules that may be the way to go on the UI front as we'll never fully know what works until it's out there being used - my initial feeling is something which is more context-aware than it is currently would be the easiest/best, i.e. highlighting most used / sensible defaults / etc. but guess that's a discussion for elsewhere. At the moment it seems like the ideal solution is being awaited upon i.e. the one token browser to rule them all, but realistically that may never happen - would be good to start somewhere though as unless I'm missing recent discussions this all seems to have come to a standstill again. Not a problem, more of an opportunity to try another push!

dawehner’s picture

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.

catch’s picture

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.

Anonymous’s picture

@dawehner thanks, that's good news!

@catch - thanks, so last post on #2336597: Convert path aliases to full featured entities was 5 months ago & sounds like there's a fair amount of work to be done there with potential further issues sprouting up, doesn't immediately sound realistic for 8.4 unless there's already plans to put focused resources on it from someone but realistically I've no idea as it's way over my head as to what exactly is involved, it's just a big step up to entities so imagine there's a whole host of other implications too.

Last post on #2856363: Path alias changes for draft revisions immediately leak into live site was yesterday and deemed critical so depending on situation above I guess we're either going to see efforts put towards entities or more likely a short-term fix if feasible due to the critical status.

If there isn't focus on this then I can imagine as there's lots of interest perhaps if we know who would have the ability to work on this perhaps we could propose a promotion of someone who has a certain SEO-related book to do a campaign where some of the revenue goes towards funding this in order to move things forward.

that's my 2p on what I see ;)

yoroy’s picture

Component: Idea » Proposed Plan
Issue summary: View changes

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

ressa’s picture

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.

SKAUGHT’s picture

#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

yoroy’s picture

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 :)

Berdir’s picture

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, ...

nod_’s picture