🇺🇸United States @sim_1

I think the downside of the current patch is that that text is added to the facet list as well when the facet is selected. That doesn't seem ideal.

sim_1 → created an issue.

sim_1 → created an issue.

Ok, i'm doing my best to remember... I wish I'd written down more details when it was fresh. I wasn't following the reproduction steps exactly. I was also working with custom client code:
- a custom module
- in the .module file there is a form alter that adds two widgets, and then attaches an ajax callback to each.
- admin theme is gin

I believe then I was getting ajax errors in the console when trying to use the submit buttons. It wasn't all the time, only after ajax had been triggered on the form by using either of the fields with callbacks. I can try to go back and reproduce. But I am guessing that all I meant by the patch not working is that it didn't fix my particular issue (not the exact repo steps from this description), but the other patch did.

+1 to have this merged.

I don't know how to change the target to the 3.x branch, but I update the MR to use the solution from #23 with some minor tweaks. I don't think the solution is perfect, but I'm also just still trying to wrap my head around it so it's such a relief that it at least gets the title on the page. My main issue is that I don't understand why the "label" render array value goes away when this module is enabled. It breaks assumptions that are made in core node templates, as well as contrib themes. But again, I'm just relieved something works!!

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

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

Marking RTBC. Things are pretty broken without this. I'm sure more improvements are needed, but better to have something than keep living with things being broken.

Patch #3 did not work for me. However patch #23 from the duplicate issue 🐛 Problem with form submit button's not working after an ajax call would refresh the form-id Closed: duplicate did work for me. Using that instead.

sim_1 → created an issue.

The other thing I'll say though, is that this is also fixed in the barrio project in version 5.5.11. So it might not make sense to add this variable, but instead mark this as an issue that is fixed upstream.

I accidentally committed the change with the default commit message, but there is now a MR ready for review. I added $barrio_path_images: "../images/"; to the _variables.scss file like the issue description suggested. This fixed the build issue when I tried it in my sub theme.

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

Added seeds layaouts and varbase layout builder modules to the list.

I've added a port of this patch and MR for the d7 branch.

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

Great, thanks for this MR and testing! Merged.

Great, thanks for checking. I think it's most important that we having a working install so hopefully we can just patch any visual issues that come up if we do end up encountering any. Thanks!

So, my understanding is that this change switches to using core's stable9, rather than the contrib stable theme. I'm fine with this (especially if the contrib stable theme wasn't installing correctly anyway). Essentially using option 2 rather than option 1 from this page https://www.drupal.org/node/3309392 → .

In your testing, did it seem like this switch introduced any issues related to the differences between stable and stable9 that that documentation mentions?

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

Great, thank you! Merging now.

Merging and marking as fixed. Thanks!

This is a great catch. We aren't supporting D8 anymore at all so we can remove that from the list.

This looks good to me and I think it solves the issue, but it does add in new classes on the list items (`breadcrumb-item` and `active`) that aren't used as a part of Foundation, and I don't see them in core's templates in starterkit_theme or stable9.

I suggest we:
- remove the extra classes.
- put the if/else statement inside the <li> like it is in core.

Or if I'm overlooking the reason why we should add in those classes let me know.

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

I think we're good to close this because 🐛 The base theme stable is not operated correctly Fixed is documenting/testing ongoing issues with stable dependencies in D10.

Added a MR, ready for someone else to review.

See this issue for the same issue and solution. https://www.drupal.org/project/google_analytics/issues/3308742 →

sim_1 → created an issue.

I'm having the same issue. It was working for me before. Now with alpha2 and drupal 9.5 it is no longer working.

I want to ask on this issue since it has the most visibility: How do we feel about keeping the D8 version as a recommended release? I feel fine (maybe after another week for some more testing) removing it from the recommended release list. I don't feel that we have the overall capacity to maintain both releases and I don't think there's much of a reason to. Do others agree?

I think you're right. Ok, changed to a 9.0.0-beta1 release.

Ok, I think that partially worked. @Grevil I tried to give you author credit, but because @anybody was the one to make the commit on the branch I guess it overwrote what I had selected in the checkboxes? If anyone knows a more foolproof way of doing this please let me know. I now think the only way to do it consistently is making and pushing the commit manually/with the command line.
- https://www.drupal.org/docs/develop/git/git-for-drupal-project-maintaine... →
- https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett... →

Ok, marking this issue fixed. I'll make a beta release and then if someone has time to work on 📌 [9.x] Test: Automatic requirement of the drupal contrib stable theme through composer.json Fixed that would great!

Ok, I'm going to try merging. I've changed the target in gitlab. My only fear right now is that last time i did this, the automatic contrib credit thing didn't work. So fingers crossed that goes smoothly!

Ok there should now be a 7.x-dev branch to start testing off of. I know it's a little confusing because we're also supporting D7 branches. If people think we should just bump it to 10x or something we can.

Lol well I tried and it did not in fact work. I'm going to make a 7.0.x branch instead.

I did some digging and couldn't find any examples of people doing that. I think it's fine just to do it. If it doesn't work we'll push a 7.x.x semver branch instead I guess.

So does it sound right that we'll create a 1.x.x-dev branch to test on first. And then merge this patch in with that if it works successfully?

Oops, I created a branch targeting the 8.x-2.x branch at first. Deleted that MR and remade one for the 3.x branch.

Ok, I created a field formatter that is the first step towards this issue. Right now it just displays the label of the root parent of a tree.

Remaining tasks:

• Fix the "link to referenced entity" feature to link to the root entity instead of the direct parent.
• Add configuration to specify which level of parent (grandparent, great grandparent, etc.) to display.
• Add tests.

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

Ok, so this issue is resolved?