cms icon indicating copy to clipboard operation
cms copied to clipboard

Strange behaviour with localized `date` fields

Open duncanmcclean opened this issue 1 year ago • 2 comments

Bug description

When the date field is localized and the value is different between the localizations, the state of the Date fieldtype seems to get out of sync when you switch localizations.

https://github.com/user-attachments/assets/319b92ab-6c8e-4643-9635-88a91d9ea182

Possibly related to #3440 & #9147.

How to reproduce

Assuming you've already setup multiple sites & configured a collection with two (or more) sites....

  1. Enable "Publish Dates" on the collection
  2. Edit the blueprint and make the date field localizable
  3. Create an entry in Site A - give it a date.
  4. Localize the entry in Site B - give it a different date.
  5. Save & refresh the page.
  6. On Site A, the date will be correct.
  7. Switch to the Site B localization, the date will be Site A's date.
  8. Switch back to the Site A localization, the date will be Site B's date.

Logs

No response

Environment

Environment
Application Name: Duncan's Wonderful Sandbox
Laravel Version: 11.19.0
PHP Version: 8.3.10
Composer Version: 2.7.7
Environment: local
Debug Mode: ENABLED
URL: sandbox.test
Maintenance Mode: OFF
Timezone: UTC
Locale: en

Cache
Config: NOT CACHED
Events: NOT CACHED
Routes: NOT CACHED
Views: CACHED

Drivers
Broadcasting: null
Cache: redis
Database: sqlite
Logs: stack / single
Mail: smtp
Queue: redis
Session: file

Statamic
Addons: 0
Sites: 2 (English, German)
Stache Watcher: Enabled
Static Caching: Disabled
Version: cd5e263bce2d6259c1fd17398c7a880099496637 PRO

Installation

Fresh statamic/statamic site via CLI

Additional details

No response

duncanmcclean avatar Aug 22 '24 17:08 duncanmcclean

We have encountered the same problem in one of our projects and have hot-fixed the Date Popover component:

 resources/js/components/fieldtypes/date/SinglePopover.vue | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/resources/js/components/fieldtypes/date/SinglePopover.vue b/resources/js/components/fieldtypes/date/SinglePopover.vue
index 174c34c7a6..762d7546b4 100644
--- a/resources/js/components/fieldtypes/date/SinglePopover.vue
+++ b/resources/js/components/fieldtypes/date/SinglePopover.vue
@@ -88,6 +88,10 @@ export default {
             this.$nextTick(() => this.updateInputValue());
         },
 
+        'bindings': function () {
+            this.$nextTick(() => this.updateInputValue());
+        },
+
     },
 
     methods: {

The watcher needs to watch the ref and not it's value it seems, though I'm not too well versed in Vue 2 😄

lostgeek avatar Mar 17 '25 17:03 lostgeek

Note: That hot fix does not solve the issue described in #11752

lostgeek avatar Apr 30 '25 12:04 lostgeek

Can this be related?

The date field is in this case not localized. When switching back and forth between the locales, it gets out of sync and the origin displays a totally different date. When refreshing the origin entry via browser it does load the correct 14-01-2025 date again on English.

https://www.loom.com/share/08c3ce65f395423e9ee0a4523c7f0dc4?sid=7e7d07cf-69ba-4924-8ac8-71033e60abbf

JorisOrangeStudio avatar Jul 02 '25 07:07 JorisOrangeStudio

Yeah it's the same bug, I think. In that case you have a date saved in the Dutch entry. Likely because at some previous point, the field was set to being localisable and therefore in the .md file there is date information in the Dutch file.

If you manually remove the date information from the Dutch .md file, the problem should go away again.

lostgeek avatar Jul 05 '25 06:07 lostgeek

That’s what I thought also, but the Dutch .md file does not contain any date and was never allowed to (localizable was not switched for this field).

JorisOrangeStudio avatar Jul 07 '25 06:07 JorisOrangeStudio

This has been fixed in Statamic 6, which is due to be released ~Q3, with an alpha on its way in the next week or so. You can learn more about v6 on our blog.

duncanmcclean avatar Aug 13 '25 12:08 duncanmcclean