User profile URLS from /user/<ID> to /u/<name>

Project module for D7 will require pathauto, so we will be able to enable this with configuration. See also #1117436: Deploy pathauto & token for organization nodes?.

I think this needs a scalability review. Adding ~1,000,000 aliases might have an impact.

If #3 is the only reason to do this it is worth considering closely. I assume CiviCRM has access to the Drupal $user object or users database table which does have the drupal.org UID in the users.init field.

Maybe we could limit this to people with the "not a spammer" role, ie trusted users. That would be less than 100k.

For association.drupal.org, we can go ahead and deploy pathauto without as much scalability review, it is a lot smaller of a site. We do need to ensure configuration for common parts, like username token pattern, are consistent across sites.

Don't we need to deal with duplicate names first #1034852: Clean up accounts with case-insensitive duplicate names?

I've never understood why people would need seperate profiles on all subsites.

If this is about association.d.o then it should be in that component. Is this just about that or also about drupal.org.

tvn raises a great point - we would also need to deal with duplicate names that differ only by case before this because aliases are case insensitive.

Separate profiles are a convenience for the d.o site builders/maintainers. If we could make them all one profile and still maintain the rich data of the subsites I'm sure we would do that but it takes more than a snap of fingers to make it happen.

x post.

I think this is about Drupal.org. Stating #8 another way: Currently if you are on a CiviCRM contact page, you can click to the Association user profile, then click to the Drupal.org profile. It would be nice to be able to type in the drupal.org/user/… URL too.

(Another possibility in CiviCRM is to alter in a link to the Drupal.org profile on contact pages. The Drupal database has the needed info. This would be a separate issue.)

Marking as needs more info because we don't know if #1034852: Clean up accounts with case-insensitive duplicate names is a blocker. Can token/pathauto handle aliases which are different only by case? Do we even want to preserve username case-ing in the URL, or all lowercase? What about spaces and punctuation, are we good with the pathauto default settings?

If this is about drupal.org then what was the point of comment #6? Kind of a rhetorical question, but...yeah.

Can token/pathauto handle aliases which are different only by case?

tvn raises a great point - we would also need to deal with duplicate names that differ only by case before this because aliases are case insensitive.

And it's more than just #1034852, we would really need to not just deny but also fix any existing names.

To make things worse, transliteration can cause additional conflicts, e.g http://drupal.org/user/68039 and http://drupal.org/user/2430896 would have the same alias.

x

@jredding it does, but that doesn't matter in the case of being an easier way to link to people's profiles because you wouldn't be able to know, from association.d.o, whether to link to d.o/user/alina-0 or d.o/user/alina or d.o/user/alina-1

I've updated the issue summary to include some of the problems and potential solutions. It would be great if the "motivation" section could be fleshed out a bit - I'll admit that I don't really understand it.

x

1. Seems reasonable. How do we handle existing people?
2. That issue is only about new users, not existing ones.
3. Agreed it will take a bit of work.

On #1034852: Clean up accounts with case-insensitive duplicate names, I'd been using that for both stopping new accounts and cleaning up old ones. The next step is stopping new problems; when that is done, I'd retitle it to fix up the old ones. That isn't very obvious from the issue, it would be okay to file a separare one for cleanup.

Updated the motivation section

Just to let you know that the grn module would also use this for good measure.

See #1319350: Create links to user/author.

We'll be looking into this soon.
#1034852: Clean up accounts with case-insensitive duplicate names is the first step.

Oliver will start looking into other blockers and what it will take to fix them.

Sorry if I'm repeating anything already said above:

Pathauto will either transliterate non-ascii128 characters or remove them from the username. Drupal.org has a lot of users who have non-ascii128 characters in their names. I'm not sure what we would do to solve this problem.

We can prevent Pathauto from removing punctuation characters from within the Pathauto settings. On my dev site, I've set it not to replace or remove the period, and this seems to have worked for https://opdavies-drupal.redesign.devdrupal.org/user/holly.ross.drupal.

There is also an option for "Reduce strings to letters and numbers. Filters the new alias to only letters and numbers found in the ASCII-96 set.". This is currently not enabled.

We would have to prevent someone from registering with a name that contains only numbers - e.g. a user named "1" would conflict with the actual user 1

Normally the aliased version would be "users/" rather than "user/", I guess to prevent this issue. I'd suggest adding Global Redirect module in addition so that if a user were to do to "user/1" they are then automatically forwarded to "users/dries", for example.

There is a scalability concern to adding 1,000,000 aliases that needs to be tested. This might not really be an issue but we'll know that from someone testing it. If it is an issue, one idea is to only give aliases to the "non-spammers" or maybe only if someone requests one somehow (an automatic process that requires no approval).

