Here's a quick rundown of how we store topic data for stories.
Read this and post a comment to let me know if you understand it,
if it seems logical, if you think something should change...
stories table is much the same as before. But in place of section
we now have stories.primaryskid. This is not the *only* skin that
the story can/will show up in. A story whose chosen topics render
into both the Apple and BSD nexuses will appear both in the Apple
index.pl skin and the BSD index.pl skin. But one or the other is
*preferred* - it's the skin that we send the user to when the user
clicks on the article from the mainpage skin. The primaryskid can
and often will be the mainpage skin.
stories.tid is still around, mostly just for compatibility (there are a
number of places in templates where we refer to it, and I don't feel
like changing them all). What this is, is the first item returned by
getTopiclistFromChosen, when passed in the chosen topics for that
story. To see what that list looks like, try perl -MSlash::Test -le
"chosen" and "rendered" topics. These are stored internally as
hashrefs, where the keys are topic IDs and the values are the
weights (which for our purposes will be 0,1,2,3 or 4). The rendered
topics are determined by the chosen topics and generated by
Authors choose the chosen topics (obviously). Choosing a topic
with weight 0 means "this is not part of this story, whatever other
topics may be chosen."
Rendered topics are roughly speaking the parents of those chosen.
Weights propagate up the topic tree. This is why a topic with
weight of 1 or 2 stays "sectional", because it does not have
sufficient weight to get into the mainpage nexus -- only topics
chosen with weight of 3 or 4 make it into the mainpage nexus.
(To pick one skin as preferred, authors will have to nudge one
topic or another up to "priority" -- see admin.pl?op=edit and its
Weight popup menu choices. That's the only reason "priority"
different from non-"priority" in that popup menu, so an author can
say "this story is both Apple and BSD, but I think it's more Apple.")
submission_topics_chosen and submission_topics_rendered work
the same way.
I honestly don't know if we should have a poll_topics_* and a
journals_topics_*, logically that makes sense, but it may be