[Resolved] DatePicker not initialized after View AJAX Pagination

[Author]

Posts

[smileBeda]

This is similar to https://toolset.com/forums/topic/views-blocks-is-not-retaining-certain-block-styles-upon-ajaxified-events/ but this time with Datepickers in Forms rendered in a View.

Create a Toolset Form with a Date Field in it.
Put that form into any Post Body.
Show the post Body (just post body) in a View paginated by one with AJAX.
Load the View and paginate to your post with the Form in it.
The Date Picker will transform into a simple text input.

Note that adding something like this to the View doesn't solve it and makes it worse (pagination breaks completely):

jQuery( document ).on( 'js_event_wpv_pagination_completed', function( event, data ) {
	/**
	* data.view_unique_id (string) The View unique ID hash
	* data.effect (string) The View AJAX pagination effect
	* data.speed (integer) The View AJAX pagination speed in miliseconds
	* data.layout (object) The jQuery object for the View layout wrapper
	*/
	jQuery('.js-wpt-date').datepicker();
});

Above code on my tests - while supposed to re-initialize the picker - broke the AJAX pagination and throws:

Uncaught TypeError: Cannot read property 'sort' of undefined
    at WPViews.ViewSorting.self.get_sort_data (wpv-pagination-embedded.js?ver=3.2.1:599)
    at WPViews.ViewFrontendUtils.self.get_updated_query_results (wpv-pagination-embedded.js?ver=3.2.1:420)
    at WPViews.ViewPagination.self.pagination_preload_next_page (wpv-pagination-embedded.js?ver=3.2.1:1849)
    at WPViews.ViewPagination.self.pagination_preload_pages (wpv-pagination-embedded.js?ver=3.2.1:1790)
    at HTMLDivElement.<anonymous> (wpv-pagination-embedded.js?ver=3.2.1:3449)
    at Function.each (jquery.js?ver=1.12.4-wp:2)
    at a.fn.init.each (jquery.js?ver=1.12.4-wp:2)
    at WPViews.ViewPagination.self.init_preload_pages (wpv-pagination-embedded.js?ver=3.2.1:3442)
    at WPViews.ViewPagination.self.init (wpv-pagination-embedded.js?ver=3.2.1:3480)
    at new WPViews.ViewPagination (wpv-pagination-embedded.js?ver=3.2.1:3484)

Uncaught TypeError: Cannot read property 'sort' of undefined
    at WPViews.ViewSorting.self.get_sort_data (wpv-pagination-embedded.js?ver=3.2.1:599)
    at WPViews.ViewFrontendUtils.self.get_updated_query_results (wpv-pagination-embedded.js?ver=3.2.1:420)
    at WPViews.ViewPagination.self.trigger_pagination (wpv-pagination-embedded.js?ver=3.2.1:2027)
    at HTMLAnchorElement.<anonymous> (wpv-pagination-embedded.js?ver=3.2.1:2252)
    at HTMLDocument.dispatch (jquery.js?ver=1.12.4-wp:3)
    at HTMLDocument.r.handle (jquery.js?ver=1.12.4-wp:3)

The JS error might be due to the mix of Blocks and Forms because in classic Views the error did not happen, but the date picker was only re-initialized without stylesy. Hence not really an option either.
It should work out of the box without us needing to craft code because it's a In-House plugin and not a 3rd party action we need to re-fire 🙂

PS.
This issue doesn't really seem new, scanning the forums, you can find tickets dating back to 2016 for this issue.

Cheers!

[Jamal Supporter Languages: English (English ) French (Français ) Timezone: Africa/Casablanca (GMT+00:00)]

Hello Beda and thank you for contacting the Toolset support. I hope you are safe and doing well!

I was able to reproduce this issue on a clean install with blocks based views and classic views. My views were very basic, containing only the title field and a date field. I was not able to reproduce the same Javascript errors, probably because my form is very basic.

You know that I am supposed to provide a workaround when possible, and I am pretty sure you have tried all possible solutions before opening this ticket, but I'll have to suggest this:
- Add a Javascript function to the view's Javascript section to build the date picker.
- Make the view call the Javascript function after each pagination from the advanced section, check this screenshot hidden link
The Javascript function would be:

