Custom Inputfield Dependencies

[Robin S]

Custom Inputfield Dependencies

A module for ProcessWire CMS/CMF. Extends inputfield dependencies so that inputfield visibility or required status may be determined at runtime by selector or custom PHP code.

Overview

Custom Inputfield Dependencies adds several new settings options to the "Input" tab of "Edit Field". These are described below.

Note that the visibility or required status of fields determined by the module is calculated once at the time Page Edit loads. If your dependency settings refer to fields in the page being edited then changes will not be recalculated until the page is saved and Page Edit reloaded.

Usage

Install the Custom Inputfield Dependencies module.

Optional: for nice code highlighting of custom PHP install InputfieldAceExtended v1.2.0 or newer (currently available on the 'dev' branch of the GitHub repo).

The custom inputfield dependencies are set on the "Input" tab of "Edit Field".

Visibility

Show only if page is matched by custom find

Use InputfieldSelector to create a $pages->find() query. If the edited page is matched by the selector then the field is shown.

Show only if page is matched by selector

As above, but the selector string may be entered manually.

Show only if custom PHP returns true

Enter custom PHP/API code – if the statement returns boolean true then the field is shown. $page and $pages are available as local variables – other API variables may be accessed with $this, e.g. $this->config

In most cases $page refers to the page being edited, but note that if the field is inside a repeater then $page will be the repeater page. As there could conceivably be cases where you want to use the repeater page in your custom PHP the module does not forcibly set $page to be the edited page. Instead, a helper function getEditedPage($page) is available if you want to get the edited page regardless of if the field in inside a repeater or not.

$edited_page = $this->getEditedPage($page);

Required

The settings inputfields are the same as for Visibility above, but are used to determine if the field has 'required' status on the page being edited.

 

https://github.com/Toutouwai/CustomInputfieldDependencies

http://modules.processwire.com/modules/custom-inputfield-dependencies/

[Robin S]

v0.0.2 released - a complete overhaul of the module. Custom Inputfield Dependencies now does the same thing but in a completely different way (thanks to a great idea from @adrian)

The module no longer requires Hanna Code and inputfield dependencies are now set on the "Input" tab of "Edit Field". See the first post for all the details.

If you are using v0.0.1 of the module then this is a breaking change and you will need to redefine your dependencies (sorry ). But the new approach taken in v0.0.2 is so much better that hopefully you'll find the change worthwhile.

[adrian]

Hey @Robin S - I just wanted to remind everyone how awesome this is

It can reduce the number of required templates (and template files) substantially in some cases where you have a standard setup, but with some minor differences to the fields in each template. Of course you could take it to extremes and have just one template per site, so you need to be careful to find the right balance, but it's a really powerful addition to PW IMO.

Thanks again!

[Karl_T]

Thanks for the module.

I would like to report that It seems that this module is breaking the inputfieldwrapper field. When I edit the inputfieldwrapper field, it shows error as following.

Error: Uncaught TypeError: Argument 2 passed to ProcessWire\InputfieldWrapper::insertAfter() must be an instance of ProcessWire\Inputfield, null given, called in /var/app/current/site/modules/CustomInputfieldDependencies/CustomInputfieldDependencies.module on line 136 and defined in /var/app/current/wire/core/InputfieldWrapper.php:296
Stack trace:
#0 .../site/modules/CustomInputfieldDependencies/CustomInputfieldDependencies.module(136): ProcessWire\InputfieldWrapper->insertAfter(Object(ProcessWire\InputfieldTextarea), NULL)
#1.../wire/core/WireHooks.php(782): CustomInputfieldDependencies->addFieldOptions(Object(ProcessWire\HookEvent))
#2 .../wire/core/Wire.php(442): ProcessWire\WireHooks->runHooks(Object(ProcessWire\Field), 'getConfigInputf...', Array)
#3 .../wire/modules/Process/ProcessField/ProcessField.module(943): ProcessWire\Wire->__call('getConfigInputf...', Array)
#4 .../wire/core/Wi (line 296 of /var/app/current/wire/core/InputfieldWrapper.php) 

[Robin S]

33 minutes ago, Karl_T said:

I would like to report that It seems that this module is breaking the inputfieldwrapper field. When I edit the inputfieldwrapper field, it shows error as following.

Could you explain some more about what you are doing at the time you see this error? I'm not sure what you mean by 'edit the inputfieldwrapper field'. Are you editing a field's settings in admin or via the API?

[Karl_T]

On 2017-5-4 at 1:52 PM, Robin S said:

