By mikeryan on

There are some enhancements I'd like to see in path.module, mostly to support the pathauto module (but some generally useful as well).

1. The newest version of pathauto in HEAD allows users to have aliases automatically replaced when editing content. Since there is no way to tell whether an existing alias was manually entered or generated by pathauto, there's a risk of blowing away manual aliases (which I believe should, ideally, never be touched by pathauto). I would like to add a flag to url_alias to indicate whether a given alias was entered manually (in a node form or the url aliases settings) or generated automatically by pathauto, so pathauto can leave the manual ones alone.

2. The path module allows multiple aliases for one page, but provides no way for the administrator to choose which is the "favored" one (the one returned by drupal_get_path_alias(). The ease with which pathauto can create multiple aliases makes this issue more apparent. I would like to add a flag to url_alias to indicate that a given dst is the "primary" alias for src. The nodeapi hook would display all aliases for a given node (currently only one is shown, regardless of how many there are) with a radio button to choose which one should be primary.

3. Replacing an existing alias breaks old links/bookmarks to the original alias. Adding a new alias to a page with an existing alias may hurt the page's search engine rankings, minimally by dividing incoming links and potentially by giving the appearance of spamming (some unsavory webmasters will give the same content many addresses to try to flood search engine results). I would like to see every alias that isn't the primary alias (see #2 above) respond with a 301 - Moved Permanently status code and redirect to the primary alias. Or, more flexibly, add a response field to url_alias which potentially could support other responses (such as 410 Gone for content that has been deleted).

I can develop the patches to implement the above, but before investing the time I'd like to see if there would be interest in making these changes to core (besides path.module, changes to drupal_get_path_alias() and drupal_get_normal_path() would be required.

Thanks for your consideration.

Comments

owen barton’s picture

owen barton commented

It would be great to be able to use permissions to force users to use the standard pathauto path, without giving them access to manually enter a path through path.module.
- i.e. They see nothing about paths when they post, pathauto just generates them automatically.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented

If you give the "administer url aliases" and "create url aliases" privileges only to administrator-type roles, that's the behavior you get. Pathauto ignores those permissions for just this reason (and that's how I run my site).

Mike
Fenway Views

killes@www.drop.org’s picture

killes@www.drop.org commented

Couldn't you extend the url_:alias table with a 'status' columns and check this before insertign your automatic path aliases? Since core doesn#t know about it, it won't care.
--
Drupal services
My Drupal services

--
Drupal services
My Drupal services

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented

Right, that's my proposal #1. Maybe I'm confused about the definition of "core" - since path.module is part of the Drupal distribution and it's the primary manager of url_alias, I consider it part of "core". It's not really appropriate for a contrib module to add a column to a core table, is it?

Or, if you mean something like adding a "pathauto" table keyed off the url_alias pid column with the additional data I'm looking for - I started trying to implement this approach (including the response column as well), and I could do it if my proposal is turned down, but it really feels like it belongs in path.module itself (for both conceptual and performance reasons).

Thanks,

Mike
Fenway Views

killes@www.drop.org’s picture

killes@www.drop.org commented

1) path.module is certainly in core.

2) Adding a column does not hurt, so why not?

3) As long as we haven't found a cure to the problem of many path aliases I am quite sure, pathauto's functionality won't get into core. I even doubt it will be added later.

4) Having a contrib project has some distinct advantages: You can hack it to your hearts content...

--
Drupal services
My Drupal services

--
Drupal services
My Drupal services

moshe weitzman’s picture

moshe weitzman commented

mike is not suggesting that pathauto be added to core. he is suggesting that some small changes be made which support modules like his.

the 'many aliases' problem will certainly be solved, and i see no reason why these suggestions can't go in as well. pathauto is proving very popular. maybe not all of them ...

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented

Thanks Moshe, that is what I meant here.

I do have in mind the possibility of submitting pathauto's functionality to core at some point in the future (patching it into path.module, rather than submitting it as a separate module). At the moment, however, it's not stable enough, I'm still making significant changes (and will make more if I can get these proposed changes in). And I recognize the Drupal community would need some more substantial experience (i.e., several months) with pathauto before committing to adding it to core.

