🇺🇸United States @mradcliffe

James confirmed again.

The Mentoring team is interested. We currently use https://drupalcontribution.org (OpenSocial) as a stop-gap solution, but that was originally made for helping to organize and organize virtual contribution events.

A new branch needs to be created, potentially 3.0.x before I can create a merge request for this.

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

Removes Needs tests tag after I wrote a test. Removes Documentation tag because this is not a documentation issue.

We can add a test recipe in core/tests/fixtures/recipes and Drupal\KernelTests\Core\Recipe\InputTest would be a good place to either add a new kernel test?

Added the Needs tests issue tag. I think the recipe.yml above could be used. We don't need to install anything. We only need to confirm the recipe is applied message is displayed to the user.

    // Most of the input-collecting methods of StyleInterface have a `default`
    // parameter.
    $arguments += [
      'default' => $default_value,
    ];

But not all of them do so adding default here causes the error for askHidden.

mradcliffe → created an issue.

The test is failing with an access denied error accessing /admin/reports/upgrade.

Honestly, I am not sure why that report uses the MigrateAccessCheck rather than a permission as the controller does not run migrations, it redirects to watchdog with the query parameter "type" set to "migrate_drupal_ui". The only permission that is needed is "access site reports", which is not restricted to user 1.

Maybe fixing migrate_drupal_ui.log route to use that permission instead would make sense because an administrative user with "access site reports" already has access to it?

Do we need to add a @todo with the issue url for the coder issue above the ignore?

I removed the Needs followup tag since @dcam created the issue.

Thanks for making the change @koustav_mondal. The MigrateControllerTest is now failing. Running that test in isolation to debug it would be the next step here to resolving.

As part of the meta issue, 📌 [Meta] Fix all tests that rely on UID1's super user behavior Active , we need to “Assign the right permissions to make the test go green without the super user access policy.”

Updated MWG item.

I think this is fixed now. Pipeline is passing.

I resolved the CS nits. I removed the use of t completely because other tests do not use it such as MapBaseFieldTest and FieldItemTest. Also I switched to using FieldType attribute.

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

Thanks for recording the discussion, @rfay!

Oh, nice catch. Thank you for the merge request.

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

Added more agenda items.

mradcliffe → created an issue.

Based on some discussion at DrupalCon Atlanta, we need to merge the changes that have already decided upon.

I am going to create a new Update Mentoring Coordinators section in MAINTAINERS.txt in the Mentoring project for the Mentoring Working Group (MWG) to elicit feedback and evaluation from Mentoring Coordinators. And then once that is ready, we can move into the Core issue queue and create a merge request.

I added AmyJune, Tara, and Mauricio to the Past core maintainers page because they have already stepped down their role.

Confirm Mentoring coordinator MAINTAINERS.txt 📌 Confirm and update mentoring coordinators section in MAINTAINERS.txt Active issue. Adding past and no longer active mentoring coordinators.

mradcliffe → created an issue.

Adding credits from the 19 March 2025 meeting.

This might be a good candidate for Member Platform if we can switch to using that rather than OpenSocial.

@rachel_norfolk might have access to get this setup on the OpenSocial site.

I am marking this as Needs work because we still need to add explicit test coverage based on the issue summary and we probably want to make the messenger string a translatable markup string with a placeholder.

It looks like the issue summary has been updated. When updating the issue summary, we want to remember to remove the tag as well.

It would be nice to get another person to do a code review.

I am a little confused. The @todo comment mentions to remove the usage of the super user, but it looks like this is still being used in the test. Does the variable also need to be removed?

For those working on this issue, can you explain why this wasn't removed too?

I talked with Jason and postponing the issue seems like a good idea after updating the issue summary about why this is postponed / should be closed eventually.

Thank you everyone for reviewing the code. I was talking with Gábor who knows a bit more about multilingual and translatable strings. He pointed out that the paragraph tag is allowed in translatable strings. He went to locale.drupal.org to search for use of <p in translatable strings.

So this may not be as straight-forward as we thought.

I am going to add the Needs issue summary update and Needs steps to reproduce tags and set this to Needs work as there is something else that is causing the error.

The test runner seems to have failed on a bunch of kernel tests, but it was not clear if it is related to the changes.

Potentially a redirect from "documentation/is-drupal-secure" the Frequently Asked Questions page → .

I added the Needs issue summary update because it would be nice to have a clear problem/motivation and proposed resolution section on the issue.

It would be helpful to list the pages that are being worked on in the issue summary or in a comment as you are working on them so we can track what pages have been worked on.

Adding a tag.

