Serendipity Forums

I'm working on the CategoryTemplate plugin, which provides custom templates for entry categories. I'm trying to incorporate the sequence widget to solve the problem of precedence when an entry has multiple categories that define custom templates. (See this thread if you want to refresh your memory.)

Currently, categories are assigned custom templates in the category section of admin. This has its advantages, but it may also be a bit unwieldy (in terms of plugin code required for support). I'd like to propose moving the assignment of custom templates to the plugin configuration, where it will be included with the category precedence drag-n-drop selector.

Any thoughts?

Hi!

IMHO that's not so intuitive to assign templates in the plugin configuration. It would also change this for users that are currently using it (plus it would need to make me rewrite the serendipity book with 2 chapters for both plugin versions for old users and new users)...

Regards,
Garvin

Right-o. Templates will be assigned in category properties, just like they currently are. Priority of multiple categories will be... determined soon. I think it's going to have to go in the plugin configuration, though.

I tried the ver 25 categorytemplates update. Broke my site. Category pages work but individual articles do not render using their assigned template. They use the blog's general template, i.e. frontpage. Not good.

Downgraded to ver 23.

Brian

Hi!

Hm, that's strange. Actually, version 23 should be the one that uses the site-wide template? I believe Version 25 was the one that introduced the feature so that category-templates would get applied if an entry has a category association.

For further info, could you please specify which categories you have setup with specific templates, what templates they specify (you can use "Template A", "B" etc.) and which entry does not correctly render and to which categories it is assigned?

This could help in debugging.

Regards,
Garvin

With 23, all articles render correctly with their specified template... and the frontpage renders with the site-wide template. See http://strumpette.com .

With 25, categories render correctly, but ALL individual articles only render to the site-wide template.

My setup for the category template (for example) is joshua/categories/news.

Hi!

I mean more detailed, like:

Blog: Template A
Category A, B, C: Template B
Category D: Template C

Entry A: Category A and D.
Expected result: Show Template B
Actual result: Shows Template A

(Actual Category names and Entry URLs would help, of course)

Regards,
Garvin

ver 23
Blog: Template A
Category A, B, C, etc.: Template B
Entry #1: Category B
Expected result for entry: Show Template B
Actual result: Shows Template B

ver 25
Blog: Template A
Category A, B, C, etc.: Template B
Entry #1: Category B.
Expected result for entry: Show Template B
Actual result: Shows Template A

Does version 24 expose the same beahviour:

http://php-blog.cvs.sourceforge.net/*ch ... ision=1.21

?

Hi!

Judebert, going through your code:

http://php-blog.cvs.sourceforge.net/php ... 21&r2=1.22

Is the SQL call to serendipity_fetchEntryCategories() really necessary? The IDs should already be inside $entry['categories'] to cycle through, a second DB lookup shouldn't be issued?

Sadly the code in that revision has changed too much, I'm afraid I don't have the time to setup an installation to test and debug this...

Regards,
Garvin

FYI: version 24 works correctly.

BD: Check out the other thread; I'll definitely get this solved, and meanwhile there's an easy workaround (just install advtypes plugin).

Garvin: I think it is necessary. In the earlier code, line 179, we called fetchEntry to retrieve the entry. I think (I'm not sure) that the entry is not actually populated by the time the 'genpage' hook is called (which is when getID() gets called).

However, we didn't really need the entire entry, so I switched the call to fetchEntryCategories(), which will hopefully perform better. I also moved it after the retrieval of categories, so it might get skipped altogether.

The biggest change in the code logic is that it originally hit the database to find the customized templates every time; now it only hits the database once, when the plugin is configured (and again whenever a category is modified). It uses the saved configuration, which is retrieved and cached, to store the customized template categories instead.

Unfortunately, if the plugin hasn't been configured, it doesn't have the config option stored.

My immediate idea is to hit the database whenever the config item isn't set. But if the plugin was installed to provide sort orders, and there are no customized template categories, then I'll be hitting the database every time a single entry is displayed. That, I don't like.

The more subtle possibility is to provide a default value in the introspection. The problem there is that my understanding isn't quite as deep as yours, so I need to know when introspect_config_item() is called, and how get_config() works.

I expect that introspect_config_item() is called only when the plugin configuration page is displayed; therefore it would show up on plugin installation, upgrade, and configuration. That allows me to set a default value as soon as the plugin is installed.

I also expect that the default value set in introspection is returned whenever get_config() is called and no value has been explicitly set.

If that's the case, then just setting a valid default will fix the whole problem. I could have it fixed nicely by this evening.

If either of those is incorrect, then I'll need to do something not-so-nice. But I could still have it fixed by this evening.

It was incorrect to expect the default value to be used whenever get_config() was called and no value was set.

I fixed the issue in 0.26 by checking the config value for being unset. That can only happen if no sequence widget is available. Whenever that is the case, I default to using alphabetical order (just like the <=0.24 version) and not resetting the config value (when a category has been templatized or detemplatized).

I took some extra time to test this one more thoroughly. If any other issues are discovered, please let me know. PM me if necessary; I'm determined to maintain this plugin.

I apologize for the inconvenience.

judebert,

you're the best.

Brian

Awwww.

Glad I could resolve it.