Needs docs update: Move field type modules into separate "Field type" package

Patch looks good.
I like the idea, but probably needs some more people saying that before RTBC.

I could go with this, but moving 'taxonomy' to the Fields package probably needs a broader approval.

Moving taxonomy into the fields package seems non-intuitive, even though it's technically a field-based module now. Aside from that (and I'm not necessarily opposed), I'm all for moving the other field modules into their own package.

I stumbled on Taxonomy as well, but then I realised, that while you can set up Vocabularies and Tags without having anything to do with fields, you can only do anything with those, if you attach them to something else, as a field. So I do think it makes sense.

I think this makes sense, even for less clear cut cases such as Taxonomy. We should privilege the needs of new and confused Drupal site builders who simply want to see all modules that provide fields.

Like the idea as well, but this will need an update probably because we now also have the email field, I'll trigger the re-test button but I have feeling it won't even pass anymore.

#2: drupal-framework.field-package.2.patch queued for re-testing.

FWIW, I have no problem with this.

As a side note, though: even though the recent new field types (url, mail - soon date and entity_reference ?) have been added as submodules of /core/modules/field (next to the existing text, number, etc...), it would be good to get MAINTAINERS.txt entries for those, and not assume they are maintained by the Field API team :-), or we're going to hit the CCK effect (field modules get neglected because maintaining them all + the API itself is too big of a task).

Re-rolled. Included email and link fields.

I think the MAINTAINERS.txt should go into a separated issue.

Looks good. I looked through the list of modules and this covers it.

I see a lot of devs in here saying +1, but no UX reviews. Assigning to Bojhan.

Could this have a screenshot or list? E.g. Do we actually make fields part of this package too?

Why isn't Field, Field UI, Field SQL storage part of this group? It seems those are the container modules, all these modules are related to?

Well the idea of grouping, is to add similar functionality together - that includes the "main" thing, since that is your orientation module. So I disagree it adds clutter. I agree that its probably never going to be clicked, so from that perspective I am fine keeping it in system.

However, the label "Fields" should be more descriptive, e.g. "Field types" - it is not clear this is about the actual types if we only use the label "Fields" then I have no doubt that field-related modules will start adding their stuff there.

FYI, I really like this - because it sets the trend of unwrangling the "core" package in more useful groupings.

Changed to Field types, I personally like it in a way as well, although you could argue that it's maybe to technical ? Anyway here goes, I also attached the interdiff, although that's half as big as the patch itself :)

- edit : too much 'maybe's' in one sentence

Lets gets this in

I'm not sure about Taxonomy - what if we wanted to add an Entity package later on?

Yeah, IMO taxonomy should not be in the group. It provides a field, but it itself isn't a field. File I'm not sure about.

Edit: on the other hand I'm not sure an entity package would mean anything to users. But taxonomy is more like comment than anything else in that list.

Edit 2: We could move the term reference field into its own module, or it could just be part of the entity reference field module once that's added... ;)

Also, it seems a little odd to have only one subset of modules that are not under "Core."

Needs a re-roll for #28 and #29, looks like.

Nice easy reroll. I'd suggest removing taxonomy from the group for now and opening a revisit-before-release type followup to discuss it further when we have a better idea of what other packages we should consider.

I also pinged @davereid about this issue since he's had concerns about the use of package for sorting modules in contrib in the past.

Removed taxonomy from the Field types package.

How does a "what if" and a "little odd" warrant a won't fix? I like how this idea groups all the modules that make stuff show up in Field UI, a little almost subliminal connecting of the dots. Having Taxonomy in here might actually help some people see that exposing tags happens as a field on your content type for example. I don't understand what #623544: How to categorize a module as developer module is about.

I would agree with classifying this as a duplicate of a core issue for #623544: How to categorize a module as developer module; I was a little ishy on the whole direction of this patch and that seems like the better solution.

Edit: didn't realize the issue was in a different queue. We'd need a core issue for .info tags. I think @davereid has a module for that somewhere.

#1833184: Find a consistent naming scheme for translation-related modules is leaning towards establishing a "Language" or "Multilingual" category in core that would let contrib modules add more modules in that category. Now that there are three interacting modules in core to deal with language-related stuff. There however the thinking was to (a) include all core modules related to language (b) let contribs add more multilingual modules there. This is somewhat different from the goals that this issue had to only group a subset of field modules. However it would set up another group that is not "Core" in core. Just to point out there is likely a need for this categorisation to sub-divide core with the explosion of functionality (and in some cases better functionality separation) we have in Drupal 8.

Re openeing since we should have field-type modules grouped separately on the modules page, even if #1868444: Introduce tags[] in module.info.yml file to categorize modules by provided functionality. does not land before d8.

Also, patch attached.

#43: core-field-types-package-grouping-1255696-43.patch queued for re-testing.

needed reroll

picture.module does not provide a field type, it simply provides a formatter. So if we call the package "Field types" then Picture should not go in there.

#47: core-field-types-package-grouping-1255696-47.patch queued for re-testing.

@tstoeckler you are quite right, have rerolled a new patch which excludes the picture module.

I have started fixing the test cases related to this issue.

Fixing title to be more accurate in that case.

Have updated the test cases which failed, was unable to run the locale test case on my local environment due to reaching max nesting level in php.

Just assigning it to myself

Missed one reference to image module in the LocaleConfigTranslationTest, should be fixed in the latest patch.

So I'm still kind of ambivalent (/cc @alexpott) about this.

