Roadmap for Pathauto for D7 and beyond

Dave Reid's picture

I wanted to post my ideas and what I thought would be a good roadmap for Pathauto as we're getting closer to a Drupal 7 release and what could be a big effort to have Pathauto in core for Drupal 8. I'd love to hear your feedback on these ideas!

Nitty gritty

  • First, split our current admin page into two separate pages: Patterns and Settings. This the first step that let's us pave the way for everything else.
    Issue link:
  • Re-use core's concepts of entities that have paths. There's a lot of code that can be reduced and generalized to support D7's entities. We even have things like hook_entity_insert and hook_entity_update that could replace a lot of the node/user code.
  • Stop supporting any of the 'sub-pages' of entites we already help alias. Support pages like user/x/contact and user/x/track aliases when we already provide support for user/x paths makes the module more complex. To simplify things it should only support paths of D7's entities (nodes, user accounts, taxonomy terms, etc.). People can that use modules like Sub-path URL aliases to support the infinite number of sub-paths that users might encounter.
    Issue link:
  • Store our patterns in the database instead of variables. This allows easier retrieval and to find the right pattern/fallback. Plus we could enable fun things like making patterns available for exporting, or for Features. And it also enables us to accomplish the next task:
  • Re-architect our concept of alias 'alterations'. Instead of having so many options for altering aliases (lowercase, separator, strings to remove, punctuation, etc.), what if we re-thought each of these things as an 'alteration', much like ImageAPI in core has 'transformations' that can be applied to an image. And think of each Pathauto pattern as an 'Image style'. For Pathauto, we'd start out with a few different types of 'alterations':
    • Change case
    • Find/replace words/strings
    • Find/replace characters.

    By default we'd have the following alterations enabled as well:

    • Change case (lowercase)
    • Find/replace words (a/an/as/at/etc => '')
    • Find/replace characters (spaces + punctuation => '-')
    • Trim length
    • Trim component length

    Like Image API in core, there are default settings/alterations, and eventually each pattern could override the default alterations to add or remove specific alterations. And users can re-order the weight of alterations as well via drag & drop. Other modules (like Transliteration) could provide their own alias alterations and make them available to Pathauto via a hook.
    Issue link:

  • Along with storing the patterns in the database, it would completely revamp the UI for how we manage URL alias patterns. Instead of overloading the user with a big long page with tons of fieldsets and every possible node type, language, etc combination possible, we go for a "progressive disclosure" approach (see screenshots below). This also means its easier to add a better 'available tokens' interface since we know exactly the entity that the pattern will be used for.
    Issue link:
  • And of course, add tests, tests and more tests.

Screenshots! Everyone loves screenshots!

The following screenshots are basic mockups of where I envision Pathauto's UI heading:


looking good

greggles's picture

The alterations makes a lot of sense to me in general. It also more easily supports the idea of being pluggable and re-orderable which is a major need that people have.

I do like the idea of a default set of alterations that can be overridden on a per-pattern basis, but that should be de-emphasized in the UI as it seems more complex than most sites need.

No, no and no

chx's picture

Have we learned nothing during the last cycle? Do a straight update and branch once you have pathauto D7 out the door ASAP.

I'm very determined that

Dave Reid's picture

I'm very determined that we'll hold our D7CX pledge. We will have a stable version on the day Drupal 7 is released (and we're basically 95% ported as well). If it means we get some of these improvements in the 7.x-1.x and have to push stuff back to 7.x-2.x, that seems fine with me but I'd like to attempt to push as much now as it is going to make the module better for its developers and end-users.

Senior Drupal Developer for Lullabot | | @davereid