Skip Navigation

[Resolved] Something wrong with JS and the latest release

This support ticket is created 7 years, 4 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.

No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.

Sun Mon Tue Wed Thu Fri Sat
- 10:00 – 13:00 10:00 – 13:00 10:00 – 13:00 10:00 – 13:00 10:00 – 13:00 -
- 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 -

Supporter timezone: Asia/Kolkata (GMT+05:30)

This topic contains 32 replies, has 5 voices.

Last updated by Minesh 7 years, 4 months ago.

Assisted by: Minesh.

Author
Posts
#548354

Juan
Supporter

Timezone: Europe/Madrid (GMT+01:00)

Hi Tina.

Sorry for the delay. This is Juan, Toolset team leader.

Hi Tina

Sorry for the delay. This is Juan here, Toolset team leader.

I would like to bring some light to the problem that you have with events binding, related to the counters for characters left for dding a custom limit to some input fields.

document ready and cred_form_ready

cred_form_ready is executed as early as possible, after we initialize some essential form element.

document ready happens when the DOM is ready. Compared to cred_form_ready, this might happen before or after, depending on how the browser manages the code that we need to run to get to fire the cred_form_ready event. This is why we had some inconsistent results when trying to nest event callbacks, like putting a cred_form_ready callback inside a document ready callback: this should not be done.

Note that before cred_form_ready, CRED applies some bindings to the form elements, which means it adds callbacks when events happen on some form elements, like clicks, focus, blur, etc.

Note also that when running cred_form_ready, the third partly library we use to manage such events may clear the existing ones. We might review this in the future, but this was needed to manage CRED forms submitted using AJAX that need to be re-initialized again after they get successfully submitted.

This is why we have different results when document ready is fired before or after cred_form_ready in different browsers: sometimes, the custom code gets erased (or just unbinded, to be fair), which means it never gets applied.

We should use cred_form_ready as much as we can. I understand that this is a little cumbersome and unexpected, so we will review how this all gets fired in a future iteration, so we can try to restate the trust in document ready again. But right now, using cred_form_ready is the best way of making sure that your own custom events get properly mantained in all scenarios, and also re-started in case your CRED form uses AJAX.

I understand this might be a little inconvenient since most of the custom JavaScript written for forms surely relies on document ready, but again this is the only way to ensure that core and custom event callbacks do work properly with CRED forms using AJAX. Relying just in the document ready event is not enough, so we were forced to use a custom event ourselves.

Hope this helps.

Regards.

#548402

I'm having the same problem - no click events work in my js on form pages since upgrading

#548406

I hadn't seen your feedback Juan. I think nearly all my cred forms have some aspect of custom javascript with custom js, or using standard bootstrap components. I can see that my form events are being bound, but they are not being raised after a click takes place.

Surely it's cred that needs to play nicely here - or do I need to rewrite my custom code on every CRED form out there?

#548408

Is it possible to dequeue the offending cred js - and what other implications would that have?

#548417

Juan
Supporter

Timezone: Europe/Madrid (GMT+01:00)

Hi Simon

I am checking a solution that should restore the event binding on document.ready hooked callbacks. I am checking against side effects to avoid filling a hole and opening another, but I am confident I will have a solution in the coming hours.

As stated above, the main problem here is related to the order in which CRED elements are initialized, and how we manage the event binding in AJAX forms to avoid double bindings. There is no assets thta being dequeued would solve the issue, and the side effects that I am trying to double check are related to conditionals, validation, and datepickers and colorpickers in fields.

When I have a working version of this ix that we can rely on, of course we will include it in our upcoming release (this is the last issue in our CRED QA tests), and I will provide a hotfix patch that can be used against CRED 1.9.0.1 which is our latest stable release.

Sorry for the delay here, I will keep you all posted.

Regards.

#548425

Fantastic - thanks Juan, I've rolled back to 1.8.8 for now. I have a challenging site for testing CRED changes if needed.

#548428

Thank you Juan, I look forward to trying out the hotfix.

Best Regards

Iain

#548484

Thank You Juan, I am also rolling back to CRED 1.8.8
It is not an option to go through all my custom functions to change document.ready events, just like Simon is saying, It is CRED that should play nice in this case...

(I'm just a bit frustrated that I always have to spend so much time in convincing your support about errors and send nasty emails before serious tickets like this gets any attention.)

#548772

Juan
Supporter

Timezone: Europe/Madrid (GMT+01:00)

Hi everybody here 🙂

First of all, I would like to state that I am sorry this happened. We should have detected this in our QA tests, and we just added specific tests to make sure this does not happen again. An special apology to Tina: I feel your frustration and I am pushing so you do not need to push that hard again.

To be totally transparent: this bug was introduced when trying to solve another compatibility issue with some themes that use the same library that we started using in CRED 1.9 to help us control the form elements. Both implementations try to affect the same page items, and the library has the rightful limitation of only allowing one set of rules per item, so we cleared the theme ones just to make sure ours were respected, with the side effect that sometimes, under some browsers, we also cleared the rules set by custom code added to CRED forms.

This should be fixed for our next release, which is stated to happen in almost no time. For now, I created this errata that contains a hotfix, tested both by myself and by a client experiencing the same problem. We have this hotfix with now under extensive testing, and I would thank a lot of Tina and Ian could confirm that this also works for them. As stated in the errata, it is supposed to be applied over CRED 1.9 or 1.9.0.1:
https://toolset.com/errata/custom-javascript-binding-events-to-cred-forms-elements-might-not-be-executed/

Please let me know if there is anything else I can do for you.

Regards.

#548785

Just to say that I have installed the patch and although I haven't tested it 100%, it does appear to fix the problem. Thanks Juan.

#549730

Minesh
Supporter

Languages: English (English )

Timezone: Asia/Kolkata (GMT+05:30)

Hello Tina,

Could you please confirm that the patch shared by Juan help you to fix the JS issue on CRED forms.

#549773

Juan
Supporter

Timezone: Europe/Madrid (GMT+01:00)

Just a small update here.

We just released CRED 1.9.1-b1, which is the first beta for our next stable release. It includes the patch I mentioned earlier, along with all the other chnages that will go into CRED 1.9.1.

You can try that one instead of applying the patch, just make sure that you test it on a staging site (it is a beta, after all), and together with all the other beta versions for Toolset plugins we also released.

Regards.

#550091

I installed all the latest beta and the forms JS seem to work.

But I discovered other stuff that don't.

My site uses a lot of edit posts links to pages where the form is not on the single post template (replacing post-body). Instead I use the "present" technique where you place the form in a view, call the view with url-param and ... They don't work any more.
Page is blank.

I can see that there is a new way of doing this in the latest release. But does this mean that all old sites have to update? I can not remember all places where this is done. There was no other way to do this before ...

What now?

#550232

Minesh
Supporter

Languages: English (English )

Timezone: Asia/Kolkata (GMT+05:30)

Hi Tina,

As your original issue is resolved with CRED JS - Could you please kindly open a new ticket with your each new question. This will help other users searching on the forum.

Thank you for understanding.

#550241

No problem I can do that.
Just to say that it is difficult to confirm that this ticket is resolved as the new betas made a lot of my pages completely blank - so I couldn't test the forms.