🇺🇸United States @mherchel

OK! I think we're good. I updated the example image with the goodest boy on the planet, which is a photo that I take and am happy to relinquish rights, assign whatever GPL/CC licenses needed.

Another situation that I ran into is if an image component has an invalid examples.

For now I'm going to delete the file in the MR. Before merging we need to figure out where its being used, and make sure nothing breaks.

I would not think this should be a blocker. but if the LOE isn't much, it would definitely be a big deal

mherchel → created an issue.

This will be a great one to work on at this weekend's Florida DrupalCamp.

Just left a review with a number of changes! Thank you!

Fixed!

Thanks for volunteering and doing this @hot_sauce

mherchel → created an issue. See original summary → .

How do you imagine this would work? Which SDC props should accept this?

I would assume that it would be the latter (icon equivalent of $ref: json-schema-definitions://experience_builder.module/image).

This would then provide a form element similar to the gif in the issue summary. This would then (I think) return a SVG which could then be inserted into an icon component.

Does that make sense? I'm not too particular on the implementation. There might be lots of gotchas, but I would like to make sure the editorial experience is great (with the dedicated icon picker), and that the DX is great by allowing an easy way to specify the icon widget from within the SDC's component.yml file.

I'm not 100% convinced we should be handling image styles on this level.

This solves a real need. I'm not sure what other alternatives we are.

I believe we should have an easy way to create responsive images in the context of a component so that I don't have to go to the Drupal UI to create these.

💯 Agree! But the same goes with image styles. I personally use responsive images only on larger images (700px wide). The majority of images are smaller.

If we implement this, then we'd want to always retrieve the source image and applying the image style would happen after running this filter.

I'm not sure I understand this. Why do we need the source image?

mherchel → created an issue.

volkswagenchick → credited mherchel → .

volkswagenchick → credited mherchel → .

volkswagenchick → credited mherchel → .

volkswagenchick → credited mherchel → .

volkswagenchick → credited mherchel → .

volkswagenchick → credited mherchel → .

volkswagenchick → credited mherchel → .

volkswagenchick → credited mherchel → .

volkswagenchick → credited mherchel → .

volkswagenchick → credited mherchel → .

volkswagenchick → credited mherchel → .

volkswagenchick → credited mherchel → .

volkswagenchick → credited mherchel → .

volkswagenchick → credited mherchel → .

volkswagenchick → credited mherchel → .

volkswagenchick → credited mherchel → .

volkswagenchick → credited mherchel → .

volkswagenchick → credited mherchel → .

volkswagenchick → credited mherchel → .

volkswagenchick → credited mherchel → .

mherchel → created an issue.

mherchel → created an issue.

mherchel → created an issue.

The root of the problem is that Olivero's CSS specificity on that page title block is greater then core's visually-hidden CSS class, so the Olivero width is taking priority.

I added a utility CSS file with an !important flag on the width property.

This should be good to go, but leaving it at NR since I added the most recent code.

Do you have another suggestion for how to fix this?

Ahh didn't know this. Will take a look.

Left a review. The CSS specific to the frontpage is unneeded.

I'm fine with either ECA or preprocess.

Looks perfect to me!

catch → credited mherchel → .

Yeah, it should really have a variable as the color, or if one off, a comment explaining why the variable wouldn't work.

I've noticed that the bottom right arrow on the card (.teaser--card::after) does not allow clicks to go through

Oh yeah, that is a big deal. Good catch! I'll fix this at some point soon :D

It's not a big deal to add the schema, but my thought was since this isn't going to be used in XB, there's not much of a point. But #5 is valid. I don't want to confuse people.

An empty *.component.yml file is valid when it belongs to a theme and is not overriding another component.

I'm not sure what the problem is?

phenaproxima → credited mherchel → .

Created followup 🐛 Case study "Client name" field should be horizontally aligned with "client logo" Active

mherchel → created an issue.

You accidentally had the project link CSS selector in the case study CSS file. I just fixed that.

Notes:

• The text still isn't aligned with the logo.
• There are some content changes that are seemingly unrelated (but don't appear to be a problem)

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

It looks like you forgot commit the code to attach the CSS, which is why it didn't look quite right!

Anyway, I fixed that, and also adjusted the top layout to remove the extra spacing. Should be good!

I'm going to work on this right now to fix the issues in #17

Overall this is looking great! There are some inconsistencies:

1. The image should be vertically aligned with the content.
2. The icons are not showing
3. Too much space between the image and the titile/phone/etc

I haven't read through the comments, but @lauriii wanted me to post my use case here for a question that I was asking:

Is it possible to allow rich text, and then limit the HTML within that within props?

Use case: I have a card component. I want the entire card to be clickable, so I can either wrap everything in an tag or do another method to make it clickable. However, I want the description text to be rich (so editors can bold and italicize). But it cannot allow links since these will not work.

Yeah, when I set this up Olivero supported IE11. So it's super complicated. If I were to refactor it today, i'd be using subgrid.

Either way, I'll take a look at it shortly.

One quick thing is IMO "eyebrow" isn't a good name to use... too "jargon-y"... I've used "pretitle" / "Pre-title" in the past.]

I can agree with that!

If anything else from #46 should change, I can make the changes myself, just let me know.

Yeah! Feel free to get in here and make changes. Just ping me in slack so we're not duplicating work.

Note that the card container is not working. But I believe this is a XB problem. Even when I place the default "Two Column" component, it breaks. Can't really do much until that's fixed.

I'm guessing everything in drupal_cms_olivero is very temporary anyway.

So, sure? TBH, I have no clue how this will affect the end users.

Just pushed a fix to consolidate the styles. Its a bit better than duplicating them, But, hopefully XB will either work w slots, or if we can easily grab the image style's height/width from the node template and pass them in that way

The previous code was relying on the code from the node--teaser.html.twig.

I created new styles in the card component and then refactored the node-teaser template to use a different classname.

@balintbrews and I had a discussion in Slack about this with he advocating that we leave the CSS out of the SDC, and me advocating that it should be contained in the SDC.

My thought is that we can do additional refactoring by duplicating the markup within the node teaser, and then creating a dependency on the SDC library.

Working on this!

No. It's an issue. But i'm fixing as part of the other MR. When that gets merged we can close this as fixed.

Style update pushed. Also added a 'Flipped layout" per Jen!

Working on this.

This is looking super great! Thank you @boulaffasae and @vasantha deepika.

I talked to @jwitkowski (the designer) and we need some changes:

• Image needs to be 4/3 aspect ratio
• Text needs to be aligned center
• Per https://drupal.slack.com/archives/C072JMEPUS1/p1736350025239129, no way to implement tags in XB. So we'll omit them. Need a followup
• I asked Jen if we should implement a reverse option, and she said yeah. It should be trivial to do

I'm going to work on this now to get it in for 1.0

Per @ckrina at https://drupal.slack.com/archives/C07G41EUJP4/p1736344315627679?thread_t...

I don’t think it’s a good pattern to force someone to open something in a new window or tap, regardless of it being external or not. They should decide. And the icon should only appear if the link is going to open in a new window.

If there i no way to make that link external, then the icon doesn’t matter.

I'm taking care of this in the CSS at 📌 Implement designs for case study/project full page display within Olivero Active , since there's an external icon there, too.

Styles and recipe updates. Should be good to go.

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

mherchel → created an issue.

Pushed some styles! Note that I normalized some spacing, and also the font sizes on the date and location title.

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

I'm running into an issue caused by this fix. In many components, I've allowed multiple types. Example:

  properties:
    is_active:
      type:
        - null
        - boolean

Now, I can't see how to do this. Furthermore, I've written code that's in prod that does this, but there's no change record. When prod updates to 11, this will break.

OMG and LOL. Sorry about that! I do have a habit of copying/pasting where I can.

+1 on getting this in. Adjusted credit.

Hi @michaellenahan,

Thanks for the issue, but since Olivero is now in core, all issues need to be created there. We already have an issue for this though at 📌 Olivero default welcome page needs link removed Active

volkswagenchick → credited mherchel → .

OK! I believe all items in #17 have been resolved!

I ended up "fixing" #24 with the latest commit.

When the wide search opens, it adds a CSS class to all search dropdowns (since we can't know which one is the correct one). On close, it removes the CSS class.

Fixed a couple things including the anonymous JS error.

However, I'm stuck on the styling for the dropdown. The issue is

• The wide search dropdown needs to have custom styling (dark background etc).
• The regular search dropdowns should not have this styling
• There's no dependable CSS selector where I can only style the wide search dropdown results.
• I delved into jQuery UI's autocomplete API to see if there was any type of pointer, reference, etc in the returned data. However, I struck out here too. Not sure quite how to proceed.

  Drupal.behaviors.searchWideForm = {
    attach(context) {
      once('search-wide-form', '[data-drupal-selector="simple-search-form"]', context).forEach(
        () => {
          $('.block-search-wide :is([type="text"], [type="search"])').autocomplete({
            open: function (event, ui) {
              // This doesn't reliably add the class to the correct dropdown. The event object doesn't point to it anywhere. The UI object is empty.
              document.querySelector('.search-api-autocomplete-search:has(.ui-menu-item)').classList.add('search-wide-dropdown');
            }
          });
        }
      );
    },
  };

The new look of the Drupal.org website is pathetically ugly. It looks like a beginner made it from free elements. The old one was nice and easy to understand. Why do they want to kill Drupal?

@atomi This is one of the rudest tasteless comments that I've ever seen in my 17+ years on Drupal.org. Lots of people worked on this, and it's a far step above the previous design.

Delete your comment.

mherchel → created an issue.

@mherchel confirming he also likes #5 🤞

So to confirm the component.yml will look something like this?

test_object_drupal_image_big:
  title: 'My title'
  $ref: json-schema-definitions://experience_builder.module/image
  width:
    minimum: 1000
  height:
    minimum: 1000
 

I'm also assuming this will be exposed in the upload/selection form so the editor can see the requirements?

if so, this is fantastic! Thanks for working on this!

@sethhill

g4mbini → credited mherchel → .