New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expand the array of field/inputfield settings that may be configured in template context #145

Closed
Toutouwai opened this Issue Dec 14, 2017 · 5 comments

Comments

Projects
None yet
3 participants
@Toutouwai

Toutouwai commented Dec 14, 2017

Short description of the enhancement

A while ago @abdusco published a blog post showing how hooks can be used to allow additional field and inputfield settings to be configured in template context.

Since then I have been doing this regularly and find it a very useful way to reduce the number of fields that are required for a project. Setting things like minimum image dimensions and textformatters per template is super-handy.

Now I'm wondering if this could be made a core feature so that hooks are not required.

I think it would be good to provide an option that includes all field and inputfield settings that may be successfully configured in template context. Because this could be considered a "power user" feature there could be a option in config.php that switches from the cut-down array of config fields that are currently configurable in template context to all config fields (apart from those known not to support template context, if any).

Why would the enhancement be useful to users?

As per the blog post title, it allows the developer to do more with fewer fields.

@LostKobrakai

This comment has been minimized.

Show comment
Hide comment
@LostKobrakai

LostKobrakai Dec 14, 2017

Collaborator

I can see the appeal of a more feature-like-looking setting, but imho hooks are the power user feature for processwire. I can certainly see a few more of those settings getting available to template contexts by default, but each of those it's another context setting Ryan does need to keep track of and actively support it's functionality. Hooks on the other end allow you to add any setting you'd like on your own without shifting the maintenance onto Ryan's shoulders.

You (or anyone else) could even make a 3rd party module, which adds a dynamic hook reading a config setting like you proposed to enable the functionality. The usage of such a module could even inform which settings should be supported by default in the core and which are less used.

Collaborator

LostKobrakai commented Dec 14, 2017

I can see the appeal of a more feature-like-looking setting, but imho hooks are the power user feature for processwire. I can certainly see a few more of those settings getting available to template contexts by default, but each of those it's another context setting Ryan does need to keep track of and actively support it's functionality. Hooks on the other end allow you to add any setting you'd like on your own without shifting the maintenance onto Ryan's shoulders.

You (or anyone else) could even make a 3rd party module, which adds a dynamic hook reading a config setting like you proposed to enable the functionality. The usage of such a module could even inform which settings should be supported by default in the core and which are less used.

@ryancramerdesign

This comment has been minimized.

Show comment
Hide comment
@ryancramerdesign

ryancramerdesign Dec 14, 2017

Contributor

I think it kind of depends on the setting. We could definitely add more, so if there are any specifically that you are looking for, let me know.

Though a setting like textformatters would be one that's problematic, as it affects the formatted output of the field, so there are security implications there. When you output a field on the front-end, you don't want to have to wonder whether it's entity encoded or not, whether it could potentially contain XSS exploits in it or not. You want to know that when you output some field named "summary" (for example) in a list of search results, that it's safe to do so regardless of what template the page is using.

That's just an example, but there are plenty of other cases where it really wouldn't be problematic at all to allow context configuration. It just kind of comes down to a case-by-case basis as to whether it's advisable or not. For most cases, it's probably okay. So like I say, if there are specific ones you are looking for let me know, as we've always got room to add more. I also agree with LostKobrakai that hooks are a good route to take for this stuff too. But I have no doubt there are context settings we could add for all that would be worthwhile.

Contributor

ryancramerdesign commented Dec 14, 2017

I think it kind of depends on the setting. We could definitely add more, so if there are any specifically that you are looking for, let me know.

Though a setting like textformatters would be one that's problematic, as it affects the formatted output of the field, so there are security implications there. When you output a field on the front-end, you don't want to have to wonder whether it's entity encoded or not, whether it could potentially contain XSS exploits in it or not. You want to know that when you output some field named "summary" (for example) in a list of search results, that it's safe to do so regardless of what template the page is using.

That's just an example, but there are plenty of other cases where it really wouldn't be problematic at all to allow context configuration. It just kind of comes down to a case-by-case basis as to whether it's advisable or not. For most cases, it's probably okay. So like I say, if there are specific ones you are looking for let me know, as we've always got room to add more. I also agree with LostKobrakai that hooks are a good route to take for this stuff too. But I have no doubt there are context settings we could add for all that would be worthwhile.

@Toutouwai

This comment has been minimized.

Show comment
Hide comment
@Toutouwai

Toutouwai Dec 14, 2017

