Jump to content
Robin S

Custom Inputfield Dependencies

Recommended Posts

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.

  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

  • Like 2

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites

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

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

  • Like 5

Share this post


Link to post
Share on other sites

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

 

  • Like 1

Share this post


Link to post
Share on other sites

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

2017-11-29_143730.png.794f9a9d6adf2a7b3c6c881e1aad5b32.png

cid.gif.e851a1b528d03e0804a599e04fc52dc9.gif

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.

Share this post


Link to post
Share on other sites

@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?

  • Like 1

Share this post


Link to post
Share on other sites
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.

  • Like 3

Share this post


Link to post
Share on other sites

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?

  • Like 1

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites
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.

  • Like 3

Share this post


Link to post
Share on other sites
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.

  • Like 2

Share this post


Link to post
Share on other sites

Thanks heaps for the speedy service!

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites
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. 

  • Like 1

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

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,);

 

  • Like 2

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...