Seeing the same with Breadcrumb and with the Mailchimp component that provides a signup form. It seems to be any component that doesn't have any settings (hence the NULL value for the component form).
Since this is only on the component form rendering, and the component has no settings, it doesn't cause any actual problems -- just looks scary. At least as far as I can see.
It's working for us now in Drupal CMS, with and without Ajax.
Updated config in Drupal CMS, we just need a small tweak to the styles to match the section below.
Current state:
Updated the section background to match but we also need to tweak some Mercury styles.
Current state:
Why was
views.view.scheduler_scheduled_content.ymldeleted?
We aren't overriding it anymore so the default view is what we want. It was only added in the other issue.
Not sure what's up with the Canvas view, I was surprised I put it in the wrong place but it looks right to me?
I agree it should be closed. Mostly because I don't think we should be acting on user testing from so long ago, which was done in a totally different universe (Seven anyone!).
The page looks a lot different than it did in 2011, although without a screenshot it's hard to directly compare. For posterity, the current state of the page in Claro:
Tests need updating now that we aren't shipping any default content.
pameeela → changed the visibility of the branch 3546880-add-an-id to hidden.
pameeela → changed the visibility of the branch 3546880-anchor-component to hidden.
Nothing to action just yet but added tag for tracking.
God that was painful. The override to disable the exposed filter prevents the view from being saved. We need to either expose it again and style it or remove it from the view, but that's a follow up.
@phenaproxima yep, the inline format is not actually supported yet anyway but I don't think we want to add alignment options in that case. Or if we decide that we want them, we should add that later when it's actually in use.
The 2.1.x branch looks good, manually tested as well. Thanks @philltran!
pameeela → changed the visibility of the branch 3467569-broken-file-upload to hidden.
Looks good and manually tested this in Drupal CMS. In the meantime we are also using simpleConfigUpdate and including the full set of matchers.
Confused by the Byte test fail, but I see it's marked as allowed to fail. Installing locally definitely works!
It's only a breaking change if the component is used in the default content, and luckily these two weren't so all good.
The components list is updated on re-install.
pameeela → created an issue. See original summary → .
I was able to take a look at this and unfortunately the other issue doesn't help with this one. Our problem is in ThemeNegotiator, when the route match happens in negotiateRoute to determine whether to swap the theme, the match fails because it uses the original request route. Somewhere along the line the route changes to match user.login so that's why everything else happens as expected later on, it just loads with the wrong theme.
The missing menus are unrelated. I'll create a separate issue.
So this left us in a weird place with just hero and hero-3, decided to rename them to be more descriptive but this may well be too much of a breaking change. I'll find out whether this is being used in any demos.
pameeela → created an issue. See original summary → .
Took another look and worked it out :) Here are the after shots:
Spoke too soon. I was looking at the footer and realised block.system_menu_block.utility is not enabled, but it's also not being disabled here so...... ?
We discussed this, the styles do change if you swap the menus around, but they shouldn't be tied to the menu name. There is a slot for utility links, the styles should apply to whatever menu is placed there.
I think this has been addressed? It looks better now.
So I have no idea how to fix either of these! Tailwind sorcery.
Hmm yeah this all got a bit mixed up.... too many balls in the air. We are pushing a couple of core issues at the same time (added as related) that will improve all of this but I should have realised that our version of the view was probably not suitable exactly as-is!
Ultimately in Drupal CMS we will link the title to the edit page, because 'View' is added to the operations links, but only in 11.3! Which will be before Drupal CMS 2.0. But it leaves this this in a weird place in the meantime.
pameeela → made their first commit to this issue’s fork.
Tagging as a stable release blocker for Drupal CMS, but I believe we also have to make some changes in Mercury and I am not 100% sure what our part of this is yet.
@galactus86 I think it would be better to wait until we have clarity on the intended outcome? I don't see this element in the Figma components list. We may go round and round a bit if we don't know what the end result should be.
Re-opening this because I'm not sure why we are giving the user the option of which HTML tag to use for the anchor? I just don't understand the benefit of this.
I also propose that we name it 'In-page link' instead of 'Anchor' because I'm not sure that term is that widely known.
Postponing since this would be a breaking change for layouts using icon tiles.
Removed the 'show only most common languages' from the IS because this feels like a potential bikeshed about which languages to show.
MR to add this to config in the starter recipe. It's unfortunate that we have to specify all of the toolbar items, if there is a way to just add one that would be better, but I don't think there is.
This has been added in core so we don't need to do it ourselves.