mradcliffe → created an issue.

I added the Atlanta2025 issue tag for searchability.

Would a good criteria for assessing need be to review the Roadmap: #3446089: [Meta] Recipes Phase 2 Roadmap → ?

I performed Novice Triage on this issue. I am leaving the Novice tag on this issue because I think the requested changes from @quietone and confirmed by @joachim are clear. As well, we can confirm the uses again and update the issue summary to clarify how we found the changes.

I am removing the Novice tag from this issue because it was hard to me to determine the novice task on the issue.

I’m using this documentation as a source: https://www.drupal.org/community/contributor-guide/task/triage-novice-is... →

I performed Novice Triage on this issue. I am leaving the Novice tag on this issue because there is a clearly defined task for resolution. The issue summary could use an update as well.

There were some test failures in the merge request, but I think those are false positives.

I am removing the Novice tag from this issue because I think the resolution is ambiguous with the does not break anything comment.

I’m using this documentation as a source: https://www.drupal.org/community/contributor-guide/task/triage-novice-is... →

I performed Novice Triage on this issue. I added the Novice issue tag because we can update the issue summary and potentially start. We need to come up with a good test for the change.

I performed Novice Triage on this issue. I added the Novice issue tag and the Needs issue summary update issue tag so that the notes provided by @pdureau can be added to the issue summary to clarify the scope of the issue.

I am removing the Novice tag from this issue because I think there is not a clear path forward at the moment.

I’m using this documentation as a source: https://www.drupal.org/community/contributor-guide/task/triage-novice-is... →

Let's try to move this forward. I performed Novice Triage on this issue. I am leaving the Novice tag on this issue because we can focus on both rebasing existing work and applying the changes from @amber himes matz in #9.

I am removing the Novice tag from this issue because I think it is not as clear how to split the based on the various meta issues.

I’m using this documentation as a source: https://www.drupal.org/community/contributor-guide/task/triage-novice-is... →

I am removing the Novice tag from this issue because I think it is a bit confusing for a first-time issue.

I’m using this documentation as a source: https://www.drupal.org/community/contributor-guide/task/triage-novice-is... →

I performed Novice Triage on this issue. I am leaving the Novice tag on this issue based on @smustgrave's triage. We should focus on the issue summary update based on recent work and resolving the code review.

Re-opening the issue as Active because the other issue is now postponed. One of the two should remain open.

I updated the issue summary with the issue summary template, some steps to reproduce, and a summary of discussion.

Both this issue and 🐛 Node created timestamp and updated timestamp are different for new nodes Needs work are now postponed. The latter issue was waiting on this issue to resolve it. One of those two should remain open.

It is not a great user experience to have to empty out the time/date every time I want to write content. This is buried in vertical tabs, and can be easy to miss depending on the theme. If I write content, and it takes me 20 minutes to write it, I should not have my creation date 20 minutes ago and the updated date the present time. Both created and changed should be equal on submit when the entity is new.

@kevin.dutra's comment 🐛 Node created timestamp and updated timestamp are different for new nodes Needs work mentions

That's the thing, this issue does not occur when creating an entity without the form. It only occurs when using the form because the entity is not created and saved within the same request. (It's created in one request when the form is generated and saved in another when the form is submitted.)

So it is related to the form in-so-much as the form requires multiple requests carrying an unsaved entity.

I think opening up the other issue as Active is appropriate now because it is more related to entity isNew and saving.

teknorah → credited mradcliffe → .

Adding issue credits. Next monthly meeting is 📌 Mentort Meeting - 9 April 2025 Active .

mradcliffe → created an issue.

I am creating a bunch of "stub" pages with copy from past events that need to be documented because I had to go digging for hard copies from several DrupalCons and large Drupal events.

Adding issue credits.

Adding issue credits.

Adding issue credits.

By using this website, you warrant on behalf of yourself, your users, and other parties you represent that you will not:

Modify, copy, prepare derivative works of, decompile, or reverse engineer any materials and software contained on this website;

I am going to assume that merging DevPanel related functionality will not make DrupalPod a derivative work of DevPanel.

I was thinking this over, and I thought "why fight it?" Maybe aggregator items should provide a Manage Fields and Manage Form Display route even if they are not used by default. It might make it easier to extend aggregator functionality dealing with description property in case someone wanted to store other metadata from a feed.

Adding a warning message to Manage Fields and Manage Form Display to indicate advanced / non-default usage would be important to not confuse default users.

Optionally, an additional setting could be added to show/hide the pages would help. Since altering the routes would still be fighting Layout Builder, maybe just hide the local tasks.

