@solideogloria

I don't think it's practical to have the entire description showing as well, as that makes each row a lot bigger.

Thanks! It would still be nice to have the version and links in their own columns. Maybe that can be a follow-up issue.

I will also note that I've never used this module before, and I have not tested it. If this feature gets added, I will have a reason to use it.

MR !79 is now the correct MR to work on, as it's from the issue branch into the project branch.

I would suggest some changes, however. Being able to masquerade doesn't necessarily mean you are an admin. I think the code should use "user" and "target_user", the same way the Masquerade module does.

When it comes to my thoughts on the feature, I was just about to try creating a custom module to do just this. I'm all for it, as masquerading is something that should be easy to audit.

I'm merging the changes into the issue branch.

https://git.drupalcode.org/issue/events_log_track-3528891/-/merge_reques...

solideogloria → changed the visibility of the branch 4.0.x to hidden.

It looks like the commits were added to the 4.0.x branch instead of to the issue-specific branch '3528891-masquerade-support'

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

https://www.drupal.org/project/drupal/issues/3252386#comment-15309908 📌 Use PHP attributes instead of doctrine annotations Fixed

@steven jones Can you backport it to 1.x? That, or can you provide a release for 2.x? There isn't a single release for 2.x.

When I write "new MyClass", the autocomplete will propose a matching qualified class name (class with namespace), and insert the import at the top.

Any convention we introduce here has to be one that is supported by commonly used tools, and does not require new custom sorting specific to Drupal.

Agreed. I never type the use statements; they are automatically added.

I just ran into this. It's certainly confusing in the UI, because I change an extended setting on Default, and when I go to any other display, it is italicized as if overridden, whether it has the same value or not. Then, if I try to "revert to default", it does nothing.

And what would cause Core to not come first? Every contrib module import is already after Core, as its namespaces are lowercase.

solideogloria → created an issue.

@drumm Thanks, but this search searches on all projects, including Drupal (Drupal Core), but I need to exclude it (eg, to count usages of some functions in contrib modules only).

@murz Just add -path:/core/

E.g. https://git.drupalcode.org/search?group_id=2&scope=blobs&search=DisplayE...

You can click "View syntax options" next to the search bar to see all the advanced search options.

RE #103, I definitely prefer what it looks like as-is compared to the groupings you showed. It makes more sense for Core use statements to come first, because Core code is the foundation, and the modules build on top of that. Plus, a single list of alphabetically ordered statements is the easiest to sort through visually (and programmatically).

Yes, if the maintainer creates new 2.x branch, then that makes sense.

I believe that's the version that introduced DeprecationHelper::backwardsCompatibleCall()

https://git.drupalcode.org/project/bartik/-/merge_requests/8/diffs#d47bc...

I sent a message to lauriii → asking for this to be merged.

solideogloria → created an issue.

Targeting most recent branch. I would still love to see a solution to this problem.

Created new MR targeting 6.3.x

solideogloria → changed the visibility of the branch 6.3.x to hidden.

@liam morland You should make a new feature branch. It'll be a lot easier to just copy in the changes, rather than trying to rebase everything from 6.2.x onto 6.3.x

This is so that the old merge request remains on the old base branch, to allow work on a backport and for the benefit of users still on that version. It is a good idea to use a logical name such as a suffix based on the new base branch to keep the issue fork's branches easy to understand.

https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... →

