Pretty URLs

[damned_colonial]

Title:
Pretty URLs

Area:
entries

Summary:
Generate a pretty URL for each entry in a journal, so that instead of:

http://some-journal.dreamwidth.org/12345.html

you see:

http://some-journal.dreamwidth.org/2010/07/15/five-things-make-a-post

Description:
The generated URL should include the date in YYYY/MM/DD format, and a simplified version of the post's subject line. If two posts with the same subject happen in one day, just add "2" to the end of the second one (and increment as necessary).

The original numeric URLs should keep working so that links don't break, but should rewrite to the pretty ones.

This will provide context in all kinds of handy situations, eg. when someone pastes a URL to you or when you hover over a link, you can see what's likely to be at the other end of it.

Poll #3836 Pretty URLs

Open to: Registered Users, detailed results viewable to: All, participants: 90

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
29 (32.2%)

Should be implemented with changes. (please comment)
22 (24.4%)

Shouldn't be implemented.
31 (34.4%)

(I have no opinion)
8 (8.9%)

(Other: please comment)
0 (0.0%)

Comments

[ninetydegrees]

What about entries with edited dates?

[ratcreature]

How would edited subject lines work? Are these all going to be redirected?

[damned_colonial]

For changes to both dates and subjects, the three options seem to be:

1) only the original works
2) only the new one works
3) the new one is canonical, and the old one redirects to then new one

