Using a PageField and supply specific data to the PageField's context

[a-ok]

I'm building a website that houses all different kinds of 'lights'. Lights (let's call them 'products') are all pages and a 'product' can have any number of 'light sources'. Each 'light source' is a page and within a 'product' you can use the PageField field to select as many options as you want. Easy.

Each 'product' and 'light source' combination has a unique 'code' but I'm struggling to work out where to add this. It would be ideal if each product has a code and each light source has a code then the total code is them both together... but it's not. A total code is random – there's no 'formula' – so I'm wondering how best to implement this? Ideally it would be some sort of 'Within your product you choose your light source and supply the code at the time of choosing' – but that's not possible.

Do you think, on save, using a hook, it could populate a repeater field or table with the 'light source' pages chosen and each 'row' has a separate field for the code? I need to output this on the front end too but I could cross reference the PageField (light sources) with the hooked repeater and return the total code that way?

Does anyone know if I'm missing something obviously simple to allow this sort of functionality or is my suggestion the best route?

Thanks!

[wbmnfktr]

What's the leading identifier in this whole product-source-total code setup?

1. the product
2. the source
3. the total code

Right now you add sources to a product... but what if you turn this around and add products and sources to a total code?

As I understand it:

• product
  • source
    • ->total code

How I would try it:

• total code
  • product
  • source

With the second setup (product + source = total code) you could use the PagefieldPairs module and sync references to make it available across all products/sources/total codes.

Are there any more details you can share to show the kind of setup and bundling of products and sources?

[a-ok]

It's interesting and really appreciate your reply. The only issue is I try to keep things as three dimensions as possible so no rabbit holes. Product and source are all their own tree so everything is on the same level.

I use @Robin S's PageFieldConnector module which seems to work well but I can't see it being useful in this instance. The total code is only relevant to the product and source code chosen (by PageField at product level) in that context/instance.

[elabx]

I don't understand if the total code is random as in, generated on runtime (like and shop's order id?) or if it can exist as another page and be referenced. 

[dragan]

I read your OP now 3 times, but I'm still not sure I understand the big picture of your "code" usage / need.