Could you explain some more about what you are doing at the time you see this error? I'm not sure what you mean by 'edit the inputfieldwrapper field'. Are you editing a field's settings in admin or via the API?

I was editing a field setting in the admin panel. This happens also when redirecting to the edit page after you create new inputfieldwrapper field.

[Robin S]

1 hour ago, Karl_T said:

I was editing a field setting in the admin panel. This happens also when redirecting to the edit page after you create new inputfieldwrapper field.

I think I get it now - you are talking about a "Fieldset in Tab" fieldtype, right? An InputfieldWrapper is something different.

Thanks for the report - should be fixed in v0.0.3.

[Karl_T]

53 minutes ago, Robin S said:

you are talking about a "Fieldset in Tab" fieldtype, right? An InputfieldWrapper is something different.

You are right. I thought they are the same thing. Sorry for the misleading. 

[Juergen]

Hello @Robin S

the problem is still there in version 0.0.3.

Argument 2 passed to ProcessWire\InputfieldWrapper::insertAfter() must be an instance of ProcessWire\Inputfield, null given, called in /home/.sites/24/site1275/web/site/assets/cache/FileCompiler/site/modules/CustomInputfieldDependencies/CustomInputfieldDependencies.module on line 156 and defined

Best regards

[Robin S]

@Juergen, thanks for the report - should be fixed in v0.0.4

[quickjeff]

Thank you so much for this! Much needed. Is it safe to run on a live site or still has bugs? I have it running on staging and so far so good but I do need to use this on quite a few pages. 

[Robin S]

3 hours ago, quickjeff said:

Is it safe to run on a live site or still has bugs?

No bugs that I know of. I'm using it on a few live sites. Should be fine.

[SamC]

Module works amazing. In my case, I needed to show the fields only if the page does not have a parent of a certain template (as the child pages simply display the parents fields on the webpage), selector:

parent.template!=complete-guide

...and the out the box options only allows for fields on the same page. Thanks @Robin S

[mel47]

Hi

Still another wonderful module I just discovered! I was wondering why fieldsetTab doesn't have visibility rule? (also not present in the core) I have to apply the same rule to all fields contained in the tab? Does the tab will disappear if empty (sorry didn't try yet I have ~15 fields in it for now)?

Thanks

Mel

[Robin S]

2 hours ago, mel47 said:

I was wondering why fieldsetTab doesn't have visibility rule? (also not present in the core)

FieldsetTab is not supported by the core "show if" dependency, but it turns out it is possible to support it in this module. Please update to v0.0.5.

[Macrura]

@Robin S Thanks for this module!

I was hoping to use this for a setup where some fields need to show/hide based on their parent, but using it caused the editor page load to go from ~1883ms to ~18056ms, using 4 custom dependencies; not sure if it is totally this module or some interaction with other modules, but the speed changed back once i removed all of the custom dependencies...

ProcessWire: 3.0.82
PHP: 7.1.11
Webserver: Apache
MySQL: 5.6.37
CustomInputfieldDependencies: 0.0.5

[adrian]

Hey @Macrura - it might be worth describing how you are defining the matches and if it's the custom PHP code option, then post that. I have used this module without any problems, but I haven't pushed it with complex matching.

[Robin S]

Hi @Macrura, looking at the module code I can immediately see a much more efficient way to match the current page than what the module is doing currently. I'll post back here shortly with an update.

[Macrura]

these are the 4 fields and the custom selector:

internal_notes
parent.id=6587

secure_files
parent.id!=6587

document_status
parent.id=6587

pr_select
parent.id=6485

now i'm thinking it would be more efficient anyway to maybe create a cache field of the parent id, and just use regular inputfield dependencies?

also, these pages have thousands of siblings, not sure if that matters...

[Macrura]

1 minute ago, Robin S said:

Hi @Macrura, looking at the module code I can immediately see a much more efficient way to match the current page than what the module is doing currently. I'll post back here shortly with an update.

you rock!

[Robin S]

@Macrura, would you mind testing the attached module update and let me know if it works as expected and improves the page load time? Just want to confirm it does the job before pushing the change to GitHub.

CustomInputfieldDependencies.zip

 

[Macrura]

sure - yes - i can test it tomorrow, and will post back asap.

[Macrura]

@Robin S - i can confirm that this fixes the issue and the page load time is now fine (~1000ms) and with 4 inputfield dependencies. Thanks for tweaking that!

[Robin S]

v0.0.6 released: More efficient evaluation of dependencies.

[mel47]

Hi,

Using upgrade module, I got "Specified download URL not valid" (my translation).

Mel