Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
\Drupal\Core\Datetime\DateFormatter should implement an interface, DateFormatterInterface, to allow it to be swappable.
Proposed resolution
Make interface.
Remaining tasks
Do it.
User interface changes
None.
API changes
\Drupal\Core\Datetime\DateFormatter will implement an interface instead of being a bare class.
Data model changes
None.
Beta phase evaluation
Issue category | Task because it adds an interface to the codebase and doesn't address a bug or add new functionality |
---|---|
Issue priority | Normal because this isn't a pressing need |
Prioritized changes | The main goal of this issue is improving developer experience due to the decision made in #2568613: Remove HTML support from date formats and replace remaining !placeholder where format_date() and 'date.formatter' => format() are used to escape HTML in user supplied format strings. The change will allow users to change this behavior in an easier fashion, if needed. |
Disruption | None. Existing code that typehints to DateFormatter will continue to work, though changing to DateFormatterInterface is recommended. |
Comment | File | Size | Author |
---|---|---|---|
#29 | interdiff-25-29.txt | 569 bytes | mpdonadio |
#29 | create-2571647-29.patch | 59.4 KB | mpdonadio |
#25 | create-2571647-25.patch | 59.95 KB | mpdonadio |
#21 | create-2571647-21.patch | 59.93 KB | mpdonadio |
| |||
#17 | interdiff-12-17.txt | 2.58 KB | mpdonadio |
Comments
Comment #2
mpdonadioQuick patch that just creates the interface, and updates the DateFormatter class to use it.
Next patch later tonight will replace DateFormatter with DateFormatterInterface where appropriate.
Comment #3
mpdonadioI think DrupalCon is making the website cry. Got a 404 when I posted that...
Comment #4
mpdonadioThink I swapped all of the correct usages according to PhpStorm. Should be ready for review.
Comment #6
mpdonadioThe fun of patches touching lot pf parts during sprints. This needs a reroll. If someone wants to do this at the sprint, feel free. Otherwise, I will reroll it tonight.
Comment #7
mpdonadioStraightforward rebase:
Comment #8
joelpittet@mpdonadio dumb question but how does making this an interface make it swappable? Is the plan to make it a service?
Otherwise this looks fine.
Comment #9
mpdonadio#8 I was only tangentially involved in the discussion in #2568613: Remove HTML support from date formats and replace remaining !placeholder where format_date() and 'date.formatter' => format() are used that led to this followup.
I assume what @alexpott meant in #39, is that by introducing the interface and using that instead of the concrete class in the injections, someone will be able to create their own formatter that implements DateFormatterInterface and ServiceProviderBase, they can swap it out in the container (see https://www.drupal.org/node/2026959). If we didn't have the interface, to swap out the service the new class would be forced to extend DateFormatter and implement ServiceProviderBase, which may not be desirable.
As a side note, if we are going to add the interface here, should we also add a proper service locator helper on \Drupal() for 'date.formatter' as part of this that @returns DateFormatterInterface?
Comment #10
mpdonadioOh, I jut re-read this. DateFormatter is already exposed as a service, http://cgit.drupalcode.org/drupal/tree/core/core.services.yml#n1247, but we don't have a helper on \Drupal for it.
Comment #11
joelpittetThanks, I should have known that since I was working with it's service yesterday:p
Not sure about the side note in #9 but I'd assume so. Maybe just add it and see what people say?
Because this a normal task it will need a beta eval.
Comment #12
mpdonadioAdded service helper. Do we have test coverage for these anywhere? Couldn't find any?
Comment #13
mpdonadioAdded beta eval. Should probably have a short CR for this.
Comment #14
mpdonadioCreated CR draft. Not sure if anything else is needed.
Comment #15
mpdonadioDOUBLE SUBMIT
Comment #16
Anonymous (not verified) CreditAttribution: Anonymous at XIO commentedThe patch looks good. I didn't find any additional occurrences.
Shouldn't these be changed to point to the DateFormatterInterface as well?
I know this is copy-pasted, but we might want to fix the indentation while we're at it.
Comment #17
mpdonadio#16-1 is fixed
#16-2 being dense here, but I don't see the indentation problem? Everything looks OK per https://www.drupal.org/node/1354 ?
Comment #18
joelpittetI don't see the code violation in that 16.2 either so I'm going to to go with RTBC on this one. Thanks for the Beta eval.
Comment #19
Anonymous (not verified) CreditAttribution: Anonymous at XIO commentedOh, I thought that it should be wrapped as close to 80 chars as possible, but it was a nitpick anyway.
Comment #21
mpdonadioReroll I think b/c #2571673: Convert Views t() usage where it is used as an attribute value
Conflict was in the use section for ViewEditForm. Chose HEAD and just updated the use to be DateFormatterInterface instead of DateFormatter
Comment #22
Anonymous (not verified) CreditAttribution: Anonymous at XIO commentedThat reroll looks ok to me.
Comment #25
mpdonadioJust needed a simple rebase:
Comment #26
mpdonadioComment #27
joelpittetBack to RTBC
Comment #28
alexpottThis seems unused and unnecessary to complete the aims of the patch.
Comment #29
mpdonadioReverted core/lib/Drupal.php to HEAD to remove that hunk.
Comment #30
joelpittetManually compared in Kaleidoscope the interface doc moves and there are no changes.
Comment #31
alexpottWhilst this is a large patch it is not disruptive since anywhere in contrib or custom that typehints on DateFormatter will still work. This became more important after we stopped supporting HTML in data formats as one of the things we said is that someone could swap out the service to add support back in. Unfortunately without an interface that is almost impossible. In fact we should have a rule that all services must implement a single interface that covers their public methods that are used as part of the service (that interface can of course extend other interfaces).
Committed 641eb3f and pushed to 8.0.x. Thanks!
Comment #33
joelpittet+1 to having that rule! :)
Comment #34
mpdonadioPublished CR. Created #2580739: [META] All core services should implement an interface.