🇺🇸United States @michaellander

Front end is not my expertise, but I felt like rather than completely overriding the gin template, just using the `form_actions` variable already defined intop-bar--gin.html.twig would make it easier to support. This branch fixes functionality issues but still needs styling fixes.

michaellander → created an issue.

Thanks for the patch. We'll likely need to create a 2.1 and make a requirement for 10.3 and above.

What I've found is the approach with this module and some of the others in the space are a bit dated(and require overriding a core controller which created this issue to begin with. I'm working on a potential new alternative that I think would be foundationally stronger, but in the meantime we'll keep supporting this.

So it might be significantly more than this module would want to try and handle, but I was curious if you could instead render layout builder in the admin theme, and then use an iframe for the front end preview. Obviously this creates a new set of challenges, but the trade off would be to keep styles from bleeding over between frontend/backend. Obviously this would be a significant departure from what the module is doing currently, but at least there would be less fighting with non-api theme overrides.

What about providing an alternative to fields for many props in SDC's(and elsewhere) that really have no need to be full fledged fields(or at least wrapped in a single json field)? Fields are great for content, but when I think of low-code style modifiers(alignment, min width, max width, heading weights, levels, etc, etc) having a field for each is very heavy handed and slow to build out for front enders/builders, and doesn't provide a great admin interface without a lot of work. Perhaps letting fields focus on content and allowing display/style attributes to be simplified would alleviate some of the bloat.

michaellander → created an issue.

I thought this was interesting: WebP fallback image → .. Their argument is that we aren't gaining the full benefits of compression with modules like ImageAPI Optimize Webp → because we aren't compressing from the source file. My original rationale was to avoid running images through image style processors multiple times(once as jpg, once as webp, for example), though that wouldn't matter so much if it's only running it through the image style as it's being requested for the first time. I think it's also more and more likely that people will favor AVIF with a WebP fallback, and almost never want to keep the original file format if JPG, PNG, etc..

Perhaps finding a way where we would no longer need to do the derivative handling at the imageapi_optimize level, and let optimize just worry about optimization.

I haven't looked at this stuff in awhile and will try and get caught back up.

Another useful resource: https://component.gallery/design-systems/

I really think this would be a nice addition to this module, and I would be happy to make it something that is an optional setting if we think it's too big of a change to introduce by default. Would love some feedback from a maintainer. Thank you!

Hi @bjc2265, I've tested this again and it's still working for me. Have you seen any error messages in console or drupal logs? I will say that if you have a lot of debugging turned on, or caching turned off, it may be a little slow(as with all things layout builder). Right now the default behavior is to prevent dropping anywhere until validation is done. I could always change it to allow dropping anywhere until validation is finished, which would fall back to the currently build-in validation. With normal cache settings enabled, it has been pretty seamless for me but I want to make sure that's true for others.

Going to need to see a resume and some references. ;)

I've added you, thanks for jumping in!

@weseze, can you clarify the part that this patch is missing? Is it the idea that cropping/scaling a JPG image prior to conversion, automatically introduces compression, even if set to 100% quality?

My hands might be tied from this modules perspective, as we are piggybacking pipelines which naturally happens after image styles are applied. If I had the time, I'd create a module(or better yet, core functionality) whose sole purpose is to generate derivatives and then allow support for multiple formats(AVIF for example) so that ImageAPI optimize can go back to just optimizing and not the derivative piece.

Really appreciate this @pdureau! We will try to get these in shortly.

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

michaellander → created an issue.

michaellander → created an issue.

michaellander → created an issue.

Rate your excitement about SDC in core: 1 ... 10 | N/A

10

Rate your excitement about potential contrib extending SDC: 1 ... 10 | N/A

10

Did you 1️⃣ refactor existing template into a component, or did you 2️⃣ write a component from scratch? 1 | 2

1 & 2

Rate the helpfulness of error messages encountered: 1 ... 10 | N/A

10

Have you tried the Storybook integration? Yes | No

No(Soon)

Any thoughts you would like to share? The sky is the limit

I think it's brilliant and love that it encapsulates style and behavior with the markup it affects. I love the reusability aspect of it and I could see a future with library systems(i.e. Material, Polymer, etc) but for twig/drupal that can be shared and reused across open source. I think it's a big step in the right direction toward moving Drupal theming toward many modern frameworks and web components.

We've started developing a theme that is primarily SDC focused( https://www.drupal.org/project/kinetic → ) and hope to bring ideas back to SDC to push it further.

(I was not paid for this endorsement :) )

michaellander → created an issue.

michaellander → created an issue.

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

@saschaeggi it doesn't happen when the menu is left aligned. What would be different in that case? I'll check out those other issues, thanks!

michaellander → created an issue.

Let me know if you can't recreate and I can dig further. Could be a conflict with another contrib module or something.

I'm getting what I think may be a similar issue for the horizontal toolbar where the secondary menu dropdowns display briefly and then disappear on every page load. I tested the patch and it did not help in this situation however.

Sorry that was my fault. The pull request merged into the wrong branch. Should be correct in 2.0.1.

Thank you for your work on this

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

Thanks for your work on this, rolling in now!

Thanks for your work on this!

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

Thanks everyone for their work on this. Will start testing and try to get something rolled in early next week.

Thanks for all your work on this!

Inside of Drupal\Core\Entity\Controller\RevisionControllerTrait::revisionOverview() at this point:

        if ($revision->isDefaultRevision()) {
          $row[] = [
            'data' => [
              '#prefix' => '<em>',
              '#markup' => $this->t('Current revision'),
              '#suffix' => '</em>',
            ],
          ];
          foreach ($row as &$current) {
            $current['class'] = ['revision-current'];
          }
        }
        else {
          $links = $this->getOperationLinks($revision);
          $row[] = [
            'data' => [
              '#type' => 'operations',
              '#links' => $links,
            ],
          ];
        }

You are opting to print links if it's not the current revision, but I could see a case where you'd want to copy the current revision to be the latest if you have multiple drafts ahead of your current revision.

If for example we start with the following revisions:

• 4 (Draft)
• 3 (Draft)
• 2 (Current/Default/Published)
• 1

and I need to make an update to 2, I could copy it to be the next revision in the sequence:

• 5 (Copy of 2 - Current/Default/Published)
• 4 (Draft)
• 3 (Draft)
• 2
• 1

I could make some edits and publish:

• 6 (Current/Default/Published)
• 5 (Copy of 2)
• 4 (Draft)
• 3 (Draft)
• 2
• 1

I could then continue work where I left off:

• 7 (Copy of 4 - Draft)
• 6 (Current/Default/Published)
• 5 (Copy of 2)
• 4 (Draft)
• 3 (Draft)
• 2
• 1

This is actually currently limited in node revision UI and the update action is explicitly blocked in _access_node_revision: 'update', which means if you create new drafts, and decide to create a draft based on what's currently published, you'd have to delete each draft in front of the currently published one. I believe you've already fixed this issue in _access_entity_revision, but the overview form is still hiding the action.

One other thought is we might consider changing the 'Revert' naming, something like 'Copy as Latest Version' would match both the 'Latest Version' tab and the 'Copy of the revision from ...' log message. There is some additional discussion about that here: #2899719: Revision/version language on revision listing page is misleading with content moderation enabled → .

Thanks again, this would be a significant improvement.