Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Problem/Motivation
If there is some use case or justification for the "field_" prefix on fields created through the UI, please let me know. Otherwise, it seems unnecessary. Fields can be created programmatically without the prefix and they, of course, work fine.
This could be ported to 7.x as well.
Proposed resolution
Remove the "field_" prefix in field_ui.admin.inc.
Remaining tasks
Tests should continue to work; no documentation.
User interface changes
None.
API changes
None.
Comment | File | Size | Author |
---|---|---|---|
#29 | 1393094-remove-field-prefix-D7_1.patch | 2.4 KB | solotandem |
#22 | field-ui-prefix-settings.patch | 1.04 KB | tstoeckler |
#19 | 1393094-19.patch | 5.69 KB | swentel |
#19 | interdiff.txt | 604 bytes | swentel |
#16 | 1393094-16.patch | 5.71 KB | swentel |
Comments
Comment #1
solotandem CreditAttribution: solotandem commentedAttached patches implement the proposed resolution for Drupal 8 and 7.
Comment #3
joachim CreditAttribution: joachim commented> If there is some use case or justification for the "field_" prefix on fields created through the UI, please let me know.
My assumption (and it's only that) is that this guarantees against clashing with any fields that are defined by modules.
Also, it means you can easy tell which ones are user-created.
Comment #4
boombatower CreditAttribution: boombatower commentedYes, that was my guess to. Our use-case is that people create fields in UI and export using features and such to become "coded" fields and given that the field length is restricted in length field_ is rather wasteful.
Patches are backwards (d7 = d8, etc).
Comment #5
solotandem CreditAttribution: solotandem commentedOops. I named the patch files opposite their core versions.
Comment #7
Barry_Fisher CreditAttribution: Barry_Fisher commentedAs a sidenote, I've created a D7 module that removes the
field_
prefix from being added in the Field UI. Basically it overrides the validate functionality and alters the field ui overview form accordingly. May be useful to anyone landing on this post as I did and needed a quick fix workaround.http://drupal.org/project/field_name_prefix_remove
Comment #8
swentel CreditAttribution: swentel commentedSo how about we make this configurable with our shiny new configuration system in core ?
No UI to configure this, but it's easy to move this into staging, change it and then import - or use 'drush cedit field_ui.settings' to change to what you like.
Comment #9
aspilicious CreditAttribution: aspilicious commentedI like it, but we need a test to verify changing a prefix actually works :)
Comment #10
swentel CreditAttribution: swentel commentedI guess yeah, here it is :)
Comment #11
aspilicious CreditAttribution: aspilicious commentedYihaa!
Comment #12
alexpottHmmm... I'm not sure about this change basically because changing this after you create a field will totally break your site. Either fields created by the field ui have field_ not... but making this configurable seems open cans of worms. Personally I think all field names should be namespaced by the module that creates them... so actually I'm arguing that we want
field_
Comment #13
aspilicious CreditAttribution: aspilicious commentedWhy would that break existing fields?
Comment #14
stijndm CreditAttribution: stijndm commentedGreat stuff. Good idea to have it as a hidden setting.
@alexpott I'm not sure how this will break existing fields as this settings is only used when a new field is created.
As for the namespacing issue, I feel there is enough argument to make this configurable. People working on distributions or features might want to namespace their fields according to the content type or feature they are building. Having field_ automatically prefixed eats into the character limit making it more difficult to have proper field naming, sometimes resulting in the use of arbitrary and meaningless abbreviations.
The average Drupal user/configurator will never know of the existence of this setting keeping all their fields namespaced within the field module. While power users have some extra flexibility.
Comment #15
swentel CreditAttribution: swentel commented@alexpott This won't break existing fields in any way. This is just the prefix when you are creating a new field, after that nothing can go wrong anymore.
I've talked this through with yched at DrupalCon and he was ok with it, also since it's a hidden setting. We'll document it of course, but there will be no UI in core that allows you to change this. This is a power user configuration option, which people have been wanting for a while already anyway.
Setting to RTBC for now.
Comment #16
swentel CreditAttribution: swentel commentedNeeded a reroll.
Comment #17
alexpottThis looks weird... does the field_prefix variable exist in Drupal 7? Perhaps you want to use
update_7_to_8_install_default_config()
?Comment #18
swentel CreditAttribution: swentel commentedAh, no it doesn't exist, good to know :)
Comment #19
swentel CreditAttribution: swentel commentedChanged the update function.
Comment #20
aspilicious CreditAttribution: aspilicious commentedOk another try :). Thnx alex!
Comment #21
alexpottCommitted 097303e and pushed to 8.x. Thanks!
Comment #22
tstoecklerCan we add a little snippet to default.settings.php that informs people about this? I'm not entirely sure if we're 100% consistent with that currently but I do think it is a common pattern to do this, and one I think makes sense.
If someone disagrees or in general thinks this should be a separate issue, no problem, I just thought this is pretty unproblematic.
Comment #23
swentel CreditAttribution: swentel commentedMakes sense to me.
Comment #24
alexpottThis should have the default value to be consistent with the other sections...
Also I'm not sure this is really required as in reality we should be encouraging people to change this in their config... if we want to only manage this here then it should move out of CMI into Settings.
Comment #25
tstoecklerRe #24: That's true, but the question then is, how will people know about this at all? I don't think when people will someday download Drupal 8.0 that they will open up every single config file to see what they can configure.
Comment #26
swentel CreditAttribution: swentel commentedWe could create a change notice I guess ? That's fine for me as well. This is not settings indeed.
Maybe we can include this in the tour integration for Field UI ? #1960824: Write tour integration for Field UI module
Comment #27
swentel CreditAttribution: swentel commentedCreated a change notice, that's good enough for me imo.
See https://drupal.org/node/2060489
Comment #29
solotandem CreditAttribution: solotandem commentedFor those that want to see this back ported to D7, attached is a rerolled patch that works with recent releases of D7, including 7.28.
Not changing the version; if there is traction to back port, then this can be done or a new issue created and referenced here.
Comment #30
dstorozhukHello, that is weird, but settings the
$conf['field_ui.settings']['field_prefix'] = 'f_';
doesn't make any effect.I also tried to change the 'field_prefix' in
path/to/my/sync/field_ui.settings.yml
and still have no luck.Does somebody has the same issue.
PS. other settings could be controlled fine from settings.php or changing configs in
path/to/my/sync/
.Comment #31
markconroy CreditAttribution: markconroy at Annertech for LocalGov Drupal commented@dstorozhuk (sorry, I know you probably have this fixed by now, but just for others who come here)
You need to use
$config['field_ui.settings']['field_prefix'] = 'f_'
not
$conf['field_ui.settings']['field_prefix'] = 'f_'
.