Jump to content

Matrix/table built with children of two pages


Recommended Posts

I don't now if this is already possible to build with one of the available modules/fieldtypes. I so far tried Table, PageTable, Repeater and Multiplier but couldn't get them work exactly as I want.

I'm looking for a way to create a matrix/table that uses the children of two pages to build the row and column headers. In my case (an online shop), I want it to take the children of the page product variants and the children of the page currencies. In the end, it should render a matrix/table, where I can enter a fixed price for every variant in every currency.

Has anyone ever done something similar? Is there a fieldtype for this?

Link to comment
Share on other sites

Not sure what you want to archive with that but I think there is a better way to solve that. So could you add some more details?

I want to be able to set the price of a product (e.g. a T-Shirt) by its category (well, T-Shirts). Now for all products within the category T-Shirts, there are the same options (size S, M, L and color red, green, blue). So if I go to the category page of T-Shirts, I want a matrix that lists all the options of this product category and then let me set a price for each currency I'm offering the product in. I hope that's understandable :)

Link to comment
Share on other sites

Thanks for the tip, but I don't think that module can help me. It doesn't create the rows/columns based on the children of pages (so that I can add another child page and that the matrix would be extended automatically). If I would do it manually, I would prefer the fieldtype table.

Link to comment
Share on other sites

I want to be able to set the price of a product (e.g. a T-Shirt) by its category (well, T-Shirts). Now for all products within the category T-Shirts, there are the same options (size S, M, L and color red, green, blue). So if I go to the category page of T-Shirts, I want a matrix that lists all the options of this product category and then let me set a price for each currency I'm offering the product in. I hope that's understandable

I am still not 100% clear, but it sounds to me like maybe you don't want a new way of storing product/price info, but just a new way of entering it. It sounds like you still want the data stored in the product's page fields. Is that correct?

If so, you might be looking at implementing something custom with AdminDataTable (core module often used by other modules), or HandsOnTable. Here are a couple of links for inspiration:



and of course the ProTable field type. 

I think with ideas from those you could build a process module that builds an editable table using the product/price info from the fields from product pages. When saving the table, the data would be written back to the appropriate pages.

Am I on track at all?

  • Like 1
Link to comment
Share on other sites

It might help if I add a screenshot of what it looks like if it's manually built with the fieldtype table. The downside is that I have to create all possible variations by hand, and that if I add a new currency or a new product option, it's not populated automatically to this table.

One solution (at least for the product options size and color) to this would be if the fieldtype table would allow columns to be of the type page and then output them as radios/checkboxes.

It would be even cooler of course if the variants (all possible combinations of the product options size and color) would also be built automatically ;)


Link to comment
Share on other sites

It sounds like you still want the data stored in the product's page fields. Is that correct?

No, the product itself (T-Shirt) is assigned to a category (T-Shirts), and all the pricing information is stored within the category page.

  • Like 1
Link to comment
Share on other sites

It really sounds like you want ProFields, the table plugin is extremely flexible. Are you wanting to make changes to all of you separate pages via one template, or are you still wanting to edit all of the pages directly?

As I mentioned at the beginning, I already tried to use the ProFields Table, Multiplier and Page Table. The screenshot in my post above is actually from the ProFields Table fieldtype.

It should be one template in the end that I can use on different pages (-> product categories).

Link to comment
Share on other sites

Are you basically creating a main page and the variants are children of that page?

So, they all have the same prices, for instance, but other variations are possible with the children?

If so, you could do something like this:

Parent - T-Shirts

Field: Default price (USD)

Child page - 

T-shirt crazy style

Field: override price (USD) - normally left blank.

In your template for the child, you can call the price from the parent page (see the API for parents), checking whether the override price as been set. If it hasn't you display from the parent, if it has been set, you display from the child.

You can do this will any field - set defaults in the parent, but allow for overrides for the children.

  • Like 1
Link to comment
Share on other sites

I'm not sure if I can follow your example. Let me add another screenshot to clarify my setup. I have a product page (T-Shirt) that is displayed on the frontend. Then, there's the Tools page (only for backend), where I define a products attributes and categories.

Now, within the page T-Shirts (which represents a product category) I want to be able to have the table I mentioned above where I can set the prices for each product variant of the attributes size and color – pretty much as in my other screenshot above.

The product page T-Shirt then actually just has a drop-down to select a product category (in this case T-Shirts).


Link to comment
Share on other sites

Okay, I am probably going to get this wrong, but let me think this through.

You want a list of attributes, but without prices - you add the price later in the T-Shirt page?

So, for instance, you could have a repeater (possibly better with a page table) that has two fields:

Page Field, picking up a list of attributes and a text field for the price.

You add a line, choose the attribute type from the page field drop down (must be single select, of course) and you put in your price.

You can then loop through the repeater to list out all the attributes and associated prices for that product..

When it comes to a category, if you are creating the product page under its parent, then it already has a category - its parent! :)

Oh, I should add, that the attributes can have more than just a title - they can have images, extra info, anything you like as they are pages in their own right - but you only use the title field when selecting them.

  • Like 2
