Custom Inputfield Dependencies

[Robin S]

3 minutes ago, mel47 said:

Using upgrade module, I got "Specified download URL not valid"

Sorry, it's due to my browser autofilling the download URL with the wrong data when I edit the module in the modules directory. Please try again now and it should work.

[mel47]

@Robin S Yes, working! Thanks!

[Federico]

Hello,

Thank you @Robin S for this awesome module, really. Just a silly doubt, maybe I miss something, but is it only me having trouble to manage visibility for a fieldset type with nested fields (not fieldsetTab)? 

I mean, within a certain template, and under its tab "Input - Visibility - show only if custom PHP  returns true", I would like to get the fieldset group visibile only if a checkbox field (called proj_code_valid) is checked and the page is saved. So this is my condition

if($page->proj_code_valid == 1) return true;

 

I've tried many alternatives, but none of them were successful..

Note: I've updated the module to its latest version 0.0.6 (my PW version is 3.0.62).

[Federico]

ok after many tentatives, I've found what could be the thing:

The fieldset group (I bet also the fieldsetTab, though not tested), when not showed - with custom filter - is actually removed from the html code. This means that the fieldtab visibility selectors will not simply add a css "display:none" but actually remove it completely, leaving all the grouped fields as single <li> list objects. 

To overcome this, you should consider a presentation option in visibility as closed (thus not open..), before proceeding with any selector or php code.

Hope it helps, in case this was not yet discussed here

thanks!

fm

[Robin S]

Thanks for the report @Federico. I believe the issue you are seeing is caused by problems in the PW core rather than being specific to the Custom Inputfield Dependencies module. I found problems with several of the inputfield visibility options when used with fieldset inputfields, and created a GitHub issue here: https://github.com/processwire/processwire-issues/issues/441

 

3 hours ago, Federico said:

This means that the fieldtab visibility selectors will not simply add a css "display:none"

This is deliberate. It would be pretty easy for the module to hide inputfields via CSS, but by not rendering the inputfields the module allows for cases where it is critical that the inputfields not be seen or modified. The core inputfield dependencies feature works in response to other field values entered in Page Edit and hides/shows inputfields immediately. Therefore the core feature can only hide/show fields via JS and CSS, which may be manipulated by the user using their browser dev tools, or may fail if a JS error occurs. But the Custom Inputfield Dependencies module applies the dependencies via PHP before Page Edit is rendered, so I think it is an advantage to not render hidden fields at all.

Hopefully the core inputfield visibility problems with fieldsets will be fixed, however I will also look at whether a workaround is possible within the module.

In the meantime, I don't think the visibility dependency you want to set up requires Custom Inputfield Dependencies. You can achieve this using only the core inputfield dependency feature by setting the following for "Show this field only if":

proj_code_valid=1

 

[Federico]

Thanks @Robin S,

I see the issue of manipulating the display:none via user dev console, therefore your approach seems more suitable for this case. 

As of the core feature "Show this field only if", although it works properly, it doesn't requires a page to be saved (immediate show/hide via js) - thus not suitable in case like mine where you need the user to save page before showing the fieldset. 

However, I've tested the option/workaround reported above, and so far so good

[Robin S]

9 minutes ago, Federico said:

However, I've tested the option/workaround reported above, and so far so good

What workaround are you referring to here? Do you mean this...

4 hours ago, Federico said:

To overcome this, you should consider a presentation option in visibility as closed (thus not open..), before proceeding with any selector or php code.

I don't see how this can work, because a user can open a closed inputfield, and also this module forces the visibility to hidden when the "show if" conditions are not met which would overwrite a "closed" setting.

[Federico]

9 hours ago, Robin S said:

What workaround are you referring to here? Do you mean this...

I don't see how this can work, because a user can open a closed inputfield, and also this module forces the visibility to hidden when the "show if" conditions are not met which would overwrite a "closed" setting.

That's true, as you also stated in the github issue. My aim was focused on finding a temporary solution to let custom php selectors hide/show the fieldset group on a page save. By apply custom php selector with presentation "open", these selectors will not work simply because the fieldset group will be not rendered in the html code (at least in may case). Oppositely, by considering fielsdet presentation as "closed", your php-based filters seem working as the fieldset is rendered in the html code (thus managed by css on a page load).

<div class="InputfieldContent">....</div>  is the part of the fieldset that will be hidden/shown based on your php selector ( in my case I display the whole fieldset with a checkbox, after a page save). 

Bottom line: I totally agree with you statement below, that secures that no one can manipulate the hidden fieldset

10 hours ago, Robin S said:

But the Custom Inputfield Dependencies module applies the dependencies via PHP before Page Edit is rendered, so I think it is an advantage to not render hidden fields at all.

 

[Robin S]

v0.0.7 released: Adds support for FieldtypeFieldset, FieldtypeFieldsetGroup and FieldtypeFieldsetTab.

@Federico, hopefully this update works for your use case.

[Federico]

Thanks @Robin S, awesome support!

For whatever reason, my fieldset did not changed its behaviour from 0.0.6 to 0.0.7, I still cannot control it via custom selectors after page save.

