🇳🇿New Zealand @quietone

Needs rebase

Re #76: +1

In hindsight I was too brief in my comment in #72. Yes, I am concerned that a policy change in being made here in a non-policy decision. That isn't usually a good practice. However, the conversations have naturally lead us here and it makes sense to continue on here until we reach consensus. At the same time we should acknowledge and make it obvious that this is a overriding a recent policy decision. That would be respectful, help with transparency and be good practice to my way of thinking.

nod_ asked me about #72 in Slack. It was then I realized that commenting about the change in this issue summary and in a comment over there would cover my point. And nod_ kindly did that before I did. Thanks @nod_!

Did anyone search for other instances?

I applied the diff and checked that myself and did not find any other instances to change.

Committed to 11.x and cherry-picked to 11.3.x

Thanks!

Hi, in Drupal core 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 → . Thanks.

Hi, in Drupal core 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 → . Thanks.

Credit given to longwave and catch who also worked on and reviewed the release notes..

11.3.0-alpha1 was delayed by 1 week. 

@jpeeraer, this is a duplicate of 🐛 datetime input inside table cannot be submitted Active , which has a comment. So closing this one.

I strongly suspect this is a duplicate. Did you search before submitting?

If this is not a duplicate, it should be on 11.x. Changes are made on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Thanks.

Hi, thanks for bringing this up and working on a fix.

Support for Drupal 10.3.x has ended. A feature request should be developed on the main development branch, 11.x. The change may be back ported as needed according to the Core change policies → . Thanks.

It would help if this had a snippet.

Chasing HEAD, 2 more files added.

format

new link for pipeline instructions

redo page, add detail

Failing with

error qified@0.5.1: The engine "node" is incompatible with this module. Expected version ">=20". Got "18.20.8"
error Found incompatible module.

And that seems to be required by:

info Reasons this module exists
   - "stylelint#file-entry-cache#flat-cache#cacheable" depends on it
   - Hoisted from "stylelint#file-entry-cache#flat-cache#cacheable#qified"

Changing to critical because 11 is not being tested on the required version

This is for the CI environments project

This is blocking updating cspell for 11.3.0

CSpell 9.0.0 removed support for Node 18

And cspell tests are failing with

 yarn run spellcheck:core --no-progress --no-must-find-files --cache --cache-strategy content
Unsupported NodeJS version (18.20.8); >=20 is required

But core requires Node 20 for Drupal 11. → Why is this testing with Node 18?

Since 11.3.x has been branch, I am setting this to active.

quietone → created an issue.

Actually, there are separate issues for dependency updates for 10.6. So this should be done over at [3552767], or more specifically a child of that.

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

Move Infrastructure tasks to one heading, with instructions to comment in Slack.

Added credit for those listed in the issue summary.

start advertise section

Using the standard template to allow the community to track tasks and progress.

@nod_, thanks.

Shouldn't this be a task as it is to simply the message for technical reasons?

The proposed resolution here is changing the format agreed to in the policy issue, #343933: Backup incomplete → . Specifically, it is putting the scope first which was an option rejected in the other issue. It concerns me that that recent decision is being overridden in a non policy issue.

Hoping the remainder can be done here, I have started an MR.

This search reports 22 pages for this->loggedInUser. Some of those are on 7.x branches and I don't see a way to exclude those from the search. So, not really all that helpful.

And it is added to the 11.3.0 alpha release notes

Converted the MR. Then moved common date propertied to DateElementBase and moved the properties descriptions for methods in Dateitme and Datelist to the class documentation.

I was reviewing this and there was another update.

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

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

quietone → changed the visibility of the branch 3522497-deprecation-poc to hidden.

quietone → changed the visibility of the branch 3522497-deprecation-poc to active.

move making the issue in packages.d.o

Thanks to those who have raised their hand so far!

There are also two new positions in the process of being created and thus are not listed in the issue summary that xjm and I want to raise awareness of. One is a "dependency coordinator" maintainer and the other is a "developer tooling" topic maintainer. The titles are self-explanatory but there is more detail in the issues for those, which are added as related here. Your thoughst and interest are welcome on both of those issues.

just putting links to the Symfony issues in the issue summary.

Rebased and tests passing now.

quietone → created an issue.

Rebased and changed the Kernel tests to use the new fixture in the contact module.

Using

$ git grep field_layout | grep -v 'core/modules/field_layout' | grep -v phpstan-baseline

shows the only remaining usages are in layout_builder.install. Those are being fixed in 📌 Remove field_layout from layout_builder Active .

@larowlan, thanks that is just what I needed.

@ajinkya45, Sorry for not making the issue summary explicit. This isn't a simple removal. We need to retain test coverage but move all the code dependent on field_layout to field_layout itself. That way we can remove the entire field_layout module from core safely.

