Skip Navigation

[Eskaliert auf 2. Stufe] DatePicker is not working after updating toolset

This support ticket is created vor 4 Jahre, 5 Monate. 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
- 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 -
- 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 -

Supporter timezone: Europe/London (GMT+01:00)

This topic contains 23 Antworten, has 3 Stimmen.

Last updated by Beda vor 4 Jahre, 5 Monate.

Assisted by: Nigel.

Author
Artikel
#1377143

Minesh
Supporter

Languages: Englisch (English )

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

I just got the news its not related. As you can see the comment its deprecated.

** @deprecated This may not be defined at all times. Use TOOLSET_COMMON_VERSION instead */
define('WPTOOLSET_FORMS_VERSION', '0.1.2');
#1377179

If it's deprecated why you use it (?) :

wp_register_script(
	'wptoolset-field-date',
	WPTOOLSET_FORMS_RELPATH . '/js/date.js',
	array( 'jquery-ui-datepicker', 'wptoolset-forms' ),
	WPTOOLSET_FORMS_VERSION,
	true
);

I changed your code to this and the date is now also working in production

wp_register_script(
	'wptoolset-field-date',
	WPTOOLSET_FORMS_RELPATH . '/js/date.js',
	array( 'jquery-ui-datepicker', 'wptoolset-forms' ),
	TOOLSET_COMMON_VERSION,
	true
);
#1377235

Minesh
Supporter

Languages: Englisch (English )

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

I reported that but logically if you think even you were not able to replicate on a different server where you installed the duplicator.

And now, you changed something in the file and it works which means there must be the cache file loaded from somewhere from the server. You shared the same copy of your site using duplicator and even you and none of us able to replicate it. This must be an edge case and I still report it to concern person. At least four people have tried your duplicator or checked with your site and none of them even able to replicate the issue but really glad to see you able to resolve it now.

#1377257

Thanks again and sorry if I become tedious. I believe that they can replicate the issue if they install an older version of the toolset (<=Forms 2.3) and then try to update.
As you said:

The code that causes the issue which is being shown in FF developer edition exists in Forms 2.3 and Types 3.0. That means the old file is loaded with somewhere from the cache.

Probably the issue is fixed, I am just saying that the versioning is wrong on the date.js file, thus the file won't be updated unless you reset everything about caching in your site...

#1377791

Minesh
Supporter

Languages: Englisch (English )

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

Ok - as per your request I've given another shot.

I've deleted the current latest Toolset Form's plugin and installed and activated the Forms 2.3. Then loaded the page and I do not see any issue with date picker selection nor I see any JS error on console.

Now, I've updated the Form's plugin to the current latest version using the installer:
=> hidden link

I again loaded the page with both FF and Chrome and no issue. I think we can close here and I do not have any concrete evidence to report to Devs. Thank you for understanding.

Happy to help!!

#1377803

Hello

I'm investing some time here to try to confirm the problem - if I cannot replicate it, it does not mean you are wrong and I will investigate and report it on a "technical" level only but still, it asks for an adjustment as you state:

A) If deprecated, why is the code used?
B) Versioning is exactly as the you say, here to avoid such issues, and you are right stating that if versions are not bumped, then an aggressive cache (no header expiration, etc etc) can affect the functionality.
C) You mention a very clear issue path: used to work, updated Toolset, stopped working. That is indicator enough, that there is a problem, along with the other (several) users I found in the forum that report this:
https://toolset.com/forums/topic/date-picker-not-working-in-some-cases/
https://toolset.com/forums/topic/layouts-plugin-elementor-syntaxerror-unexpected-token-in-json-at-position-0/
https://toolset.com/forums/topic/date-and-upload-file-is-not-working-for-non-admin-accounts/
(and more)

I will feedback to you my findings and eventual adjustments that you can make

For now, I think it should work on your existing site after you (aggressively) clean every cache possible.
If that does not help, it may be required to check your .htaccess for eventual "out of the usual" caching, or your browser settings for eventual keep-in-cache settings.

In any case I will look to have a proper solution or reasoning as soon as possible.

Thanks for your patience, and for reporting the issue.

#1378015

OK, this is now escalated to the Developers to be changed.
I think all that is needed, is redefining that outdated WPTOOLSET_FORMS_VERSION to TOOLSET_COMMON_VERSION, it can be done in one place each plugin (in the common /vendor/toolset/toolset-common/toolset-forms/bootstrap.php file)

However, of course this will need the Developer approval and work, I cannot make these changes - neither "baptize" them just yet.
I will create an erratum later if it is required - and will keep you in the loop about the progress made on the issue.

#1378037

Thanks a lot, I have already made that change on my site. I also think that's the right approach.

#1378047

Great, and I want to extend our gratefulness to you again for reporting, your patience, and also the extended informations provided which helped me to narrow the technical aspect of the issue in much faster time than usual.

I'll update you here once I have better news than "we are on it" 🙂