Hi! We've been using the project config feature for a while now, and with the changes to split out config to separated files we're seeing a lot of improvements in merge conflict resolutions etc.
However, as we work with multiple developers on a single project, sometimes someone will check out an upstream branch, and forget to properly apply all the upstream project config changes, or just flat-out rebuild the config from a divergent local DB before applying the newer changes.
Anyway, sometimes this leads to some mishaps in fields disappearing from entry types where they were just added for example. We use code reviews via pull requests, but it's really hard to read the associations between different entities.
A good example would be a diff for this entry type config file for example:
I can't really see what's been added / changes here unless I manually go into the config/fields folder and check for the UUID.
A simple change which would be REALLY helpful would be to add a YAML comment wheever a UUID is referenced for another config file.
For example;
fieldLayouts:
a10f84d1-1f05-4616-9de0-c5e35e7be121:
tabs:
-
elements:
-
autocapitalize: true
autocomplete: false
autocorrect: true
class: null
disabled: false
id: null
instructions: ''
label: Bedrijfsnaam
max: null
min: null
name: null
orientation: null
placeholder: null
readonly: false
requirable: false
size: null
step: null
tip: null
title: null
type: craft\fieldlayoutelements\EntryTitleField
warning: null
width: 100
-
fieldUid: 74c655a8-9bd5-41db-9402-f58841eed0ff # descriptionField
instructions: null
label: null
required: false
tip: null
type: craft\fieldlayoutelements\CustomField
warning: null
width: 100
Would perhaps also be helpful for other areas:
Graphql scopes
isPublic: false
name: Frontend
scope:
- 'sections.b24278b3-77ef-490f-8d5e-10d2dc43a481:read' # sections.article.read
Section site settings
siteSettings:
0aedc5e6-b00f-4a0c-816a-fd98100cf2da: # myPrimarySiteEN
I'm probably missing a few areas here but you get the idea :)
I agree it would be helpful, but it probably won't happen, as it's not possible to do with the Symfony Yaml component.
Related discussion here: https://github.com/symfony/symfony/issues/22516
Oh I really like this idea as well.
What if instead of saving the handles as comments, we just prepend them to the UIDs, the same way we’ve done with the YAML file names?
That's a shame about the lack of support in symfony, doesn't look like it's
going to be added anytime soon either.
Perhaps the handles could be added to the yaml into the exported objects as
normal attributes, and simply only be used on write and not on read, rather
than having to combine and split the two into a single attribute on both
write and read (also sidesteps any backwards compatibility issues)
On Wed, 17 Feb 2021, 21:32 Brandon Kelly, notifications@github.com wrote:
Oh I really like this idea as well.
What if instead of saving the handles as comments, we just prepend them to
the UIDs, the same way we’ve done with the YAML file names?[image: The contents of my config/project/fields/ folder]
https://user-images.githubusercontent.com/47792/108264179-1200d700-711c-11eb-9455-9518833e5ba9.png—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/craftcms/cms/issues/7584#issuecomment-780834686, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AADF5CAM6OPWECRAXT6X4WTS7QRVHANCNFSM4XX72QGQ
.
Yeah – that’s what I’m suggesting. The field handles in those file names are completely ignored on read.
Yeah maybe I misunderstood, but I thought you meant changing the project config from this:
fieldUid: 74c655a8-9bd5-41db-9402-f58841eed0ff
to
fieldUid: descriptionField--74c655a8-9bd5-41db-9402-f58841eed0ff
While I meant
fieldHandle: descriptionField
fieldUid: 74c655a8-9bd5-41db-9402-f58841eed0ff
Anyway, its probably a minor difference ;)
Oh gotcha. Yes I’m suggesting the former.
We just talked this over and have an idea for how we could possibly get the original comments idea to work, despite the YAML library not supporting it.
Just added this for the next Craft 3.6 release!
Craft 3.6.8 is out now with this change. Thanks for the great suggestion, @FreekVR!
Any chance this was undone in the 3.6.11.x branches? I touched a field and 600 files were updated removing those yaml comments!
Most helpful comment
Just added this for the next Craft 3.6 release!

