Project:Drupal core
Version:8.x-dev
Component:base system
Category:feature request
Priority:normal
Assigned:Unassigned
Status:active

Issue Summary

seems to be that this is sensible default behavior for core. is there a core patch yet? if not, please submit.

Comments

#1

If only I knew where to start for that kinda thing. I'll take a peek around - see what I can find.

#2

Personally and as pathauto maintainer I think we'd be best off if urls could have at a max 2 aliases: the internal alias and 1 external alias and then any other aliases are implemented as some form of redirect (301, 302, etc.).

This has several benefits:

1. Performance - drupal wouldn't need to load the behemoth url_alias table because the alias could be stored in the node/ and similar locations
2. No longer any opportunity to have content at multiple nodes which is a problem both for usability (Jakob Nielsen writes about this) and for SEO
3. It makes pathauto simpler to maintain :)

That is something I'd like to work on for 6.x (isn't it nice to know that the next version will be 6.x!)

This node is certainly an improvement towards that direction of limiting the public face of Drupal and helps spread the point that multiple aliases for a node is a "bad thing".

#3

I totally agree with your suggestions greggles (especially getting rid of the huge url_alias table, and probably the 20-50 database calls per page to it :)). There's no use that i can think of for 2 aliases pointing to the same content, and core 301 redirect for node/nid should be default.

Great stuff!

#4

Getting the alias into the node table is a fantastic idea. I dont know why this hasn't been done already.

Just an idea for performance - is it not worth generating the url_alias table as an array (internal URL as the key, external as the value) and then dumping it in the cache table? At least then there is just one hit to pull them all out...

Also - about submitting this module to core, is there not a code freeze?

#5

Yeah, but it should still be submitted. Whether it makes it into 5 or 6 depends, I guess, on if it is seen as a feature or a bug fix.

#6

I see it as a bugfix personally, because from a search engine optimization point of view, it kills sites. Google really doesn't like 2 'pages' (aliases) having the same content on the same site, especially if its for every piece of content.

#7

Status:active» postponed

#8

Status:postponed» active

Too late for D6 now, let's get this at least into D7! Might work on this next week.

#9

Subscribing. The de-slashing feature of GlobalRedirect might also be possible at .htaccess level.

#10

The deslashing is DEFINATELY possible at htaccess level, however the question about de-slashing is surely up to the person running the website? What if yuo WANT slashed on the end of the URL?

#11

Title:patch for core» Global Redirect in core
Project:Global Redirect» Drupal core
Version:7.x-1.x-dev» 7.x-dev
Component:Code» node system

If you want Global Redirect's functionality in core... shouldn't the issue be against core?

#12

Category:task» feature request

#13

Status:active» postponed

Based on the reported bugs that have been reported since release 1.2 I'm setting this to postponed until GR has matured.

GR badly needs some love from i18n, custom_url_rewrite as well as URL alias experts - please step in if you belong to this group.

#14

Surely after a full year there's been some progress on this, no? I've never once done a site without Global Redirect, and I'll be I'm not the only one. It makes all the sense in the world to have its functionality in core—especially for new Drupal users who would be unlikely to identify a module called "Global Redirect" as appropriate to their need to eliminate duplicate aliases and remove trailing slashes! Can we give this another look?

#15

Version:7.x-dev» 8.x-dev
Status:postponed» active

Nope.

And now it's too late. Guess we'll try again in D8.

#16

Component:node system» base system

Also, given that we output canonical path info in meta tags now, is this still an issue after all? Most search engines should respect that.

#17

I think it is worth doing. It is an annoyance for analytics and ad tags and various other things when same content is available on multiple paths.

nobody click here