You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since I stumbled over this once again today in a repository, I got an idea about how this could be avoided:
Issue
There are a couple of "reserved" names which interfere with standard Statamic behavior. For example, when creating a text field for a URL and giving id a handle of "link", this can result in unwanted things that sometimes take some time to debug - in this case:
{{ link :id="id" }}
results in an error since the id modifier is not present on a string because the field might overwrite the built in link tag.
Idea
In my opinion, it would be a huge help to use the list of reserved words that already exists which might be additionally auto-populated by adding all built-in tag handles etc. for an internal check list. This list could then be used when naming a field to quickly check if this would conflict with some Statamic internal name. If there was a warning somewhere on or below the field, this would be a great quality of life improvement, and would maybe make sense there directly in the UI.
--
What do you think? And would there be a sensible place for this maybe in the revamped v6 interface? :)🖖
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Hi there. :)
Since I stumbled over this once again today in a repository, I got an idea about how this could be avoided:
Issue
There are a couple of "reserved" names which interfere with standard Statamic behavior. For example, when creating a text field for a URL and giving id a handle of "link", this can result in unwanted things that sometimes take some time to debug - in this case:
{{ link :id="id" }}results in an error since the
idmodifier is not present on a string because the field might overwrite the built inlinktag.Idea
In my opinion, it would be a huge help to use the list of reserved words that already exists which might be additionally auto-populated by adding all built-in tag handles etc. for an internal check list. This list could then be used when naming a field to quickly check if this would conflict with some Statamic internal name. If there was a warning somewhere on or below the field, this would be a great quality of life improvement, and would maybe make sense there directly in the UI.
--
What do you think? And would there be a sensible place for this maybe in the revamped v6 interface? :)🖖
Beta Was this translation helpful? Give feedback.
All reactions