Dara

Hi,

Thanks for the screenshots and the further explanations, that helps a lot. I think I was able to identify the cause based on your description.

I am preparing a fix that should stop the unwanted image from appearing while still keeping the dynamic background functionality where it is intended.

If you’d like to test the fix before the release, you can send me a message at [email protected]. I will share a test build tomorrow so you can try it on your setup and confirm everything is resolved.

Thanks again for your help and patience.

Regards,
Dara

Hi dddean (@dddean),

Thanks for taking your time to report this issue. It has been reproduced on my side and I am working on a fix. At the moment, the only workaround is to downgrade the filter version to 1.8.6, which can be downloaded from the advanced releases page here: https://ww.wp.xz.cn/plugins/better-post-filter-widgets-for-elementor/advanced/.

I will be releasing a fix shortly this week.

Regards,
Dara

Hi digitaldesignerau (@digitaldesignerau),

Thank you for the detailed report.

The filter should work with both the Posts widget and Loop Grid widget, so if you don’t mind I would like to gather more information about this 500.

– Was the Posts widget located directly on the page, or inside an Elementor template (Archive Template, Single Template, Saved Template, Template Widget, etc.)?

– Were you using the “Elementor Template ID” setting under Additional Options on the filter widget, or was it left empty?

If it was left empty, could you try entering the ID of the Elementor document that directly contains the Posts widget and test again?

To clarify, this should be the ID of the template that contains the Posts/Loop Grid widget itself, not necessarily the ID of the page where the template is displayed.

The reason I ask is that the plugin automatically attempts to detect the correct Elementor document during AJAX requests. If the wrong document is resolved, Elementor will fail and return a 500 error.

If manually setting the template ID resolves the issue, that would help determine whether this is a document detection issue rather than a Loop Grid Widget compatibility issue.

Also, if you were using a custom Loop Item template or custom template structure, would you mind sharing what elements were inside it? For example, whether it contained standard Elementor widgets, nested templates, third-party widgets, custom query widgets, etc. This may help identify whether a specific element in the template is triggering the rendering error.

Please let me know the template structure you’re using and whether manually setting the template ID changes the behavior. Again, thank you for taking the time to report this issue and for helping me investigate it.

Regards,
Dara

Hi artemiusgreat (@artemiusgreat),

Thanks for reporting this and for helping narrow down the conditions required to reproduce it.

After investigating, this appears to be caused by an overlap between Elementor control IDs. I’ve already prepared a compatibility fix on my side to prevent this type of overlap and it will be included in the next update.

As a temporary workaround, the following CSS can be loaded in the Elementor editor. Please add this snippet to your child’s theme functions.php file:

add_action(
	'elementor/editor/before_enqueue_styles',
	function() {
		if ( wp_style_is( 'post-editor-style', 'registered' ) ) {
			wp_add_inline_style(
				'post-editor-style',
				'.elementor-control-title_style{display:initial !important;}'
			);
		}
	},
	20
);

This should restores the hidden “title” styling section until the compatibility update is released.

Thanks again for the report,
Dara

Hi nicorsm93 (@nicorsm93),

Yes, this is possible. If you are using Elementor Pro Query ID, it only applies when the query is handled through the elementor/query/{id} hook. When the filter modifies the query after that, it can look like nothing is applied.

The filter widget has two different ways to include those queries:

You can enable “Include Loop Grid Query ID” option in your filter widget under “Query”, which will make the filter automatically respect and integrate the Loop Grid query.

Or you can use the Filter Query ID system, which lets you fully control the query through the plugin’s hook system. In that case you would use a function similar to Elementor’s Query ID approach:

Eg:

add_filter( 'bpfwe/filter_query_args/my_custom_filter', function( $args, $widget ) {
    // Show posts where meta key 'highlight' equals 'yes'.
    $args['meta_query'][] = [
        'key'     => 'highlight',
        'value'   => 'yes',
        'compare' => '=',
    ];
    return $args;
}, 10, 2 );

Just make sure to use only one of these approaches per widget, otherwise the query modifications can conflict and override each other.

Let me know if that helps.

Regards,
Dara

Hi Mei Yin (@mei-yin),

There is no native setting that directly keeps the Loop Grid completely hidden until the filter interaction happens.

However, this can easily be achieved using CSS. The filter widget already adds an active class when a selection is made, which you can use as the trigger to show the Loop Grid only after interaction.

So essentially, the grid remains hidden by default and is only revealed once the filter becomes active.

Your CSS would look like this:

.your-wrapper-selector {
    opacity: 0;
    visibility: hidden;
    pointer-events: none;
    transition: 0.2s ease;
}

.your-wrapper-selector.filter-active {
    opacity: 1;
    visibility: visible;
    pointer-events: auto;
}

The CSS class added by the filter after an interaction is .filter-active and .your-wrapper-selector would be the same as your post widget target.

Hope this help.

Regards,
Dara

Hi tommyd17 (@tommyd17),

Unfortunately, numeric custom fields currently do not support value formatting. To avoid confusion, this option will be hidden for numeric fields in the next update.

For the euro sign, it can be repositioned using the following CSS:

.field-wrapper .before {
    right: 5px;
    left: auto;
}

This will be properly supported in the next update, which I plan to release later this week.

Regarding the decimal separator, this is mostly controlled by the user’s browser and system locale. It cannot be enforced consistently unless the browser language is manually changed.

Let me know if the CSS workaround works for you.

Regards,
Dara

Hi artemiusgreat (@artemiusgreat),

I checked the page and also tried reproducing the issue on my own my end using the same query options from the widget. On my side, the “Product Visibility” filter works correctly and I can successfully include or exclude out of stock products.

The fact that the product appears with a “Read more” button confirms WC correctly identifies it as out of stock, so this makes it more likely that something else is affecting the final query results on the page, such as:

– A third-party plugin modifying WooCommerce queries
– The active theme altering product visibility/query behavior
– Another query setting in the widget overriding or conflicting with the visibility filter
– Custom code/snippets affecting pre_get_posts or WooCommerce product queries
– If the post widget has a Query ID (this would directly influence the end results)

A cache could also potentially cause this behavior, especially if the product stock status or widget query settings were changed recently.

I would recommend temporarily testing with:

– Only Elementor + Elementor Pro + WooCommerce active
– A default theme such as Storefront
– The same widget/query configuration on a new clean test page

This should help isolate whether the issue comes from a conflict or from a specific page/query configuration.

Regards,
Dara