Though a setting like textformatters would be one that's problematic, as it affects the formatted output of the field, so there are security implications there.

Not sure I get your point here - you would still apply "essential" settings like an entity-encoding textformatter to the field outside of template context. This then becomes the default setting for the field. Sure, you could potentially remove the textformatter in template context, but that's no more of a danger than failing to add such a textformatter in the first place. These are superuser-only settings so we assume decisions are made sensibly. In my case, I wanted to selectively apply the NewlineBR textformatter on a template-by-template basis.

Hooks are fine, but if you want to expose all possible config settings to template context that would be a lot of hooks. You'd have to hook the getConfigAllowContext() method for every Fieldtype and Inputfield class (okay, or two hooks to the parent classes with a huge switch structure within).

And some of the useful config settings are a bit tricky to add via a hook. For instance, the min/max width/height settings for image fields are contained within unnamed fieldsets. So you have to add another hook to first apply a names to those fieldsets before they can be added to the settings configurable in template context.

But the main thing is that I think most PW devs don't realise it is possible to add to the field settings that may be configured in template context. It never occurred to me before reading Abdus' blog post, and I'm sure there are many out there who never saw the post. So that means a lot of devs are missing out on something that is really useful, and we are hiding the true power of the template context feature.

It's no big problem for me to do this via hooks - I'd just like to see the power-features of PW showcased (behind a $config option to reveal them) so users can discover them more easily.

Toutouwai commented Dec 14, 2017

Though a setting like textformatters would be one that's problematic, as it affects the formatted output of the field, so there are security implications there.

Not sure I get your point here - you would still apply "essential" settings like an entity-encoding textformatter to the field outside of template context. This then becomes the default setting for the field. Sure, you could potentially remove the textformatter in template context, but that's no more of a danger than failing to add such a textformatter in the first place. These are superuser-only settings so we assume decisions are made sensibly. In my case, I wanted to selectively apply the NewlineBR textformatter on a template-by-template basis.

Hooks are fine, but if you want to expose all possible config settings to template context that would be a lot of hooks. You'd have to hook the getConfigAllowContext() method for every Fieldtype and Inputfield class (okay, or two hooks to the parent classes with a huge switch structure within).

And some of the useful config settings are a bit tricky to add via a hook. For instance, the min/max width/height settings for image fields are contained within unnamed fieldsets. So you have to add another hook to first apply a names to those fieldsets before they can be added to the settings configurable in template context.

But the main thing is that I think most PW devs don't realise it is possible to add to the field settings that may be configured in template context. It never occurred to me before reading Abdus' blog post, and I'm sure there are many out there who never saw the post. So that means a lot of devs are missing out on something that is really useful, and we are hiding the true power of the template context feature.

It's no big problem for me to do this via hooks - I'd just like to see the power-features of PW showcased (behind a $config option to reveal them) so users can discover them more easily.

ryancramerdesign added a commit to processwire/processwire that referenced this issue Dec 22, 2017

Add support for custom configuration of what Fieldtype/Inputfield set…
…tings may be overridden for field/template context. Appears only in $config->advanced mode. You can see it when editing a field (ProcessField) on the "Overrides" tab. Related to processwire/processwire-requests#145
@ryancramerdesign

This comment has been minimized.

Show comment
Hide comment
@ryancramerdesign

ryancramerdesign Dec 22, 2017

Contributor

I've just added something that may answer this request. You can now configure which settings may be adjusted per-template, when editing any Field. Because I'm not certain how safe this may be (per what I mentioned earlier), I've got it enabled only when $config->advanced mode is active. However, anything you add there when advanced mode is active should continue to persist even when not in advanced mode. Please take a look and let me know if this seems to provide what you were looking for?

Contributor

ryancramerdesign commented Dec 22, 2017

I've just added something that may answer this request. You can now configure which settings may be adjusted per-template, when editing any Field. Because I'm not certain how safe this may be (per what I mentioned earlier), I've got it enabled only when $config->advanced mode is active. However, anything you add there when advanced mode is active should continue to persist even when not in advanced mode. Please take a look and let me know if this seems to provide what you were looking for?

@Toutouwai

This comment has been minimized.

Show comment
Hide comment
@Toutouwai

Toutouwai Dec 22, 2017

This is excellent! Thanks, and Merry Christmas.

Toutouwai commented Dec 22, 2017

This is excellent! Thanks, and Merry Christmas.

@Toutouwai Toutouwai closed this Dec 22, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment