omeka-s-modules / Sharing

Omeka S module for sharing content via 1) Social Media and 2) Embedding Omeka S content in other sites
GNU General Public License v3.0
4 stars 6 forks source link

Coflict between Sharing and Collecting Site Settings #29

Closed patrickmj closed 7 years ago

patrickmj commented 8 years ago

The ways to make a field required seem to be causing conflicts when it uses inputFilter.

To reproduce, with both modules installed on latest master and core on global-settings-event branch, watch these lines around Sharing\Module.php ll 115 to 125:

            'attributes' => [
                'required' => false,
            ],
        ]);
// /*
        $inputFilter = $form->getInputFilter();
        $inputFilter->add([
            'name'     => 'sharing_methods',
            'required' => false,
        ]);
// */
  1. Comment out the inputFilter. Then try to submit with no Sharing options checked. Gives warning that it is required.
  2. With inputFilter still commented out, submit form with at least one sharing option checked. Both Sharing and Collecting options are saved.
  3. Restore the inputFilter. Sharing options are saved, even with no options checked. BUT, new Collecting options are not saved.

It's almost certain that this is related to the quirky results from the global settings callback. Look to the different callbacks, and comment in and out to confirm

        $sharedEventManager->attach(
            'Omeka\Controller\Admin\SettingController',
            'global_settings.form',
           // [$this, 'globalFieldset'] // fail!
            [$this, 'globalForm'] // works!
           // [$this, 'globalFormNoInputFilter'] // fail!
        );
jimsafley commented 8 years ago

This may be a result of an annoying quirk of $form->getInputFilter() which attaches input filter defaults only on its first call. Default input filters of any elements added later aren't loaded at all.

patrickmj commented 8 years ago

That makes a lot of sense with the different results I've been getting. Would it be worth making an Omeka\Form\Form that extends Zend\Form\Form to avoid that quirk? Maybe add an addInputFilter() method, and adjust getInputFilter() to use those when it's called in prepare()?

zerocrates commented 7 years ago

Pretty sure this is resolved because of the separate "elements" and "input filters" events.