Proper way to build this with processwire

[flavy]

Hi,

I need to build a website where I will have different product details like size, color etc. The problem is that I am not sure what is the best way to do this because there will be arround 50 different fields needed for each product and I'm trying to get best of both worlds, to have a good backend (to be easy to complete all the fields by the editors), and to be good from the performance point of view.

I think about some ways :

1. Regular fields, one for each thing ? The problem is that there will be at least 50 fields for each product and when I need them all it will probably have an impact on the performance, even more when I'll want to filter based on some values (like a specific color and a size smaller than X)

2. Page refferance ? As some of them will have just few options like the category the product is part of I am thinking I can do this for almost all fields (just not for the ones like size etc)

3. Repeater field ? The problem might be that it is hard for editors to complete both the "label" and the value for example and seems like repeater fields are for different things.

4. The pro fields table module ? Is this what it is meant for ?

Did any of you had to build something similar ? How does processwire handle pages with more than 50 fields (or probably to be sure in future it might have more, something arround 100 fields), keeping in mind that there might be a total of 2000-3000 pages of products. 

Also I need almost all of them to be search-able and to be able to compare any 2 (or a bigger number) of products and show which one has a bigger size for example, so the values have to be somehow separated from the labels.

Any idea is welcome. Thanks

[apeisa]

100 fields is no problem. It seems though like a project that would gain great benefit from ProFields.

[flavy]

Thank you for your reply. I didn't completly understood how profields works and how it whould help but will try to look some more at the videos. Another problem is that I can't buy the module now, I am getting this error always:[#30X117] Could not locate invoice.

Tried to pay with both, CC and paypal, same error for both.

[Craig]

That sounds like a great project

To make the UI a bit more organised with those fields, you could also break them up into tabs using a FieldsetTab (already available - just add new field "FieldsetTabOpen" and add to templates), and put fields in columns using AdminTemplateColumns.

It might make sense to use inputfield dependencies to show and hide inputs based on certain conditions.

Page reference fields: you should probably use these for categories, but you could also use them for size, colour or other product variations as well.

[diogo]

Also I need almost all of them to be search-able and to be able to compare any 2 (or a bigger number) of products and show which one has a bigger size for example, so the values have to be somehow separated from the labels.

You can even get the product that has the biggest size of all $pages->find("template=product,sort=-size,limit=1")->first();

[flavy]

Great responses so far, thank you!

Diogo, I was more interested into comparing two or more specific products that user choose, not to get the bigest of all. I am concerned about the number of queries that are needed for this because I will need 100 fields x the number of products to compare. Are there ways to get all fields at the same time using a single database query (or do the api do exactly this)?

I think I will set a maximum of 5 products to compare at a time (even 3 if there will be a performance hit), but I am still unsure how processwire works under the hood and if for 3 pages with 100 fields each it will query the db for each field or how it works (it gets all fields with one query or how) . Also is there any way to easily see what queries are run and how much memory they use (also the time needed) when using the api?

If someone can explain those things a bit I think it will be easier to decide exactly which is the better way for my needs.

Thanks

[ryan]

Flavy, I wouldn't worry too much about quantity of queries. Instead, focus on the end results and how fast it performs. Quantity of queries means very little as you can have a 100 well optimized and/or simple queries that execute faster than a single complex one. So counting queries is more than often a waste of time, and trying to combine queries can even slow things down.  

The way that ProcessWire works is that it loads data on demand, as it is requested, using simple and well optimized and indexed queries that are very fast. That is, unless you check the box for "autojoin" in your field advanced settings. When checked, it will join that field's data with the original page query. For instance, we have the "title" field set to autojoin by default, since this is one field that is most likely to be accessed on any given page object. However, whether or not autojoin speeds up anything is debatable, so I would use it sparingly. It has potential to speed things up in some cases, but at the cost of memory, and cost of loading data unnecessarily. As a result, we only recommend it for fields that will always be accessed on every instance of a page. Beyond the obvious "title", examples might include a date or summary field used when outputting lists throughout a site. For the most part, I don't use the autojoin option at all anymore except for "title" fields because there is rarely a measurable benefit, but there is always a measurable drawback (loading stuff in memory that may or may not be used). 

You might also want to look at the "Cache" Fieldtype, which is included in the core. It's something that people rarely use, but it is directly applicable to your question. It caches all of your fields for a given page (or at least those you select) into one. It's more often used to combine several text fields together for searching purposes, but it can also be used to keep all your page data together in one chunk (and correspondingly, 1 query). Again, it may or may not result in faster performance in the end, but it's another tool worth knowing about and worth experimenting with. 

Other tools I recommend considering are MarkupCache (core module) and Template cache (a feature in any template settings). Or for the best performance, we also have ProCache, which makes your site perform as quickly as static HTML files. Most PW sites don't need much in the way of caching, but if you find you need it or want it, you've got some great options here. 

I agree with Antti that 100 fields will not be a problem. Many of us here regularly deal with more than that. But it also is good to think of fields as a finite resource and something that you want to conserve. While there is no technical limit on quantity of fields that you can have, it's possible for overhead to increase as the number of fields do. This isn't about page loading per se, but about overall system overhead and memory required to manage lots of fields at once. The ProFields package is specifically aimed at reducing the quantity of fields necessary to accommodate a site's data needs. Depending on what those needs are, it has the potential to drastically reduce the number of fields in your system. As a result, I think it makes a lot of sense for the needs you are talking about. You should also look into PageTable (on the dev branch) as a better option to repeaters.