trying to grasp field concept

[DarsVaeda]

I still try to grasp the "field" concept of processwire and yet did not manage to do so. Maybe someone can help me to understand the concept?

I have 14 templates currently. Most of these have fields that are very specific to a template so I wasn't able to reuse fields much. It's not like every template has: an input, a link, a list and an image. Thus I already end up with ~150 fields aka 150 tables. Imagine opening the fields menu...

Let's say I need to make a new page that has an html form. The form has 15 input fields. So I need 15 x titles, 15 x placeholder texts at least, maybe error & success messages for JS validation and so on.
This means I need at least 30 processwire text fields just for this one template / page.

I could use something like a repeater but I don't find this very usability friendly for something like forms for instance.

 

How would you go about this? Do I miss something that would make my life more easy here or is processwire just not made for that use case?

 

[bernhard]

15 minutes ago, DarsVaeda said:

Do I miss something that would make my life more easy here or is processwire just not made for that use case?

Indeed I think that's a very special use case. Do you know FormBuilder?

[DarsVaeda]

Yeah I've seen form builder. Though this was just an example I had recently. It is not restricted to forms though.

[bernhard]

So I don't really get your question. For a customized input in general you need a customized field.

You can tag them, then they are grouped in the fields list. You can also use https://processwire.com/api/modules/profields/textareas/ and you can read the blog post here: https://processwire.com/blog/posts/making-efficient-use-of-fields-in-processwire/

[Robin S]

36 minutes ago, DarsVaeda said:

I have 14 templates currently. Most of these have fields that are very specific to a template so I wasn't able to reuse fields much. It's not like every template has: an input, a link, a list and an image. Thus I already end up with ~150 fields aka 150 tables.

That does sound like a lot of fields. Why is it that the fields can't be reused? You do realise that you can set things like label and description (and loads more since this update) in template context? So you can have a field "text_1" and label it "First name" in one template and "City" in another template, etc.

[Zeka]

By the way there is template context for fields. By default, there are not many options that you can override, but by setting advanced=true you would be able to override all options.

https://processwire.com/blog/posts/pw-3.0.87/#new-field-template-context-settings

[AndZyk]

Hello @DarsVaeda,

I always try to reuse as many fields as possible so I don't end up with too many fields.

I usually make one field for a textarea, a text, one image, multiple images etc.

Tagging them as mentioned helps you to keep them organized.

If you ever need multiple fields of the same type in one template, you can always make specific fields, but most of the time you can avoid this by using general fields.

31 minutes ago, DarsVaeda said:

Let's say I need to make a new page that has an html form. The form has 15 input fields. So I need 15 x titles, 15 x placeholder texts at least, maybe error & success messages for JS validation and so on.
This means I need at least 30 processwire text fields just for this one template / page.

I know this is just an example, but why would make fields for a form in the first place? Will the titles or placeholders of the inputs change and therefore should be dynamic? For this you could try the commercial module FormBuilder. But I think it is unlikely that the form will change much and therefore I would define everything inside the template. ?

Regards, Andreas

[DarsVaeda]

Yes I know about template context of fields. That's why I have something like: text_1, text_2, text_...n in my field list.

@AndZyk

Unfortunately they change a lot as they are tweaked constantly. But if I would place it into the template, I as a developer, would have to change, test and deploy them. I just want the content person to do this without having me involved in it.

I'll try to see if I can produce an example to make it more clear, but maybe I'm just on the wrong track ?

----

example:

