Problem/Motivation
#501428: Date and time field type in core included some code to load date formats from configuration, which has been ported around since. It means two config entity loads + cache sets on every cold cache request.
Steps to reproduce
Proposed resolution
Going to see what happens if we remove it.
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|
Issue fork drupal-3587601
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3587601-11x
changes, plain diff MR !15854
- 3587601-avoid-loading-date
changes, plain diff MR !15610
Comments
Comment #3
catchSo we need to add defaults in the element callbacks, but otherwise this works fine. Can see the difference in performance tests.
Comment #4
dcam commentedI left several comments on the MR. There are a couple of optional code style changes. But I saw inconsistency in checking for NULL entity loads. I'm not sure if I'm missing something about the code that makes the checks unnecessary. If I did then I apologize.
Comment #5
catchMade changes based on some of the feedback and answered the rest I think.
Comment #6
smustgrave commentedFeedback for this one appears to be addressed
Comment #7
godotislateI think this comment https://git.drupalcode.org/project/drupal/-/merge_requests/15610/diffs?f... was not addressed?
Can put back to RTBC if it was.
Comment #8
smustgrave commentedFrom what I can tell they both were covered in https://git.drupalcode.org/project/drupal/-/merge_requests/15610/diffs?c... by moving the variable assignment to the top.
Comment #9
godotislateI'm not seeing it? At the top of
processDatetime(), we have:$formats = DateFormat::loadMultiple(['html_date', 'html_time']);But the concern is that the loadMutiple() could have at least one NULL result, and it's not guarded against here. $formats['html_date'] or $formats['html_time'] could be NULL.
Comment #10
alexpottYeah there is one outstanding comment on the MR that is not addressed - note that this is an existing issue.
Note that I think the NULL checks are invalid. Both html_date and html_time are locked formats and cannot be deleted see the system/install config. So I do not think the NULL checks are correct.
Comment #11
catchSo the null checks may have been due to the maintenance mode check. But I think we also have test coverage for them. Will try removing first though.
Comment #12
catchOK removed the isset() checks, and
DatetimeElementFormTestfailed.But we can install system config in that test, then it passes. Given the element is already relying on the config existing in multiple places, let's drop the defensiveness altogether I think.
Note that
DatetimeElementFormTesttest is not the same asDatetimeFormElementTestwhich we also have a directory down - could probably consolidate these into one test class in a spin-off issue.Comment #13
alexpott+1 DatetimeElementFormTest is just a kernel test that doesn't install all the config it should.
Comment #14
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. The merge request has merge conflicts and cannot be merged. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #15
catchComment #16
godotislateConfirmed the unnecessary null checks were removed, and confirm the date formats in question are locked. lgtm.
Comment #17
alexpottCommitted 941b575 and pushed to main. Thanks!
Comment #20
catchAdded a backport MR. Just performance test conflicts so back to RTBC.
Comment #24
godotislateCommitted 6811487 and pushed to 11.x. Thanks!