Closed (fixed)
Project:
Drupal core
Version:
11.x-dev
Component:
base system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
23 Apr 2025 at 12:49 UTC
Updated:
15 Feb 2026 at 19:04 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #3
mondrakeHuh, harder than I thought. This is adding future additional interface parameters, since it seems that they are just missing currently.
Comment #4
smustgrave commentedAren't these considered API changes for some?
Comment #5
mondrakeFuture changes, yes, following the process:
https://www.drupal.org/node/3376455
https://www.drupal.org/about/core/policies/core-change-policies/how-to-d...
Comment #6
smustgrave commentedI know we were looking to close that meta but guess it’s been used another round.
Going to comment there I suggest closing the meta in 12
Chances here seem fine then
Though without a dedicated CR may be a surprise to some when the parameter just appears
Comment #7
mondrakeAgree we should close that meta issue, made changes there accordingly.
wrt to the CR, I am unsure. tbh I find the as-is a bit weird, many implementations of the interface methods rely on those params that are not in the interface signature - to the point that I was confused, started trying to remove them in the implementations just to realize afterwards I should do the other way around i.e. adding them to the interfaces. So for me we are just getting things right as they should be here, not changing conceptually the API. My 0.02€.
Comment #8
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 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 #9
mondrakerebased
Comment #10
xjmThanks @mondrake for working on this.
My main concern here is disabling the entire commenting standard over whole methods just because of (I think) the commented-out parameters inside the method params. Can we find a more targeted way to do that?
Comment #11
mondrakeNarrowed the PHPCS uncovered code by replacing
phpcs:(dis|en)ablewith targetedphpcs:ignoresingle line ignore directives, specifying the rule to be ignored.Comment #12
smustgrave commentedSeems feedback from @xjm has been addressed to disable specific rules vs disable
Comment #13
xjmSorry, one more suggestion now that (apparently) Coder may have fixed the single-line ignore thing for method signature lines. If it doesn't work, we can take your current approach.
Also, can you rebase the source and target branches so that the recently reverted unstable Ajax test thing stops making functional JS tests blow up? Thanks!
Comment #14
mondrakeIf we remove the three lines
from the MR and run phpcs on the file, we get
i.e. phpcs tells us the failing line is the one in the docblock, not the actual method declaration.
And, per https://github.com/squizlabs/PHP_CodeSniffer/wiki/Advanced-Usage#ignorin...,
So, adding the ignore like this
I checked it does not work.
Comment #15
xjmStrange? OK, thanks @mondrake!
Comment #16
xjmOh ah, I get it of course. Because as far as phpcs is concerned, the
@paramrefers to something that does not, as yet, exist. Sorry for being slow on the uptake!Comment #17
xjmSaving credits. Almost accidentally credited the bot.
Comment #18
xjmSorry, I thought I was about to commit this, but then had another question about the formatting. You are my guinea pig for improving this standard. 🐹
Comment #19
smustgrave commented@xjm this good to go now?
Comment #20
xjmWell I disagree with:
To me it seems we are adding PHPCS overrides in order to make the section hard to read. We do not do this with the deprecation and change record @see for API removals; those are spaced out properly. I think these should be too. I think we can simplify it a lot by spacing it normally and removing the unnecessary PHPCS overrides, right?
Can we try changing it to my suggestion? Then we can compare the two and if needed get feedback from the coding standards folks. :D
Thanks!
Comment #21
mondrake@xjm it would help if you could post how you would envisage a docblock to look exactly like in this case, WITHOUT the phpcs caveats. With that, we can try to decorate it with the phpcs:ignore directives that phpcs will tell us are necessary.
Comment #22
xjm@mondrake, OK, that's fair, will try to take a look myself when I can. :) Sorry for adding time and scope to the issue but I think we can improve the existing policy a lot.
Comment #23
xjmComment #25
xjmI pushed up a branch with the formatting I had in mind. I think this is far more readable, requires fewer phpcs ignores, and also allows for the fact that there might be multiple interface parameters or typehints added in a given major.
We'll see what the bot says and if this format just works or if there would be blockers. Forgive me for not scanning it locally; I'm watching several cities' worth of fireworks from my deck. 🎆
Comment #26
xjmThat passed pipelines. I shall now propose the standard be adjusted accordingly!
Comment #28
mondrakeWhat more work is needed here?
Comment #29
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 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 #30
mondrakeComment #31
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 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 #32
mondrakerebased
Comment #33
smustgrave commentedGoing on a limb but believe feedback for this one has been addressed with the new MR. If I'm wrong sorry!
Comment #34
longwaveQuestion about the deprecation skips (and I have similar questions about other generic skips that we have added)
Comment #35
mondrakeComment #36
dcam commentedI checked the regex in the edited ignore statements based on the feedback from #34. The statements now target specific namespaces and classes in Drupal Core. So the feedback was addressed.
Comment #37
longwaveI think we need two change records here, one for each interface; if there are any contrib or custom implementations of these interfaces they will break when we actually add the new argument, so we should tell them what to do?
Comment #38
mondrakeComment #39
mondrakeRebased and added the two draft CRs.
Comment #40
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. 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 #41
mondrakebot fluke
Comment #42
longwaveCommitted and pushed 13d18b6bd92 to main and 7b931dcb3fa to 11.x. Thanks!
Comment #47
mondrakeFiled follow-up.