Jump to content

Game plan suggestions

Chris Falkenstein

Recommended Posts

Hello all,

I'm more of a designer and front-end developer, but Processwire has allowed me to extend my offering to more complex solutions for my clients.  And sometimes I find myself not quite sure about the most efficient game plan.  I'd like to share some of the features I need to pull off and maybe you good folks can let me know what you would do.

When I say game plan, I'm referring to setting up the templates, fields and relationships in PW as well as filtering/selecting the content using PW's API.  So here's what I have...

Visitors of the website will be able to find products and product manufactures (among other things, but let focus on just this).  The products will be categorized. One product may have multiple categories.  Visitors can search for products (via search field) and navigate products (via the categories).  I believe this bit is setup as best it can be in PW. I predefined all categories under a page called 'categories'. There are 2-3 levels of categories. When inputting a product I have a page reference field which allow the user to efficiently assign one or many categories.  Pretty straight forward.

This is where I start spinning my wheels in the mud...

In addition to the search and navigation via categories, the client wants to allow visitors to further narrow down the results with filters.  See attached wireframe to get an idea. Imagine Amazon-like functionality. The filters will be things like style, shape, material, size, etc. Not all products will have the same filters though. For example, benches may not have a size attribute, while trash receptacles  will.  So this opens up a couple questions.

  1. How would you set this up in PW so the user can input these bits of data? Keep in mind they differ from product to product.
  2. Wouldn't it be safer to pre-define these attributes and their values?  Probably, but how, like categories, but it's a filter label and its value (e.g. Size, XXXL)
  3. How can I use that data to display the filter options to the visitor? The fact that the filters can differ from product to product is clouding how I see this working.  What needs to happen to find out what filters are available.

See.. Usually it seems like you have a fixed amount of filters, say one is color, and the page just goes through the collection, looks at the color value, and builds a list of options based on that targeted value.  In my case there is no fixed filter that all products use. Attributes/filters can change from product to product.  These attributes need to be identified and a list of options/values for that atrribute need to be made available to the visitor to select/tick to narrow down the results.

Let's start there.  I have more questions, but maybe your feedback will help me clear them up.



Link to comment
Share on other sites

I sounds like what you are trying to build is a multi faceted search that updates the filters and results depending on what the user has chosen or typed. 

I think you are on the right track with the setup you've described, using the Page reference field to apply the categories to each product. The challenge will be how you build the logic of what to show / hide depending on the filters, and combine this into a usable experience. Most of the solutions I've seen are a combination of javascript logic in the front-end that connects to search results via an API.

This project called instantsearch.js is a library of UI widgets for building these type of instant-search multi filter type experiences - unfortunately it only works with a commercial hosted search service (algolia), but it may give you some ideas on how to build your solution (some kind of javascript + api combination).

This e-commerce example looks similar to what you are trying to build…



  • Like 1
Link to comment
Share on other sites

Regarding the filter options in the sidebar, I see a few approaches...

1. Foreach the search results

This will not be efficient and personally I would rule it out. But the idea is that you iterate over all the pages in the search results PageArray and build up an array of unique categories that have been selected in the result pages, then you build your filter options from it.


2. Use the Connect Page Fields module

Say you have the categories from the wireframe above (there are probably more but the principle is the same): Style, Frame, Surface. The child pages (the category options) use the templates "style_item", "frame_item", "surface_item".

Your product template is called "product" and contains three Page Reference fields for selecting these categories named "style", "frame", "surface". You create a Page Reference field "selected_on" which allows the template "product" for selectable pages. You add this field to the templates "style_item", "frame_item", "surface_item".

In the Connect Page Fields module config you make three connected field pairs: "style" <=> "selected_on", "frame" <=> "selected_on", "surface" <=> "selected_on".

In your search results template you get the related categories with something like this:

// find search results
$results = $pages->find($your_selector);

// get categories that have been selected in these results
$related_categories = $pages->find("has_parent=/selects/product-categories/, template!=blank, selected_on=$results");

// build your filter from the related category pages...

If you are limiting/paginating your result items (which you probably will be) you could use a separate $pages->findIDs() query to get just the IDs for use in the $related_categories selector.


3. Use SQL to query the tables of the category Page Reference fields

You'd need a solid understanding of SQL for this approach. See this post for the general idea of how to query a field's table:


  • Like 2
Link to comment
Share on other sites


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...