Move all field functionality into a new, separate [type]_field.module.
E.g., so there is a file.module and a file_field.module.
core/modules/fields/file_field
core/modules/fields/image_field
core/modules/fields/number_field
core/modules/fields/options_field
core/modules/fields/text_field
- or alternatively - use a "field_" prefix instead of suffix and use no grouping folder at all; e.g.:
core/modules/field
core/modules/field_ui
core/modules/field_file
core/modules/field_image
core/modules/field_number
core/modules/field_options
core/modules/field_text
core/modules/field/lib/Drupal/field/Plugin/FieldType/File
core/modules/field/lib/Drupal/field/Plugin/FieldType/Image
core/modules/field/lib/Drupal/field/Plugin/FieldType/Number
core/modules/field/lib/Drupal/field/Plugin/FieldType/Options
core/modules/field/lib/Drupal/field/Plugin/FieldType/Text
Comments
Comment #1
berdirFor completeness, the *field (without _) module names have been discussed/suggested before as well, not exactly sure which is better. Also, did you leave out image.module for a specific reason or just forgot about it? :)
Comment #1.0
sunUpdated issue summary.
Comment #2
tim.plunkettI'm sorry, but this is not an issue that should count toward thresholds. The problems outlined above seem to be for architectural purity's sake only.
Note that I don't disagree with this idea.
Comment #3
sunRelated: #1862656: Move field type modules out of Field API module
Comment #3.0
sunUpdated issue summary.
Comment #4
andypostseems mostly done
Comment #5
klonosComment #6
berdirIt's not done at all, but I guess it also not going to happen anymore in 8.x?
Comment #7
sunIsn't it a much better question why we still have separate modules to provide field types?
From the issue summary:
In fact, the majority of these .module files are almost empty now:
They're just providing
Only the following field modules are more complex:
By moving the simple field type plugins directly into Field module, we'd
Doing that appears to be a really trivial patch, and I'm not able to see any problems or caveats?
Thoughts?
Comment #8
yched commentedThe goal of #2150511: [meta] Deduplicate the set of available field types is to merge the set of field types used by "base fields" and configurable fields. De facto, this would move most "basic" field types into Core/Field.
This issue over there is a much more valuable goal IMO, and could really use some hands :-)
Comment #9
sun#2191285: Text module is not required, but is marked as required just made the last field type module not required anymore.
As a consequence, we should now be able to do #2199637: Replace "required" flag of Field module with proper dependencies
That said, the same question as in #7 came up once more — merging the trivial field type plugins into Field module itself would simplify a lot of things, while still retaining a module as a provider for hooks, CMI, etc.pp. (which is an aspect that a move into Drupal/Core/Field would have to additionally solve)
And regardless of where the field types are moved, plenty of tests will need to be adjusted to no longer enable the corresponding field type modules in their
setUp().Thus, wouldn't it make sense to attempt a move into Field module as an interim step?
Comment #10
yched commentedWorks for me.
Only worry (which would be true with a move to Drupal/Core/Field too) is the discovery folders for field types, widgets and formatters each becoming a large flat unorganised list of classes, while the current "module by field type" split keeps "field type, widget & formatter classes for type A" in one place, "field type, widget & formatter classes for type B" in another place.
There's probably not much to do about that though, other that possibly, if need be, renaming a couple classes for consistency & ease of human navigability.
Comment #11
sunCreated #2202925: Move simple field types into Core/Field
Comment #25
smustgrave commentedThank you for sharing your idea for improving Drupal.
We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #26
smustgrave commentedSince there's been no follow up in 3 months going to close out, but this can always be re-opened.
Thanks all!
, think I've also heard a few people talk about consolidating them into sub-modules?