Hi

Are the quotes necessary?

item_class = $uri->getValue('type')

Instead of

item_class = "$uri->getValue('type')"

yes, otherwise it throws an SQL error like unknown column (ex. the query becomes "item_class = product_class" and product class is the name of the content type so it must be quoted...)

that's very weird....

Hi

That does not sound right then...

What are all your settings then?

This works for me, no quotes needed anywhere

Table = #__content
Options Name = title
Options Value = id
Order By = id

On this one, storage is none because I am using FieldX....

Hi

Or maybe it should be:

"item_class" = $uri->getValue('type')<br>

Also, this works for me:

Thanks Bucklash, very kind of you, but I am not seeing it working here unfortunately and I cannot see an explanation if not a hidden bug in some usage of the field.....

The full SQL in my select dynamic that does not work in saving is this one

The same query (except the repetition AS text) works perfectly in another field as live value with SQL plugin retrieving an id, so the syntax is correct in my opinion.

And if I replace the last part

"$uri->getValue('type')"

with its expected value ("lpt_product_photo_camera"), the field magically saves correctly. Note that if I delete the surrounding " (so writing items_class = $uri...), I get the SQL error

So it the type IS retrieved from the URI!

It does seem that uri->getValue( 'type') in select dynamic has a problem in saving (no problem in just displaying correct value and no problem in retrieving the id from URI)....

Hi Guise

Damn... sorry...

Have you tried a really simple query, just to test the storage?

nope, even with very simple select dynamic, construction form, where condition = 

it displays but does not save the value. Seems as retrieving the type from the URL causes problem in storing values.... Klas, can you reproduce it?

cheers

Giuse

I would say the problem is in $uri->getValue - there is no such thing. With uri you need to use getString or any other JInput shortcut that mathes your variably type as described in JInput methods https://api.joomla.org/cms-3/classes/JInput.html

ok, but also with $uri->get('type'), values are not saved in select dynamic. And if I put as WHERE condition

I get the SQL error

it means that the value IS retrieved, but it is not saved. Also $uri->getString('type') does not work.

You need to quote your value too, standard for quoting values is single tick, so 

name = '$uri->getCmd('type')'

yes, sorry, I mistyped, but it does not work unfortunately. The test is simple

QUERY: construction

TABLE: #__cck_core_types

WHERE: name = '$uri->get('type')'

OPTIONS NAME: name

OPTIONS VALUE: id

I just tested this and it saves correctly. I presume your problem is that you don't have type variable in url in edit or content and since query can't work.

Hi Klas, thanks for your reply. The URL in edit is

so the type variabile is present and infact the dropdown menu is built correctly with option name "test". Only saving has no effect.

I just created a new content type "test" based on article with a single additional select dynamic field configured as reported above. Saving has no effect here.. did you tested this scenario?

Thanks again very much

I checked in database and it get's saved fine in my case, I just added optioncat=com_content to menu variables to get categories from com_content in query. In select dynamic I used extension = '$uri->get('optioncat')'

Perhaps stupid question - do you by any chance have storage set to None or had this setting before (it does not get correctly changed when you change it after creation)? So check database if column is there and value gets actually saved.

hI Klas, I am afraid your test is slightly different. I made countless additional tests finding very weird behavior of this inside select. I recap here:

• define a new content type "test". This will add a new row in #__cck_core_types table with field name filled with "test".
• add just a select dynamic field named "xxx" like this
  
  • TABLE: #__cck_core_types
  • WHERE: name LIKE '$uri->get('type')'
  • OPTION NAME = OPTION VALUE = name
  • storage as default (standard/article)
• create an item of test in backend
  • the url will be http://.../www/administrator/index.php?option=com_cck&view=form&type=test&return_o=content
  • for field xxx you will get a dropdown list with a single item of "test" (so far good)
  • try to save: the item is saved but the column "xxx" remains empty.

Additional hints:

• I added a BeforeStore field to inspect things

and the result is very interesting:

so the field is filled as a form, but its value is not prepared for being stored!

• Now, iIf I change the WHERE condition adding a %
  • name LIKE '%$uri->get('type')'

  then... it saves! And infact with the beforeStore I get

With these additional tests, can you guess where is the problem?

thanks and hoping to see the light on this :)

I kept on testing (I'm getting lost....) and really there must be something very weird with using Seblod type names in select dynamic.

The test case above should be enough to replicate the problem (but it must be done exactly like that). In the meantime I made another scenario, with a select dynamic cascade on 2 stages where first stage select the Seblod type name and the second select an item in two joined tables using the Seblod type name as [parent]: well, everything works in visualization (the dropdown menu is correctly built), but the second field does NOT save into DB. If I replace [parent] with the actual value (lpt_product_photo_camera), it saves! 

It cannot be a problem in storage since with hand filling the value it saves, it cannot be a problem of parent since the menu is built correctly....

Is there a conflict in Seblod code when using Seblod content type names? It's the only hypothesis I have now...

After all this investigation, waiting for Klas enlightment :)

