Articles, and some other parts of the system, have a technical need for unique aliases (part of it comes from routing).

If there isn't a technical need for unique aliases, I'm not so sure we should enforce they be so. What would be the use case(s) which dictate that fields have unique aliases and how should the level of uniqueness be determined (remember articles under different categories should be able to have the same alias, so it can't be a global thing).

If they end up in the same form, they have to be unique since the alias is used as identifier (both field name and ID).
#13576 tries to solve that part.
Personally I would have removed the alias and used the field ID as identifier (which is unique by design) but people wanted the name to be configurable...

I think that the field is not shown anymore in the article because i created the others with the same alias... Will test the PR thanks @Bakual

Personally I would have removed the alias and used the field ID as identifier (which is unique by design) but people wanted the name to be configurable...

:eyeroll:

Well one of the people is me. It´s more userfriendly to call a field in an override by it´s alias. Otherwise i have to look up the ID all the time and comment every output...

Honestly the thing that irks me about it is it's creating a superficial requirement for little to no gain. Yes, a word alias is probably easier to remember than an ID mapping (which is why we have the option to turn on a URL schema that's easier to remember index.php?option=com_content&view=article&id=1&Itemid=101), but by that argument all unique identifiers should then be aliases or some other human friendly value and the primary keys just be dropped (it's not like Joomla actually uses keys in the database to begin with...).

I'm just not sold on the gain here and at this late in what's supposed to be the beta phase you're asking for a borderline major B/C break in the data model. I know there hasn't been a stable release yet, but this isn't the point in a release cycle that we should be discussing/testing major data modeling changes.

So if i create two fields with the same alias and therefore they are not shown in the fieldset - it´s not a bug from your perspective then? Right?

Because it isn't a unique identifier, right now it can't be relied on to return an expected value. So the bugs in the system as it is now relates to trying to use the alias as a lookup (database query, key in an array, etc.) and since it can produce a non-unique result it throws off everything else. A unique value has to be used, be it an already existing value or changing the data model to enforce uniqueness on alias, which will require discussing how uniqueness is calculated. And to me that's making a rather big change really close to release.

The database itself uses the id as unique identifier. It is only in forms where the alias is used for the name and id of the formfield.
Funny enough, when the field is rendered outside a form, the alias isn't used at all.

Sorry to bother you two, but i feel like i have to speak for some "endusers". Please don´t throw away the alias. Isn´t it just possible to add always the Field-id to the alias at automatic creation? And if alias exist to throw out a warning? Please?

Why don't we make it similar to https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_content/models/article.php#L559-L588
Also make its hidden and auto populated, less inputs === better UX

Isn´t it just possible to add always the Field-id to the alias at automatic creation? And if alias exist to throw out a warning? Please?

You don't want to add the id to the alias. If you do that you could as well just use the id directly as the alias becomes useless.
The other PR I referenced earlier will throw a warning and refuse to save the field if the alias isn't unique. It will not automatically try to change it.

Look... When i create an override for a view and want to insert customfields, i can map the alias and use the fields later like that:

$customFields['companyname']->value;

instead of

$this->item->fields[3];

even if it would be
$customFields['companyname-3']->value;
it would be ok...

it makes my live as a frontend-dev way easier as i don´t have to comment each output to remember which field i output there. Even if the id is appended to the alias i have no problem. Most important is that i can use a own value. I see this issue aktually also coming with the editor plugin {field 3} is just completely meaningless. {field companyname-3} would be a least a better way for the ENDcustomer and the author to understand what he is doing.

I know you are all poweruser and don´t need any fluff like this, but i really ask you for at least try to view it from my perspective.

A warning-message would be also ok for me, but please don´t remove it.

I have closed my PR to remove it long ago. That's not a topic anymore for me ☺

I don't know how all the relations work in fields, but at least using the existing data model in com_content (articles and categories) as an example, here's why you can't JUST use alias.

I have two articles in two different categories that result in an alias of "f-a-q" (I've actually done this on a site). So if I were to do something like JTable::getInstance('Content')->load(array('alias' => 'f-a-q')); I would have a non-unique result, all articles with the "f-a-q" alias would be returned. The only way to make sure I get the one item I expect would be to also include the category in my lookup (array('alias' => 'f-a-q', 'catid' => 10)).

Say you create two fields for articles with an alias of "name". One is in a field group, one isn't, both are available to all categories. Not a logical configuration, but should be allowable (I don't see the logic behind enforcing unique field aliases globally, so similar to how you can have the same alias in multiple category/menu paths as long as it is a fully unique path (basically the alias is unique at a level in the tree), "name" and "group/name" would be acceptable paths and both have the "name" alias). So when you build your $customFields array with the keys being aliases, which "name" field is actually going to be used here, the one not in the group or the one in the group? If you do {field name} in a content item, which field gets loaded?

One of my extensions uses that {item id} syntax for its plugin. This syntax was in use long before I added many features to the extension, including what equates to categories and alias support. If I would have rewritten that plugin to support {item alias} syntax, and the user had multiple items with the same alias, how would they have specified the actual item they wanted without making the thing more complex (i.e. {item alias category})?

Alias on its own would work if it were enforced in a context that you can only have one field with a given alias (so you have one "name" field for all the things, even if you're actually creating two or three completely separate forms for different groups/contexts that all have a name field and they would all have to have different aliases). I don't think that's user friendly given how aliases are handled throughout the application (it'd be like us having a limitation that says you can only have one category in the entire com_content category tree with an alias of "updates", regardless of how deep it is in the tree).

So no, alias on its own right now is not a reliable value that can be used. Yes I get where you're coming from with this request, but realize the system implications here. This is not something that is done with a simple patch, and as I've said a couple of times now this is a major (and B/C breaking) change to be made to fields very close to the release. Addressing it would mandate delaying the release, and to me this one item does not warrant that.

Thank you for your explanation Michael. Ok last try from my side to rescue this :-)

What about if the fieldname itself takes the former function in my code in combination with the id?

1. The "Alias" would be removed from the field-creation-form and is not of interest for the editor himself
2. The field has an internal alias which is a combination of Fieldname and Fieldid and the frontenddev is superhappy

?

As long as that alias is displayed somehow, it could work. Generating and using them isn't a major issue, it's just making sure that ultimately if you're using it you're certain you get what you're expecting, and that part is the major issue ?

i ran just in another argument pro having at least a hidden alias. It is used also for the #id container around the field. Which is important to add js functions to the field.

Just want to second eliza's argumentation. Its something i argued in the early days of dpfields. If one has developed an alternate layout / view for a content item. One would not want to reference the fields by an Id as the id's on a next site probably are not the same. Using an alias to reference the field makes it reusable.

Again, at this point nobody wants to remove the alias and replace it with the field ID. I have closed that PR long ago.
There is a PR open which will enforce uniqueness for the alias (and rename it to "name" which is more meaningful), which is needed because it creates issues otherwise.
It doesn't need a "hidden alias" and adding the ID to the alias would make the layout not reusable anymore, which was the main reason to have an alias to begin with.

All we need is having unique alias/name because it is used as formfield name (jform[params][alias]) and ID of the field (jform_params_alias). So please test that PR and get it solved.

I'm closing this issue since there is a PR which deals with it.