[#39863] - [4.2] Fix wrong data for calendar custom fields when user registration fail
- Fixed in Code Base
- 28 Feb 2023
- Medium
- Build: 4.2-dev
- # 39863
- Diff
- joomdonation:fix_date_field_error_on_user_registration
User tests: Successful: Unsuccessful:
Pull Request for Issue #39844
Summary of Changes
Currently, if you use Calendar custom fields for user registration, if registration fail, there could be some issues with data of Calendar custom fields:
- Time of the selected date could be changed. It happens because the Calendar form field expect to receive input datetime from UTC timezone , but the provided value is from user timezone (filter is not applied yet)
- In some cases like when you use US language package, the Calendar field could not parse the selected date and result in fatal error
To address these issues, we can use same code which we are using on FormController https://github.com/joomla/joomla-cms/blob/4.2-dev/libraries/src/MVC/Controller/FormController.php#L839-L855 : Process filter for Calendar fields, store the filtered data back to request.
Testing Instructions
- Follow instructions at #39844 and confirm the issue
- Apply patch, confirm that when registration fail, you do not get fatal error anymore. The date which you selected in the field remains as how it is.
Actual result BEFORE applying this Pull Request
There is fatal error
Expected result AFTER applying this Pull Request
No fatal error anymore
Link to documentations
Please select:
- No documentation changes for docs.joomla.org needed
- No documentation changes for manual.joomla.org needed
joomla-cms-bot
- | Category | ⇒ | Front End com_users |
| Status | New | ⇒ | Pending |
The issue with default data is a different issue with our Calendar Form Field. For the default value you entered, it is the format could not be parsed by PHP DateTime class. I guess that's the reason in description of the field, it says:
This is the default date. The value can be an ISO 8601 format (YYYY-MM-DD HH:MM:SS) or NOW, which displays the actual date.
So you need to enter default value for the custom field in that format.
The behaviour of the form gets quite murky, if I may say so. In a new test the Default Date is in the correct ISO date format and the patch is applied, the form returns the error message about an existing user and the selected date is in the correct US format. The form is cancelled and the browser is closed. The Chrome browser cache in History is cleared. A new tab is opened and the registration form is loaded. Now the custom date field shows the date selected from the Calendar button, not the Default Date. Strange, it should not behave like this.
The I open the test site in Edge and go to the registration form. The Default Date is displayed.
Thank you for your assistance! It is past midnight and I will continue tomorrow. It would be good to keep our US webmasters happy. Maybe some documentation improvements or a Help page sritten by an expert could clarify the use of custom calendar fields.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/39863.
@toivo It is because the old wrong date is already stored in session. That's the way Joomla pass the entered data back to the form (so that users don't have to re-enter it) when validation false
So please test it again with the default date in right format. We should handle error better in case wrong date is passed to Calendar form field to avoid fatal error, but it is for a separate PR.
(Strange that PHP could not parse US Date :D )
I have tested this item
Tested successfully in Joomla 4.2.8-dev of 15 February using PHP 8.1.10.
Default Date 2022-12-31
Show Time: No
After the error message about the existing user the custom calendar field displayed the date selected earlier though the Calendar button in the correct US format.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/39863.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/39863.
| Status | Pending | ⇒ | Ready to Commit |
| Labels |
Added:
?
|
||
RTC
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/39863.
| Labels |
Added:
?
|
||
| Labels |
Added:
?
|
||
| Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2023-02-28 21:34:07 |
| Closed_By | ⇒ | fancyFranci |
I really appreciate how much bugs you are fixing! Thank you :)
I have tested this item? unsuccessfully on 0c7530c
Reproduced the error 0 Failed to parse time string (01-30-2023 12:30:22) at position 0 (0): Unexpected character
When the option Default Date was 01-30-2023 12:30:22 and the option Show Time was Yes and the patch had been applied, browsing to the registration form at http://joomla4test/component/users/registration?Itemid=101 displayed the error "0 Failed to parse time string (01-30-2023 12:30:22) at position 0 (0): Unexpected character"
That error was then displayed repeatedly even after Default Date was set to 2023-02-15 and Show Time was set to No, whenever the registration form was loaded. This error was shown until the custom calendar field was unpublished.
When the same custom calendar field was published, just loading the registration form displayed the same error.
It looks like the request or the session does not get cleared and that is why the time entry stays in the form data.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/39863.