🇬🇷Greece @gkffzs

vensires → credited gkffzs → .

vensires → credited gkffzs → .

Hello @ishani patel, quite a quick response, thank you!

I just reviewed and there are no phpcs or phpstan errors, so I think the MR is OK to be merged.

I noticed that pipeline #500809 failed, however I don't know if this has to do with the MR, but I think it doesn't.

@bserem Sorry for my misunderstanding, I thought the extra environment type would be included in the proposed resolution of this issue.

@ki Thank you for your work, I just reviewed the color palette and it passes the contrast checks for WCAG AAA (used WebAim Contrast Checker again).

However, it seems that it requires some change to ensure that colors are distinct for users with deuteranopia (for this check I used Adobe Color's accessibility tool).

Perhaps #AD1818 could be used for production, it has a 7.19:1 contrast ratio and gives no color blind conflicts with the rest of your palette?

OK, understood, thanks for your remarks, I will try to help with the related core issue.

Hello @ishani-patel, thank you for your answer and sorry for my delay!

I would suggest going with the first solution you proposed (hiding the "Delete" action) since it decreases the information load of the user. The second solution doesn't offer any benefit to the user, I think.

Working on a site that had #2 comment's patch applied, we faced a problem with the automatic download after the batch finished. More specifically:

• The files were properly saved in the private directory, however the respective database entry in file_managed table was not updated and pointed to the temporary directory.
• Thus $headers in finishBatch() were empty because the function failed to find the file via its URI and consequently it was not downloaded.

Based on that patch, I added some code in order to update the respective database entry with the new URI (that points to private directory), along with a couple of log messages to have a better overview of the process.

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

vensires → credited gkffzs → .

vensires → credited gkffzs → .

gkffzs → created an issue.

Adding to what sense-design and mlncn already reported, I found out that the reason getActiveTrailLink() returns such results for View-generated links is probably because /Drupal/Core/Menu/MenuTreeStorage's loadByRoute() function searches for route_param_key, which View-generated links have not. I tried creating a link to the View page manually via UI and then the route_param_key was properly populated and the active trail worked as expected.

So I searched if there is a way to populate that table field while creating it via Views, or if I can alter loadByRoute() query, and found out that there is a related core issue: [regression] missing menu active trail since Drupal 9.5.9 🐛 [regression] missing menu active trail in Drupal 9.5.9 Needs work . I applied the latest patch (#103 as of now) 🐛 [regression] missing menu active trail in Drupal 9.5.9 Needs work to Drupal 10.4.4 and the active trail worked for Views-generated links.

However, in case someone wants to avoid patching Drupal core, I did some work on current module's getActiveTrailLink(). I added an if-clause to handle the case of Views-generated links and make it return a proper result to add active trail. I attach the patch and leave the related MR is here: https://git.drupalcode.org/project/menu_trail_by_path/-/merge_requests/18.

vensires → credited gkffzs → .