The most simple solution (unless I'm overseeing something) would be to use page IDs.

Since every product is a page and hence has a unique ID, and every light source is a page too, you could construct a code like e.g.

P1234LS5001_5002_5003

P = product (page id 1234)

LS = light source(s) (page ids 5001, 5002, 5003)

instead of _ you could use any other delimiter of course.

That way, you can easily identify the "owner" (product) and the "attached" light sources (regex, substr etc.). Instead of page IDs you could also use page-names instead, but IDs are usually more future-proof.

PS
Is the ultimate goal to create URLs that automagically "assemble" the product with all parts? Did you consider using URL-segments? You could use something like
mysite.tld/products/product-page-slug/lights/5001/5002/5003/

Edited June 14, 2019 by dragan
added url-segment question

[wbmnfktr]

52 minutes ago, a-ok said:

Product and source are all their own tree so everything is on the same level.

That's possible and needed actually.

• Products
  • product #1
  • product #2
  • product #n
• Sources
  • source #1
  • source #2
  • source #2
• Total codes
  • total code #1
    • product #2 ref
    • source #1 ref
  • total code #2 
    • product #2 ref
    • source #2 ref
  • total #n
    • product #1 ref
    • source #n ref

[a-ok]

1 hour ago, dragan said:

Is the ultimate goal to create URLs that automagically "assemble" the product with all parts? Did you consider using URL-segments? You could use something like
 mysite.tld/products/product-page-slug/lights/5001/5002/5003/

No, sorry. I have clearly confused everyone.

Each product has a 'light source' PageField which chooses the 'light sources' for each product. One product may have 10 light sources, another maybe one.

The issue is that I need to add a 'unique product code' (almost like a SKU) that only exists for a product and light source combination. So if I was editing product A and chose LED35 GEN2 from the light source I would need to enter a unique code for that combination of product and light source. Same if I then choose another light source. Then when editing another product (product B) and adding a light source to that, it would, again, be unique/different.

I need a way, when choosing a light source for a product, to enter a unique code for that selection, for each selection. This needs to be inputted manually.

Hope that's cleared things up?

[a-ok]

1 hour ago, wbmnfktr said:

That's possible and needed actually.

• Products
  • product #1
  • product #2
  • product #n
• Sources
  • source #1
  • source #2
  • source #2
• Total codes
  • total code #1
    • product #2 ref
    • source #1 ref
  • total code #2 
    • product #2 ref
    • source #2 ref
  • total #n
    • product #1 ref
    • source #n ref

This isn't a bad idea and is how it is almost set up just now but just seems like A LOT of data input for very little return? Having to add each total code separately, outside of the product context, then reference a product and source (assuming by two PageFields on the total code page?) – it might be the only solution, however! ?

[wbmnfktr]

Forget my idea for a second. It is based on a (maybe) wrong assumption.

Reading your previous posts and the explanation again... there is a few things I don't get.

WHO defines the total code. Does your client say "Product D with Source  Z,D, and H has total code [WH-ATS-OEVER]"?

If so... you could take the total codes (defined by your client) as a leading instance and use my idea (probably).

If not... you could go the way @dragan recommened and create your very own total codes.

This is kind of hard to understand because of the huge amount of product-source-bundles you can possibly create.

And another thing... what if a product has only one light source and not ten or seven or four? Can they even be mixed in that way or is there another dependency?

[a-ok]

1 hour ago, wbmnfktr said:

WHO defines the total code. Does your client say "Product D with Source  Z,D, and H has total code [WH-ATS-OEVER]"?

Correct but the total code is only based on the product with one source. Product D with source Z = 123, Product D with source D = 456, Product D with source H = 789. There is a single code per product+source. The client states this. It needs an entry for each 'source' they choose per product.

I reckon your method makes sense but just seems time consuming for the client but maybe that's how it is. Why they couldn't just have a code for each source and code for each product and the total code is them concat'd together. But alas.

1 hour ago, wbmnfktr said:

And another thing... what if a product has only one light source and not ten or seven or four? Can they even be mixed in that way or is there another dependency?

It shouldn't matter based on my explanation above.

[wbmnfktr]

14 minutes ago, a-ok said:

reckon your method makes sense but just seems time consuming for the client

Oh... kay... now I understand and get almost the whole idea here.

This might be too good to be true but maybe your client already has a CSV, XML or something similar with each and every possible configuration... you could import and use. With such a foundation/starting point you could even take a lot of stress on the client-side.

[Robin S]

If I understand right you need to use a repeating fieldtype that contains a Page Reference field and a text field for the unique code. You could use any repeating type such as Repeater, PageTable or ProFields Table, but I think ProFields Table would be the optimal interface. You can use some custom JS in Page Edit to disable options in the Page Reference field that have already been selected in another row of the table - just shout if you need advice for doing that.

[Robin S]

1 hour ago, Robin S said:

You can use some custom JS in Page Edit to disable options in the Page Reference field that have already been selected in another row of the table

Here's some JS for that, for a Table field named "table_select_once". Add the JS any way that suits you - with AdminOnSteroids, a hook before Page Edit execute, etc.

$(function() {

	// Disable options already selected in another table row
	function disableSelectedOptions() {
		var $selects = $('.Inputfield_table_select_once select');
		$selects.find('option').prop('disabled', false);
		$selects.each(function() {
			var $selected = $(this).find('option[value!=""]:selected');
			if($selected.length) {
				$selects.not(this).find('option[value="' + $selected.val() + '"]').prop('disabled', true);
			}
		});
	}

	// Disable selected options on DOM ready
	disableSelectedOptions();

	// Disable selected options when select changes
	$(document).on('change', '.Inputfield_table_select_once select', disableSelectedOptions);

});

[a-ok]

9 hours ago, Robin S said:

If I understand right you need to use a repeating fieldtype that contains a Page Reference field and a text field for the unique code. You could use any repeating type such as Repeater, PageTable or ProFields Table, but I think ProFields Table would be the optimal interface. You can use some custom JS in Page Edit to disable options in the Page Reference field that have already been selected in another row of the table - just shout if you need advice for doing that.

Okay great so that's the best way to do it. ProFields Table! I prefer this to the Repeater field too. I really appreciate everyone's help.

I think I'll add the JS to a hook under ready.php (stupidly I didn't know you could add JS to this?)

[a-ok]

Ah but it looks like I cannot add a PageField as a column type?

[Robin S]

3 hours ago, a-ok said:

Ah but it looks like I cannot add a PageField as a column type?

You must have an old version of FieldtypeTable - it has included Page column types since 2015: https://processwire.com/blog/posts/major-updates-to-profields-table-field/#new-support-for-single-and-multi-page-reference-fields

[a-ok]

Omg what? I’ve been paying for it since then too (upgrades and support) haha! I’ll upgrade and check!

[a-ok]

19 hours ago, Robin S said:

You must have an old version of FieldtypeTable - it has included Page column types since 2015: https://processwire.com/blog/posts/major-updates-to-profields-table-field/#new-support-for-single-and-multi-page-reference-fields

Perfect. Thanks so much. I like the idea of using ProTable for this rather than a Repeater to reduce overheads.

Much appreciated everyone.