Values for a field populate across all fields of the same type

[FireWire]

This may be an issue when using the ProFields Custom Field.

I have a block that contains a Custom Field. That custom field contains a Page Reference field (single), Page Reference field (multiple), and a number input. When I create several blocks containing this field the values become unmanageable. They all appear in all blocks and can't be ordered in any of them.

I have several of these blocks and each should have only 3 or 4, but they are all rendered with all of them.

I did do some digging and found that the custom fields are not prefixed as a repeater field in the request data when saving the page, so each of these Page Reference field with multiple pages selected are all returned as a single variable array.
 

I've attached a txt file with the POST request parameters and it shows the following variable repeated without a repeater suffix:

event_activities_select_activities[]

Which may need to be handled as something like:

event_activities_select_activities_repeater5783[]

This is just a guess... I could be off on that, but the only constant that I could see in the issues when rendering is that every block has the same event_activities_select_activities variable without a way for it to be processed individually by block.

That's what I could pull together while experimenting.

Something that's fixable? I have to determine if I need to rewrite the blocks to use different fields 😵‍💫

 

 

rpb_blocks_custom_fields_request.txt

[gebeer]

The list of currently supported inputfield types under heading "Possible values for “type”" at https://processwire.com/blog/posts/custom-fields-module/ does not list AsmSelect which you chose for your page field (multiple) based on the screenshots. Maybe this is the issue? Have you tried field type SelectMultiple instead of AsmSelect?

[FireWire]

@gebeer Was a good idea to double check, in the example documentation in the module it shows compatibility. I do see AsmSelect in the list of approved fields on that blog post.

<?php

/**
 * Page reference fields
 * 
 * All Page reference Inputfields need to have at least the following
 * properties defined: 
 * 
 * - `derefAsPage` (int): Whether it single or multiple mode: 
 *
 *   - `0`: Multiple page (PageArray).
 *   - `1`: Single Page or NULL when empty.
 *   - `2`: Single Page or NullPage when empty.
 * 
 * - `inputfield` (string): Which input class to use, can be any of the following.
 *    You can specify the Inputfield class name or optionally omit the `Inputfield`
 *    prefix, like the options below: 
 * 
 *   - `select`: Select one via standard select.
 *   - `selectMultiple`: Select multiple via multiline select.
 *   - `radios`: Select one via radio buttons.
 *   - `checkboxes`: Select multiple via checkboxes. 
 *   - `asmSelect`: Select multiple/sortable via asmSelect.
 *   - `pageAutocomplete`: Autocomplete for single or multiple selection.
 *   - `pageListSelect`: Select one page from tree. 
 *   - `pageListSelectMultiple`: Select multiple pages from tree. 
 *   - `textTags`: Select one or multiple via text tags input. 
 * 
 */

I also tested it in a vanilla repeater field and wasn't able to replicate the issue there. Using the field in a repeater applies a unique suffix:

event_activities_select_repeater5720_activities[]

[gebeer]

@FireWiresorry, I totally did not see AsmSelect in the list albeit it being the very first item. Strange things happen sometimes...

[FireWire]

No worries at all, I always figure that if something gets posted in the forums it will end up helping someone!

[bernhard]

Hey @FireWire sorry for the trouble. I don't have any experience with this field and I have to focus on RockCommerce until December, so don't expect a quick solution.

From your request it looks like you have a load of data sent, so I guess this is related to your post saying that you had to increase the max input variables setting of your server?

When using the Frontend for editing this is not an issue. Can you confirm that?

Can you also confirm that when clicking the "edit this block in a new window" on the backend it is possible to edit the block as expected?

...Because I'm thinking of maybe adding an option for blocks to prevent direct editing and only show a button to edit them in a modal popup. I think that could solve such issues in a common way.

[FireWire]

@bernhard It was on the same page but addressed an overall issue where the page wasn't saving. I upped the max input variables to 2000 and the page started saving again. I haven't been using the front end editor due to the workflow and jumping around in the admin. Admittedly, I think the max input vars and this was a perfect storm or I probably would have seen it sooner, one covered up the other.

I'll figure an alternative out. Using a custom field isn't a requirement. This post may help others in the meantime though. But this one is kinda on me...

Ryan:

Me: WELL I BETTER GO USE THIS IN PRODUCTION RIGHT AWAY!

[bernhard]

19 minutes ago, bernhard said:

Can you also confirm that when clicking the "edit this block in a new window" on the backend it is possible to edit the block as expected?

...Because I'm thinking of maybe adding an option for blocks to prevent direct editing and only show a button to edit them in a modal popup. I think that could solve such issues in a common way.

?

[FireWire]

@bernhard Sorry, it's 2:40am here and I'm migrating servers. My brain is a little fried and I misread what you typed. I'll check it out when I can.