entry detail url format change

[sertac]

I suggest placing pk of entry into url format and lookup from entry with id not from slug ,

when people need to change title of entry they won't bother with 301 redirects or 404 errors later
this can be optional so people can use as they want

sample
from -> blog/this-is-entry-instance
to -> blog/1/this-is-entry-instance

[ivanvenosdel]

Thanks, I can see how a project would find that useful. I agree that it would be best as an optional feature.

Do you have any recommendations of examples/tutorials/posts for doing something like this with a Django site? It may help whoever wants to take a stab at a pull request for this feature.

[ivanvenosdel]

Reading up on this approach a bit more I think we can implement it without having to make it optional. When I first came this I wasn't sure how a site like stackoverflow did this without violating canonicalization. I see now that they do a permanent redirect when someone navigates to the URL without the slug (just the Id) to the URL with both the Id and the slug (as opposed to loading the same page at a second URL).

TL;DR: This can be implemented without having to make it optional if we make sure that the we have a view that redirects the /{id} URL form to the primary view at /{id}/{slug}.

[ivanvenosdel]

To address this issue we would need tests for both URL forms in test_entry_detail.py.

[bradmontgomery]

One idea would be to set the url scheme through a couple of settings with defaults that keep the current behavior. Something like this (I've dabbled with this, but it's still a fairly rough idea):

1. An ANDABLOG_ENTRY_PATTERN settings, that defines the URLs pattern. The default would be: r'(?P<slug>[A-Za-z0-9-_]+)/$'.
2. An ANDABLOG_ENTRY_ARGS setting that's a tuple of the Entry field names that should be used to generate a url. The default would be ('slug', ).

The default URLConf would look something like this:

url(settings.ANDABLOG_ENTRY_PATTERN, views.EntryDetail.as_view(), name='entrydetail'),

And Entry.get_absolute_url would look something like this:

def get_absolute_url(self):
        args = [getattr(self, field) for field in settings.ANDABLOG_ENTRY_ARGS]
        return reverse('andablog:entrydetail', args=args)

A user of the app might set the following:

ANDABLOG_ENTRY_PATTERN = r'(?P<id>\d+)-(?P<slug>[A-Za-z0-9-_]+)/$'
ANDABLOG_ENTRY_ARGS = ('id', 'slug', )

And the URL for an entry would be: /blog/42-hello-world.

This is a fairly flexible approach that lets users set their own schemes but dosen't require building new views. New users could define URLs however they want, and if existing users wanted to change their scheme, they'd have to handle orphaned URLs themselves, which I think is OK.

I'm happy to get any feedback on this idea 😄

[ivanvenosdel]

I think that is an excellent idea. Though in keeping with the spirit of the project (easy integration) I think the feature would also need some pre-canned forms that people can use. They can be mentioned in the documentation. I think this is important so that those with alternate needs but not URL opinions can get going quickly.

For instance, I see three cases mentioned in here already.

1. The default

Slug lookup only. Advantage: URL simplicity
No setting needed.

2. Id only lookup /{id}/{slug}

This still uses a friendly URL but uses the Id for lookup. A URL with only the Id causes a 301 redirect to the id/slug form. Advantage: Performance (id based lookup) and support for entry renaming.
Put this in your settings

ANDABLOG_ENTRY_PATTERN = 'entry-pattern_id'

3. Id and slug lookup /{id}-{slug}

This uses both an Id and slug for lookup. Advantage: Performance (id and slug based lookup)
Put this in your settings

ANDABLOG_ENTRY_PATTERN = 'entry-pattern_id-slug'

Custom

Set ANDABLOG_ENTRY_PATTERN to your own url pattern and ANDABLOG_ENTRY_ARGS to the fields that should be used for lookup.

Caveats

• Case 2 would actually cause 2 entry patterns to be hooked up behind the scenes. One for the entry and the other for the 301 when the naked form is used.

[ivanvenosdel]

Hmm... maybe instead of magic strings we could put the pre-canned things under different bool-type settings all together in keeping with the original optional idea.

Either way, they would invoke the same code as ANDABLOG_ENTRY_PATTERN/ARGS behind the scenes.