Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The new subform field returns NULL instead of the default value #11318

Closed
HitkoDev opened this issue Jul 27, 2016 · 9 comments
Closed

The new subform field returns NULL instead of the default value #11318

HitkoDev opened this issue Jul 27, 2016 · 9 comments

Comments

@HitkoDev
Copy link

HitkoDev commented Jul 27, 2016

Steps to reproduce the issue

In plugin.xml add something like

<field name="property_sets" type="subform" formsource="plugins/system/plugin/propset.xml" 
    min="1" max="10" multiple="true" layout="joomla.form.field.subform.repeatable" 
    groupByFieldset="false" label="Label" description="Desc" />

Then within the plugin.php call

$sets = $this->params->get('property_sets');

Expected result

$sets contains one set with default values from propset.xml.

Actual result

$sets is NULL when plugin is installed. The user has to open and save plugin config for the default values to load.

System information (as much as possible)

Joomla! 3.6.0

@ghost
Copy link

ghost commented Jul 28, 2016

That's the expected behavior, not a bug. Any parameter/property is NULL if not defined in a Registry object.

So, use:
$sets = $this->params->get('property_sets', new stdClass); or
$sets = $this->params->get('property_sets', array()); or
$sets = $this->params->get('property_sets', 'thing'); or
.... or ...
to set a default value for $sets for the next steps in your code.

Or use
if (!empty( $this->params->get('property_sets')) or
if (! is_null( $this->params->get('property_sets')) or
if (false === $this->params->get('property_sets', false)) or ... or ...

@HitkoDev
Copy link
Author

HitkoDev commented Jul 28, 2016

You're almost right. Take a look here: https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/installer/installer.php#L1555 - the installer parses the default values from plugin.xml and stores them in the database, so the default value should always be defined in the registry object. However, it doesn't handle the subform field properly, i.e. by parsing the formsource file and storing its default values.

@Fedik
Copy link
Member

Fedik commented Jul 28, 2016

Expected result
$sets contains one set with default values from propset.xml.

nope, NULL is expected result 😉

same is true for simple text field

<field name="property_sets" type="text" default="ueueue"/>
$value = $this->params->get('property_sets');

$value will be null if the form was never saved before

you can have default value in next way:

$sets = $this->params->get('property_sets', array('foo' => 'bar') /*... default value ...*/);

@Fedik
Copy link
Member

Fedik commented Jul 28, 2016

or wait, I did not seen that installer.php#L1555 parse something,
then maybe try set default for subform field:

<field name="property_sets" type="subform" formsource="plugins/system/plugin/propset.xml" 
    default='[{field: "value"}, {field: "value2"} ... ]' ....

but I think installer.php#L1555 will parse it as simple string instead of json 😄

well, just use default in your code:

$sets = $this->params->get('property_sets', array('foo' => 'bar'));

@brianteeman
Copy link
Contributor

Closed as expected behaviour


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/11318.

@HitkoDev
Copy link
Author

Sure, putting escaped JSON in an XML attribute is such a good idea, next thing I need a custom build system to parse any referenced subform when packing in a simple plugin, and hardcode it inside a PHP script or an XML attribute. How about we fix the installer to properly handle nested fields instead of hacking our way around?

@HitkoDev
Copy link
Author

Oh and @brianteeman, maybe check GitHub once in a while and you'll notice @Fedik overlooked the parsing in installer.php, so reopen maybe?

@Fedik
Copy link
Member

Fedik commented Jul 28, 2016

fields instead of hacking our way around?

it not really haking, it how thing works

next thing I need a custom build system to parse any referenced subform when packing in a simple plugin, and hardcode it inside a PHP script or an XML attribute

well, I do not see any hardkoding in use Registry API to have the default value in your code

$params->get('key', $default);

it is easy

@HitkoDev
Copy link
Author

HitkoDev commented Jul 28, 2016

And I'm supposed to set the $default how? By parsing the subform each time the plugin runs? Let's face it, the way it's supposed to be is for the installer to parse the config when an extension is installed / updated and make sure the default (required) values are present in the registry. Currently it's not doing that when it comes to subform fields, and that should be fixed.

While I understand it can work by entering the same config multiple times, it's not something to be encouraged as it leads to inconsistency and hard-to-maintain code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants