Generic Settings Pages: Make getSettingPageFilter() public so we can use it in hooks

[mattwire]

Overview

If you use the generic settings page and then want to load a custom resource (eg. javascript to conditionally hide fields) you can use the buildForm hook but can only match on CRM_Admin_Form_Generic which will match multiple forms. To target an individual "page" we need to know the value of the filter.

Before

Not possible to get the filter value from the form.

After

Can retrieve the filter value from the form and use it to conditionally load resources.

Technical Details

The property _filter is available but private, it can be accessed via the protected method getSettingPageFilter(). We need to check the filter value to work out which settings "page" we are loading.

Comments

@eileenmcnaughton This seems like a simple change, not sure if there is a better way to do this. But being able to match on a specific filter makes the generic settings pages much more useful because they can be individually customised via buildForm hooks.

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[eileenmcnaughton]

@mattwire I don't have a problem with this except that maybe you should add a comment as to why it's public so it doesn't later get un-publiced.

Also I imagine you are aware you can add or remove things from the form using the alterSettingsMetaData hook - I can see that you are saying conditional so that's by the by

[eileenmcnaughton]

test this please

[mattwire]

@mattwire I don't have a problem with this except that maybe you should add a comment as to why it's public so it doesn't later get un-publiced.

Thanks. I've added a comment. And just used the alterSettingsMetadata hook on another project :-)

[eileenmcnaughton]

@mattwire we have a big picture issue that we don't really define what functions we expect sites to use when interacting with core classes that can be accessed in hooks.

Ideally we would make the right calls about what is public & private & perhaps use interfaces & documentation. We seem to be a long way from there but we should be thinking about it.