Issue with a custom Repeater field in the listing form

[acham]

Description:

When using the “Add Listing” forms that allow for multiple category selections, the following issue occurs:

1. If a user selects a category, the associated fields are correctly displayed.
2. If the user then selects a different category, the fields from the new category are added to the form, but the fields from the previously selected category are not removed.

Problem:

The form fails to remove fields that are not associated with the current category unless the page is refreshed. Instead, it adds the new category fields to the form in addition to the previous category fields.

Expected Behavior:

When a user selects a category, the form should only display the fields associated with that category. Any fields from previously selected categories should be removed.

Steps to Reproduce:

1. Open the “Add Listing” form.
2. Select a category with specific fields.
3. Select a different category with different fields.

Actual Result:

Fields from both the previously and currently selected categories are displayed together, creating a cluttered and confusing form.

Expected Result:

Only the fields associated with the currently selected category should be displayed, and fields from any previously selected categories should be removed.

Suggested Fix:

Implement a functionality to clear the form fields not associated with the currently selected category whenever a new category is chosen. This will ensure that only relevant fields are displayed, improving user experience and form accuracy.

[andrii]

Hi,

This is most likely a caching or third-party plugin issue, as you should only see the fields associated with these categories if you add a listing through the frontend. Please disable third-party plugins and customizations (if there are any) and check if this issue persists. If you use a caching plugin, make sure that caching is disabled for logged-in users.

But if you add a listing through the backend, then yes, you need to select a category there, and if it has the appropriate attributes attached to it, then you need to refresh the page to make these attributes available. We also plan to improve this in future updates.

​I hope this is helpful to you.

[acham]

I realized that issue is related to a custom repeater date/time field that I wrote. It applies to adding a listing through the frontend. I referenced example code snippets on Github and Hivepress community and used the hivepress/v1/models/listing/attributes hook to implement it. Do I need to add javascript to ensure that the fields from previously selected categories are removed when a new category is selected or do you have a better suggestion? Here is the code that I’m using:

add_filter('hivepress/v1/models/listing/attributes', function ($attributes) {
    $category_ids = [36]; // Restrict to category ID 36

    $attributes['repeater_date_time'] = [
        'editable' => true,
        'categories' => $category_ids,
        'edit_field' => [
            'label' => 'Additional Dates and Times ',
            'type' => 'repeater',
            '_order' => 7,
            'fields' => [
                'date_time_field' => [
                    'label' => 'Date and Time',
                    'type' => 'date',
                    'format' => 'Y-m-d H:i:s',
                    'display_format' => get_option('date_format') . ' ' . get_option('time_format'),
                    'required' => false,
                    '_order' => 0,
                    'time' => true, // Enable time selection
                ],
            ],
        ],
    ];

    return $attributes;
}, 1000);

[ihor]

The snippet seems to be ok, does it affect other fields remaining after the category is changed or you mean the inner fields of the Repeater? Also, please let me know what you mean about multiple categories, do you use a code snippet to enable multiple category support in the front-end listing form?

[acham]

I discovered that the issue is not related to the repeater, as it occurs with other attributes as well. The problem seems to lie in the snippet I use to set the order of form fields.

I do not enable multiple categories. One category includes “start date and time” and “end date and time,” while another category includes “start date” and “end date.”

In the front-end add listing form, when I select a category, the associated fields are displayed correctly. However, if I then select a different category, the fields from the new category are added to the form, but the fields from the previously selected category are not removed unless I refresh the page.

As I mentioned the issue occurs with any field that is assigned to one of the categories. If I disable the snippet that I use for ordering the form fields, they populate correctly. Below is the snippet, which I found in the community forum. Do you have any recommendations to address this issue?

add_filter(
	'hivepress/v1/forms/listing_submit',
	function( $form ) {
		$form['fields']['categories']['_order'] = 1;
		$form['fields']['images']['_order'] = 2;
		$form['fields']['title']['_order'] = 3;
		$form['fields']['setting']['_order'] = 4;
		$form['fields']['location']['_order'] = 5;
		$form['fields']['start_date_time']['_order'] = 6;
		$form['fields']['end_date_time']['_order'] = 7;
		$form['fields']['start_date']['_order'] = 8;
		$form['fields']['end_date']['_order'] = 9;

		return $form;
	},
	1000
);

add_filter(
	'hivepress/v1/forms/listing_update',
	function( $form ) {
		$form['fields']['categories']['_order'] = 1;
		$form['fields']['images']['_order'] = 2;
		$form['fields']['title']['_order'] = 3;
		$form['fields']['setting']['_order'] = 4;
		$form['fields']['location']['_order'] = 5;
		$form['fields']['start_date_time']['_order'] = 6;
		$form['fields']['end_date_time']['_order'] = 7;
		$form['fields']['start_date']['_order'] = 8;
		$form['fields']['end_date']['_order'] = 9;

		return $form;
	},
	1000
);```

[ihor]

I guess I found a reason, since _order is set for the field regardless if it’s present in the form, then this field is always rendered. Please try wrapping category-specfic fields this way:

if(isset($form['fields']['start_date'])) {
    $form['fields']['start_date']['_order'] = 8;
}

If you wrap every category-specific field with a condition this way, the issue should be resolved. Also, please note that you can use a single snippet for the listing_update form as the listing_submit form inherits it anyway, two snippets are needed only if there are different orders.

Hope this helps

[acham]

Thank you for your solution. Super helpful!

I tested it and noticed that if I remove the listing_submit snippet and keep only the listing_update snippet, the fields on the “add listing” form are no longer ordered correctly. They do, however, appear in the correct order on the “edit” form.

Additionally, wrapping the category-specific fields with a condition works only if I apply it to the fields in both the listing_submit and listing_update snippets.

I’d prefer to use a single snippet to simplify maintenance. Please let me know if I’m missing something to have the listing_submit form inherit from listing_update as you mentioned.

[ihor]

Sorry for the confusion, I guess the function which adds custom attributes to the forms does this for both forms (not just the parent “listing_update” one) so I guess keeping both snippets is needed. You can simplify it by using a single named callback function and adding 2 “add_filter” lines with referencing this function by name.

[acham]

Perfect. Thanks!