It looks good to me as far as the readability but I can't really speak to accuracy without doing a deep dive!
Just tagging this for Drupal CMS because it'll help with Canvas-ing the remaining content types.
Updated the relevant components, manually tested a re-install of Byte and added one of each with no issue.
The only thing I'm not sure of is why raw was used in Storybook?
This no longer affects Mercury so removing the tag although I understand this is an overall DX improvement so may be a good idea anyway.
Looks right but we need to do the same for all image instances, and also specify sizes for responsive images.
Just came here to file this issue and then saw I've already been involved :)
I agree with the latest proposed fix to remove the percentages.
Looks good to me, we will need to update the Tailwind doc with the modified approach but can do that later once it is more in place.
Ah yeah I knew it was broken, figured you were onto it. Is there an issue in Sitemap module?
Ah thanks I wondered about that, easy enough to just remove the ones we don’t need! Probably just the two Latin ones actually, I guess there is a chance we’d use icons above the fold too though.
Whoops, sorry -- the underlying blog config that needs to be updated to disable Ajax is still in the original blog recipe! I created #3554686: Fix broken blog view config → to fix the broken config.
This is in the Byte config. I forgot to create an issue for that broken blog config problem, it's extremely wonky and we need to sort it out, basically an early days workaround that we need to fix properly.
Thanks @catch for the Olivero tip, it was easy to copy this (noting though that we have a lot more fonts, but that's because of character sets rather than general font bloat.
I've also removed the Breadcrumb and Branding CSS from libraries.yml because these are now added as Canvas components so the CSS loads dynamically.
OK yeah so this fixed the issue but it broke the text resizing on the Text component, but I've added the missing classes into the template.
Hold off on this, might have found an issue with the text resizing.
Agreed, the Gin into core work continues and Gin Login will be merged in. The approach is changing so it may resolve this anyway! #3554529: Merge Gin Login into the merged theme →
@shubham_pareek_19 sorry I think best to hold off until we figure out the final structure of the section. The section header is causing the gap, and we may not keep it so this would be resolved in that case.
FWIW it would be better to fix the Navigation one with ✨ Allow SDCs to be marked to be excluded from UI Active but I was not able to get it to work. There are actually three SDCs in Navigation but the other two are compatible right now, so they don't appear. But all three should not be in the UI I think.
I've disabled the Messages block as well as an SDC from Navigation, and removed the entire Latest view because that's a hangover from 1.0, we don't need that view.
I've removed this component altogether in 📌 Remove newsletter component Active
I messed up the commits and accidentally included another issue here but hopefully not a showstopper :)
I am actually really happy about this change, I've removed the component altogether and instead used Tailwind classes on the parent div. I also added a few more generic form classes which makes a start on styling the Mailchimp form, if that's what you use, but very lightweight.
This also resolves 📌 webform-newsletter.css is loaded on every page Active
Ready for review. Note that I updated the icon template to use the SVG because this is required in order for the icons to display within the admin UI. If it is using classes, the styles don't apply because they don't exist in the admin theme.
It's still using the <i> markup for icons within components.
Noticed that this also is needed in for the copyright in the footer, which we had an override in place for, so we can simplify that as well once this is in.
Initially didn't test with multiple paragraphs and had the wrong classes but that's fixed now :)
FWIW I don't think grouping is worth doing.
The Administration, Content, and Navigation user links menus are all cleanly 'admin UI' but the other two are not. I genuinely do not know what Tools is for (is this a Bartik hangover?) and User account is used in the header in Olivero so that's not the admin UI but it is an admin-side function. So then would we need three groups? And is that really making this easier to understand? It would be adding even more information to the UI.
So unless someone has a killer idea for how to group them intuitively I think it's probably better as-is.
I do agree that hiding it from the list is a weird pattern to introduce for config but it's also a weird pattern to provide seven menus, five of which most users won't ever touch!
Ideally we can update the form to submit via Ajax but that is blocked by #3553957: Unable to use Ajax submission for webforms on Canvas pages → .
Tagging as a target rather than a blocker because we can have the form without Ajax, it is just quite clunky to use the modal and will require us to figure out how to work around the Gin/Claro styles hijacking the modal.
I manually tested a reinstall after updating to RC2 and all is well (so far).
I think this is a duplicate of 📌 Update image rendering to use the Canvas responsive image Active ? Basically, we don't have image handling set up properly yet in Mercury.
I don’t think the icon is currently being used in core, so there is no change really to review. We’ve opted to use it as part of a change that will be introduced in Canvas. So I’m not sure how it could be tested in place.
You could update one of the existing link classes in your browser with a before and after but since there is no core change I think just comparing the files is enough?
I am a little unsure what the use case is for changing the line height? Are there specific scenarios or layouts where this would be needed? If editor types think so all good but I would have thought this is a standard thing site wide.
Had a look at actual core (the design is not based on core) and realised that the menu links are already out of order with the tabs, the blocks link comes first but isn't the first tab (not to mention comments is a tab but not a menu link...). So I think let's leave this as-is in the MR.
Yeah, we can reorder the links but not the tabs. The design had the Pages link first which makes sense but the design doesn’t have the menu tabs.
If we can get a way to surface Canvas pages in the autocomplete I think that would be a good interim step. I found ✨ Allow looking up more content entity types in menu item autocomplete Active but I am not sure if there is another core issue where this has been discussed in more detail.
This came up in context of including Canvas page entities in the autocomplete, which we will want to do. Something like what is proposed in ✨ Drastically improve Drupal's default linking experience in text fields Needs work would be good I think, so that core can provide defaults but modules can opt their entities and bundles in where relevant?
I don't think this is a bug. I can understand why it seems that way, but the setting on content type controls what is available from within the node form, it's not intended to be a wider restriction. I'm not totally convinced this is desired, since the setting is for better UX within the form and not necessarily for a hard restriction.
It also seems based on the description that the issue is more about the way the autocomplete fails to handle similarly named content.
I think that there are a bunch of related issues around being able to control what appears in the menu autocomplete, specifically being able to enable and disable specific entity types and bundles, and that seems like it might address the underlying issue here.
Manually tested the latest and it looks good. I also tested with the change in 📌 Add a link to the Pages view to the administration menu Active .
The only thing I just noticed is that the menu links are now out of order with the tabs, Content will always come first because it's the default tab. So I think we can either live with this or reorder the menu links? Not a huge deal imo.
Created 🐛 Update database icon to use phosphor Needs review for the icon.
Added screenshots for Claro and Gin. The icon is kind of weird but that needs to be updated in Navigation.
Definitely a feature request because the problem is that the menu link won’t appear in the menu in the editor or in the preview until the change is published (and this can’t be done easily until workspaces are available). So it might be pretty confusing to add since it would be the only element that doesn’t update in real time I think.
Oh that was quick :) Cross posted an after screenshot as well!