User tests: Successful: Unsuccessful:
last edit of this description 2017-01-16
Please have a look to this pr (#13182) first. It has a solution for the same issue. But for the case that there is no agreement my solution would help solving the issue with the not unique alias.
Pull Request for Issue # .
#13335
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";
ALTER TABLE #__fields
CHANGE alias
name
VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '';
(or make new installation of Joomla after applying this path).
Apply this patch
Create and edit Custom fields in the frontend and in the backend
No
Status | New | ⇒ | Pending |
Category | ⇒ | SQL Administration com_admin Postgresql com_fields Language & Strings Front End com_users Installation Layout Plugins |
So whats then the gain here at all, when you have a read only field with some cryptic id, IMO why not use then the id directly as suggested in #13576? For me must the form name be changeable, if it's not then we build another kind of id field.
The name stays even when you have changed the title so the admin will not be able to change the name as well? We will have the situation then that the title is not inline anymore with the name? I see here a big problem as well.
The gain is:
If i want to copy i custom layout to another web-site i will not have to remap the ids.
You have to, because of the unique id which is always generated when the field is created. When we have a name the admin can define, then you can set up a field on the other site with the same name and copy the layout.
Using uniqid()
certainly doesn't make sense when we already have an unique ID that could be used.
Imho, we either use the ID as identifier like in my other PR or we rename the field to "name" and move it to the regular options (not after the title). During save we check that it is unique, if empty fall back to the ID. That would be the simplest approach
But I still don't see why that needs to be configurable. I doubt you're going to copy layouts from one site to another 1:1. You will have to adjust them anyway and it would be easy to adjust that ID.
Also, it is much more likely that the site admin will break that layout/design if it is a configurable field.
@laoneo
For me the main problem is the alias, and that fields with the same alias only shown ones. So I thought the layout override problem not to the end.
You need a special field that you can manipulate for die override. Why is it not possible to use the title field for this override?
Title |
|
||||||
Labels |
Added:
?
?
|
Category | SQL Administration com_admin Postgresql com_fields Language & Strings Front End com_users Installation Layout Plugins | ⇒ | SQL Administration com_admin Postgresql com_fields Language & Strings Front End com_users Installation Plugins |
I changed the name from unique name to name.
The position of the field is now within the options.
I check if the name is unique.
The MSSQL files nees to be adapted as well.
Category | SQL Administration com_admin Postgresql com_fields Language & Strings Front End com_users Installation Plugins | ⇒ | SQL Administration com_admin Postgresql MS SQL com_fields Language & Strings Front End com_users Installation Plugins |
This was my first conflict editing. I hope everything is correct :)
I like the PR very much and it is done the way it needs to be now. You need to change the description and title of this pr as it behaves now differently with the changes you made in the last few commits.
I'v tested it and it works as expected. There is now a missing language string
Fater this one gets fixed, I can mark the test as successful. Good work!
I'm so sorry. I had forgotten this text when renaming.
Thanks for the patience with me and the tips :)
Title |
|
Title |
|
I have tested this item
No need to apologize, we need people who are willing to help.
It would be good to change the pr description as well as it does now something different.
@franz-wohlkoenig found another issue with allowing to set the name of the field: #13621 (comment)
Basically you can overwrite existing fields of the original form when you name it the same as the existing field. At least as long as we store the fields in the "params" group of the form which may be used already by the original form.
Yep, that would solve the overwrite issue. But it's not about being a compromise, that one needs to go in anyway
Please solve the merge conflicts, that we can get this one in.
Thanks
Can you fix the conflicts please?
I just did it.
Do I have to do something because of the not successful test "continuous-integration/appveyor/pr — AppVeyor build failed" ?
No, almost any pr fails at the moment.
At some points I am not sure what I have to delete and what is correct. I think it would be easier for me to create a new pr. Should i do this?
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-03-12 21:33:28 |
Closed_By | ⇒ | astridx |
Have planed to do a similar pr over the weekend, but you was faster. I would rename it to "name" only. As most joomla components do a check on store if the alias is already set (for example here ), I would do the same with fields as well. Then you can remove the confusing uniqid from the name, it will look then much cleaner. Read only is then not necessary anymore as we allow the user to change the name then.