thanks

I tested this - your problem is in the usage of the url variable "type" - this variable is used by Seblod to determine content type to load, so you just need to change type in url to something else and it will work.

Thanks Klas, that explains everything and confirm my suspects on an internal conflict in Seblod of the type variable, that I think should be added in the tutorial/manuals.

The problem is that I need to tune the WHERE condition in the select dynamic according to the content type being used when the field is inside a parent type: I have a content type P as parent and S1 and S2 as its sons that inherit fields from P. P has the select dynamic field that needs to know which is the content type being used (S1 or S2) in the where condition.

From what I know, select dynamic supports just $uri->... and $user->... as variables so the only place to know which is current content type is $uri. But type is not supported in $uri->get (my post here) so we're stuck.........

Any other way to retrieve current content type? [config] is not supported in select dynamic, isn't it?

By the way, the SQL pack plugin DOES support retrieving the type with $uri->get (I am using it as live value to store category Id depending on current content type) so I'd be very useful to have that support in select dynamic too.

So you are retrieving actual type variable? then it should work, I tested with variable added to the menu (which is conflicting with type variable set by set by Seblod, but there is no conflict in your case). But if it doesn't just create another variable with the same value in the parent.

Right, I am trying to get the seblod type, it's what I am trying to highlight from the start of this thread since I find it does not work :)

You suggest to add a variable: you mean create a menu item for each content type and add a custom variable for each Child type (not Parent, that will not distinguish current content type that is a child type, not parent type)? Apart from adding several menu items, the problem is that this solution works in front end but not in backend where menu items are not applicable, am I right? No way of adding this custom variable inside the child type so that applies both in BE and FE independently of a menu?

I still think select dynamic should handle get('type') (I can open an issue on github to request overcome the conflict), this would be a clean solution and takes away a limitation of select dynamic field.

thanks

I have to disappoint you, I retested and with only type variable from Seblod, saving works perfectly for me.

Check what data type you have set on storage (click on Modify), it should be Varchar or text. Also try making new field instance, could be storage was not set correctly on current one.

you are right, Klas, I am disappoited and frustrated. The exact test pattern in backend is 7 messages up

• define a new content type "test". This will add a new row in #__cck_core_types table with field name filled with "test".
• add just a select dynamic field named "xxx" like this
  
  • TABLE: #__cck_core_types
  • WHERE: name = '$uri->get('type')'
  • OPTION NAME = OPTION VALUE = name
  • storage as default (standard/article). Varchar(255).
• create an item of type test
  • the url will be http://.../www/administrator/index.php?option=com_cck&view=form&type=test&return_o=content
  • for field xxx you will get a dropdown list with a single item of "test" (so far good)
  • hit "Save": the item is saved but not field xxx.

This exact scenario works for you? I did it again from scratch (new content type, new field) and it does not work.

Before you said that Seblod type has a conflict with internal usage and was a reason, now I am again very confused

Conflict happens only when you add additional variable type to url, if you just get existing one it works fine for me.

Hi folks

Just thought I'd share my result:

QUERY: 
  Free
SQL Query: 
  SELECT name AS text, name AS value
  FROM #__cck_core_types
  WHERE name='$uri->get('type')'

QUERY: 
  Construction
TABLE: 
  #__cck_core_types<p>OPTIONS NAME:
  name
OPTIONS VALUE:
  name
WHERE:
  name='$uri->get('type')'

Thanks Buchlash for support :) !

Klas, if you please do my test, you will see that it does not work. Tonight I made a fresh install of bare Joomla, added just seblod with no plugins, done the test and the field is not saved. I can produce a video but I hope also Bucklash's confirmation shows that I am not doing things wrong.

thanks

It works fine for me (form after save)

Database:

Field configuration

Ok, I think I found a reason for difference in our tests - it works fine in frontend where I was testing, but for some reason it indeed does not work in backend.

Yes, it works in front-end, not in back-end. Are you investingating the issue? To keep track I opened an issue on GitHub

Issue 356

I studied a lot the code and found the problem: where uri variables are being replaced in JCckDevHelper::replaceLive method, the JInput object $app->input does not always (depends on the operation add/edit and backed/front-end) contain the "type" variable in the data array. Nevertheless, when the type variable is not directly in the first level of input object data, it is present in the config data of the input. So I made a workaround that solves the problem replacing in libraries/cms/cck/dev/helper.php line 328:

with

Is it correct or a cleaner solution lies in having the input object having the type when it is built?

This works for fixing FrontEnd and BackEnd views, it is not enough for fixing Content View and List View where Seblod type is nowhere in the JInput object passed to replaceLive method.

Cheers

Giuse