Skip Navigation

[Resolved] The 'js_event_wpv_parametric_search_triggered' & force_form_update

This support ticket is created 6 years, 8 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- 8:00 – 17:00 8:00 – 17:00 8:00 – 17:00 8:00 – 17:00 8:00 – 17:00 -
- - - - - - -

Supporter timezone: America/Sao_Paulo (GMT-03:00)

This topic contains 4 replies, has 2 voices.

Last updated by Adriano 6 years, 8 months ago.

Assigned support staff: Adriano.



Currently wpv-pagination-embedded.js listens to it's own 'js_event_wpv_parametric_search_triggered' event and may force a parametric form update if the output results will be updated (see line 2615-2635).
It does this ... "to update the pagination links it contains to be in sync with the new results, and default to page 1" (per comments in the source file).

However, any other listener (user code) attached to the 'js_event_wpv_parametric_search_triggered' event will not be aware of the fact that form data was force updated by the internal event handler. The user code will see the original event which will not have force_form_update set in data.
This could cause a logic error in user code (it can't be known how/what user code does with this flag so no assumption should be made about the side effects).

To ensure that user code gets the correct state of force_form_update wpv-pagination-embedded.js should ensure the force_form_update flag that user code sees is set according to what is actually done inside wpv-pagination-embedded.js.

To accomplish this one solution will be to introduce a new event 'js_event_wpv_parametric_search_pre_trigger' which the internal code will listen to prior to then triggering the 'js_event_wpv_parametric_search_triggered' event with the correct setting of force_form_update.

The implementation would be to replace 'js_event_wpv_parametric_search_triggered' with 'js_event_wpv_parametric_search_pre_trigger' in lines 2555, 2562, 2570 2580 and 2609.
Then replace line 2615-2635 as follows:

	$( document ).on( 'js_event_wpv_parametric_search_pre_trigger', function( event, data ) {
		var defaults = { 
			force_form_update: false, 
			force_results_update: false
		settings = $.extend( {}, defaults, data );
		// When the form is not forced to be updated, but the results will be updated, and the layout has pagination
		// we need to force update the form too, to update the pagination links it contains to be in sync with the new results, and default to page 1
		if (
			settings.force_form_update == false 
			&& (
				settings.force_results_update == true 
				|| settings.form.hasClass( 'js-wpv-ajax-results-enabled' ) 
			) && _.has( WPViews.view_pagination.paged_views, 'viewnumber' ) ) 
			&& _.has( WPViews.view_pagination.paged_views[ 'viewnumber' ) ], 'has_controls_in_form' )
			&& WPViews.view_pagination.paged_views[ 'viewnumber' ) ].has_controls_in_form == 'on'
			|| settings.form.hasClass( 'js-wpv-dps-enabled' ) // (BA) If the form has dependencies also flag force_form_update
		) {
			settings.force_form_update = true;
		$( document ).trigger( 'js_event_wpv_parametric_search_triggered', [ { view_unique_id: data.view_unique_id, form: data.form, force_form_update: settings.force_form_update, force_results_update: settings.force_results_update } ] ); // (BA) Use value determined above
		self.manage_changed_form( settings.form, settings.force_form_update, settings.force_results_update );

The alternative would be to replace all the jQuery triggers with a direct function call to the single function that will eventually issue the jQuery trigger event 'js_event_wpv_parametric_search_triggered'.

I've implemented and tested solution #1 and verified correct behavior.





Yes, this makes sense to me. I've raised this to our development team. Thank you for suggesting that.


Your suggestion will be applied in Views 2.1 because we need to do some more tests. Again thank you for your suggestion.



Thanks for the update Adriano.

Do you have an ETA for 2.0 release yet?
All my taxonomy regex & free form taxonomy term search code is working on 1.12.1 at the moment.
I have included a workaround for the cache sub-filtering as well as the fixes to the JS frontend code.

I will need to re-introduce the taxonomy regex/free form search implementation to 2.0 while you guys determine when you might formally implement the taxonomy search/regex filter features to Views.

FYI you can see a working demo of the filtering at hidden link (click on the demo menu).
You can search by free form within the terms of the taxonomy used on the image catalog.
If you click the TABS button you will open a form only view which breaks out taxonomy into alphabetic groups under tabs.

Give it a try...



ps - have another bug report (well a compatibility issue with another plugin really).
I'll report that once I do a little more diagnosis.


All Toolset plugins will be released next monday. For any other issue please open a separated ticket.

Please let me know if you are satisfied with my reply and any other questions you may have.


Adriano Ferreira