On the one hand, the "we shouldn't use package for module tagging/categorization" statement really doesn't work now that multilingual is using its own package anyway. And this probably does improve usability (versus having to search through the whole list).

However, I'm kind of unsure still why we don't just fix #1868444: Introduce tags[] in module.info.yml file to categorize modules by provided functionality.. That change would be an API addition, not a BC break, so it can go in right up to RC1. (It's feature-y, so maintainers might choose to hold the patch until our major/critical counts are better, but the issue isn't RTBC anyway.) The solution in this issue seems too simplistic to me, and here's why:

• @lslinnet has added only actual fielt type modules to the list, which makes sense.
• Conceptually, field types themselves are plugins and not modules. A module should not need to be exclusively about the field type it provides. A module should be able to provide one or more field types along with other functionality. And, indeed, this is already the case with taxonomy. (If we manage to get #1847596: Remove Taxonomy term reference field in favor of Entity reference in that will change, but it's still a completely legitimate usecase for contrib.)
• If I were a site builder, I'd probably be confused as to why taxonomy wasn't in the list. I'd also be confused when a contributed module that provided a field type along with other functionality didn't show up in the list. I might even be confused as to why other field-related modules (that provide widgets, formatters, and the like) didn't show up in the list.
• In short, tags make a bunch more sense than package for categorizing field modules.

Codewise, the patch is fine. Here's what it looks like in the UI.

I also verified that these are the only exclusive field type modules in the list.

The problem with waiting for tags is that we haven't figured out a usable UI for them yet, or a way to make the infinite list of tag possibilities manageable. But, packages, we have now :)

In short, I think we should do both things. I think we should do this - now - because it will make things better - immediately.
*And* I think we should add tags, once we figure out all the details and resolve all the associated problems that go along with them.

Patch still applies cleanly. :)

There's a discussion going on in #2064727: Separate Core modules into separate packages on module page about how to do this generally for all core modules and I think we should wait a bit for its outcome..

As a site builder and parttime coder, this new package is a huge help. My two cents:
- This discussion is very old for a clear UX improvement. Just get it in. It splits off a 30% of the core modules.
- The beste name should be 'Field', since the list contains modules leveraging the Field API. (The 'Options' module does not provide a Field type, only widgets+formatters.)
- The proposal in #2064727 leans towards 'Core Field'. We shouldn't do that. Contrib modules are welcome in the 'Field' package.
- About Taxonomy: I would add it to the Field package, but it is not worth delaying this improvement.
- Tags are fine, I guess. But normally I just scan the modules list using a text search. I'm happy with the Package-way.

BTW. This is another approach: #1371524: Remove packages from modules list and .info files

This now also got more interesting now that comment is a field ... :)

Just a reroll. Web services just go into a separate package too, so why don't we just make a decision here and go ahead with this ?

Because we don't have an agreement yet in the other issue.. ?

I think we can just move ahead.

Ok, seems we have consensus here.

I was initially confused by why e.g. Taxonomy, Image, etc. don't show up here but it looks like this was covered above. Basically, if the module's doing other things and also defining a field, it goes in whatever package makes the most sense. If it only defines a field, it goes here. Feels like we need to capture that somewhere in e.g. the UX guidelines so that module developers know what they're supposed to do here.

So tagging for both a change notice and documentation.

Committed and pushed to 8.x. Thanks!

I am making up a new tag here.

Re #68: Well in fact Image is in there but taxonomy is not, so this is now *hugely* inconsistent in core. :-/

You define huge, as 1? :P

It's a fair point. Why is taxonomy special? We need to be able to very clearly and simply define this, or else we need to roll this patch back.

The current separation makes sense to me. The main thing that image.module does is providing image fields. It also provides image effects and stuff like that, but in most cases, they're used in combination with image fields. You install image.module because you want to add image fields.

taxonomy.module is about categorizing/structuring your content, it just uses the field system to store the assignments. That would be even more obvious if it would use the entity reference field type and not provide it's own. Comment is similar.

This doesn't represent an API change; does it still need a change notice?

Also, for some reason, I get "Access denied" when I try to update/edit this issue. I can access the edit page for other core issues just fine.

@Les Lim: happened to me in another issue. It's because some user that had the proper rights edited the issue summary in a text format that allows more html tags than what we regular users are allowed to. So, now that we try to edit we have no permissions.

Fixed input format

I don't actually think this needs a change record. Also, as far as I know, the "use package only for actual honest-to-goodness packages" recommendation was mostly unwritten and proclaimed in issues, but if not, then we still need a docs update.

We probably *should* have a change record because all the field types in D7 standardized on 'Fields' as the package and will have to change this line in D8 to match what core is doing. Insert irony here about how core went and did something different than a well-established pattern in contrib.

@Dave: I think I captured that in a change notice that I just added in https://drupal.org/node/2186029. Not sure where this needs a docs update though.

@Dave: @Gabor:

If I read that CN correctly, it means the the Fieldgroup module should not go in the "Field type" package, but in a more proper "Fields" (or similar :) package, right? Sorry if this has already been answered but I didn't follow the discussion here.

Triaging as not Novice because it looks like it went into a discussion giving no clear path forward.

This issue was committed in November 2013 (#68) and re-opened for an update to documentation. While this is not a bug the Bugsmash Initiative has found that issues that have been committed and re-opened tend to linger and that making a followup so the issue can be closed improves the chances it will be resolved.

So, restoring the fixed status of this, at the time it was fixed, and opening a new issue to look into the documentation.

The follow up is #3280347: Document package type to use for modules primarily providing field types.