The main difference is in how they get related to entries. When you relate a nested Structure section entry, that’s the only thing that gets related. When you related a nested category, its parents get related as well.

But yeah, I’m sure there are cases where it would make sense for categories to have authors; there are cases where entries shouldn’t have authors. Etc etc. For now we’ve just given each element type the features that they most commonly have in other systems.

Thanks for the explanation - Auto-relating parents for categories is definitely something I wasn't considering.

The main difference is in how they get related to entries

Just spitballing - Since what you're describing is more a characteristic of the Entires/Categories field, if one were looking for more parity between Structures & Categories, a field setting of "Relate structural parents?" might work as well.

there are cases where entries shouldn’t have authors

Indeed. Run in to that before. In the future, perhaps both categories and sections could have the options:

• Enable versioning for entries in this section?
• Allow entries to have authors?

Yeah realistically I’d rather just merge the two concepts, rather than duplicate a bunch of entry features for categories and vise-versa. But I wouldn’t want to merge the concepts until we can come up with a way to customize how the "entries" / "categories" can be displayed for content managers (e.g. #1662).

Thanks - subscribing to that thread.

I wanted to propose the same thing, so thanks @timkelty for the issue. We’re facing the dilemma of deciding whether to go with categories or entries on every Craft install. Currently we have to make the decision based on the way the associated relations field type works, or if a field layout select (entry types) is ever needed, and we usually end up with elements used for classification in both places, obviously bad for content managers.

@brandonkelly don’t you think customizable sources view in the entries index is good enough to implement this request before #1662, which is probably still a good time away (considered for 4.0).

@carlcs Realistically we’re not going to drop a major concept like Categories outside of a major release cycle (and 3.0 GA is way too close for us to consider it for this one). That said, if there’s anything you’d like to see us do to make using Structured entries a more viable replacement for categories in the meantime (e.g. allow Entries fields to be more like Categories fields), feel free to post those suggestions as separate issues.

@brandonkelly understandable. And a good idea with making the Entries field type more advanced as a first step. Thanks

And a good idea with making the Entries field type more advanced as a first step.

Yep - if we wanted it as a 3.0 feature, I'd say the biggest thing would be an option to "Include ancestors when related".

Only question then is - is that an option when creating a Structure section, or just a field option for Entries fields. I'm guessing the latter would be most flexible, and maybe easier to implement as well.

Yeah seems like the obvious place to put it is in the Entries field settings.

@brandonkelly FWIW, here's what my plan has been:

Make a new "Enhanced Elements" field type

This would be a catch-all replacement for all applicable element types, with additional field options to address the ancestor selection issue, as well as several other enhancements:

• First field settings option would be "Entry Type"
  • Presumably, there would be a way for devs to register an element type for this field, which would make it show up as an option. This would be great for plugin devs, as it would allow them to easily have a field for their element type without having to roll their own.
• Next would be the "Display/Selection" type:
  • Options include: Default (for selected element type), Element Index, Tag List, Checkbox/Radios/Dropdown (like https://github.com/timkelty/craft-simplecategories)
    • What would be cool about this is you could have Entries, but with a Tag List/Creation UI.
    • A simplified element selection is a frequent request from clients, specifically with Categories, where they aren't usually creating new ones. They really want to just bang through entries and use checkboxes, not the element index modal.
• Next would be Element type specific options:
  • The normal options for that entry type: eg "Limit/Branch Limit", "Sources"
  • Add "Include ancestors on selection" and "Branch Limit" for Entries

While it is on my "someday" list to implement this as a plugin, I think having the ability for plugin devs to automatically register their entry types is a good reason this should be implemented in core. For example, Field types like Freeform Form would no longer be necessary.

Another cool concept would be that a plugin dev could register a new element "view type" UI, that would become available when installed. E.g. - if the above were implemented w/o a "Checkboxes" view type, I could write a "Simple Element View Types" plugin, instead of having to make various field types: "SimpleCategories", "SimpleElements", etc.

Hi there,

I see this looks to be on the 5.0 milestone, which I understand as it is a major core concept to be changed.

But... are you planning on adding an "include ancestors on selection" option to the structures field (on a 3.x or 4.x release) before replacing categories entirely in 5.0 so we can use them as a full replacement to categories and benefit from their added power (multisite I'm looking at you)? In core or via plugin. Or maybe I missed a plugin that exists already?

Just a quick update on this to know where you stand would allow us to adapt accordingly. Thanx ;)

@JeanLucEsser both issues (this one and #2632) are on the same milestone list right now. It looks like Entries field updates won’t make it into a Craft 3 release in the end.

@carlcs yes that's what I thought. So in the meantime I guess I'll use structures because I need multisite ability, but I'll add a query to find all descendant ids of the structure parent's entry before querying the content related to all those ids. Guess it's the best way to go for now.

The real downside is having no visual cue of the ancestors tree for the selected entry in the structure field. Which by the way I find it to be an issue even when using structures as intended with no relation to ancestors, as it could be useful information. But it's tricky to implement, as each entry should be independent and able to be re ordered... maybe on hover or something... anyway, not the subject at hand, I digress.

Thanx anyway for getting back to me. Much appreciated.

I agree with what you said about the label of entries in the entries field. In structures the title isn’t always enough info for an entry to be recognizable.

Sorry this is actually intended to be part of 4.0. Just fixed that.