248 Posts
Giuse
7 years ago
Topic

Hi, I have a select dynamic field (simple construction mode) with WHERE condition is

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

The dropbox menu is correctly filled with options but... saving does not work, it does not save the value. If I replace "$uri...." value with the static value of the content type taken from the URL, saving works normally. Is a bug? This problem blocks usage of this dynamic field.

Thanks a lot

Giuse

Get a VIP membership
1283 Posts
Bucklash
7 years ago
12
Level 1

Hi

Are the quotes necessary?

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

Instead of

item_class = "$uri->getValue('type')"
248 Posts
Giuse
7 years ago
11
Level 2

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....

1283 Posts
Bucklash
7 years ago
10
Level 3

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....

1283 Posts
Bucklash
7 years ago
9
Level 4

Hi

Or maybe it should be:

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

Also, this works for me:

248 Posts
Giuse
7 years ago
8
Level 5

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

SELECT JCAT.id AS value, JCAT.id AS text FROM #__cck_store_form_product_category AS JCAT WHERE JCAT.items_class = "$uri->getValue('type')"

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

Unknown column 'lpt_product_photo_camera' in 'where clause' SQL=SELECT JCAT.id AS value, JCAT.id AS text FROM #__cck_store_form_lproduct_category AS JCAT WHERE JCAT.items_class = lpt_product_photo_camera

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)....

1283 Posts
Bucklash
7 years ago
7
Level 6

Hi Guise

Damn... sorry...

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

248 Posts
Giuse
7 years ago
6
Level 7

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

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

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

4229 Posts
Kadministrator
7 years ago
5
Level 8

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

248 Posts
Giuse
7 years ago
4
Level 9

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

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

I get the SQL error

Unknown column 'lpt_product_vendor' in 'where clause' SQL=SELECT name,id FROM #__cck_core_types WHERE name = lpt_product_vendor

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

4229 Posts
Kadministrator
7 years ago
3
Level 10

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

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

248 Posts
Giuse
7 years ago
2
Level 11

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

4229 Posts
Kadministrator
7 years ago
1
Level 12

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.

248 Posts
Giuse
7 years ago
0
Level 13

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

http://.../administrator/index.php?option=com_cck&view=form&type=test&id=486&return_o=content

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

4229 Posts
Kadministrator
7 years ago
2
Level 1

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.

248 Posts
Giuse
7 years ago
1
Level 2

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

echo 'xxx = ' . $fields['xxx']->text . '  ';

var_dump($config); die();

and the result is very interesting:

xxx =          array(23) {......["xxx"]=> string(4) "test" .......}

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

xxx = test   array(23) {......["xxx"]=> string(4) "test" .......}

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

thanks and hoping to see the light on this :)

248 Posts
Giuse
7 years ago
0
Level 3

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

4229 Posts
Kadministrator
7 years ago
3
Level 1

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.

248 Posts
Giuse
7 years ago
2
Level 2

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.

4229 Posts
Kadministrator
7 years ago
1
Level 3

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.

248 Posts
Giuse
7 years ago
0
Level 4

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

4229 Posts
Kadministrator
7 years ago
2
Level 1

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.

248 Posts
Giuse
7 years ago
1
Level 2

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

4229 Posts
Kadministrator
7 years ago
0
Level 3

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

1283 Posts
Bucklash
7 years ago
1
Level 1

Hi folks

Just thought I'd share my result:

Using SELECT DYNAMIC FREE:
QUERY: 
  Free
SQL Query: 
  SELECT name AS text, name AS value
  FROM #__cck_core_types
  WHERE name='$uri->get('type')'
Using SELECT DYNAMIC CONSTRUCTION:
QUERY: 
  Construction
TABLE: 
  #__cck_core_types<p>OPTIONS NAME:
  name
OPTIONS VALUE:
  name
WHERE:
  name='$uri->get('type')'
SELECT DYNAMIC FREE:

Using SELECT DYNAMIC CONSTRUCTION:

Renders in Form in each case:

It renders in the form, but does not save.....
Not saved as shown in form:

Not saved as shown in db...

248 Posts
Giuse
7 years ago
0
Level 2

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

4229 Posts
Kadministrator
7 years ago
0
Level 1

It works fine for me (form after save)

Database:

Field configuration

4229 Posts
Kadministrator
7 years ago
2
Level 1

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.

248 Posts
Giuse
7 years ago
1
Level 2

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

248 Posts
Giuse
7 years ago
0
Level 3

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:

$str=str_replace( $matches[0][$k], $app->input->$request( $variable, '' ), $str );

with

$found = $app->input->$request( $variable, '' );

$altFound = $app->input->$request('config', '');

if ($found == NULL && $altFound != NULL)

    $str=str_replace( $matches[0][$k], $altFound[0], $str );

else $str=str_replace( $matches[0][$k], $found, $str );

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

248 Posts
Giuse
6 years ago
0
Level 1

Solved in Seblod 3.16 when there is the new procedure $context->getType() to retrieve current Seblod type.

Get a VIP membership