Determine the default node type for categories in each container
| Project: | Category |
| Version: | 4.7.x-1.x-dev |
| Component: | User interface |
| Category: | task |
| Priority: | normal |
| Assigned: | Jaza |
| Status: | active |
Jump to:
This task is to make the functionality described in this forum post work properly. Essentially, it will involve the category module 'determining' the default node type for categories that can get added to a particular container. This determination will simply be done by looking through the list of allowed containers for categories of a certain node type, and finding the container of lightest weight in this list (if 'all' is selected, then the lightest-weight container on the site will be the one picked). If multiple node types fit these criteria for a single container, then the first node type found will be the one used (i.e. the node type in the module of lightest weight, and of alphabetical or physical first order).
This will affect the 'add child category' links on a container (or category) page, as well as the 'add category' tab-link in the category admin pages. Instead of the link pointing to a URL in the form node/add/category-cat/parent/x' (where 'x' is the container), it will point to a URL in the form node/add/y/parent/x (where 'y' is the default content type for categories in container x).
I don't think a per-container setting is really necessary for this, as it would be a rather confusing setting, and as the validation to check against other node-type-category settings would be significant. Perhaps just a global setting to turn this feature on or off would do - or perhaps not even that. Users who don't make use of the 'allow other node types to be categories' feature won't notice or be affected by this feature at all, and those who do will only have a slight (and beneficial) change in their links.
Also: when the new links API (i.e. hook_link_alter() and friends) gets into HEAD, the HEAD version of category should probably be updated to make use of it - this feature would be a perfect candidate to implement using that hook. But the 4.7 version will have to do things a more old-fashioned way. ;-)

#1
node/add/y/parent/x
Would this solve the problem of the container drop down being prepopulated with the calling node's value?
Can't wait!
#2
I raised this as a related topic over at #251119: Allow various node types with category behavior to be used for free-tagging (per container) (6.x)
Not changing the issue status here, until we either incorporate this into that other patch, or decide not to. Then this needs to be revisited and updated accordingly.