- Issue created by @catch
- First commit to issue fork.
- Open on Drupal.org βEnvironment: PHP 8.2 & MySQL 8last update
over 1 year ago Not currently mergeable. - @elber opened merge request.
- last update
over 1 year ago Custom Commands Failed - Status changed to Needs review
over 1 year ago 2:13pm 15 May 2023 - Status changed to Needs work
over 1 year ago 7:18pm 15 May 2023 - π«π·France andypost
I bet it needs to convert and clean-up all usages in core
here's a different approach - removal of property definition and throwing deprecation message
- last update
over 1 year ago Custom Commands Failed - last update
over 1 year ago Custom Commands Failed - π«π·France andypost
It could use existing change record https://www.drupal.org/node/3359695 β as the method now more useful
But maybe it should use parent method implementation (from Symfony)
- last update
over 1 year ago 27,838 pass, 330 fail - last update
over 1 year ago 27,861 pass, 328 fail - last update
over 1 year ago Custom Commands Failed - last update
over 1 year ago Custom Commands Failed - last update
over 1 year ago 29,377 pass, 5 fail - last update
over 1 year ago 29,378 pass, 3 fail - Status changed to Needs review
over 1 year ago 10:51pm 15 May 2023 - last update
over 1 year ago 29,388 pass - last update
over 1 year ago 29,388 pass - last update
over 1 year ago 29,388 pass - Status changed to RTBC
over 1 year ago 11:17am 16 May 2023 - π§π·Brazil elber Brazil
Hi applied succesfully in drupal 11.x version
Tests are passing
Deprecations are corrects (deprecation message follows the required patters)
Property has been removed has issue's summary saysMoving to RTBC
- π¬π§United Kingdom catch
Committed/pushed to 11.x, thanks!
I thought about backporting this to 10.1.x but I don't think the late deprecation after beta will particularly help anyone.
- π³π±Netherlands spokje
Not seeing the push yet?
Also unsure if this needs a change record as per the tag?
- Status changed to Fixed
over 1 year ago 11:26am 18 May 2023 - π¬π§United Kingdom catch
I've added this issue to https://www.drupal.org/node/3359695 β but I don't think we need a separate one.
- π«π·France andypost
I think it needs follow-up to remove other mentions in code-comments
- π³π±Netherlands spokje
Thanks @andypost. I've opened π Remove remaining occurences of ::supportedInterfaceOrClass property Fixed for that.
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
I was (pleasantly!) surprised to already see this land due to its BC break implications β¦ but I see it landed only in
11.x
! π€― Will this not be a problem for10.2
! - π³π±Netherlands spokje
- Deprecation warning is on 10.2 in the 11.x branch
- The 10.2.x branch will be branched from 11.x branch at the time of 10.2.0-alpha1, so that will "inherit"the deprecation.I think we're good.
- Status changed to Downport
over 1 year ago 12:57pm 19 May 2023 - π¬π§United Kingdom catch
Yes this will be in 10.2.
I do wonder if we should consider backporting this bit (and the similar ones) to 10.1, without the deprecation message, so that contrib modules can start to use it as soon as they drop support for 10.0 and 9.5:
+++ b/core/modules/serialization/src/Normalizer/NormalizerBase.php @@ -37,7 +30,13 @@ public function supportsNormalization($data, string $format = NULL, array $conte - $supported = (array) $this->supportedInterfaceOrClass; + if (property_exists($this, 'supportedInterfaceOrClass')) { + @trigger_error('Defining ' . static::class . '::supportedInterfaceOrClass property is deprecated in drupal:10.2.0 and is removed from drupal:11.0.0. Use getSupportedTypes() instead. See https://www.drupal.org/node/3359695', E_USER_DEPRECATED); + $supported = (array) $this->supportedInterfaceOrClass; + } + else { + $supported = array_keys($this->getSupportedTypes($format)); + }
Moving back to 'to be ported' in case people agree.
- Status changed to Needs review
over 1 year ago 1:45pm 19 May 2023 - last update
over 1 year ago 29,388 pass - last update
over 1 year ago Custom Commands Failed - Status changed to Needs work
over 1 year ago 2:01pm 19 May 2023 - Status changed to Needs review
over 1 year ago 2:17pm 19 May 2023 - π«π·France andypost
The patch is for 10.1 which has SF 6.3 and can benefit from the change, 9.5 I triggered just for fun
- π³π±Netherlands spokje
Thanks @andypost, I was already wondering about SF 6.3 and 9.5.x.
Also, we had a few escapees (See π Add missing ::hasCacheableSupportsMethod deprecations Closed: outdated ), may we should get those in first and then do the backport?
- π«π·France andypost
Good idea to combine backport with polishing, we can include π Remove remaining occurences of ::supportedInterfaceOrClass property Fixed
- Status changed to RTBC
over 1 year ago 7:10pm 19 May 2023 - πΊπΈUnited States smustgrave
So marking as the tests seem green. Change record appears to cover what's happening too.
- Status changed to Fixed
over 1 year ago 8:21am 20 May 2023 Automatically closed - issue fixed for 2 weeks with no activity.
- Status changed to Fixed
6 months ago 8:06pm 18 July 2024 - πΊπΈUnited States nicxvan
I'd like to add some information to the change record. I got hit with a deprecation that referenced the change record associated with this issue.
https://git.drupalcode.org/project/rest_views/-/commit/69d089ef7794badda...
The change record did not seem to address this case. I'd propose updating the title to something like:
Normalizers/Denormalizers should implement ::getSupportedTypes() instead of ::hasCacheableSupportsMethod() or using protected $supportedInterfaceOrClass
Then in the change record showing a before and after:
Before
/** * The interface or class that this Normalizer supports. * * @var array */ protected $supportedInterfaceOrClass = [RenderableData::class];
After
/** * {@inheritdoc} */ public function getSupportedTypes(?string $format): array { return [ RenderableData::class => TRUE, ]; }