October: Date picker produces JS error

[MaTToX3]

• OctoberCMS Build: 459 (same error on 458)
• PHP Version: 7.2
• Database Engine: MySQL
• Plugins Installed:
  * Ompmega.MixHelper-1.0.2
  * AnandPatel.WysiwygEditors-1.2.9
  * RainLab.Translate-1.6.2
  * RainLab.Builder-1.0.26
  ** RainLab.Pages-1.3.1

Description:

Date picker does not open up and produces the following error:

Uncaught TypeError: Cannot read property '0' of undefined
    at renderTitle (storm-min.js?v=459:2456)
    at Pikaday.draw (storm-min.js?v=459:2530)
    at Pikaday.show (storm-min.js?v=459:2544)
    at HTMLInputElement.Pikaday.self._onInputFocus (storm-min.js?v=459:2481)

Tested in Blog plugin and also custom form that was created with Builder plugin

Using Date picker with mode "Date and Time" produces the same error, however time picker does work as expected.

Steps To Reproduce:

Try to create a new blog post using RainLab.Blog and pick a date for "published at" field.

[bennothommo]

@MaTToX3 Just to eliminate one potential cause, would you mind running php artisan october:util compile assets in your command line and see if that makes a difference?

[MaTToX3]

Thank you for your response!

Sadly, nothing has changed. Same error as before.

Error is within this line:
opts.i18n.months[i]

[LukeTowers]

@MaTToX3 what is your app locale, app fallback locale, and backend user's locale set to?

[MaTToX3]

Genius!

My backend locale was set to 'Bahasa Indonesia' and I switched it to English (US) and it is working now!

App locale is 'sl' (Slovenian) and fallback is 'en', but the important part is backend locale.

Care to explain what happens behind? Would appreciate it! Otherwise this can be closed.

[LukeTowers]

@MaTToX3 it's possible that there aren't locale files for Bahasa Indonesia for the datepicker library, so when it tries to load them based on the current backend locale it fails which would cause issues when attempting to get the translation strings for a locale that doesn't exist in the view of the datepicker library.

[MaTToX3]

Thanks for help again. Really don't know how Bahasa Indonesia was selected but it's solved and that's all that matters. Hope it helps anyone else.

Closing it down.

[bennothommo]

@MaTToX3 I've figured this out - for the benefit of anyone else who encounters it, the error actually was the result of using sl as the app locale - that locale does not exist in October. A new user would be automatically assigned this locale before overriding it with their own backend locale preference.

The reason "Bahasa Indonesia" was selected was simply because its the first item in the locale list, and sl did not correspond to a valid locale.

[LukeTowers]

@bennothommo why would new users be assigned a locale at all? User's locales should only be set when they themselves have chosen it in the backend preferences, until then it should not be present in the database. Additionally, why is sl in the locale list if we don't actually support it?

[MaTToX3]

sl is not on the list - I entered it in the config file.

[LukeTowers]

@MaTToX3 ah, gotcha. I'll add a warning to the app config about setting a locale that doesn't exist.

[bennothommo]

@LukeTowers sorry for the delay in responding - yeah, what @MaTToX3 said. And you're correct about the new user locale - I was looking at Xdebug when I should've been looking at the database for that.

[MaTToX3]

Maybe I should clarify, why I use sl locale in my case.

It's a legit locale for my country and for my case I use it because my page is in that language. Backend is still in English and that's OK, frontend is in Slovenian. However, when I am using Magic Forms plugin the Recaptcha is still displayed in english. So, I switch my language to 'sl' and pass that locale to Recaptcha API so it is displayed in the correct language.

I should be able to pick any locale in my config file, backend should be independent I believe. Maybe put backendLocale option in config/cms.php for that case? Or maybe this locale should not be set at all (default to en) until user selects it.

[LukeTowers]

@MaTToX3 I would say your use case is a bit of an edge case (including backend features on the frontend), although I do that in a few of my projects too.

The locale isn't set at all until the user picks it, but that means that the code is trying to load the main app locale (in your case sl) in most backend uses of locale. The reason your preferences page said it was set to Baha Indonesia is because there is no emptyOption specified on that dropdown so it defaults to showing the first option instead when an invalid value is provided (will be fixing that so in the future it would have just shown you "Invalid locale" or something).

I would say in your specific case you should probably be using the RainLab.Translate plugin, since I believe it modifies the application locale to be the currently selected locale. However, I'm not sure if it supports configuring what the default locale it uses or if it just assumes it's the locale set in app.php.

Another thing that we could do to improve this is have smarter asset loading for the date picker so that if a locale file for the current application locale isn't found it could at least switch to loading the fallback locale.

[github-actions[bot]]

This issue will be closed and archived in 3 days, as there has been no activity in the last 30 days. If this issue is still relevant or you would like to see it actioned, please respond and we will re-open this issue.

[github-actions[bot]]

This issue will be closed and archived in 3 days, as there has been no activity in the last 30 days.

• If this issue is still relevant or you would like to see it actioned, please respond and we will re-open this issue. - If this issue is critical to your business, consider joining the Premium Support Program where a Service Level Agreement is offered.