Using fields more than once in a template

[Sevenupcan]

Hi there,

For one of my templates I have a start date and an end date. Both fields are effectively the same type of input and output. Rather than create two fields can I add the field twice and customise the label in the template? I thought this might be possible using field-template context but realised the problem is that a fieldtype is unique and can only be added once.

This example stems to a bigger concern.

When I create the fields needed for my template, each of my fields effectively serve the same purpose regardless of what template they are on, the only difference is they have different contexts depending on the template. The field-template context option allows me to avoid creating fields like book_title and book_price. As I can just create one field called price. Which means that if I create a new template of movie, I can re-utilise the same field for give different descriptions based on the template. Unfortunately this model stops working when the same fieldtype is needed inside the same template. For example lets say I need two more fields one might be for a featured image and another for generic images I must create a field called featured_image and another one called images. This example might be debatable because you could say that this should be controlled by creating a custom fieldtype module with a checkbox for featured images.

So what are you thoughts on using fields and their modularity?

Lets say you had a site with a shop and a blog. How would create and name your fields? Would you have fields like:

blog_title
blog_body
blog_author
product_title
product_body
product_price

or would you have...

title
body
author
price

ps. I've really enjoyed developing with ProcessWire, for a designer at heart it has been super easy for me to build a site with my own markup without sacrificing the back end. Thank you to everyone who's been involved in it's development.

[diogo]

Hi, and welcome to the forum.

I made exactly this same question to myself, and I think I even asked somewhere in the forum. I don't remember what the answer was, but I think I know the reason why this isn't possible. The thing is that, you have a one-to-one relation between fields and pages on the database, So, although you can give the field a different name on each template, for the database they are always the same field, and so, they just can't be repeated in a row/column logic associated to the same page. Am I right? I hope I'm not saying something completely wrong

I would definitely use the second option.

[ryan]

The thing is that, you have a one-to-one relation between fields and pages on the database, So, although you can give the field a different name on each template, for the database they are always the same field, and so, they just can't be repeated in a row/column logic associated to the same page. Am I right?

You are close on this. You can't actually give a field a different name. A field name is the same no matter what template you put it on. It is a constant. Though you can change the label or description according to the context of a template.

Unfortunately this model stops working when the same fieldtype is needed inside the same template.

Fields are not fieldtypes, they are variables on a page. There are fieldtypes in ProcessWire, and you can have as many of the same fieldtype on a template/page as you want. You do have to create the fields (of your chosen types), and assign them to your template. But just like you can't have two variables in PHP named $foo in the same namespace, you can't have two fields on the same page named 'foo'. If you need another field just like 'foo', then clone it and name it 'bar' or 'foo2' or whatever you want. You can create as many copies as you need. In the admin, Setup > Fields serves as your master directory of all fields in your site.

To take the example further, some types in PHP can contain multiple values, i.e. arrays. The same goes for ProcessWire, as some fieldtypes are multi-value fieldtypes. Examples include page references, files, images, comments. There's also the 'repeater' fieldtype, which appears to throw all rules out the window, but that's in appearance only as it is technically mapping everything within the rules behind the scenes.

Underneath it all, every field maps to a database table, ensuring that everything remains quickly selectable, searchable and consistent throughout the API.

[Sevenupcan]

Thanks Ryan, I really appreciate you taking the time to read my post. I thought the reason would be close to what you and diogo talked about.

Can you offer any insights or advice into how you manage your fields and fieldtypes?

I guess the idea of copying the same field is only weird to me because you can see them altogether in a universal list, but if you created these fields from within a template they might look like the same field but underneath it, they would probably have their unique IDs to keep them separate.

I just wanted to be sure I wasn't going against the DRY method.

Many thanks for your time.

[apeisa]

I guess the idea of copying the same field is only weird to me because you can see them altogether in a universal list, but if you created these fields from within a template they might look like the same field but underneath it, they would probably have their unique IDs to keep them separate.

You cannot create new fields within a template. You only choose which fields you add to the template. And the fields you can choose from are the ones you (or system has) created already.

I would say that "best practice" (well, at least I have found it good ) regarding fields and templates is this:

-use generic field names whenever they make sense. Good reusable fields are usually named like this: summary, body, image, images, files, featured_image etc...

-Don't re-use the field, if it wouldn't make any sense without changing the label. I mean that don't use field called "summary" if it really means "Requirements for the job". Just create a new text field called "requirements" and use that. Yes, this will "pollute" your universal field list, but you do not want to write code like this:

<?php
echo "<div class='job_requirements'>$page->summary</div>"; // summary keeps the requirements...
echo "<div class='how_to_apply'>$page->body</div>"; //body keeps how to apply...
echo "<div class='other_information'>$page->headline</div>"; // headline has other information

Template field context is a new thing and I want to think the label editing there is just for to give end users a better experience. For things like changing "Title" to "Name of the city" etc.

[Sevenupcan]

You cannot create new fields within a template. You only choose which fields you add to the template. And the fields you can choose from are the ones you (or system has) created already.

Sorry I should have said "but if you could create fields from within templates".

Also this:

<?php
echo "<div class='job_requirements'>$page->summary</div>"; // summary keeps the requirements...
echo "<div class='how_to_apply'>$page->body</div>"; //body keeps how to apply...
echo "<div class='other_information'>$page->headline</div>"; // headline has other information

Helps me visualise how fields work better with data context driven names.

Many thanks for your comments Antti.