It might also be helpful to add the "role" attribute as button since these are also essentially buttons.

This should probably be a merge request now so changing to Needs work.

I added ✨ Screen Reader Accessibility Active as a related issue.

teknorah → credited mradcliffe → .

Seems good to me. Do we need to trigger a "PHP 8.3 PostgreSQL 16" test run?

teknorah → credited mradcliffe → .

I'm going to guess this should have tests for when field_ui and layout_builder are enabled respectively.

I started looking into this and I quickly found that without defining a field_ui_base_route, which automatically pulls in manage fields and manage form display, layout builder quickly throws exceptions instead of handling errors. Additionally, layout builder will continue to throw exceptions if the form display routes are removed.

So in the end as I was playing around with this, I needed to also alter local tasks to hide the manage form display and manage fields, as well as adding a dummy route that redirects to manage display when field_ui is enabled.

It's kind of a hack and pretty much all due to Layout Builder.

I'll create a work-in-progress issue fork and branch shortly.

I also found that the display options configured in Item need work. If a field display options are defined, then warnings will be thrown because of type and label keys.

Thank you, @Kristen Pol. I forgot to click the checkboxes too.

mradcliffe → created an issue.

mradcliffe → created an issue.

Adding credits and closing.

A follow-up would be to make a deriver class because as-is this will have some problems without manual YAML modification (migration_lookup, etc...) if using migrate_upgrade / migrate_plus entities.

I'm not able to reproduce this. The agreement cookie is set to expire in 10 years when frequency is -1. It is not possible to set a permanent expiration on that cookie by specification so I set it to 10 years.

I do notice that the patch that was contributed for this feature does not set the frequency correctly for other frequency values for anonymous users. I may split that into a different issue.

I have been trying to debug this and find a way to reproduce locally. On a fresh install, agreement with anonymous works fine and no session cookie is used.

I tried manually setting a session cookie created for an anonymous user and agreeing to the agreement. I navigated around a couple of times. Then I deleted the session cookie and navigated to a node, and since the agreement cookie was still active, then it did not redirect to the agreement page.

I also tried manually setting a session cookie (in code) for the anonymous user after refreshing cache, agreeing to the agreement after I navigated to a node, then deleted the session cookie, refreshed cache, tried to visit the node, and since the agreement cookie was still active, it did not redirect to the agreement page.

So I think I need more steps to reproduce.

A simple workaround in the meantime is to grant the "revoke own agreement" to the anonymous user, which will display the checkbox and button on the agreement form.

Trying to think about it some more, maybe when checking if hasAnonymousUserAgreed, if the user has a session cookie, then migrate their session so it gets an updated date. If the cookie is gone, then it won't update the session cookie.

I mentioned I was going to be able to get to this a couple of weeks ago, but unfortunately I got caught up. I apologize for not addressing it. I will try to review this week.

Failing tests:

- Drupal\Tests\file\Functional\DownloadTest::testPrivateFileTransferWithoutPageCache()
- This seems like the approach/resolution may have a security-related issue.
- Drupal\Tests\standard\FunctionalJavascript\StandardPerformanceTest::testAnonymous()
- The test assertion should be updated.
- Drupal\Tests\settings_tray\FunctionalJavascript\SettingsTrayBlockForm::testBlocks()
- Seems to be consistently failing with the patch/merge request.

Rebased again as 📌 Replace \PDO::FETCH_* constants to indicate fetch mode with an enumeration Active was merged.

I've been running nodeinfo with this patch for about a month or so without any ill effects. Appreciate any additional manual testing to try to get this RTBC.

I am also getting this. The patch resolved the issue for taxonomy term pages via views, but there is also a duplicate crumb when visiting views pages in the menu.

Maybe this module needs something like Easy Breadcrumb's removeRepeatedSegments?

I'll set to Needs review to get further review on the deprecation message.

Rebased 3359511-regression-missing-menu onto latest 11.x

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

mradcliffe → created an issue.

I fixed a typo and changed the resolution from being a question to a statement in the proposed resolution that made it difficult for me to understand without reading the code.

I applied merge request 104 to my site and it resolved the issue of not having HTML titles anymore on views pages after I installed metatag.

Though it looks like Needs tests is applied and the merge request may be out-of-date with any recent test fixes so I'm going to update the status to Needs work.

teknorah → credited mradcliffe → .

I guess on new installs it gets the new release so not Major. I think it could be a Minor to just ditch the extra dependency and bring in its classes into diff module.

It will remove the need for the hook_requirements, phpstan overrides, etc...