I have a page that has several content areas. So first of all I made fieldsets to group them. (Here I could optimize a bit by making general fieldsets instead of landingpage specific ones but I'd still need several of them)

Each set contains a number of textareas that have specific, non-generic content. That's why they are grouped.

Code looks something like this.

<section class="content background_dark">
  <div class="container">
      <div class="row">
          <edit textarea_number_1><?= $page->textarea_number_1 ?></edit>
      </div>
      <div class="row">
          <edit textarea_number_2><?= $page->textarea_number_2 ?></edit>
      </div>
      <?php if (!empty($page->textarea_number_3)) :?>
          <div class="row">
              <edit textarea_number_3><?= $page->textarea_number_3 ?></edit>
          </div>
      <?php endif; ?>
  </div>
</section>

 

[flydev]

40 minutes ago, Robin S said:

That does sound like a lot of fields.

Concretely, what is the downside to have a lot of fields ? In a setup I have 12 templates and 56 fields (not optimized) and reading the link given by @bernhard I fear your answer now ?

[DarsVaeda]

I don't see any performance issues so far. It's merely a "keeping the overview" thing right now. I don't think there would be any impact in having like 2000 tables in the database. Though it kinda sucks to have one table for one field in one template in one page that has just one row.

[Robin S]

4 minutes ago, flydev said:

Concretely, what is the downside to have a lot of fields ?

Just the things that Ryan says in the blog post mentioned above:

Quote

• Every field you create represents an additional variable you [the developer] has to keep track of. Sites with fewer fields are easier to maintain over time, and easier to collaborate on with other developers.
• The fewer fields you have, the more reusable your output code tends to be. If your fields tend to be more general purpose rather than template-specific, you'll be able to write reusable code that can output a broader range of page types.
• ProcessWire loads data for fields on-demand. If you've got 200 fields on a template and your page is outputting all of them, that will take longer than if your page had 50 fields. The more fields you have in your system, the more potential memory usage and overhead on the server. Granted you may not be able to tell, but the point is that every field takes up a little bit of space in memory.

But I don't think it's anything to worry about for most websites. Besides this topic I haven't heard of anyone having any problems with large numbers of fields.

[Soma]

You haven't heard but it's there, we've been there.

It's some weak point of PW. A template with 50 fields and you output the data you end up having 50+ queries just for one page. Every echo $page->yourfield does a DB query. If you list or render other data from other pages etc, you can easily have 200+ queries just for one page. It doesn't all scale well especially with lots of fields and stuff going on. Add with heavy traffic and you end up in performance problems very fast for a complex site (PHP & mySQL not being the fastest). Caching is one thing, but sometimes you can't cache everything, because you have logged in users etc.

Edit: Just because you haven't heard, doesn't mean it's not there. Ryan also sometimes has this misconception, that if he doesn't know/hear about it, it's not existent. Most people don't always tell, they just move on. ?

[bernhard]

Thx for that insights @Soma

9 minutes ago, Soma said:

Ryan also sometimes has this misconception

I don't think that's a misconception. He has limited time so he does focus on topics that either he or the community needs - if he has no problems and the community doesn't report any why should he invest his time then?

[Robin S]

18 minutes ago, Soma said:

Every echo $page->yourfield does a DB query. If you list or render other data from other pages etc, you can easily have 200+ queries just for one page.

Although if you knew that you had a lot of fields to load for a particular page, or were rendering a lot of fields from other pages, then you could use the load options for $pages->getById() - which can be passed also via $pages->find(), $pages->get(), etc - to autojoin the fields you know you will be accessing. That will cut down the DB queries a lot.

[Soma]

6 minutes ago, Robin S said:

Although if you knew that you had a lot of fields to load for a particular page, or were rendering a lot of fields from other pages, then you could use the load options for $pages->getById() - which can be passed also via $pages->find(), $pages->get(), etc - to autojoin the fields you know you will be accessing. That will cut down the DB queries a lot.

That's true, thanks for mention it.  But Autojoin can also be counter productive/ make things worse.

[AndZyk]

4 hours ago, DarsVaeda said:

example:

I have a page that has several content areas. So first of all I made fieldsets to group them. (Here I could optimize a bit by making general fieldsets instead of landingpage specific ones but I'd still need several of them)

Each set contains a number of textareas that have specific, non-generic content. That's why they are grouped.

In this example, if you already know that you need one field type multiple times, you could just use a repeater field. Inside this repeater field you could repeat a textarea field and maybe a page title field for better labeling the repeater items. That would be three fields in total instead of maybe 50. ?

I know it is not always that easy but repeaters and the repeater matrix is one possibility to reuse fields on the same template.

 

4 hours ago, DarsVaeda said:

<?php if (!empty($page->textarea_number_3)) :?>

You could shorten this to:

<?php if ($page->texarea_number_3): ?>

 

[DarsVaeda]

2 minutes ago, AndZyk said:

I know it is not always that easy but repeaters and the repeater matrix is one possibility to reuse fields on the same template.

For me repeaters is no problem. And it is no problem for front-end editing. But some users don't use front-end editing and for some cases f-e-d isn't even possible. That's why I can't use them. Some users can't grasp the concept and fail to link where the content goes. Also you can't disable reordering afaik and that also puzzles users.

Using repeaters would help in most cases actually bringing down the field count a lot.

[Robin S]

7 hours ago, DarsVaeda said:

Also you can't disable reordering afaik and that also puzzles users.

https://modules.processwire.com/modules/limit-repeater/

[OLSA]

Hello for all,  here is module what I just posted in forum module section. It can store/hold multiple fields values in JSON format, and because of that it can help to reduce total number of fields in project, total number of queries at front-side, and reduce DB storage space.

Regards.

[gmclelland]

I haven't tested these yet, but to reduce the amount of fields you could try:

• http://modules.processwire.com/modules/fieldtype-yaml/ 
• https://processwire.com/blog/posts/functional-fields/ formerly called Static fields https://processwire.com/blog/posts/processwire-updates-and-new-field-types/.  Note this is a paid module.
• All the other Profield modules https://processwire.com/talk/store/product/10-profields/

[Zeka]

Little bit OT. 

As the former user of Seblod (Cck extension for Joomla) I remember that they have quite flexible storage setting for fields.

https://www.seblod.com/resources/manuals/advanced/understanding-the-storage

Would be super cool to have some kind of module that can provide such functionality.

[DarsVaeda]

I think I asked this already in another thread. But couldn't this be solved by allowing fields to be reused in a template?

So instead of having to generate multiple fields (like the text areas in my example) you generate one field but are able to use that one field several times in your template but with different values.
You would need to put one more level into the table to know which field is which value. And maybe allow to set an identifier for each field so you can specifically call it in the template rather than having to do something like "$page->text_area[x]".

Isn't this how repeaters works anyway?

[OLSA]

5 hours ago, DarsVaeda said:

 

Isn't this how repeaters works anyway?

DarsVaeda sorry your project task It's not perfectly clear to me, but answer on last question is that repeaters create pages. That pages you can find deep inside Admin page tree (under title "Repeaters"). Repeater field has own table just like other PW fields and changes are happen inside cell "data" (rewirite when adding new repeater items), but also when we press "Add new" that add rows inside table_pages. Or, in short, repeaters also create nested pages. To get content from some repeater field PW need to get data from more rows inside more tables. Because of its complexity repeaters use more resources.

----

"...you generate one field but are able to use that one field several times.."

I think that someone write about commercial, here is textareas maybe that?

-----

I read this topic few times, and still it's not clear to me what you want to get, but if I want to get less fields (less database tables) and if that task about number of text-areas is static/fixed  and never changed (eg. 15 textareas inputfields) I would go with custom fieldtype (eg. with columns "text_area_1", "text_area_2"...).
On the other side, if that number is not fixed, and need flexibility, I would go with custom JSON field type. JSON is great in many cases, and as example you can on the fly create "columns/cells", or change/add new atributes, etc...

----

There is and one alternative solution, in theory I think that would work. In short, there is always option with PW to create fields using pages. If this is confused, concept is that inside pages tree, eg. "Fields types" we store pages with "field-types" definitions (eg: textarea-type-1: name, label, placeholder, maxchar, notes, pattern...), later using custom module (to add desired "fields" to "form-template") and through foreach dynamically - on page - create input fields / interface. After submit content could go to some textarea+markup divider in text format, or different, stored in JSON format.

Regards.

[teppo]

On 8/11/2018 at 2:58 PM, DarsVaeda said:

I think I asked this already in another thread. But couldn't this be solved by allowing fields to be reused in a template?

So instead of having to generate multiple fields (like the text areas in my example) you generate one field but are able to use that one field several times in your template but with different values.
You would need to put one more level into the table to know which field is which value. And maybe allow to set an identifier for each field so you can specifically call it in the template rather than having to do something like "$page->text_area[x]".

Isn't this how repeaters works anyway?

As @OLSA explained above, that's not how Repeaters work. In order to connect more than one instance of a specific field, behind the scenes they create pages, and store field values on those new pages.

The change you've suggested here wouldn't be a trivial one, at least. Calling field value ($page->field_name) when multiple fields have the same name is one issue, and selectors are another ($pages->find("field_name=value")). Probably a few other issues as well, but at least in those cases we'd need to do a lot more – that would ultimately add a ton of complexity for a use case that, in my humble opinion, is very rare.

Now, getting back to your original issue:

Although I think I get what you're trying to do here, you're approaching this in a really "non-ProcessWire" way. When using any given system, you'll eventually run into things that work in a certain, perhaps unique way – and that's where you can either try to work with the system, or work against it. The latter, obviously, is not particularly productive approach.

In ProcessWire fields are most useful (considering data architecture, use in selectors, keeping your code readable, and so on) when each of them has a specific and semantic meaning: "this field stores phone number, so we'll call it phone_number – and this one stores a first name, so let's call it first_name". When you need to reuse multiple fields on a single page, we're often talking about some sort of a content block builder, even if in your case you need to predefine the number of items, the order of items, and so on.

For such constructs ProcessWire provides two options right out of the box, Repeaters and PageTable. Both have their own benefits, but it essentially boils down to this: while Repeater UI is more embedded to the Page editing workflow, PageTable uses modal windows for editing content – and while PageTable supports multiple different content types, Repeaters only support one (although you can use showIf settings to define rules governing when a specific field is displayed).

Commercial RepeaterMatrix field (part of the ProFields package) essentially provides the best of both worlds, at least in my opinion: in-context editing like Repeaters and proper support for multiple content types. That's what I usually use for my client sites when a content block builder is required. If you're looking for a free (as in beer) solution, PageTableExtended is definitely worth checking out as well.

To summarise: it seems that your use case would greatly benefit from the use of a repeating field type (Repeater, PageTable, or RepeaterMatrix). If the number of items and the order of them is the main issue and things will fall apart if those two are wrong, I would try to find a programmatic solution to that: use hooks to force each new page to have specific items – and when a page is saved, make sure that those items are still there. You could also hide or disable features that sort items or remove/add them using some simple JS or CSS, which you can embed yourself (via hooks), or by using a module such as Admin Custom Files.

Finally, if you're adamantly against the idea of using a repeating fieldtype, one more (commercial) solution you should check out would be the Table fieldtype, which is also included in the ProFields package. It's essentially a flexible fieldtype you can use to create new custom fieldtypes on the fly, so more or less what OLSA suggested above, but with a nice GUI.

This way you can quite easily make each of your fieldsets a single field, and you'd have much fewer fields in total.

---

Hope I didn't come out too smug, but while I do sympathise with your struggle with this particular use case, in my opinion it is something that ProcessWire already supports – it just doesn't do it exactly the way you'd like to. Also: while this is no doubt among the use cases that can be solved using ProcessWire, in some cases you have to face that ProcessWire might not be the best possible tool for the job. Given the wide variety of web based solutions, such situations are bound to pop up eventually ?