Hello,
it appears that SEBLOD requires the name of a field added to a Content-Type to be globally unique, even if the field is locked to the Content-Type.
However, when I create a copy of a Content-Type using the "batch" copy feature, all fields in the new Content-Type have the same name as in the original. In fact, they appear to be the same (i.e., identical) fields, since (a) they are listed only once in the field manager, and (b) changing one of these fields in one Content-Type simultaneously affects its twin in the other.
Is this the expected behavior? If so, then why is it not possible to reuse a field locked to one Content-Type in another while constructing the Content-Type manually? That would be a very useful feature, since I have several not-so-simple field definitions, e.g, checkboxes with many options that have always been tedious to manually define anew in another Content-Type after I needed a field previously created in an Content-Type again in another one.
In any case, why does a field with locked storage need to have a globally unique name? Is this expected behavior? It is somewhat awkward having to reinvent new names for conceptually the same thing like "headline" or "name" for every new Content-Type. In in addition to that, it also makes code-reuse in a set of custom templates more difficult.
Did I miss something?
Best regards
Stefan
Hi Stefan
it appears that SEBLOD requires the name of a field added to a Content-Type to be globally unique, even if the field is locked to the Content-Type.
Totally true.
Each field must have a unique name to store in the database,
However, when I create a copy of a Content-Type using the "batch" copy feature, all fields in the new Content-Type have the same name as in the original. In fact, they appear to be the same (i.e., identical) fields, since (a) they are listed only once in the field manager, and (b) changing one of these fields in one Content-Type simultaneously affects its twin in the other.
You have duplicated a content type so now you have two, but the fields have not been duplicated.
Is this the expected behavior? If so, then why is it not possible to reuse a field locked to one Content-Type in another while constructing the Content-Type manually?
That might be worth putting on github if it is the case i.e. fields locked in a content type (get stored in #__cck_store_form_somecontenttype) do not show in batched content type.
That would be a very useful feature, since I have several not-so-simple field definitions, e.g, checkboxes with many options that have always been tedious to manually define anew in another Content-Type after I needed a field previously created in an Content-Type again in another one
For long select simples I would copy and paste the fields select list from the db (#__cck_core_fields.some_field) to the new field, or have the fields storage available to all i.e not locked to a content type.
In any case, why does a field with locked storage need to have a globally unique name? Is this expected behavior? It is somewhat awkward having to reinvent new names for conceptually the same thing like "headline" or "name" for every new Content-Type. In in addition to that, it also makes code-reuse in a set of custom templates more difficult.
Name conventions for your site’s fields is a funny one. Gotta come up with a naming system and stick with it. I did.
Did I miss something?
Seems like it :)
You have a lot of emphasis on locked fields, do you understand storage options or are they a bit of a mystery?
Whether a field is locked or not depends on your design and approach....
Best regards
Jon