Join GitHub today
Expand the array of field/inputfield settings that may be configured in template context #145
Short description of the enhancement
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.
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.
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.
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.
added a commit
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