Hi

Klas will have the official answer but my answer goes like this:

Fieldx/groups does not need to be 'unlocked'

The only criteria I have for fieldx is whether I want to use the field in a search generic field, you can not use more than one fieldx in a search generic field in a search type...

The only criteria I have for groupx is whether I want to use live values etc as there are limitations.

As far as storage goes there are three options:

Default:

#__content

Joomla table, ie art_title etc

_______

#__cck_store_form_mycontentype

(padlock locked)

Extra db for fields specific to the content type

----------

#__cck_store_item_content 

(padlock unlocked)

fields available to any content type that shares the same object (article, user, usergroup, categroy... etc).

Multiple content types can store/access the same column in a db. I feel like I should use this but never really do....

Hi Bucklash, Thanks for the reply :)

Regarding your statement

Fieldx/groups does not need to be 'unlocked'

Why this page https://www.seblod.com/resources/extensions/plug-ins/group-x-field says that :

All fields must be created with unlocked storage (before you add new field click on lock icon next to the field list)

Is the documentation page up-to-date?

Hi

Yes, sorry, I missed that....

reason a)

So the idea is to not create a table just for a groupx because the whole point of groupx is to reuse it in various content types.

It just seems a waste to create tables only for a groupx field rather than for a content type.

Also, 

reason b) 

if grouox data is stored in 

#_cck_store_item_content

or 

#__cck_store_item_user

etc...

then content types that use the groupx field are storing any data in the correct place for fields available across multiple content types.

Phew, It's not easy to write that coherently....

That make sense?

Hmm really confusing lol. So basically creating field with Locked storage or unlocked storage is just about how we store data in the database?

Anyway, I'm also unable to make a generic search working properly with groupx content. Is this issue related to Locked storage or unlocked storage too? 

Hi

I edited my answer...

but yes, it is to do with how the data gets stored.... If groupx is in it's own table then a search has to potentially search an extra table rather than just the normal three.

Re your last bit about generic search:

No idea... but sounds painful :)

Thanks @bucklash but it's still not really clear for me. So in your opinion, in what conditions we should create unlocked (storage) field or locked field?

Hi

I think it comes down to your preference. 

Groupx is shared between content types so that should go in the 'unlocked' table. 

Fieldx isn't necessarily shared between content types so can go in either .

Anything else is subjective. 

If you had an automobile site, created bike and car content types then the unlocked fields could be:

qty_'wheels', 'max_speed', '0-60' 

and fields specific to bikes would be locked and fields specific to car would be locked.  

Nice work, webchun!

Hi,

you figured out this basically correct: groupX fields need to be created with unlocked storage as otherwise they are not available in searches where you need to use child fields which are from different content type. And storage must be set exactly as described in the manual, storage None is incorrect.

For fieldX you don't need unlocked storage as it is used in the same conten type.

Hi,

FieldX and GroupX with false information have been unpublished.

New manual items are on these topics are in progress.

Unlock and locked have no matter about GroupX or FieldX. A GroupX field is not required to be a "shared" field cross content types.

Unlock is about to create "common" / "shared" fields between content types, yes, these fields will stored into the SEBLOD "common" table.

Field(s) used into GroupX or FieldX don't require a storage because the storage used is the one of the GroupX or FieldX itself.

Thanks.

Hi @bes thank for the clarification, but

 Field(s) used into GroupX or FieldX don't require a storage because the storage used is the one of the GroupX or FieldX itself. 

I've done this when starting this thread but the generic search doesn't work. Once I recreate the child fields with unlocked pad lock then the generic search worked properly (searching through the groupX's child fields). Am I missed something?

You need to insert into your search type the child field then click on button 3 (match) then on + button and select the "collection" field which is the groupX or FieldX.

That's exactly what I did before. 

Anyway, I have tested it again and still unable to make the generic search works without unlocked padlock + no storage. So maybe it's a bug?