While it would be easy to say I was driven by the fact that the PHP world is so dense with CMS solutions or attempts at them and as such found this topic fitting to the general gist of the channel, it would probably be more honest to admit it was simple human error and bias - having recognized the article as excellent, I neglected to even think about other channels, enthusiastically giving it only one main category - mine. : )
Regarding the categories, I was always fond of a nested tags approach which worked for me in the past on large repositories of content. Tags with children (which essentially translates to categories and subcategories) solve all the problems I can envision in large scale CMS efforts, as long as the creation of tags is centralized and well defined. Internally to a site, there needs to be an approval flow to new tags, and the tags structure needs to support synonyms. Their IDs (and, by extension, URL slugs) need to differ if they’re homonyms and the problem is solved indefinitely.
Furthermore, such tags can be given root (or “meta”) tags that define their purpose, which themselves may be nested. Thereby, a CMS is given the flexibility to define which tags are visible to the end user in the site’s search engine, which are to be interpreted as forum categories, which are to be considered statistics-tracking-related, and so on.
In short, a tagTree-on-tagTree model has worked very well for me in the past, covering thousands of books each with dozens of chapters, hundreds of thousands of users, dozens of journals with hundreds of entries and dozens of quarterlies each, all in a single system, and every entity tagged to some extent. The same tag engine powered the user-facing search, the employee-facing search and CRM, and the system-facing invoice tracker and more.