Well, let's see what I can work out here. We're talking how to choose a custom template for displaying the single-entry view for entries with multiple categories that have custom templates defined. (Whew!) The shorter version: two or more categories are fighting to display their own custom template. Who will win?
Option 1: Everybody loses, use the default template.
This is the option being used right now. The code looks like this:
Code: Select all
// Set up and return the custom category
if (count($custom) == 1) {
if (serendipity_db_bool($this->get_config('fixcat'))) {
$serendipity['GET']['category'] = (int)$custom[0];
header('X-FixEntry-Cat: true');
}
return (int)$custom[0];
}
: Whoever is mentioned first wins.
This option is a little unpredictable, since we don't know if the categories are sorted in any particular order. We don't know if it's dependent on the database, the category ID, or the category name. There's a lot we don't know. In any case, its code looks like this:
Code: Select all
// Set up and return the custom category
if (count($custom) >= 1) {
if (serendipity_db_bool($this->get_config('fixcat'))) {
$serendipity['GET']['category'] = (int)$custom[0];
header('X-FixEntry-Cat: true');
}
return (int)$custom[0];
}
No biggie; just changed from "if there's one" to "if there's at least one".
Option 3: The category with the highest (or lowest) ID wins.
This
almost makes sense. If your blog's categories were all created at one shot, it's likely they're in some sort of order. The code would look like:
Code: Select all
// Set up and return the custom category
if (count($custom) >= 1) {
array_reverse(sort($custom, SORT_NUMERIC));
if (serendipity_db_bool($this->get_config('fixcat'))) {
$serendipity['GET']['category'] = (int)$custom[0];
header('X-FixEntry-Cat: true');
}
return (int)$custom[0];
}
The array_reverse() is necessary because sort() always sorts ascending. So if you want the
lowest ID to win, just remove the array_reverse().
Option 4: The category with the alphabetically highest name wins.
This is tempting, because Serendipity's archive URLs ignore the category name if the category ID is specified. Therefore you could rename all your categories for the correct precedence, and your old URLs would still work. However, it requires some more extensive code changes, because our db query doesn't retrieve the category names, and the names aren't unpacked when we "unpack the response".
Therefore, I'm not providing code for this option unless we decide this is what we really want.
Option 5: Specify the precedence of the category where we specify the template.
The easiest and most intuitive way to do this is to add an additional text field after the category template field, on the category page. The new field would be the "Precedence", and we'd add code to check it when multiple categories were found.
The problems with this option include that it's still possible to set categories with equal precedence, leading to the problem not actually being solved; there's a lot of code to modify (so again, I'm not working it out unless we decide this is the way to go); the database schema needs to be changed so the precedence field is included; and it's impossible to see all the categories' precedences at the same time.
Option 6: Specify the precedence of the categories on the plugin configuration page.
This is probably the best of our available options. It's going to be a bit of a pain to code, though. My idea is that the plugin configuration page would include a list of all the categories that have custom templates and allow you to drag them up and down until they're in the order you like. I'd want to steal the code from the plugin page to do this (the code that lets you drag plugins to the appropriate place in your sidebar, for instance).
Whenever you assign a custom template to a category, I'd insert it at the top of the list (most important), so your new changes are certain to take effect.
This keeps all the categories in an unambiguous order. All the heavy processing is done when the templates are assigned or the plugin is reconfigured, so the retrieval can be as fast as possible. It may not require a change to the database: if this can be made into an "ordered list" option, it could be placed into a configuration variable instead -- and it might be useful for templates or other plugins that need an ordered list.
The only drawback is that it's a LOT of code. But, if you can find a programmer dumb enough... uh, I mean,
interested enough to take it on, it would be pretty slick.
Oh, I forgot
Option 7: pick randomly.
Just replace the array_reverse(sort($custom)) with shuffle($custom) and carry on. This is probably the most capricious of all the available options.
Discussion?
