[Resolved] Paging broken – raising js errors after Views upgrade

[Author]

Posts

[simon]

Hi,
We have a highly modified Toolset site. We upgraded recently to the latest versions of Toolset Views 2.9.2, and we just noticed that paging is broken on our main search view.

We use views paging, but we dequeue the front-end pagination scripts as we don't need the ajax functionality etc

This all worked fine, but I see a function in the wpv.class.php introduced in 2.8.5 enqueue_optional_frontend_assets - this appears to be doing a late enqueue of the pagination script which is effectively overriding our earlier dequeue action.

Is there a better way I can remove the views-pagination-script? If I need to dequeue it, then could you recommend a hook that I could use after enqueue_optional_frontend_assets is run?

[Minesh]

Hello. Thank you for contacting the Toolset support.

Can you please try to use the following code and try to resolve your issue. Please try to add the following code to your theme's functions.php file:

function remove_unwanted_scripts() {
   
    if (!is_admin() ) {
   
        /// add scripts to dequeue
// Remove: /res/js/wpv-pagination-embedded.js
wp_dequeue_script( 'views-pagination-script' );
   
    }
}
add_action( 'wp_print_scripts', 'remove_unwanted_scripts', 100 );

[simon]

I had already tried the following and this does not work

add_action( 'wp_print_scripts ', function () {
    wp_dequeue_script('views-pagination-script');
}, PHP_INT_MAX );

[Minesh]

I got the information that default priority is 10 using which the scripts are enqueued.

What if you try another way - try to change priority from 11 to 100 if 11 does not work.

add_action('wp_enqueue_scripts', 'func_cleanup_scripts', 11);
function func_cleanup_scripts() {
                   if (!is_admin()) {
 
                           wp_dequeue_script( 'views-pagination-script' );
                   }
}

[simon]

If you check my script again Minesh, you'll see it is using the biggest integer available for priority so it will be executed last. I've tested with both wp_print_scripts and wp_enqueue_scripts and neither work.

Could you ask one of the developers? - and perhaps you could test it yourself before sending me something else to try? - it's easy to check that the script is dequeued.

[Minesh]

Can you please share full screenshot of your view's edit page as well as how exaxtly where you added the view? Is the view is added using blocks editor or you added the view using view's shortcode?

Once you share this information I will start my further debug and test this further.

[simon]

Hey Minesh - that will not take us anywhere.

	/**
	 * Enqueue the frontend scripts, only when a View has been printed.
	 *
	 * @since 2.8.5
	 */
	public function enqueue_optional_frontend_assets() {
		// Pagination
		// Note that both jquery-ui-datepicker-local and views-pagination-script have jquery-ui-datepicker as dependency
		// Note that since WP 4.6.0 we do not register this locale script anymore
		if ( wp_script_is( 'jquery-ui-datepicker-local', 'registered' ) ) {
			wp_enqueue_script( 'jquery-ui-datepicker-local' );
		}
		if ( ! wp_script_is( 'views-pagination-script' ) ) {
			wp_enqueue_script( 'views-pagination-script' );
		}
	}

This is the new enqueue code added to the Views plugin in V2.8.5 - I need to dequeue the 'views-pagination-script' - it really is that easy. Could you please pass this to someone who might be able to help me.

[simon]

If anyone else finds this thread then following code will remove the pagination scripts:

add_action( 'wpv_action_require_frontend_assets', function () {
    if (!is_admin()) {
        wp_dequeue_script('views-pagination-script');
    }
}, PHP_INT_MAX );

The custom action wpv_action_require_frontend_assets is used to enqueue the scripts.

[simon]

My issue is resolved now. Thank you!