Don't mess with Texas, or with django ID field

Apparently we've had some folks who have been messing with the django ID fields, which has spurred some e-mail traffic from our tech guys. Rob says it better than I can, so here is his e-mail:

We’ve been getting a rash of Web site errors over the past couple of weeks that stem from two places: duplicate slugs and bad Django IDs. Here’s a quick reminder of why those happen, and how to prevent them.

First off: You must put a date (preferred) or some other unique identifier into the “slug” field when you create a new article. The reason for this is that the slug is how Django saves files internally. Two slugs = confusion for the site. (Think of it like saving a file with the same filename as another file on your computer.)

Please also remind reporters of this problem -- “my awesome council story” isn’t a good slug. Nor is “Boone Life” or any other slug that will repeat. If you don’t know exactly when it will run, put the expected run date in the slug. You can always edit it later (as long as it’s not duplicative of an existing slug).

AP stories are particularly susceptible to the error above, as they tend to use the same slugs repeatedly. Dating them is a simple way to avoid confusion. Our preferred way to handle writethroughs is to add them to the existing story, but you could also generate a new story (again, with a unique slug) to use with those.

Second off: You may not edit the Django ID. Just don’t mess with it. It’s generated automatically from the initial title of the story, so put something other than “Headline goes here” if you can.

Questions? Confusion? Let me know.

Thanks, Rob


--
Rob Weir
Director of digital development
The Columbia Missourian
Missouri School of Journalism
207 Lee Hills Hall
Columbia, MO 65211
(573) 882-5057

Blogged with the Flock Browser