Should id point to latest slug?

[JeanMertz]

I used to use friendly_id but found it too bloated and full of options I never used anyway. And for the custom options that I did want to use, I had to hack them in which wasn't very nice.

For my next version of the app I want to use slugged instead of friendly_id. I made the transition and am testing it now, however, it seems that the slug isn't converted to an ID when I make a page request.

It says: Couldn't find Page with ID=homepage

when I use the following show method:

def show
  @page = Page.find(params[:id])
end

Am I doing anything wrong or assuming slugged should do something that friendly_id did before, but I should be doing myself now?

[JeanMertz]

Guess I should've done some more testing.

Page.find_using_slug(id) does the trick. Through I created a new method find_by_slug, as that seems to be more in-line with the Rails way.

Any other things I should be aware of comparing to friendly_id?

[Sutto]

The reason behind find_using_slug is that the findby* methods are reserved for the wild card queries (e.g. find_by_cached_slug should exist with no work), but most libraries (e.g. autologic, cancan and a few others afaik) use the pattern of findusing* for situations where there is extra logic (in this case, the chained slug look up).

Re. differences compared to friendly_id - None that I can think of, but it's been a while since I've used it.

[JeanMertz]

Okay great, thanks. I guess it makes sense to keep using find_using_slug, as it visually shows that there is some extra logic being applied instead of the rails find_by methods which all do the exact same thing.

Also, on a final note. I am working on having pages with infinite subpages and want the slug of /mypage to be different from /page2/mypage.

Would it be a smart solution to actually store the entire url /my/page/title in the cached_slug, as that will always be unique, and simply update that slug whenever the page is moved to a different location. F.e. /my/page/title suddenly becomes /your/page/aboutus.

The only problem I see with this is that I need some kind of way to keep the history of a slug (as is the case right now), but remove a "history stage" from a slug when another page wants to use that cached_slug.

So /about-us/startpage and /startpage both exsists, and suddenly I change /about-us/startpage to /about-us/contact. Now /about-us/startpage will redirect to /about-us/contact using "has_better_slug".

But what if I decide to move /startpage to /about-us/startpage, now I need /startpage to redirect to /about-us/startpage and no longer want /about-us/startpage to redirect to /about-us/contact.

Does this make sense? Is this a good approach to tackle this issue (storing the entire url in the cached_slug column)? Thanks for all the help so far. Love the fact that slugged is so much more lightweight and more easy to modify than friendly_id.

[Sutto]

the best bet for that is the latter (simplicity wise) - If you have the slugs table (see the README), and history set to true, slugged will automatically track history (the current slug always takes precedence).

[JeanMertz]

Sutto, thanks, but will slugged know if a new page starts using a slug that was previously in use by an old page, and link that slug to the new page? i.e. break the redirect to the old page? And if that new page then changes current_slug, does the history now know to start redirecting to the new page, or does it revert to redirecting to the old page, which was the first to use that cached_slug name? (are you still following me, because I'm hardly following myself here?)

I had this previously hacked into friendly_id, so just wondering if I need to reuse that code to do the same for slugged, or not. (I still need to write my own code to make sure a doesn't get the same cached_slug value as a page which currently uses that cached_slug value, correct?)

[Sutto]

Yehp, it will - as part of the slug history code, it'll automatically expire past slugs (e.g. it finds based on cached_slug first and then falls back to the history list to find it via that method).

[JeanMertz]

Thanks, also on a final note (for anyone else who might find this post), I figured using the full url as the cached_slug seems to be a bad idea after all. Because if any page in the chain changes its cached_slug, this isn't represented in the url for lower pages.

f.e. /my/page/contact might work, but /my/page might already be renamed to /my/page2, which is confusing to visitors and really creates a mess.

So the best method would be to only use the page title as the cached_slug name, and then do some mumbo-jumo in a method that checks all parent pages and creates the url from there for navigations etc. This would still mean I can't have /page and /my/page as both would have cached_slug "page", but I guess I have to figure out another way to solve this.

Thanks again for the help.

update: actually I guess I could allow duplicate cached_slug titles, as long as the parent_id isn't the same (or nill). However, I am unsure if the history method of slugged would work nicely with this. Not sure if it checks for duplicates in the history, but as long as it only checks for duplicates with the same id, I should be fine.

update 2: Actually, scrap that. I guess when I use duplicate cached_slugs find_using_slug would no longer work/get confused, so duplicate slug names in the cached_slug column is out of the question for now. Back to the drawing table.