🇳🇿New Zealand @quietone

There is a phpstan error now,

 ------ ------------------------------------------------------------------------------- 
  Line   core/tests/Drupal/Tests/Core/Entity/Sql/SqlContentEntityStorageSchemaTest.php  
 ------ ------------------------------------------------------------------------------- 
  1456   @covers value                                                                  
         \Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema::onEntityTypeUpdate()    
         references an invalid method.                                                  
         🪪  phpunit.coversMethod                                                       
 ------ ------------------------------------------------------------------------------- 
 [ERROR] Found 1 error                     

So, regenerating the baseline and tagging for a follow up to fix that test.

quietone → created an issue.

I am not sure about this.The standard states

All summaries (first lines of docblocks) must be under 80 characters, start with a capital letter, and end with a period (.).

The examples in the issue summary are actually not correct summary lines, and not just because of the first letter. They also do not meet the standard that "All documentation and comments should form proper sentences, use proper grammar and punctuation". And one of them is for a callback which has a completely different format which requires two separate lines.

The first case here isn't how @code/@endcode is supposed to be used. The Drupal standard states

Drupal standards: Put the @code and @endcode tags on their own lines. Do not use a blank line between the text that explains the code sample and the code sample itself.

So, I think that should be re-written.

I tested the code sample with Drupal.Commenting.DocComment.TagsNotGrouped and didn't get any errors. Therefor, closing as outdated.

It is true that Drupal core is not fully compliant with the Drupal Coding standards, and that the set of sniff automatically enforced by core is different than contrib.

Core continues to work to enforce all the Drupal Standards but not Drupal Practice. That work has been happening for many years and continues. It is done incrementally, that is, as core becomes compliant with a standard, the relevant sniff is enabled. For example, since Jan 1, 2025 there have been 35 changes core/phpcs.xml.dist, adding enforcement of a standard on all, or part, of the code base.

To find out more about how coding standards work happens, there is the Coding Standard project → and there is a #coding-standards in Drupal Slack.

The related issue in core is 📌 [Meta] Fix coding standards in core Active .

Yes, I think I just misinterpreted the error message and how 'module' is used. So, this is working as designed.

Rebased MR1889 onto 11.x and updated phpcs.xml.dist. This will need another rebase when the child issues are fixed.

Time for reviews on this one.

@lavanyatalwar, I just saw your comment. If an issue has been fixed the status is changed to 'Fixed'. If not, then there is usually something to do. I have updated the MR and the task now is to review the changes to ensure they are correct for the file as well as correct American English.

No longer postponed.

I rebased and fixed the remaining.

The sniff referred to in #57 was closed in favor of #3250986: Sniff "Drupal.Commenting.InlineComment.WrongStyle" doesn't like #[\ReturnTypeWillChange] → , which is fixed.

With the sniff enabled, for core, the many constants in module files are not reported as errors. Such as \Drupal\user\Controller\UserAuthenticationController::LOGGED_IN

@florianmuellerch, The developer documentation on Drupal.org can be edited by any member of the community. To learn more about that I suggest joining the #documentation channel in Drupal Slack.

Adding a related issues which I skimmed. I think #2486967: [meta] Move/Create Form Element Documentation → may provide insight into why the page referred to in #12 is not part of the Drupal 11 docs. And having skimmed those issues, I think this should be closed as a duplicate of 🌱 [Meta] Improve documentation for Render and Form Elements Active .

Came across this issue today. I don't see what this is postponed on so normally I would set an issue to 'Active'. However, all the remaining tasks here have been completed, so closing as fixed makes more sense. That is not to say that Views documentation can't be improved, just that this issue is complete. There are existing issues for views to improve documentation as well. Therefor, closing this meta.

Rebased and rebuild the baseline.

No longer a child of a core issue.

Converting FieldTypeTest was completed in 3414259. The remaining part here is to create a trait for the creation of blocks.

I am changing the title for that new goal and removing the parent.

There has been improvements in the config import and export since this issue was opened 8 years ago. Is there work to do here that has not already been fixed, or is addressed in other issues?

I am setting the status to Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

quietone → made their first commit to this issue’s fork.

Is this issue still needed?

@joegl, The Drupal Core issue queue is not the ideal place for support requests. The 'support request' option is there for filing support issues for contributed modules and themes. There are several support options listed on our Support page → . This is 'Get Support' at the top of Drupal.org. There is also information about Drupal Slack → , at 'Get Support -> Drupal Slack' also at the top of Drupal.org. You may get better replies in one of those places.

There is no indication on what this is postponed on. Using git log -S with varying strings from the issue summary, I was not able to find that code in core. Therefore, closing as outdated.

Setting to NW and tagging for a change record.

@joachim, thanks.

Trying for more explanatory title.

I searched core and there are no current examples of the proposed style. Does anyone know the history of why the @see style is used?

I deleted the CR titled, "Delete this CR".

quietone → created an issue.

quietone → created an issue.

Oops, postponed the wrong issue

quietone → created an issue.

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .

@dpi, I agree on having clarity but we should keep in mind that the Drupal Standards do not follow RFC2119. See ✨ Revise coding standards to use IETF RFC 2119 standards Closed: won't fix .

Committed 367e25f and pushed to 11.x. Thanks!

This doesn't initialize the output string anymore and adjust the code for that, which was nice refactoring. Now, this just adds a NULL return and, of course, add the return type. Very simple to review.