function buildDatePicker(){
  jQuery('.js-wpt-date').datepicker();
}

If this workaround does not work for you, please allow me temporary access to your website and let me see what I can come up with. Your next reply will be private to let you share credentials safely. ** Make a database backup before sharing credentials. **

I am escalating this ticket to 2nd Tier, and I'll get back to you as soon as possible.

[smileBeda]

Hi Jamal, I'm fine, thank you!
I hope you as well 🙂

I already tried the JS workaround as described initially, which is precisely what triggered the follow-up JS error (only if using BLOCKS UI)

However, I had no time yet to replicate this detail on clean, and we all know that usually, on "clean" it'll turn out to need a step or 2 more to trigger the issues usually 😛

I'll see if I can make time for it.
Actually, the important is that Toolset fixes the longstanding issue with the Datepicker simply not initialized. I can wait with AJAXification, so the JS "hack" is not really where I want to go just yet (once because of the error it produces on the sample site, and also because it's hard to remember and once Toolset Fixes, it, that code will conflict with the fixed code of Toolset, effectively firing the datepicker twice, and that'll throw errors again 🙂 )

So, unless I find time for it, I'll stick to "wait for a fix"
The JS error might be due to several other things used on this specific site, which is not mine, so I can't share access to.

I'll be in touch if I can replicate the JS error itself on clean...

Cheers!

[Jamal Supporter Languages: English (English ) French (Français ) Timezone: Africa/Casablanca (GMT+00:00)]

Hello Beda and my apologies for the late reply. I do not work on Mondays, and I started the day with a high number of tickets.

According to our 2nd Tier, using forms inside of sliders is a kind of unusual use case, and we'd prefer to stick to a workaround, if available, instead of escalating this issue to the development team. Hopefully, it may be fixed, when we fix the other issue related to custom styles inside the post body in an AJAXified view.

Please, let us know if the workaround works for you. If it does not, please allow us temporary access or a copy of the website to let us check a possible workaround.

If you believe that this use case should be addressed, please elaborate more about it and I'll escalate it to the 2nd tier again for another discussion.

All the best, Jamal.

[smileBeda]

No problem Jamal, and sorry for my late reply too.

I understand that it’s indeed “unusual” to display a form in a slider. You could even say “wrong”. But did you know that toolset makes it perfectly possible, and some forum threads even suggest it? Not that this makes it more “right” - just saying 😌

Also given the (hundreds) amount of tickets in the forum asking for “multistep forms” and this (having some forms and other “steps” outlined in a view) being one of 2 possible solutions to the “multistep form” requirement, I’d not say it’d be wrong for views to support its own sister plugin to 100%.

The other Solution to create multistep forms with toolset is php redirects hooked to forms api.
Turns out in neither of both solutions (the second being the “more better” one), you can not use Ajax.
In the first solution you can’t because it’s unusual and turns out things break like date pickers, and with php redirects the Ajax submit of forms is basically overwritten because forms Ajax’s submit, if used with redirect to a “next form (post or page)” doesn’t replace the form or post, it reloads the screen, which is not what Ajax submit generally means.

That’s why I even ended up in the first place doing the unusual “forms in sliders thing”, and because I needed “client” controllable Elements for the design and flow (things should be easily editable in the backend) and php does not belong to the things that not-so-techy persons would want to administrate. If I need to do php for each form, code “skip and back” pagination for each, etc, I don’t need to offer a tool that “does not need code to build advanced websites”, because people who aren’t so experienced on webdev wont understand what makes Toolset so great if they still need code for their simple things.

Forminator pro and elementor both offer the feature of “form steps” out of the box no code needed, forminator even with Ajax, I’m not sure on elementors new forms feature which is still a fresh product, and I’m not sure on their api endpoints yet.

We'll maybe use that, I’ll need to study their options.

Toolset forms is great because indeed it offers a good api, which you then can use to do the really advanced stuff like sending data to external databases etc.
Here it’s clear that one always will need code. For something like a simple multistep form however people simply expect more ease and “click and done”.
Well. One can’t have all features in the same spot.

Thanks!