After meeting with the Kalamuna team, they frequently need to create a "Categories" taxonomy on their sites which is different than Panopoly's "Categories" taxonomy. But since "Categories" comes from panopoly_core, they are stuck with it. Since this more relavant to panopoly_pages, we decided to move it there.

We also discussed renaming it to "Tags", because I thought it was a free-form tags field on panopoly_page. However, it turns out that it isn't! I still kind of like the idea of doing that, but it'll need more discussion, so I made a new issue about that:

#2282057: Rename "Categories" to "Tags" and make a free-form tags field on panopoly_page?

Comments

lsolesen’s picture

lsolesen commented

Categories taxonomy is also used by Panopoly News. Moving it away from Core would make Panopoly Pages a neccessary dependency on Panopoly pages. Maybe to a more generic Panopoly Fields module so we do not force dependencies which are not necessary?

dsnopek’s picture

dsnopek
he/him
Primary language English
Location USA
commented

It seems like that is the goal of the 'apps_compatible' module:

https://drupal.org/project/apps_compatible

Of course, it doesn't include a "Categories" taxonomy, only a "Tags" one.

But, yeah, I understand your concern. Someone could want to use Panopoly News, but NOT use Panopoly Pages.

Thinking about it now, maybe Panopoly News should create it's own Taxonomy? Does it actually make sense for a Content Page and a News Article to exist in the same set of Categories?

lsolesen’s picture

lsolesen commented

In the general use case, does it make sense for pages to have a category.

cboyden’s picture

cboyden commented

I can definitely see a case where someone might want an image or blog content type to share the same vocabulary as News.

dsnopek’s picture

dsnopek
he/him
Primary language English
Location USA
commented

Thanks @lsolesen and @cboyden for participating in this discussion!

A couple of thoughts:

  1. panopoly_news actually already does depend on panopoly_pages! So, moving "Categories" there shouldn't make anything worse than it already is. :-)
  2. However, maybe getting "Categories" (and maybe "Featured Image" and "Featured Content" too?) into apps_compatible and using that makes the most sense? Then we could include 'apps_compatible' in panopoly_core.make (but not depend on it there) and have both panopoly_pages and panopoly_news depend on it. I'm going to contact the maintainer and see what he thinks.
  3. The question about panopoly_news/panopoly_pages sharing the Categories taxonomy is interesting: it's really what do we want to support by default. Currently, they share by default, but someone might want seperate categories! Both are possible regardless of what we do by default, it would just require some site building.

But, yeah, because of #1, I don't see any reason not to move forward with this issue and move "Categories" to panopoly_pages.

dsnopek’s picture

dsnopek
he/him
Primary language English
Location USA
commented

Actually... I might be having 2nd thoughts about this. :-) We really are doing a lot of stuff in panopoly_core with the "Categories" taxonomy, including adding fields, setting up some Panelizer defaults, pathauto patterns, etc. It definitely should be made easy to disable or ignore, but I need some more time to think about how...