Sidebar UI improvements

Right now we have 3 different things:

* Action: Immediately publish/unpublish, discard draft: regular button
* Sidebar-Link: Translations/Revisions
* Link to a page: entity usage, confirm forms, view/edit

And we also have red to indicate destructive things (although delete is much more destructive than discard draft, but it also only goes to a confirm page). And edit is a half-action kinda and also very common, which is why our original idea was to use a ghost button for that.

Maybe delete should also be in the bottom list as a red link.

1. +++ b/src/Controller/ModerationSidebarController.php
   @@ -282,8 +282,8 @@ class ModerationSidebarController extends ControllerBase {
    
          // Provide a list of actions representing transitions for this revision.
          if ($is_latest) {
   -        $build['actions']['quick_draft_form'] = $this->formBuilder()->getForm(QuickTransitionForm::class, $entity);
   -        $build['actions']['quick_draft_form']['#weight'] = 2;
   +        $build['actions']['primary']['quick_draft_form'] = $this->formBuilder()->getForm(QuickTransitionForm::class, $entity);
   +        $build['actions']['primary']['quick_draft_form']['#weight'] = 2;
          }
   

   maybe there should even be three sections? those on top, the quick_draft_form and those below? not sure how yet to name them yet.

2. +++ b/templates/moderation-sidebar-container.html.twig
   @@ -14,5 +14,17 @@
   -  {{ elements.actions }}
   +  <div class="moderation-sidebar-primary-tasks">
   +    {{ elements.actions.primary|without('quick_draft_form') }}
   +
   +    <div class="moderation-sidebar-actions">
   +      {# Put the revision log above the form. #}
   +      {{ elements.actions.primary.quick_draft_form.revision_log_toggle }}
   +      {{ elements.actions.primary.quick_draft_form.revision_log }}
   +      {{ elements.actions.primary.quick_draft_form|without('revision_log_toggle', 'revision_log') }}
   +    </div>
   

   yeah, because the template currently then does exactly what I suggested above. This would then become easier if we have 3 top-level keys and if the weights in the quick actions from match the default order.

   People can then still use stuff like that if they want a different order, but we can keep the default template simpler.

Also, I only saw specific hardcoded things in the patch I think, make sure to e.g. install entity_usage to see where that ends up now.

+++ b/src/Controller/ModerationSidebarController.php
@@ -282,13 +282,12 @@ class ModerationSidebarController extends ControllerBase {
+    $build['actions']['secondary'] += $this->getLocalTasks($entity);

This will create problems as 'secondary' can be null. I think we should initialize it as [];

This is a patch against #2988331: Content translation moderation because it conflicts with that in a few cases. We definitely want to get that in first, as that fixes a lot of bugs while I'm sure this will need some more discussion.

It will obviously not apply on d.o, but I would suggest that if you make further changes here, you always work against the latest patch in the other issue.

This should work better ;)

This is close, but there were three things I wanted to change:

1. Ghost buttons normally invert color/background on hover, so I added that.
2. The "danger" links should look like action buttons - I know there's a confirmation for deleting the node but discarding the draft has no confirmation so it should feel dangerous.
3. I didn't like the new placement of the revision log field - I get how this is probably nice for people that fill it out, because you want to fill it out before making the action, but not all users fill this out every time and it broke up the actions in a way that I thought didn't look nice. This is totally my opinion so I'm happy to chat about this more if you'd like.

If you're OK with the changes above, you can mark the issue as RTBC and I'll commit. Otherwise we can iterate on the design more.

Thanks for the feedback! I'll check this internally, there's also always the option to override something if we can't agree, that's fine. Will think about the position, it kind of made sense to me because even if you don't fill it out, you need to be aware of doing so before you press that button. But we'll try it out.

> 1. Ghost buttons normally invert color/background on hover, so I added that.

Can you point me to some real Drupal styleguide that defines this?
We found such definitions in many other styleguides and adopted it in a first iteration. Furtheriterations with UX research showed that inversion on hover creates visual irritation and we try to never do this and instead apply a 20% change on BG / FR color. This, by trying to shift it into the direction of higher contrast on hover, not less.

As a comparision, material.io only applies a slight effect, typically adding BG. They however reduce text readability with their hover in most cases, but only slightly - so it doesn't hurt that much:
https://material.io/design/interaction/states.html#hover

@miro_dietiker I don't think there's a Drupal styleguide for this, I think it's just common for ghost buttons to behave this way. I would rather go back to the old button styling (or something similar, they should look like buttons) than just underline the text inside the button, which was the styling in #21.

Love the new look! What everyone's thoughts on updating the colors so we don't have two blue buttons?

@kevinfunk https://www.drupal.org/project/type_style has a sub-module, type_style_moderation, that allows you to set colors for Workflow transitions. That's how I'd recommend setting colors, because otherwise we would have to hard-code color mappings for transition IDs, which may differ across sites.

An integration for Moderation Sidebar used to live in DF: https://github.com/acquia/df/commit/fc688c8c30c395fffa9eff67d4a5d65588a2...

That's understandable. Thanks @samuel.mortenson.

I'm doing a release today and wanted to get this in after tagging. I reviewed #32 and think it's good enough to move forward with. For active state on links - please file a new issue is this is needed, I'm not an expert on that but it seems like a good addition. Thanks for being patient everyone!

I'm going to ask people using the new release to review the UI changes so that the next release (8.x-1.4) isn't too surprising for everyone.

Just a note that this causes breaking changes for alter hooks and template overrides, see #3137427: Document render/TWIG changes introduced by 1.4 these need to be documented in the release notes at the very least.