if (str_starts_with($display_id, 'data_export')) {

This is not ideal. Users can set custom machine names for displays, can't they?

See /admin/structure/views/nojs/display/VIEW_ID/DISPLAY_ID/display_id

Let me know if you need me to provide a stack trace or anything else.

I don't use either as I'm still stuck on 2.x. The new Navigation module isn't stable yet, and there are open issues in the Core module I need fixed before I will be able to use it in production.

Is it a major change to a site to get from 3.2 to 3.3? If there's no upgrade path, maybe it should stay. I'd personally want 2.x listed more than 3.1.x or 3.2.x, because of the project usage → .

Even 2.x doesn't have that anymore.

Looks good to me.

I would consider the solution proposed in ✨ Navigating to first level menu items is not obvious Active to be the best approach to solving the problem, because it solves both the issue there and this issue.

I guess the problem here is that it looks like a title and so user's ignore it. How can we update the design to have this be clear that its a link?

With the proposed solution in the issue summary, it can remain a title because the icon itself will be clickable again.

I tend to middle-click or ctrl+click on links to open them in a new tab. I try to do this with the "Configuration" top-level nav item but it's not a link, so doesn't work. It would be good to make it a link. I can do the same with the "Extend" item because it is a leaf.

Same. The new module is hard to use because of the difference between the top-level links.

I approve of the proposed resolution:

A possible solution to that one (which could apply to the lower level as well) is to separate the menu item link from the ability to navigate to its child items

I have a site that uses this structure for its non-admin menu, and it works really well on both desktop and mobile. Items that don't have children can just be links, and items that have children but aren't themselves clickable can be expanded but not clicked. Works great.

Personally, I'd prefer if the menu item containing children could itself be clicked with ctrl+click or middle-click in order to open its link in a new window. That's how admin_toolbar works. You hover to open the submenu, and you can click to open its page.

Fixed typo

I applied the MR diff as a patch to my Drupal 10.4 site, and I still get the error.

I get this error when installing the new Navigation module. (I'm not using any patches for this issue)

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "navigation_layout" plugin does not exist.

This issue is prohibiting me from converting my site to the new module.

I think this is a Core issue.

solideogloria → created an issue. See original summary → .

AI is just a tool like autocomplete

Yes, however, autocomplete is not good enough to replace a human at a programming job, nor is it enough to create a module entirely on its own that is ready to be published.

but this is future tool that companies are quickly adopting and it improve teams velocity and also quality in long term with accurate review process and appropried prompts it is still human driven the AI will not do nothing that is not already done by humans. I understand that there is some resistence to the changes more when they are radical like this but we will see shortly how situation will evolve, Microsoft already start layoffs of engeeners and developers.

It's not as helpful as you think it is, nor as helpful as Microsoft thinks it is. Just look at the GitHub pull requests that Copilate is "helping" with:

https://old.reddit.com/r/ExperiencedDevs/comments/1krttqo/my_new_hobby_w...

The code written is full of errors and mistakes. A knowledgeable human can do it better. So rather than relying on AI-generated "slop" and pushing it live as-is, you either need to do a lot of manual (human-led) testing and review of the results, or you need to write it yourself, using the AI only for ideas and boilerplate code.

FYI, I scanned comments #17 and #19 with GPTZero, and it detects both comments as 100% written by AI. I have reported the comments as spam.

@mkalkbrenner Thanks for that! Can we have a new release as well?

Please update the template. The file is more concise now.

https://git.drupalcode.org/project/gitlab_templates/-/blob/main/gitlab-c...

Should this issue be closed? I've been using the module in Drupal 10 without issue for a while.

Is this issue still needed? Work could probably continue in

📌 New branch for 11.x, fix deprecation notices Active

Bump. This needs to be reviewed.

+1 RTBC. Looks great.

I also approve of the idea of a 2.x branch and release.

Confirmed. Please merge MR !9 rather than 7. MR 9 adds composer.json to the project.

When looking at the Update Status module's report, these two changes are the only changes it sees as needed for D11.

Very simple changes. RTBC. Please merge.

web/modules/contrib/webform_submissions_delete/src/Form/WebformResultsBulkDeleteForm.php (lines 124, 152)

Relying on entity queries to check access by default is deprecated in drupal:9.2.0 and an error will be thrown from drupal:10.0.0. Call \Drupal\Core\Entity\Query\QueryInterface::accessCheck() with TRUE or FALSE to specify whether access should be checked.

Updates to these files cannot be patched with Composer. This needs to be merged for people to use it.

Looks good to me.

solideogloria → created an issue.

solideogloria → created an issue. See original summary → .

I don't know how to add a hook like this in a contrib module, since it's called in the core module's functions.

@jrockowitz Is there another way to solve this then, that would be acceptable? Perhaps a way to indicate that certain private fields should be viewable by "own node" users?

Could someone please review this? I've been using these changes successfully in production for around a year.

Both of the suggested issues are RTBC. I would like to see a D11-compatible release.

I agree. It's also becoming more important, since the 10.x EOL is this year.

Also, please use merge requests instead of patches. That way, the code review pipeline will run with the changes.

The issue summary should be updated to reflect whether this is specifically for D11 compatibility (in which case this issue should be closed as a duplicate of 💬 Drupal 11 Compatibility Active ), or to include information about the return type functionality that was re-added.

Re-adding removed functionality should be in a different issue. Also, it wouldn't be good to merge a patch that contains commented out code, as that doesn't comply with Drupal coding standards.

Please look at and review 🐛 2.0.x not compatible with Drupal 11 Active . That will help for 2.x, and then we can reroll the 2.x MR once that issue is fixed.

Please look at and review 🐛 2.0.x not compatible with Drupal 11 Active , which contains the change that was added to 1.x

Please look at and review 🐛 2.0.x not compatible with Drupal 11 Active , which contains the file that was added to 1.x

Please look at and review 🐛 2.0.x not compatible with Drupal 11 Active , which contains the README.md that was added to 1.x

Please look at and review 🐛 2.0.x not compatible with Drupal 11 Active , which contains the README.md that was added to 1.x