Link to comment
Share on other sites

I think we got tangled up in my use case. Maybe I have to go back to the beginning, because what I'm looking for has different use cases in my opinion.

What I'm looking for is to have some kind of matrix fieldtype where I can define the row and column headers. Now, these headers should automatically be built by the page title of definable pages (actually their respective child pages).

Say I have two pages (Size and Color) with the following child pages:


   – S

   – M

   – L



   – Red

   – Blue

   – Green

Now in this matrix fieldtype, I could apply Size to be the row header and Color the column header. This would result in a matrix like this:

   | Red | Blue | Green |


S  |     |      |       |


M  |     |      |       |


L  |     |      |       |


Now, if I add another child to the page Color (e.g. Black), the matrix would be automatically extended: 

   | Red | Blue | Green | Black |


S  |     |      |       |       |


M  |     |      |       |       |


L  |     |      |       |       |


Is there already a fieldtype like that?

Link to comment
Share on other sites

OK, let me wade in as well :-)


I don't think there is a module like that. Does this have to be a fieldtype or would a ProcessModule do? i.e. a custom view/page within the admin. The table cells would be input fields that contain any data you want. This is a similar idea to what Adrian mentioned above. The ProcessModule would just be a means of easily entering your data but these would be stored within the fields of your pages themselves. The advantage with this approach is that you could have a table of all your products, then clicking on an edit button/link would bring up the matrix. This would be built on the fly based on the number of your 'child pages'...Anyway, just thinking out loud here...

  • Like 1
Link to comment
Share on other sites


Creating the matrix is the easy part. The problem is deciding where and how that data will be stored. At the end of the day you want to be able (preferably) to easily query your data using PW API, say find the price of 'small red' t shirts.... The problems with my solution are, e.g. where do you store the price of a 'Large Blue' t-shirt? If you had a fixed number of variations, fine, but in your case they are dynamic. A 'pink' variant can be added later and you want to be able to accommodate that...hmm...

Maybe the fieldtype route is the way to go :-). I am not sure how Martijn's FieldtypeJson works but it seems to be able to accommodate any number of columns. If you want to go down that route, then you can adjust that Fieldtype to suit your use case. It's a matter of rewriting the code and renaming the module class. Of course, you need to know what you are doing... :-). There's also Ryan's event fieldtype that could be modified to do what you are after...

Link to comment
Share on other sites

Me again... :-)

Will your product sizes be fixed, i.e, always S, M, L? If yes, can your matrix be like this instead?

           |  S  |  M   |  L   |
Red   |      |        |       |
Blue    |     |        |       |
Green  |     |       |       |
Black   |     |       |       |
meaning....only add rows with new variants but columns will be fixed...
  • Like 1
Link to comment
Share on other sites


I like the thinking but you never know when an extra X will get added to a size; particularly medium. In other words, I suspect the table would need to accept changes in either dimension.

How about simply concatenating the x and y variable to give a key that can then have a simple value stored against it? So you'd end up with a table that had an indexed product page id, an indexed "key" and an "amount" column. The function to make the key would just do something like...

function makeKey($size, $variation)
    $size      = wire()->sanitizer->name($size);
    $variation = wire()->sanitizer->name($variation);

    $key = "$size/$variation";

    return $key;
  • Like 2
Link to comment
Share on other sites


Good point. I was thinking along those lines (the indexed key) but wasn't sure how search would work (i.e. grab 'red small' t-shirts) using PW API and related performance issues. Back then, I was thinking storing the pairs using json like syntax $size:$variation - something similar to yours. 

Link to comment
Share on other sites


Just to answer my own question about how the search for the 'indexed key' would work [database side of things] - this could either work  the way PW handles repeater fields - data stored as comma separated integers (1234, 5688), i.e. $size,$variation ID pages respectively as you suggested, or why not store them as PW multiple page fields - i.e. a row for each addition, consisting of page id (integers) i.e. 

E.g. assuming Red = ID 1124, small = 2545 and medium = 2745

$variation    $size   $amount

1124           2545    $20

1124           2745   $10

On the inputfield side of things, the user will still be able to see a table similar to the one I posted above that would grow both vertically and horizontally with each new addition of size and variation...Of course horizontal growth could get very messy very quickly... :-)

Edited by kongondo
  • Like 2
Link to comment
Share on other sites

Hi Charger,

I thought you'd given up on this given your absence :P   :-)

I'd started to work on something (it was actually working, i.e. dynamically adding rows and columns - except for saving to the DB) but then I hit a few snags and was wondering whether this wouldn't be best achieved by a dedicated ProcessModule or an extended PageTable....If you are about later, I could try and explain...

