Template fields

[theoretic]

Hi fellas! And thanks for Processwire!

I have an idea which, I suppose, might appear interesting to the PW community. I'd call it "template fields".

Come on, we have it already! Any template may have fields, it's Processwire basics. Yes. And no! The fields attached to any template are used with the pages having this template, but not with the template itself.

Feel perplexed? A short pseudocode example to explain what I'm trying to say.

//one-of-my-templates.php
...
foreach( $productPages as $productPage ){
	$productImage = $productPage->image? : $productPage->template->image;
	//outputting some html etc.
}
...

Default field values (e.g. default images) are not a strong point of Processwire. Okay, we can use 3rd-party modules like @Macrura's Settings Factory (but oops, SF doesn't support image fields). Or we can create a dedicated "defaults" page with dedicated "defaults" template having all necessary fields... hmm, looks like a patch, yes? At last, we can give up and use some hardcoded image urls (yes, it's "patchy" again!).

Using a kind of $page->template->image could be a much better solution. Let's imagine a second set of data fields bound to any template. The first one represents the fields used like $page->myfield. The second one could be used in the following way: $page->template->myfield or even $template->myfield. This approach may give us much more flexibility than PW already has, and I don't suppose it should be too complex to implement. Maybe it will be reasonable to make a module offering this new functionality. Think I possibly could do this... but would like to see the community reaction first.

So what do You think friend? Is it worth doing or not? Thanks in advance for any opinion.

[da²]

Hey,

I see your idea like having static properties, instances are pages and static properties are on template.
I don't know it this is a good idea, on my side, since I discovered custom page classes I declare this on UserPage for example:

public function getAvatar(): string
{
    return $this->avatar ?: wire()->config->urls->templates . 'img/default-avatar.png';
}

I could also have the default avatar on a generic configuration page.

[zoeck]

I'm not entirely sure, but wouldn't that be a great usage for custom page classes?

Blog Post from Ryan: https://processwire.com/blog/posts/pw-3.0.152/#new-ability-to-specify-custom-page-classes

 

And bernhards Video:

 

[theoretic]

On 12/12/2023 at 5:20 PM, da² said:

Hey,

I see your idea like having static properties, instances are pages and static properties are on template.
I don't know it this is a good idea, on my side, since I discovered custom page classes I declare this on UserPage for example:

public function getAvatar(): string
{
    return $this->avatar ?: wire()->config->urls->templates . 'img/default-avatar.png';
}

I could also have the default avatar on a generic configuration page.

Thank You @da²! Both ways are usable. But I still think it's a bit "patchy", especially hardcoding the paths/URLs of the default images. Having a "regular" image inputfield allowing to upload images, add some metadata to them etc. could be a much better solution. That's why I had the idea of creating the second set of per-template fields.

[theoretic]

On 12/12/2023 at 5:44 PM, zoeck said:

I'm not entirely sure, but wouldn't that be a great usage for custom page classes?

Blog Post from Ryan: https://processwire.com/blog/posts/pw-3.0.152/#new-ability-to-specify-custom-page-classes

Hm, not bad, not bad ) Could be a working solution if we'll extend the default Page class with some extra data. Thanks )

[da²]

On 12/13/2023 at 6:05 PM, theoretic said:

But I still think it's a bit "patchy", especially hardcoding the paths/URLs of the default images. Having a "regular" image inputfield allowing to upload images, add some metadata to them etc. could be a much better solution.

It's hard-coded for now but I will eventually move it to a PW config page, so my clients can change it.

Having it in a template wouldn't help because I highly discourage my clients to go in templates/fields area, it's way too much dangerous for a non-developer (their standard accounts can't access here).