Remove jQuery Dependency

Hi @markparolisi

Thank you for the feedback here. I have filed an enhancement issue regarding this request for our developer team to look into and consider.

Right now I suspect they’d be more open to at least handling our javascript used on the frontend, while any that is used on the admin side with the form builder would be a longer term task to accomplish. That said, we also assume site owners try to control jQuery inclusion more on the frontend than at all on the backend, where performance is a bigger topic.

Thank you for the feedback.

Thanks for your response.
And yes I agree that the CMS scripts for the form builder, etc are fine. It’s only on the client-facing front-end where we want to see a performance improvement by removing the jQuery library.

Great to hear. Since this has been filed now for ourselves internally, going to mark the support thread as resolved. Hopefully in a near future release, but we’ll see.

Just wanted to chime in quick and say that we’ve been actively working on this, after agreeing that it’d be for the best. The changes are currently going into internal review to help make sure we’re not breaking any functionality, and hopefully it’ll be ready for our next big release. However, I can’t say for certain when that would be. **Probably** version 2.4.0, but no promises.

Much appreciated. Not sure where you are doing the development as I don’t see a public repo for this in your Github org, but I’d be happy to help test and review.

Are you willing to test all the changes that we have thus far in the next version of the plugin?

Right now that list would have the jQuery changes as well as:

• Individual address fields and available required fields match up to what’s included.
• Updated Internal logging library.
• Moved disclosure messaging to outside of the generated <form> tag.
• Empty list information when creating a list in WordPress Dashboard.

Sure, I’ll help where I can. Just let me know how to communicate changes if not via this support forum.

For now here will be fine.

Here’s the zip:

https://www.dropbox.com/scl/fi/2xegu6j06svznjclamm8a/constant-contact-forms.zip?rlkey=5rxtk029djiejcv7u2nws5k1p&dl=0

All good so far. Been doing routine functional tests just submitting data via forms created with the plugin. Both to CC subscriber lists and general contact form information submitted to an email address.

One spot that we’re not consistently recreating internally, that maybe you could help confirm, would be the submit button not being re-enabled when trying to submit with not all required fields being filled in.

Beyond that, great to hear that everything appears to be working so far.

Now that you mention it, I can reproduce that bug.

I also notice an error in the console…

An error has occurred. [ File: ./wp-content/plugins/constant-contact-forms/assets/js/ctct-plugin-frontend.min.js?ver=2.4.0 ] [ TypeError: Cannot read properties of null (reading ‘querySelector’)

                        e.cache.forms[r].honeypot = t.querySelector(".ctct_usage_field"),

Do you have any public links where we could check on that behavior? I’m not managing to create either issue with my own local install. Curious if we could see it happening elsewhere and get some ideas.

https://www.theyonkersledger.com/newsletter/

Feel free to submit dummy email addresses to that live list. Just make them obvious so I can delete them later.

I have some leads but it’s going to need to wait till tomorrow before I can get them touched up and provide a fresh copy of the plugin.

Thanks for all the willingness to help thus far.

Give this one a try.

https://www.dropbox.com/scl/fi/2xegu6j06svznjclamm8a/constant-contact-forms.zip?rlkey=5rxtk029djiejcv7u2nws5k1p&dl=0

I’m decently confident that I missed providing some fully compiled minified assets and this should handle that going forward.

Visual code changes noticed in a diff check from my original copy to you and this one include using removeAttribute() instead of setAttribute() and “false” for disabled state on buttons, as well as a missed change away from jQuery.val() to fetch honeypot contents.

Hopefully this fixes up both of the issues you were seeing.