ps: low-level or high-level?? :unsure: 

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Similar Content

    • By MarkE
      This fieldtype and inputfield bundle was built for storing measurement values within a field, rendering them in a variety of formats and converting them to other units or otherwise modifying them via the API.
      The API consists of a number of predefined functions, some of which include...
      render() for rendering the measurement object, valueAs() for converting the value to another unit value, convertTo() for converting the whole measurement object to different units, and add() and subtract() for for modifying the stored value by the value (converted as required) in another measurement. In the admin the inputfield includes a checkbox (which can be optionally disabled) for converting values on page save. For an example if a value was typed in as centimeters, the unit was changed to metres, and the page saved with this checkbox selected, said value would be automatically converted so that e.g. 170 cm becomes 1.7 m.

      A simple length field using Fieldtype Measurement and Inputfield Measurement.
      Combination units (e.g. feet and inches) are also supported.
      Please note that this module is 'proof of concept' at the moment - there are limited units available and quite a lot of code tidying to do. More units will be added shortly.
      See the GitHub at https://github.com/MetaTunes/FieldtypeMeasurement for full details and updates.
    • By tcnet
      File Manager for ProcessWire is a module to manager files and folders from the CMS backend. It supports creating, deleting, renaming, packing, unpacking, uploading, downloading and editing of files and folders. The integrated code editor ACE supports highlighting of all common programming languages.

      This module is probably the most powerful module. You might destroy your processwire installation if you don't exactly know what you doing. Be careful and use it at your own risk!
      ACE code editor
      This module uses ACE code editor available from: https://github.com/ajaxorg/ace

      This module uses the JavaScript dragscroll available from: http://github.com/asvd/dragscroll. Dragscroll adds the ability to drag the table horizontally with the mouse pointer.
      PHP File Manager
      This module uses a modified version of PHP File Manager available from: https://github.com/alexantr/filemanager
    • By tcnet
      This module implements the website live chat service from tawk.to. Actually the module doesn't have to do much. It just need to inserted a few lines of JavaScript just before the closing body tag </body> on each side. However, the module offers additional options to display the widget only on certain pages.
      Create an account
      Visit https://www.tawk.to and create an account. It's free! At some point you will reach a page where you can copy the required JavaScript-code.

      Open the module settings and paste the JavaScript-code into the field as shown below. Click "Submit" and that's all.

      Open the module settings
      The settings for this module are located int the menu Modules=>Configure=>LiveChatTawkTo.

    • By tcnet
      Session Viewer is a module for ProcessWire to list session files and display session data. This module is helpful to display the session data of a specific session or to kick out a logged in user by simply delete his session file. After installation the module is available in the Setup menu.

      The following conditions must be met for the module to work properly:
      Session files
      Session data must be stored in session files, which is the default way in ProcessWire. Sessions stored in the database are not supported by this module. The path to the directory where the session files are stored must be declared in the ProcessWire configuration which is by default: site/assets/sessions.
      Serialize handler
      In order to transform session data easier back to a PHP array, the session data is stored serialized. PHP offers a way to declare a custom serialize handler. This module supports only the default serialize handlers: php, php_binary and php_serialize. WDDX was dropped in PHP 7.4.0 and is therefore not supported by this module as well as any other custom serialize handler. Which serialize handler is actually used you can find out in the module configuration which is available under Modules=>Configure=>SessionViewer.

      Session data
      The session data can be displayed in two different ways. PHP's default output for arrays print_r() or by default for this module nice_r() offered on github: https://github.com/uuf6429/nice_r. There is a setting in the module configuration if someone prefers print_r(). Apart from the better handling and overview of the folded session data the output of nice_r() looks indeed nicer.

      ProcessWire module directory
    • By Robin S
      Repeater Easy Sort
      Adds a compact "easy-sort" mode to Repeater and Repeater Matrix, making those fields easier to sort when there are a large number of items.
      The module also enhances Repeater Matrix by allowing a colour to be set for each matrix type. This colour is used in the item headers and in the "add new" links, to help visually distinguish different matrix types in the inputfield.
      A Repeater field

      A Repeater Matrix field with custom header colours

      Easy-sort mode
      Each Repeater/Matrix item gets an double-arrow icon in the item header. Click this icon to enter easy-sort mode.
      While in easy-sort mode:
      The items will reduce in width so that more items can be shown on the screen at once. The minimum width is configurable in the field settings. Any items that were in an open state are collapsed, but when you exit easy-sort mode the previously open items will be reopened. You can drag an item left/right/up/down to sort it within the items. The item that you clicked the icon for is shown with a black background. This makes it easier to find the item you want to move in easy-sort mode. You can click an item header to open the item. An "Exit easy-sort mode" button appears at the bottom of the inputfield. Configuration
      In the field settings for Repeater and Repeater Matrix fields you can define a minimum width in pixels for items in easy-sort mode. While in easy-sort mode the items will be sized to neatly fill the available width on any screen size but will never be narrower than the width you set here.
      In the field settings for Repeater Matrix you can define a custom header colour for each matrix type using an HTML "color" type input. The default colour for this type of input is black, so when black is selected in the input it means that no custom colour will be applied to the header.
      The easy-sort mode is only possible on Repeater/Matrix fields that do not use the "item depth" option.
  • Create New...