.
Updated the IS for the reasoning for the dates.
@quietone Thank you for fixing that silly test.
Thanks @smustgrave!
Updated the IS with what we eventually settled on here. Thanks!
I will be contributing in my role for the coming year.
Thanks @volkswagenchick for everything over the past years!
No, it is actively being worked on because the release comes out in less than a week. Thanks!
Amending credit.
pameeela → credited xjm → .
Can you clear your browser cache in FF and see if that resolves the problem?
It would also be good to document the exact browser version, since the latest version is always changing, and to test in an anonymous/incognito window with no browser extensions etc.
Thanks!
We would need a merge request created against 11.x first (which would be backported to other branches once committed). (Also, the existing branch appears to be empty.) Thanks!
Could we confirm whether or not the use of Paragraphs is required to reproduce this, and search for other similar issues in the queue?
If confirmed, this would be critical.
It also seems somewhat related to your report in 🐛 Editing existing translation with set admin language edits wrong translation (data loss) Active , although the precise steps are different.
Thanks!
Thanks @jrockowitz! The only thing is that we need the MR to be created against 11.x, since issues are committed there first and then backported. Trying to switch the target branch can get really messy, so sometimes it's best to close the previous MR and re-create it against 11.x with a cherry-pick or whatever.
This also seems like a bug that should get some FunctionalJS test coverage, if it's a JS bug.
Thanks!
This would need approval from the Claro maintainers, so tagging. (It would also need to be a merge request rather than a patch, but best to wait to make sure the subsystem maintainers are on board first.) Thanks!
We would also need a merge request rather than a patch, since patches are no longer supported by automated testing. Thanks!
Thanks for reporting this issue! It reminds me of another issue that I think was fixed recently (I think having to do with modal content or something), so it would be worthwhile to search for other existing issues related to Claro and wordbreak handling. We might need a more general fix in the theme.
We need steps to reproduce this issue from a fresh Drupal 11 install. Thanks!
@Maninders, it's not helpful to post a patch when an issue already has a merge request, and therefore that doesn't receive issue credit.
Also, the merge request needs to be against 11.x. Sometimes it's easiest to just open a new MR and close the old one. However, note that any of the above are not enough to receive credit without other contributions to the issue. Thanks!
Also, I notice that there's still a disconnect in the form between the enabled checkboxes and the disabled label. That would also be confusing for a user. Unchecking the box would be bad too because it'd be data loss, since the user might want to retain which of a disabled menu item's children are enabled or not if they plan to turn it off only temporarily (or other usecases).
There's probably actually enough here already for a UX review; it's not too hard to look at the given screenshot and imagine "disabled by parent" 20 more times or whatever.
Interesting!
My first concern on reading this approach is that it would say "(disabled by parent)" five, ten, dozens of times if a disabled menu item had a lot of disabled children. That wouldn't be the best UX.
I would suggest adding before-and-after screenshots, showing the problem and the proposed solution when there are multiple menu children under a disabled item. Once we have that, we could tag this issue "Needs usability review" to get feedback on what the best approach would be from a UX perspective.
Closing as a duplicate of the linked issue. Thanks!
Sounds like we need more information here.
Moving to 11.x, which is where issues get fixed first.
We can't do anything with an empty bug report, so closing. If you can provide complete steps to reproduce your issue as well as a description of what the issue even is, that would merit opening a new issue.
It should also be noted that Drush is not a part of core, nor technically supported by core. In general, issues with Drush should be reported to Drush. (If we can confirm that a core change broke Drush, then we might revert that change from core until a fix for Drush was ready; however, we would need confirmation of what that change was and it should still get an issue in the Drush queue.)
Interesting! Moving to the main development branch, where it would need to be fixed first.
Steps to reproduce would indeed be helpful; usually, errors like this are caused by a bug in contributed or custom code. Thanks!
Thanks for reporting this!
The merge request needs to be created against 11.x (our main development branch); it will be backported to supported versions once committed to 11.x. In some cases the easiest thing to do is close the previous merge request and create a new one against 11.x. Thanks!
Per discussion with @chrisfromredfin, @Gábor Hojtsy, @leslieg, and @thejimbirch, Recipes support is a Starshot blocker. However, as Gábor pointed out, it requires extensive API changes in PB, which means that we'll have the best success if we also treat it as a beta blocker for core. I didn't update the IS because I'm hoping someone from the initiative can confirm. Thanks!
Thanks for reporting this. If we can confirm this bug, it sounds critical. It might be a good idea to search and see if there is an existing issue filed for this problem, also.
The merge request needs to be created against 11.x (our main development branch); it will be backported to supported versions once committed to 11.x.
Issues go into 11.x first unless they are confirmed to be D10-only. Please don't change the branch without a specific reason related to the issue's development. Thanks!
Thanks @miksha. The merge request needs to be created against 11.x (our main development branch); it will be backported to supported versions once committed to 11.x. In some cases the easiest thing to do is close the previous merge request and create a new one against 11.x.
This is actually still 11.x; it was left at 10.2.x by accident after the revert.
Thanks for your work on this issue.
Merge request should always be filed against 11.x to start. Fixes will be backported to the appropriate Drupal branches when the issue is committed.
Sometimes the easiest thing to do is to close the old MRs and create a new one based on 11.x. That will bring us closer to passing automated tests Thanks!
Note that all merge requests should be created against 11.x. It's often simplest to create a new MR against 11.x and close the old ones. Thanks!
Thanks @pradhumanjain2311 for your interest in contributing to this issue.
Simple rerolls, rebases, merges, or conversions to merge requests no longer receive issue credit. Only updates that address a merge conflict or that include other fixes will be credited. For merge conflicts, the merge conflict that was resolved must be documented in the text of an issue comment.
To receive credit for contributing to this issue, assist with other outstanding tasks or unaddressed feedback.
See the issue credit guidelines → for more information.
Meanwhile, all merge requests should also be created against 11.x first. (They get backported to the appropriate branches when they're committed.) So, updating the target branch.
Merge requests should be created against 11.x first. Thanks!
Thanks for the very detailed issue report!
Issues get fixed against 11.x (our main development branch) first, and are then backported to the appropriate Drupal versions once a fix is committed. So I'm just adjusting the issue's target branch.
Thanks for working on this. MRs should always be created against 11.x first, and will be backported to the appropriate versions once the issue is committed. (Sometimes, the cleanest thing to do is to close the old MR and open a fresh one against 11.x.) Thanks!
The eslint job is failing, but I wasn't able to understand why from the logs. I reran it to confirm. Maybe someone could run the esllint job locally and see what coding standards issues there might be?
@JonMcL, thanks for asking about this issue. There are thousands of open core bugs, and thousands of potential core contributors -- including you. 🙂 We fix thousands of issues a year, but there are still many more out them. What gets fixed and when depends on contributors stepping up to complete the work needed to fi the issue.
Drupal 9 is end of life and insecure, so it does not receive any further commits. You should upgrade to Drupal 10 as soon as possible to avoid security vulnerabilities with your site.
All merge requests should be created against 11.x (which is our main development branch). We should close other merge requests that don't target 11.x. If and when this issue has a fix that is ready for commit, it will be committed to 11.x first, and then backported to the actively supported branches of core according to our backport policy. In the case of this particular issue, the fix appears to be complex and to require internal API changes, so it might be committed to minors only (which would mean it would be available in 11.1.0 and 10.4.0 if we manage to fix this in the next five months).
Some sites use composer-patches to run interim/partial fixes until a proper fix is available in a stable release.
Thanks!
To address this issue, we should first create a merge request against 11.x. The easiest thing to do is probably to close the current MR and create a new one against 11.x. Thanks!
To address this issue, we should first create a merge request against 11.x. Thanks!
MRs need to be created against 11.x first. Thanks!
All changes go into 11.x first. Also, we should not create patch files when there is already a merge request, so @mbuechner please work on the MR instead to receive credit for contributing to the issue. :)
Hiding the patch files.
The MR needs to be created against 11.x. Also, contributors should only take the time to create the MR if they're also going to work further on the issue -- creating an MR from a patch with no other contributions is not creditable under our policy. Thanks!
The next step here is thorough manual testing of all the scenarios -- with and without view results, with and without the "display even if view has no results" checked. (Sounds like at least four total testing scenarios, which we should do before and after the patch.) We'll also need automated test coverage, probably a data provider to do exactly those scenarios above.
Thanks everyone!
OK, now reviewing the issue. Are we sure this isnʻt works as designed? Iʻve actually deliberately used this behavior sometimes, of having a global area to display when there are no results. I think this change might cause what appears to be a regression for some sites.
Tagging for subsystem maintainer review to decide if we actually want this change.
Saving credits.
Weʻre actually better off simply creating a new MR, so doing that now.
@prabha1997, fixes should always start against the main 11.x branch. Thanks!
10.2.x has had its final bugfix release, so marking fixed against 10.3.x (which means those credits from Portland will finally show on your profiles.) 😅 Yay!