[#28596] - [3] Add workaround for calendar fields on reload and invalid save
- Fixed in Code Base
- 14 Apr 2020
- Medium
- Build: staging
- # 28596
- Diff
- HLeithner:fix/reload
- Pending Hound Hound is busy sniffing around... Details
User tests: Successful: Unsuccessful:
Pull Request for Issue #28386 .
Summary of Changes
Add an exception for calendar fields when we do a reload (for example on category change) and if the data validation fails.
In both cases we iterate thru all form fields and check for the field type Calendar, if found we use the filter data for the saved session data.
Testing Instructions
- Set an UTC offset in the settings
- Create a custom field
- Create an article and enter a publish date.
- Save it.
- Check the date, should still be the same
- Change the category
- A page reload happens.
- Check the date, should still be the same
Second test
Do the same as in test one but add invalid field content
- Add a broken Url to a Link field (ex. broken://field)
- After save you get a error message and the publish date should still be the same
Expected result
Same date as before
Actual result
Date fields get changed by timezone offset after every save/reload
Documentation Changes Required
no
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Libraries |
you don't need to create a custom field
Ok you have to add a custom field ;-)
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/28596.
I have tested this item
Tested successfully, followed your testing instructions.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/28596.
| Status | Pending | ⇒ | Ready to Commit |
RTC
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/28596.
@HLeithner We just were pointed by @laoneo in the Glip chat to an old PR #17859 . Reading that it seems to me that it solves the same issue than this one. Could you both check that? I will later when I have enough time check the other PR, too.
Hmm, it seems when backend language is Persian and website time zone is not UTC, there is still an issue with all datetime fields in the Published tab are empty after having changed the category.
With both PR #17859 and this one here applied together this is solved, and all is fine with any website time zone and with any backend language.
Yes, we need both PR's, that one and this here, to be really safe in Persian with time zone not UTC.
| Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-04-14 14:55:58 |
| Closed_By | ⇒ | HLeithner | |
| Labels |
Added:
?
?
|
||
Thanks
hmm, wasn't plan to merge my own pr... anyway pr is needed and there was no better solution yet
@HLeithner As far as I did read in the issue, it needs to create a custom field for articles to reproduce the issue with reload on category change. I've just checked and can reproduce the issue only when having that custom field. Could you update your testing instructions accordingly, i.e. just add a step "Create a custom field of any type for articles" or so between the 1st and the 2nd step of the first test?