[4.x] Clarify default field instructions/helper-text #8808
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This tiny tweak originated in a Discord chat with Erin & Sam. Currently, the
fields_default_instructions
—which is used for the helper text belowDefault Value
on field definitions—reads as:This PR tries to put a lil more meat on dem bones. 🍖 Proposing a change to:
This is definitely a subjective thing, so won't hurt my feelings if you all decide to reject or edit...but this has bit me a couple of times, with how the setting actually works. Copying in a bit of that Discord convo linked above, for more context:
I tend to think of default as more of a UI consideration—ie, a default value to save the user some time in the GUI, by pre-populating the field at time of creation, with a commonly-used default. And what's actually happening, I would maybe consider more of a fallback that's typically handled via code—ie, a stand-in value, in the event that the user hasn't provided a value and the system needs one, for whatever reason.
The way Statamic actually works is kind of an interesting hybrid, IMHO...it's similar to the former, as it's purely a front-end thing (at least as far as I can tell...nothing seems to be happening server-side to "force" that default into place). But it has the persistence of the latter, as it always attempts to "re-insert" the default, including on edit forms.
So as an example, say a user goes to create a new entry and clears the default value from the field. This saves as expected, with a null value. But if they return to edit that previously-saved entry—ie, any one that has a blank value in the field—the default value will be "quietly" re-entered via the CP GUI. And they might not realize that, causing confusion and/or problems when they unknowingly save a value into that field.
Again, totally realize this is mostly subjective semantics. TBH, would be nice to have both a
default
and afallback
to serve both purposes. But no biggie—just thought it might be beneficial for all, to have a slightly more descriptive rundown on how that works under the hood.