Within my holly.ross.drupal testing, I didn't use the bulk generate alias function and instead simply re-saved the user which then triggered the creation of the alias. We could potentially save x number of users in batches via a Drush script or something, or just not generate them automatically and tell people that the next time they log in and update their profile the alias will be created automatically for them?

Thoughts?

or just not generate them automatically and
tell people that the next time they log in and update their profile the alias
will be created automatically for them?

I like this idea. I'm not sure how big of an impact that creating aliases might have on db load and using this approach (at least at first) will help to mitigate any huge increase in that load.

I'm not sure how big of an impact that creating aliases might have on db load and using this approach (at least at first) will help to mitigate any huge increase in that load.

I'm a little concerned that when we announce that this is a feature, we'll get similar load issues from lots of folks logging in to claim their URL all at once. That said, the rolling nature of an announcement would be better than the hit of an automated process that slowed the site for an extended period of time.

I wonder if we have had any comparable announcements where everyone would rush to the site to perform an action.

The other thing to consider is paths like https://drupal.org/user/381388/track where the uid is the argument to limit the content of the page. Are these going to stay the same, or do we need to assess updating these also?

re #29: I just wouldn't announce it :) But yes, after last summer's breach, every user who had logged in came to change their password and the site roughly stayed online.

re #30: https://drupal.org/project/subpathauto could be availabled for that, perhaps as a followup issue. I wouldn't create an additional alias for each path with uid in it.

re #30: https://drupal.org/project/subpathauto could be availabled for that, perhaps as a followup issue. I wouldn't create an additional alias for each path with uid in it.

I did not know of this module. It looks like it will certainly do the trick. :)

I think this is the current proposal.

We would like to implement drupal.org/[user:name]. I think the original request was inline with the defaults, but one of our goals is to make the user profile of every Drupal user a bit more prominent and easy to share. The addition of /users in the path makes the URL longer and does not add value.

We are also going to need to set up global redirect. The ancillary pages that sub-pathauto could address are not as important at the moment. I would like to see how many records we end up with in the alias table before we set up sub paths.

If there are no objections or red flags, we will have Oliver push the change to production some time next week. Oliver would you work out a date with Neil for the change?

I don't think we can do drupal.org/[user:name], that would be full of conflicts like https://drupal.org/user/135515 and https://drupal.org/user/41414. We could do drupal.org/u/[user:name].

I don't think we can do drupal.org/[user:name], that would be full of conflicts like https://drupal.org/user/135515 and https://drupal.org/user/41414. We could do drupal.org/u/[user:name].

Agreed.

Is there some backstory/discussion on #34? I haven't seen discussion around that in a public place.

Not to pile-on the topic, but as a (mostly former) maintainer of Pathauto I think I'm qualified to say that letting people put their username at the root of the site is a risky idea. It would need a lot of testing and perhaps some work to improve core/contrib in order to make it work.

Global redirect for d7 is one option, but the Redirect module is already on the site and #905914: Merge global redirect functions into Redirect module can add global redirect style features.

Global redirect for d7 is one option, but the Redirect module is already on the site and #905914: Merge global redirect functions into Redirect module can add global redirect style features.

That's good news. One less module to install. :)

I agree with using drupal.org/u/[user:name]. That is still short enough to be useful.

Drupal.org only has 87,539 rows in url_alias now. We should at least keep an eye on the DB load as this is deployed.

This change has been deployed onto staging, and after saving my profile, I get the https://staging.devdrupal.org/u/opdavies URL.

The Drush commands used were:

drush vset pathauto_user_pattern "u/[user:name]"
drush vset pathauto_punctuation_period 2

I've also added drush vset pathauto_punctuation_quotes 2 to stop apostrophes being being removed, although they are replaced in the URL with %27.

Deployed!

So where does this leave users with periods in their name?

Both of these 404:
https://drupal.org/u/tim.plunkett
https://drupal.org/u/timplunkett

I tried resaving my user page to trigger it just in case...

EDIT: Apparently I didn't wait long enough after saving, https://drupal.org/u/tim.plunkett works now.

We aren't doing a bulk update - only active accounts get aliased as they get saved. This gets URLs to the people affected by #1034852: Clean up accounts with case-insensitive duplicate names and doesn't suddenly change how big the url alias table is. Varnish could have cached the 404 if you tried those first.

Note: this breaks tabs on user profile pages once you have a u/[user:name] path alias. See #2281829: New URL aliases for user profiles breaks drupalorg_crosssite user tabs. I assume we just have to hack a bunch more special-cases into drupalorg_crossssite so it can handle both user/[uid] and u/[name] and still keep everything sane.

I just created a follow-up issue to make the URLs case sensitive, as it would reflect better the usernames and IRC nicknames: #2494609: Make user profile URL aliases case sensitive username (nickname)