Contextual visibility in custom image fields

[NikNakNoodle]

Contextual visibility ('Show this field only if...') on custom image fields operate as expected visually - but fields using contextual visibility do not save the field content on page save. Removing the contextual visibility on such fields makes the input saving work ok.

Custom image fields, as per this blog post.
https://processwire.com/blog/posts/pw-3.0.142/#:~:text=Identify%20the%20file%2Fimage%20field,using%20your%20own%20custom%20fields.

Setup/Environment

Dev environment AMPPS

• ProcessWire version: ProcessWire 3.0.168
• (Optional) PHP version: 7.1

[ryancramerdesign]

@NikNakNoodle Are you talking about visibility of the file/image field, or of custom fields within it? If you add the following to your /site/templates/admin.php file (after the <?php namespace ProcessWire;) do you find that it resolves the issue?

$config->InputfieldWrapper('useDependencies', false);

[NikNakNoodle]

Hi Ryan,
I'm talking about the custom fields within. I have a toggle designating the image as a photo or a chart... which dictates if other fields are relevant. This is a site that's been running since 2013 - so there wasn't a namespace declaration in admin.php. I have updated the file and added the new line as you mention, but get the following error...

Error: Exception: Method Config::InputfieldWrapper does not exist or is not callable in this context (in wire/core/Wire.php line 544)

#0 wire/core/Config.php (559): Wire->___callUnknown('InputfieldWrapp...', Array)
#1 wire/core/Wire.php (400): Config->___callUnknown('InputfieldWrapp...', Array)
#2 wire/core/WireHooks.php (823): Wire->_callMethod('___callUnknown', Array)
#3 wire/core/Wire.php (465): WireHooks->runHooks(Object(Config), 'callUnknown', Array)
#4 wire/core/Wire.php (468): Wire->__call('callUnknown', Array)

Kind regards
Nik

[daun]

This seems to be the same issue raised in #1267, regarding custom image fields that don't save when they have field dependencies.

[daun]

@ryancramerdesign Adding $config->InputfieldWrapper('useDependencies', false) indeed solves the issue here. Could you elaborate on what this does and if it could have any negative side effects?

[NikNakNoodle]

Thanks Daun and Ryan... I can confirm that on a fresh install, the suggested additional code line works. Just can't currently work out why it spits an error on my website. (site was originally PW2 so perhaps that's causing the issue for me).
Kind regards
Nik
UPDATE:
Ryans extra line of code only works if the admin theme is 'AdminThemeUikit';
If I use the default Admin theme, I get the errors previously mentioned.

Kind regards
Nik

[NikNakNoodle]

Not sure if you get sent notifications of updates to individual comments (as above) - so - just to be sure...

Ryan's extra line of code only works if the admin theme is 'AdminThemeUikit';
If I use the default Admin theme, I get the errors previously mentioned.

[ryancramerdesign]

@daun That setting tells the form to still process all of the submitted Inputfields rather than filter some out if dependency conditions don't match. It enables the dependencies to be front-end (visual) only, which is what you'd want for this particular situation. Otherwise it would be difficult to nail down dependency conditions since these are dynamic items that don't have a fixed name you can reference in a showIf/requiredIf condition.

[daun]

@ryancramerdesign Will enabling this option result in A) visually hidden fields not being touched or B) hidden fields being cleared of existing data?

[ryancramerdesign]

@NikNakNoodle The $config->InputfieldWrapper('useDependencies', false) setting shouldn't have any relation to the admin theme, as it is used by the core InputfieldWrapper class only, and not used or recognized by any admin theme.

@daun The option just makes the form behave as if the dependencies weren't there. Fields hidden by dependencies on the front-end fields will be processed with whatever value is present, rather than being ignored as a result of the dependencies.

[matjazpotocnik]

@NikNakNoodle can this be closed?

[NikNakNoodle]

@NikNakNoodle can this be closed?

At the time I couldn't get the workaround to function in anything but AdminThemeUikit, and didn't get a resolution that worked in the standard admin theme... so I gave up on this avenue. I don't know if this is still the case, but feel free to close this issue.

[matjazpotocnik]

Thank you. Closing, it can be reopened at any time.