Option 3 makes for the least breakage and failure, I think. I think option 2 is closest to how Wordpress does it (Wordpress was my model for the URL layout, and the one I'm most familiar with). Option 1 would be a very bad idea IMHO.

[damned_colonial]

Huh. Just thought of a possible (small?) privacy implication. If someone linked to a locked post that you don't have access to, you'd have slightly more information about that post than you currently do. OTOH, people don't often do this (since most people won't be able to follow the link, and what's the point?) and if they do link to a locked post (by accident or design) they usually provide some context anyway via link text, surrounding description, etc., so the change is not very significant imho.

Example:

Person A posts, "someone posted a great rant about broccoli the other day."

Person B comments, "Um, locked post!"

Person A says "oops", edits post, but you already know that the post was by someone, and that it was a rant about broccoli. Knowing the URL /2010/07/16/aauuuugh-fscking-broccoli won't make much difference.

[damned_colonial]

I replied above to 900degrees who asked a similar question.

[ninetydegrees]

Option 3 makes for the least breakage and failure, I think.

You're right.

[matgb]

Wordpress and Blogger now work that the original URL is set on first post and future edits don't change it, and WP now allows you to edit it (and even set it originally) separately.

Which I think works well.

[matgb]

It should be an option on a per-journal basis (definitely not per post although you could have default and override I guess).

But there are definitely privacy concerns, in a bigger way to my concerns about LJ, outboundlink and locked posts, but in the same ball park.

If you know it's happening, and want it to happen, then it's up to you to make sure you're doing it right. Allowing it to be turned off on a per-post basis is probably a good compromise.

(my with changes is to not put the day of the month in the URL, just year and month should be enough)

And for some reason I thought this was already a planned feature, it's definitely been discussed in the past, otherwise I'd have suggested it with my last batch, definitely in favour, really want it, it'll make the difference, for the way I use DW, of DW being cool and DW being incredibly effective as a platform.

And when it switches to incredibly effective, I actively start recruiting people.

[ratcreature]

I'm not fond of the URL text remaining even though the content changed. I mean, you could have said something wrong, be corrected, edit that in your subject, and the wrong statement remains in the URL. Or you are careless, title a post with a spoiler, feel the wrath of the spoiled, hurriedly edit the post, yet your URL still spoils everyone when they see it.

[matgb]

All true, but I'm also not a fan of broken links, especially given I use automated services to aggregate my posts in many places, some of which don't update much subsequently (unfortunately).

If edits can be redirected, brilliant, if not, make sure they're editable separately, not on every edit of subject line (and I'm incredibly prone to typoes, even when I proofread, so it'll really matter for me).

And yes, you're thinking spoiler, I'm actually thinking of UK libel law, but same principle, you do need to be able to change URLs, but not automatically per typo.

[ratcreature]

Well, after the clarifications in the comments, I changed my mind from "no opinion" to against. I've always been happy to have the simple numerical URLs anyway, so I don't need this, but if these prettified URLs became the default it seems like there'd be a lot of trouble for me, in that my links could break if I didn't want the wrong subject represented (or look stupid with typos remaining), not to mention the hassle of having to edit another thing manually.

Maybe if you could disable them for your journal and just have the regular URLs, with no prettified URLs at all.

[matgb]

Ah, reread, I see it's presented as a default always on, I want it as an option on a per-journal basis, so I'm changing my vote to with changes.

I really want this, until we've got proper domain mapping and this, DW isn't a platform I can actively promote as being better than Blogger and Wordpress for the people I want to promote it to (ie my friends within party politics blogging).

You need pretty links for policy blogging because it works a lot better with search engines, and that's really important for this sort of thing, at the moment DW scores lowly for search, whcih for many users is an unthought of benefit, but for me it's a known about disadvantage, and I want to have the option to make it an advantage.

[damned_colonial]

What if it redirected automatically? (my option 3, up-thread)

[damned_colonial]

Good point re: outboundlink.

To clarify for anyone who might not understand the issue.

Let's say I make a locked post called "Why I hate Person X" and in that locked post I link to a website of Person X's where they're doing something hateful. The URL for my post includes something like /2010/07/16/why-i-hate-person-x.

When Person X looks at their web server logs, or analytics/statistics on where their visitors are coming from, they'll be able to see that people are clicking through from my post with that name, and they'll know I hate them. Previously, all they could see was "12345.html" so they know I said *something* about them, but not what. If they followed the link back, they'd see the "You are not authorized to view this protected entry" page.

[shaela]

This has been at the top of my wish list since I created my journal. But there are a couple of things I’d add:

1. I’d want people to be able to decide for themselves how they want their URLs to look. Some people might want to keep them the way they are. Others might want the year and the month in the URL, but not the day. (Ideally, this would be part of the wizard.)

2. I’d want a separate field for the entry’s slug (the word or words that are in the URL). That way, if someone wants to give one of their entries a ridiculously long title, they can still give it a short URL. (If they left the slug field blank, the URL could still fall back on the title.)

[ratcreature]

That would be better, but I'd still rather have this as option, with the default remaining what it is. Another thing I wonder about is how this would work if the subject line was in a non-latin language.

Are these URLs possible for subject lines in all languages? And how does linking then work? I know I sometimes have trouble with the c&p of characters for which I didn't configure my system. Could I still link to a post in a language I haven't set up on my system, because I like the images posted in it?

[ninetydegrees]

What about a general privacy setting:
-- prettify the URLs of all my entries
-- only prettify the URLs of my public posts (could a post which is made private later on have its URL rewritten to anonymous everywhere? Edit: everywhere on the site I mean not on third-party sites but I think you know what you're doing when you post potentially offensive posts in public)
-- never prettify the URLs of my entries (the default)

And a setting when you post. The same way it works for comment screening.

[aliya]

I'd like to echo suggestions both to make the pretty URL an opt-in, and to take the day-of-the-month out of the pretty URL. But another option I can see is to make the pretty URL option closer to Tumblr's: they give users the option to name the pretty URL on a post-by-post basis. I'm not sure how much more complicated it is from a technical standpoint (I'd imagine quite a bit), but for privacy & security reasons might be worth the extra development work to implement.

ETA: perhaps, rather than having the date in the "pretty URL," the system-generated entry number in the original URL could be the unique identifier before the user-named option? I think that, too, may be how Tumblr does it (there's always a number before whatever you name it, though IDK if it's actually random or not)...

(If you couldn't tell, the pretty URLs is a feature of Tumblr's -- one of the few -- that I really like.)

[jazzfish]

I want it as an option on a per-journal basis

+1. Possibly 'per-post' as well.

[axiom_of_stripe]

+1

[damned_colonial]

The benefit to dates is that they provide additional context: "oh, that's an old post" or whatever. Quite often I see people link to older posts and click through and go "oh, I remember this, I've read it before" -- which I might have remembered earlier if I'd seen the date and subject.

[aithine]

+1

[aliya]

Oh, I agree on the context element -- I just thought from a technical/implementation perspective, it might be easier if some part of it was tied into the hard-coded system-generated unique ID instead of a date that could be user-modified infinitely.

[green_grrl]

+1

[turlough]

My "with changes" is that this only be implented as an opt-in.