And, in light of 🌱 Deprecate hook_help() and combine with Topics Active , which @mstrelan reminded me about, it makes sense to make minimal changes here.

@mstrelan, thank you!

Can someone complete the proposed changes section?

There hasn't been discussion here for 8 years and the only comment was not supportive.

If there is interest in pursuing this, add the new issue template and complete the proposed resolution.

Is there interest in this?

Convert to new issue template.

This now needs proposed text.

This needs some scoping, considering the similar issue 📌 Fix inconsistent indentation between @code - @endcode block in core Active

It is confusing that the current text section shows other issues. Skimming through I don't see that there is consensus on CommonMark. Since I think this needs more discussion I am changing the status to 'active'.

Needs work for the change record

@borisson_, thanks. I agree.

I am going to close this. If anyone disagrees, reopen the issue and add a comment. Thanks.

Changing status so it will be reviewed by the committee.

This needs an issue summary update to incorporate the discussion from #21 onward.

I searched Drupal core for instances of "@.*stdclass" and found 3.

2. https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/views...
3. https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/image...
4. https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/edito...

No consensus on this yet.

Moving to critical because of the discrepancy between what Code does and the standard.

Updated issue summary to include nicxvan's support.

Changing to NW for a change record, step 3

Yes, it would be nice to say we comply. I updated the remaining task with some steps.

I also am changing this to 'Minor'. While we don't have a definition of the priorities for Coding Standards, I think 'normal' would be issues that directly affect our code base.

Skimming through those pages, they are about good practice and convention. If there are parts that are definite standards then that should be pulled out to a separate page, yes. Probably worth a discussion in a meeting for this.

The sniff has a property for spacing before the assignment.

Using the code in #16 with this

  <rule ref="Squiz.WhiteSpace.OperatorSpacing">
    <properties>
      <property name="ignoreSpacingBeforeAssignments" value="false" />
    </properties>
  </rule>

reports these errors

---------------------------------------------------------------------------------------------------------
FOUND 2 ERRORS AFFECTING 2 LINES
---------------------------------------------------------------------------------------------------------
 53 | ERROR | [x] Expected 1 space before "=>"; 3 found (Squiz.WhiteSpace.OperatorSpacing.SpacingBefore)
 54 | ERROR | [x] Expected 1 space before "=>"; 2 found (Squiz.WhiteSpace.OperatorSpacing.SpacingBefore)
---------------------------------------------------------------------------------------------------------
PHPCBF CAN FIX THE 2 MARKED SNIFF VIOLATIONS AUTOMATICALLY

There has been no work here in 8 years, usually indicative of no interest in a change.

If there is interest then complete the issue summary thanks. Otherwise this issue may be closed after 3 months.

Just pointing out that the next text is using 'must' which is not the more friendly tone that our coding standards use.

Updating issue summary.

Setting to RTBC so it can get on the agenda for a CS meeting.

@nicxvan, thanks for updating the title.

Committed 7488aea and pushed to 11.x. Thanks!

This now needs a rebase.

#8 explains that t() was resolved and I think SafeMarkup was eventually resolved in 📌 Improve FormattableMarkup documentation Fixed .

Closing as outdated. If that is incorrect re-open and clarify what is still needed to do. Thanks.

This tries to use replace the use of annotation style in the text and examples with attributes, except for leaving the 'annotations defgroup'. Some parts of the annotations defgroup is copied over to the Plugin API @defgroup and changed as needed to use attributes.

There are still references to annotations that should change.

Is this moving in the right direction?

Only comment changes and linting checks have passed, so setting to NR.

quietone → created an issue.

Added core/includes

Linting passed so setting for review.

quietone → created an issue.

I am confused by this. The baseline does have an ignore line, which is

$ignoreErrors[] = [
	'message' => '#^Method Masterminds\\\\HTML5\\\\Parser\\\\Tokenizer@anonymous/core/modules/filter/src/Plugin/Filter/FilterHtml\\.php\\:268\\:\\:setTextMode\\(\\) has no return type specified\\.$#',
	'identifier' => 'missingType.return',
	'count' => 1,
	'path' => __DIR__ . '/modules/filter/src/Plugin/Filter/FilterHtml.php',
];

The difference is that the base line has /core/modules/filter but the pre-commit check has /modules/filter.

It can be fixed by adding a void return to the function, but that is out of scope.

🌱 [meta] Fix 'Drupal.Commenting.VariableComment' coding standard Active fixed.

My searching about how to punctuate lists, which was weeks ago, didn't come up with a definitive answer. Although having full stops at the end of single words wasn't usually an option. So,yes, it may appear odd. I lean to thinking it is better to have some odd or unusual cases while gaining the benefit of fixing, and preventing, future errors.

Also see #6 about the @return void.

I went to rebase this due to recent commits and there are a huge number of conflicts. On a closer look this has changes to core/tests, which is done in another issue. All of those are out of scope and unfortunately, duplicating work in another issue. I didn't look at the scope when I visited this issue a few days ago. That seems like a good reminder to all of us to check the scope of an issue.

I have rebased, removing the out of scope changes.

This does need a followup work for '@return void'. I guess one in coding standards to sort that out.

Two more completed, 📌 Fix DrupalPractice.Objects.GlobalFunction in module Postponed and 📌 Fix DrupalPractice.Objects.GlobalFunction in hooks Postponed .

No remaining problems were found.

quietone → created an issue.

This time the conflicts were in NodeHooks1. And it was straightforward and linting has passes, so restoring RTBC.