Restarted this by reverted the previous two 'removal' only commits. The test was moved to field_layout in a sibling issue, that just leaves dealing with function layout_builder_install():. For that I followed the advice in #20 but as an OO hook.

Adding locales not in the CLDR is a good thing. However, there would also have to be criteria for removing a locale that is not in the CLDR or we would have an ever growing list. Administrating some process to keep track of whether those additions have some number of active members will be difficult in my opinion. Would we check every year with the members responsible for a locale? Who is responsible for that?

In other words, for me, the title is 'inclusion and removal criteria for territories not in the CLDR'.

Two questions were asked here and we waiting for a reply, so I am changing the status.

Hi, in Drupal core 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 → . Thanks.

Hi, in Drupal core 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 → . Thanks.

Hi, in Drupal core 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 → . Thanks.

Hi, in Drupal core 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 → . Thanks.

@andrii-500, this is assigned to you. Are you still working on it?

Hi, in Drupal core 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 → . Thanks.

I notice the remaining tasks states this needs review but the status is needs work. Which is correct?

Came here because the version in 10.3.x, which is no longer supported.

That last two comment think this is a duplicate, where the correct fix is in 🐛 AJAX MessageCommand markup and styling differs from Theme default Active . So I am going to close this as a duplicate and update credit. If you think the credit is wrong, ping me in @contribute on Slack.

I've updated the Issue summary to mention the correct fix and that this issue documents workarounds.

Thanks

Found the duplicate and by the same author.

Changes are made on 11.x first. Also restoring template to track tasks and progress.

This may be a duplicate, has anyone searched?

Hi, if this problem was discovered on a version of Drupal that is not 11.x, add that information in the issue summary and leave the version at 11.x. In Drupal core 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 → . Thanks.

I notice that there are four merge requests here. That is unusual because in Drupal we use one MR to work on an issue collaboratively. An extra MR is typically only used to try a completely new approach or when backporting a fix. The issue summary should be updated so that anyone wanting to review or work on this know which MR to use.

Hi, in Drupal core 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 → . Thanks.

Is this a problem on Drupal 11.x?

OK, then updating version.

Hi, in Drupal core 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 → . Thanks.

Restoring standard issue template → so we can track progress on this issue.

Hi, if this problem was discovered on a version of Drupal that is not 11.x, add that information in the issue summary and leave the version at 11.x. In Drupal core 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 → . Thanks.

Restoring standard issue template → . The issue template is used to track progress and tasks on an issue.

Hi, in Drupal core 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 → . Thanks.

Hi, in Drupal core 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 → . Thanks.

Hi, in Drupal core 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 → . Thanks.

Hi, in Drupal core 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 → . Thanks.

Tested on 11.x using the steps in the issue summary as was able to reproduce the problem. But when the field was not required and left empty, the db record was deleted. I updated the issue summary

@group and @coversDefaultClass are documented at Required PHPDoc metadata for test discoverability →

These are not API documentation tags. They are like annotation -- used by PHPUnit. We do not document annotation on node/1354, just documentation tags. PHPUnit and how to write tests are documented in this section: https://www.drupal.org/phpunit → which should cover those "tags".

From #7. So, that means that page gets updated with the attribute information. And, that this should have stayed in the core queue.

@astonvictor, thanks for doing the research. It is good practice to check the history.

This issue began in 2009 and in Aug 2012 the "jQuery coding standards" page was added with frequent updates in 2013. Updates continued, at a slower pace until 2020. That alone makes we wonder if this issue is still relevant. Plus there has been not discussion here on the proposal since 2012.

So, is there work to do here? If there is add a comment, otherwise this issue will be closed after three months.

Thanks.

@vijaycs85, why does this have the 'novice tag'?

Took another look at this today. @jonathan1055, is correct that completing that issue summary would help. However, and in hindsight, I don't think we need to go through the Coding Standards process because this is simply bring this documentation up to date with current practice. The full process is needed for changes to the standards not making corrections in the documentation.

I have created an MR for this and changing to NR.

Sorry, @borisson. I am not sure what you mean in the last paragraph. Can we use this issue for adding what requirement?

The existing standard and the new one proposed in 📌 [policy] Remove the requirement for doxygen for test methods Needs work would include data providers and thus, they would need to be documented. So, that seems fine to me and no change is needed. No, there is the possibility to recommend that the return array uses meaningful string keys. That could be documented at Drupal Test coding standards → , which is not part of the Drupal Coding Standards. They seem more akin to best practice.

In the converting to an MR I changed the text. The meaning should not have been changed but can someone confirm the MR is correct?

There are 3 supporters, next is a change record.

Time for review.