[#46023] - Add Indication of Default Content Field Value In Use
- New
- Medium
- Build: 5.3-dev
- # 46023
Is your feature request related to a problem? Please describe.
This isn't a problem, per se. It is, however, problematic. Content fields can be used in individual articles to input data unique to that article. But what if the field is, for instance, a restaurant menu price that needs to be updated in multiple articles throughout the site? This means it is the field's default value that should be updated, not the individual article's. Once an article's individual content field is set, it will no longer follow changes to the default value of the field definition. There is currently no way to tell when a content field default value has been overridden (set specifically) for a particular article.
Describe the solution you'd like
Either provide a way to disable showing the Content Field Category tab (to avoid inadvertently changing fields in that category per article while making those fields still accessible in the editor) or, at a minimum, indicate in this tab when the default value has been overridden for the particular article. Currently, there is no way to tell.
Additional context
This is particularly important when a site's backend is customized for a proprietor to maintain and they don't know or think of such things. If the site is designed to use the field default values, it should at least be evident when that is not the case. This must apply to ALL users, including Super Users. The current permissions-based method does not prevent Super Users from editing field values.
joomla-cms-bot
- | Labels |
Added:
No Code Attached Yet
|
||
That's interesting since there must be code somewhere that checks whether there is an override value for the field (when the article is loaded into the editor?) and, if not, it uses the default. I'm certainly not familiar with that core code.
If there is no value saved for the field in the article then the default value is presented AND it is saved with the article
That could be problematic for my use case, which wants to use the custom field default value as the source for all instances of that field, always. If the article field value is saved and then the default value changes, that change won't propagate to those articles.
In fact, this is not the behavior I have witnessed. When I don't change the value at the article, the field default presides, even if the article is subsequently modified. I will confirm this later today, but this is why I have removed permission for field editing from all ACLs. I just can't do it for Super Users.
EDIT: Confirmed that editing the article does in fact apply the current default value as the article-specific value. So this is not the solution I need. I will have to write my own plugin, it would seem.
Dang it anyhow.
I just add, when you do not want default value then no need to use default value.
If you need to show "the value example" then you can use placeholder.
I have assumed that what Bruce wants is to set a default value of $10 today but in the future he wants to change the default value to $15 and he is expecting that this will make all future and existing articles with that field to be updated with the new value
Not necessarily. If it's doable, I'd still like to see this change.
Since I needed a solution ASAP, I did write a plugin that was cloned (more or less) from the core LoadModule plugin, specifically the {loadposition} variant, that simply plugs an alphanumeric value in for each tag you define. It supports any number of "pluggable" values. You define pairs of tokens and values with optional descriptions. The token is used like {plug my-token} in an article or custom HTML module. This allows the restaurant owner, in this case, to keep their menu the same, but vary the prices without editing any articles. The generic version of this plugin is called "Value Plugger", but the custom instance for this restaurant I named "Price List" and even created a Quick Icon to get to it quickly from the admin dashboard. So for her case, she puts in something like ${price 4-course-dinner} into her menu page.
I think changing how field default values work to lookup the default values of a field if there is no value set in the article's field instance would have made writing this custom (trivial) plugin unnecessary. And if that change is made, my original feature request to indicate when there is no local value and the default is being used is still valid. Alternatively, adding an option to make a field always use the default value would be good also. This supports using fields in a more globally-applicable way, as in my case.
I think I got my head around your request but unfortunately I cant imagine a scenario where it could be fixed. UNLESS it is possible to use some javascript to get the default value of the field and compare it to the saved value of the field and apply a css class if it matches