I'll try and find some time to implement my suggestions and supply a patch - however, I also need to find a little time to get back to my site's content too:-). Actually, it'll be best to wait until the performance patch is finalized and committed to HEAD before messing with any path-related code...

Thanks,

Mike
Fenway Views

Jaza’s picture

Jaza commented

Regarding #2 above, I too would really like to see a new column indicating that a given dst is the "primary" alias. But instead of just a boolean value "primary", I would like to see the following:

  1. a new "weight" column in the url_alias table, so that a group of aliases with the same src can have their order configured. The alias with the lightest weight would be the primary alias. Storing the other weights is not really necessary at this point, but it helps in the listing I describe in my next point, and it makes the path system more extensible for the future.
  2. A new tab in the "url aliases" admin page, that lists the aliases as usual, but that groups them by src (similar to taxonomy terms being grouped by vocabulary on the categories page). Since many users only have one alias per src, I think that the current flat listing should remain (and should remain as the default), but that the new grouped listing should be implemented as an alternative view of a site's aliases. Actually, come to think of it, maybe this 'alternative listing' should be a separate module (e.g. path_listing_grouped.module).

Jeremy Epstein - GreenAsh

Jeremy Epstein - GreenAsh

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented

...but what's the benefit of weighting secondary aliases? Who's going to take the trouble the weight them just to order them in the admin pages? The "more extensible for the future" comment makes me think you have something particular in mind...

Anyway, I had originally planned to store a "1" for primary and "0" otherwise, it'd be just as easy to store a "0" for primary and "1" otherwise in a SMALLINT as a first implementation, and you could add your grouped UI allowing other weights later.

Mike
Fenway Views

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented

I've addressed #1-2 in a patch, #3 will require more thought...

Mike
Fenway Views

johnpg’s picture

johnpg commented

From a new user perspective I'd say pathauto is a must part of core and should be built into path.module. The results one gets out of pathauto are infinitely more user friendly. It's a great idea, and a great implementation.

I've discovered the same issue with automatic created paths interfering with manual ones, or just the case of wanting an occasional entry to be something specific. It seems that pathauto doesn't allow manual entries when it's active, so a flag that would mark an alias as manual would be great.

John

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented

I appreciate the support. And it's a good excuse to point out concrete results from putting those keywords in the URL - if you Google the phrase "Covering the Bases" (Red Sox pitcher Bronson Arroyo's upcoming album), guess whose site comes up 1 or 2 in the results? And I've picked up 12 Amazon orders so far, for a CD that's being released a week from now...

I agree that the functionality belongs in core, but I don't think it's quite ready to be submitted yet. Pathauto is still fluid - people keep coming up with new ideas for it, and I'm continuing to tweak the implementation - it needs to stabilize a bit more.

Also, there are some other things I'd like to see addressed in Drupal's alias handling (see #3 above, I've already submitted a patch to cover #1-2) - at the moment I'm thinking about experimenting with a completely rewritten path module incorporating pathauto's functionality along with those other ideas. Stay tuned (and be patient, not much time the next couple of weeks to put the ideas into action...)

Mike
Fenway Views

budda’s picture

budda
Primary language English
Location Cheshire
commented

I've also run in to the problem detailed in #1

My user writing a 'story' has no admin of paths or pathauto settings so just writes articles. however if they edit some older 'story' pages and submit them path auto is overwriting existing paths already stored for that node with new style ones - breaking links to the old content.

Would it not be possible to just not auto generate a path if an existing path already exists for the node?

I realise this fails if the user updates their category or node title and its not reflected in the path, but, um.... :-)

--
www.gadgetspy.co.uk | www.bargainspy.co.uk

--
Ixis (UK): Drupal support, Drupal hosting.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented

Go to pathauto settings and look under Update action - "Do nothing, leaving old alias intact" is what you want.

Mike
Fenway Views