Needs work
Project:
Drupal core
Version:
main
Component:
base system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
17 Apr 2023 at 10:11 UTC
Updated:
29 Nov 2024 at 13:06 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
andypostComment #3
fjgarlin commentedNote that we might run into this issue when running the tests: https://github.com/mglaman/phpstan-drupal/issues/527
I ran into it when trying to use the new method.
The new code does work in Drupal, but it wouldn't pass CI validation.
Once it's fixed then everything is good but I thought I'd mention it just in case.
Comment #4
andypostBetter title and updated summary
As measurements in #3274867-39: Add TrustedCallback attribute and comment #40 showing we can deprecate interface as well
Filed CR https://www.drupal.org/node/3355686 but probably we can improve existing one https://www.drupal.org/node/3349470
Comment #5
andypostThere's extra interface and API around render elements
RenderCallbackInterfaceMoreover phpstan has check for the interface and will fail test
PS
47 files changed, 192 insertions, 433 deletions.Comment #6
andypostphpstan needs improvement first
Comment #7
mglamanphpstan-drupal issue: https://github.com/mglaman/phpstan-drupal/issues/527
I'm working on support in this PR https://github.com/mglaman/phpstan-drupal/pull/529
PHPStan doesn't have an API for reading attributes from its reflection API yet. Or at least I cannot find it. So it's going to require a bit of work and refactor of the existing rule. This is needed anyway to handle
date_time_callbacksanddate_date_callbacksrequiring this anyway.Comment #9
fathershawnThe phpstan work referenced in #7 has been merged and closed.
Comment #10
andypostLocally it still fails
Comment #12
andypost@mglaman still reported https://git.drupalcode.org/issue/drupal-3354584/-/pipelines/27567/codequ...
Added workaround to MR to simplify testing
Comment #13
andypostOne test still fails
\Drupal\KernelTests\Core\DependencyInjection\AutowireTestlooks like it needs fixes as this services has no interface anymoreComment #14
andypostThe failed test looks like has wrong expectations, specifically looking at
the whole test from https://git.drupalcode.org/issue/drupal-3354584/-/jobs/149954
Comment #15
andypostThis services need aliases so added, maybe it makes sense to add condition for
TrustedCallbackInterfaceto expectation, so services implementing this interface also will require aliasingComment #16
andypostUsed to split out follow-up #3392396: Improve AutowireTest to ignore TrustedCallbackInterface
Comment #17
berdirOne thing I'm wondering here is how this works with inheritance. The method also worked if you have a subclass and override the callback there. I just verified that this doesn't work with attributes: https://3v4l.org/42bu0
Apparently this isn't something that happens with core, but especially views uses this a lot on all many plugin base classes, so there's definitely a non-zero chance that contrib/custom code has changed them? Would we need a BC layer that explicitly checks parent classes implementation?
Comment #18
andypostThanks, good point, maybe we should keep interface usage but check for attribute before BC
Comment #19
fathershawnCreated https://github.com/mglaman/phpstan-drupal/issues/611 to request a phpstan rule that checks the parent method. If we are going to deprecate the interface we need something.
Comment #20
fathershawnI don't have much hands on experience with the PHP Reflection library - is is possible to recurse up the inheritance chain?
Or could we simply allow overrides to fail if the extending class fails to add the attribute just like we have failures if either the trustedCallbacks method either fails to be implemented for new callbacks, or is implemented but fails to call the parent method to initiate the list.
Comment #21
berdirThe problem is that the current patch would immediately fail on a minor release, it wouldn't be a deprecation.
But yes, if we either keep the interface and method for now but check the attribute first, which we should anyway now for performance reasons or check the hierarchy at least for BC then that would work.
Comment #22
fathershawnThanks for clarifying @Berdir - yes we should deprecate but retain the interface and remove it in 11.x
Comment #23
andypostMoved condition to make check for attribute a priority
Comment #24
andypost\Drupal\Core\Render\Renderer::doCallback()and\Drupal\Core\Render\Element\RenderCallbackInterfaceneeds work to remove mentionsmaybe makes sense to introduce
RenderCallbackattribute at the same timeComment #25
andypostRebased on 11.x as fixed #3392396: Improve AutowireTest to ignore TrustedCallbackInterface
Comment #26
andypostNeeds review for #24 and related context #2982949: Introduce CallableResolver to help standardise the DX and error handling for callbacks across various subsystems
Comment #27
fathershawnCould we not also refactor uses of RenderCallback to use
#[TrustedCallback]? Is there some separation of concerns here that warrants two attributes?Comment #28
andypost@FatherShawn interesting, sadly they are coupled but maybe we need more cuts for that
split it
- priority of attribute before interface check (possible for 10.2)
- separation of
RenderCallbackInterfacefromTrustedCallbackInterface- the deprecation
Comment #29
longwaveRe #17 do we need additional test coverage for the inherited case?
Comment #30
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch 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 #31
longwaveAddressed #17 by explicitly checking parent methods for attributes, which works for now but we issue a deprecation if the parent has the attribute but the child method does not. Added test coverage for this, also bumped the other deprecation to 12.x.
Comment #32
godotislateNits/questions about which CR https://www.drupal.org/node/3355686 or https://www.drupal.org/node/3349470 should be used in deprecation messages. Looks good otherwise.
Comment #33
longwaveThanks, will try to revisit soon.
Comment #34
andypostThe only remaining question is about
RenderCallbackInterfacewhich would be great to move as well.Or at least follow-up is required
Comment #35
longwave@godotislate Thanks, updated all references to point to the deprecation. Also updated the deprecation CR to explicitly mention versions and point back to the original CR as an example for conversion.
@andypost Not sure what to do about that, maybe wait for followup? We could allow
#[TrustedCallback]on the class to allow all methods in the class - but then we run into the inheritance problem that @berdir describes immediately, because:We don't want all element implementations to have to specify
#[TrustedCallback]on the class.Do we strictly need this outside of
ElementInterface? Maybe we changeRendererto:and deprecate
RenderCallbackInterface? But I think this is out of scope here and needs a followup to discuss.Comment #36
godotislateChanges in MR and CR look good to me. I agree that what to do with
RenderCallbackInterfaceorElementInterfaceshould be handled in a follow up.Test failure looks to be unrelated, so I think it just needs to be re-run. Once it passes, I think it's good to be moved to RTBC.
Comment #37
longwaveRerun is green, moving to RTBC per #36.
Comment #38
andypostThe follow-up exists #2966711-57: Limit what can be called by a callback in form arrays and there's some work already done
Updated IS, RTBC++
Comment #39
alexpottI'm not sure that this deprecation is being done correctly. I think we need to leave the interface and static methods in place. I think we should issue a deprecation when using the interface and no attribute is present on the method (this will make the inheritance case simpler). And then deprecate the interface in 12 and remove in 13. That way we're not breaking API (as removal of an interface is). Consider the case of a class in contrib that extends from a core class and overrides \Drupal\Core\Security\TrustedCallbackInterface::trustedCallbacks() to add new trusted callbacks. That would be broken by the proposed change here.