creating *different* articles which resolve to the same permalink allowed
Reported by Jeffrey 'jf' Lim | June 30th, 2007 @ 05:32 PM | in The Big 1.0
An example of 2 articles which *are, of course, different*, but resolve to the same url (because of the way things are "interpreted", and a url is constructed from the words in the title):
article 1 title: "mephisto rocks!!"
article 2 title: "mephisto ROCKS??"
Now most of your users should probably not come up with 2 articles like that, but then again... Are you sure about that? what if they DO do that - and expect for the system to be able to construct different urls for that? Try the following article title which sounds like it might very well be repeated: "project status update". A user posts one project status update, and posts the stuff in there. He posts again when he wants to report on another update again - and yet fully expects for the old post to be accessible as well!!!
Capitalization is also a problem. "my Ruby rocks!" would talk about my ruby skills, while "my ruby rocks..." might talk about my rubies which I bought from the gem store.
'Update': yeah, I know about the permalink editting thing, but... a mechanism whereby this clash of urls would be resolved automatically would be great. If not, this really is a bug.
Comments and changes to this ticket
-
rick July 14th, 2007 @ 08:11 AM
- → State changed from “new” to “open”
Sounds good, I'll await a patch for it :)
-
Jeffrey 'jf' Lim July 14th, 2007 @ 08:11 AM
:) I'm more interested in the patches necessary to implement my optimized version of YetAnotherTagCloud liquid filter right now - but i'll see what i can do!!! no promises though - as u can clearly tell (if u read my blog), i've got quite a few things that i wanna play with, or am playing with...
-
rick July 14th, 2007 @ 08:11 AM
At any rate, they can enter their own permalink. So, it's not a bug.
-
-
Jeffrey 'jf' Lim July 14th, 2007 @ 08:11 AM
what the heck, I think there's some problem with posting large comments, but I'll see what I can do...
What I wanted to post:
well... not exactly. See my example of "project status update". A normal user would expect to post another follow up article with the same title, and yet be able to have the system resolve that differently from the earlier article with the same title.
Or what if the update is like a few months later? It would be nice to resolve the path clash automatically for the user - instead of the user having to double-check by either going back to the history, or clicking on the generated article to see where it went (assuming the old one is maintained - I don't really know at this point in time).
Anyway, turns out that the problem isn't so difficult to resolve after all (patch is attached; apologies if you are expecting a different "patch" format... If so, do let me know).
A few notes...:
- 'permalink_for' assumes that 'create_permalink' has been called already. Since 'before_create :create_permalink', this shouldn't be a problem.
- I have chosen to get around the problem of creating unique permalinks for the articles by appending "number-of-secs-since-epoch" to the url. I hope that's a logical (and sane) choice to use - at least it helps to give you a sense of the time when the article was created. Using a random value (Process.pid, ... whatever) can still lead to name clashes (depending on what you use).
- (minor) the 'articles' "method" (or whatever you call it) ends up using Article.find_by_date - which orders the article based on published_at. That's fine, but since mephisto only publishes everything at ":00" seconds, if you publish 2 articles with the same title within the same minute, what you end up with after doing a find_by_date is the wrong order for these 2 articles (a sane SQL engine won't bother to re-order these 2 articles any further when your "order by" field value is the same already)
-
Jeffrey 'jf' Lim July 14th, 2007 @ 08:11 AM
oh hey, sorry about that 'def convert_to_utc' line in the diff - somehow inadvertently managed to convert the spaces before the 'def' into a tab! Please ignore that line...
Thanks,
-
Jeffrey 'jf' Lim July 14th, 2007 @ 08:11 AM
("see earlier comment":http://ar-code.lighthouseapp.com/projects/34/tickets/110-not-exactly-crucial-but-take-note-creating-different-articles-which-resolve-to-the-same-stub-allowed#ticket-110-7) fixed the patch to remove that offending line.
-
Philip Reed July 14th, 2007 @ 08:11 AM
A normal user would expect to post another follow up article with the same title, and yet be able to have the system resolve that differently from the earlier article with the same title.
Exactly, I think that's a reasonable expectation by a user. An optimally usable system should alert them to the conflict, not assume that they're aware of it.
If you have a blog with thousands of posts, do you really want to be responsible for manually tracking each title to make sure you never duplicated one?
-
Jeffrey 'jf' Lim July 14th, 2007 @ 08:11 AM
:) thanks, Philip, for supporting me on this. Anyway, see the attached (in unified format) diff. Tell me what you think! ;)
-
James Cox October 18th, 2007 @ 08:36 PM
- → Title changed from “creating *different* articles which resolve to the same "stub" allowed” to “creating *different* articles which resolve to the same permalink allowed”
- → Milestone changed from “” to “The Big 1.0”
- → Assigned user changed from “” to “James Cox”
If you have existing content that's going to collide on the same node (it's ok to have duplicate titles if they are in different sections), is this something you're going to want to care about? of course, the answer is no.
the question is, how do we resolve this?
appending seconds-since-epoch is kinda nasty, since it is essentially meaningless junk that cannot collide, due to its ever changing state. So what else could we do? one option is to increment a number and append that. this is more work in figuring it out, but it's not as if we need to worry so much if we do this invisibly.
anyone else got suggestions of way to keep the url scheme tidy?
-
-
Philip Reed November 22nd, 2007 @ 05:47 PM
An example of 2 articles which *are, of course, different*, but resolve to the same url (because of the way things are "interpreted", and a url is constructed from the words in the title):
article 1 title: "mephisto rocks!!"
article 2 title: "mephisto ROCKS??"
Now most of your users should probably not come up with 2 articles like that, but then again... Are you sure about that? what if they DO do that - and expect for the system to be able to construct different urls for that? Try the following article title which sounds like it might very well be repeated: "project status update". A user posts one project status update, and posts the stuff in there. He posts again when he wants to report on another update again - and yet fully expects for the old post to be accessible as well!!!
Capitalization is also a problem. "my Ruby rocks!" would talk about my ruby skills, while "my ruby rocks..." might talk about my rubies which I bought from the gem store.
'Update': yeah, I know about the permalink editting thing, but... a mechanism whereby this clash of urls would be resolved automatically would be great. If not, this really is a bug.
-
rick February 3rd, 2008 @ 11:46 AM
- → State changed from “open” to “resolved”
Fixed this tests + code from permalink_fu.
Please Login or create a free account to add a new comment.
You can update this ticket by sending an email to from your email client. (help)
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