I reverted back to the combo presentation "closed" and checkbox fieldtype "yourcheckboxfieldtypeName" as "not checked", as this is still a working solution for me. I mean, when the checkbox is checked and the page is saved, than the fieldset is showed. If not checked, the fieldset is hidden via css

 

[Robin S]

@Federico, the module seems to be working for me as expected.

So I will leave the module as is for now unless I hear of others having problems with fieldsets.

It sounds like you have your own solution that is working for you.

[Federico]

@Robin S after additional tests, I've found that the "007" release works as expected for fieldset visibility only outside individual templates (fields visibility overwrite). correct?

[Robin S]

6 hours ago, Federico said:

after additional tests, I've found that the "007" release works as expected for fieldset visibility only outside individual templates (fields visibility overwrite). correct?

Ah, good find, thanks. Fixed in v0.0.8.

[adrian]

Hey Robin,

I went to use this on the User template without success. Do you see any reason that can't be enabled with:

        if($this->page->process !== 'ProcessPageEdit' && $this->page->process !== 'ProcessUser') return;

in the evaluateCustomDependencies() method?

[Robin S]

@adrian, I think that should be fine, but could you first make the change on your local installation? If it seems to work okay let me know and I'll update the module.

[adrian]

7 minutes ago, Robin S said:

@adrian, I think that should be fine, but could you first make the change on your local installation? If it seems to work okay let me know and I'll update the module.

Yeah, I have been using it here and works great for hiding certain user fields from non-superusers.

[Robin S]

1 hour ago, adrian said:

I have been using it here and works great for hiding certain user fields from non-superusers

Great. I have applied your suggested change in the latest version.

[adrian]

Thanks heaps for the speedy service!

[szabesz]

Hello @Robin S,

I've just noticed your initial post of this thread points to no longer available images, you might want to fix that. Also, I find it a bit strange you use the GitHub link in the module's info instead of this thread's or the module directory's, since in the README.dm there is no link to learn about the other two pages.

[Robin S]

11 hours ago, szabesz said:

I've just noticed your initial post of this thread points to no longer available images, you might want to fix that.

Thanks for the heads up - I've fixed that.

11 hours ago, szabesz said:

Also, I find it a bit strange you use the GitHub link in the module's info instead of this thread's or the module directory

I don't think it's strange. The href property in getModuleInfo() is optional so getting any link is like a bonus - Ryan rarely uses it in his modules for example. If a developer does choose to use the href property then the guidelines are "URL to more information about the module" - I think the GitHub readme satisfies that guideline quite well. The online repository is the primary home of the module - the module directory listing just pulls the readme from the repo. Also, at the time I'm filling out getModuleInfo() the repo URL is the only one that exists. The module doesn't have a directory page or support thread at that point, and some modules never will, so using the repo URL keeps things consistent across all my modules. 

[digitex]

@Robin S This is a very handy module, thank you.

I have a situation that is inconvenient at best but has me wondering. I have 2 fields set side by side on the template with 50% width and a showif condition that means one of the fields only appears occasionally but when it's not visible the layout goes to hell since the first field is set to 50% width.

Is it possible to expand this module to include the column width so that if the same selector that determines visibility is met the column width would change from 50% to 100% to fill in the row? If so it would allow for field visibility to change without effecting the rest of the layout. that would be awesome.

[adrian]

1 minute ago, digitex said:

if the same selector that determines visibility is met the column width would change from 50% to 100% to fill in the row?

That is how the PW is supposed to work already - just unfortunately with the new(ish) uikit theme, it doesn't always work as expected: https://github.com/processwire/processwire-issues/issues/480

The percentage based option may or may not fix it for you.

[digitex]

4 minutes ago, adrian said:

That is how the PW is supposed to work already - just unfortunately with the new(ish) uikit theme, it doesn't always work as expected: https://github.com/processwire/processwire-issues/issues/480

The percentage based option may or may not fix it for you.

No it doesn't. I have other fields that do fill in when field visibility is conditional but not in this case. I don't know why but when the field in question is not displayed, the other field beside it, set to 50%, stays at 50% and the fields in the next row flood in and alter the layout, in a bad way. I'm using this module because I need a custom selector and it's very handy. I got around the problem by giving both fields 100% width so not a big deal.

[Robin S]

@digitex, thanks for alerting me to this issue. I've made a change in v0.2.0 that should solve the issue.

A note for all users of the module...

Before v0.2.0 the Custom Inputfield Dependencies module did not render an inputfield in Page Edit if it determined that the inputfield should be hidden. But this creates problems if the inputfield and its neighbours have column widths of less than 100%. So from v0.2.0 onwards hidden fields will be rendered in Page Edit and hidden with CSS, so effectively the same type of hiding as occurs with the core inputfield dependencies feature.

[sz-ligatur]

Hi Robin - thank you for your improvement on that. I guess there is a typo in CustomInputfieldDependencies.module @Line 52, the comma breaks the installation…

				$this->hideInputfield($inputfield, $field,);