Problem

  1. In order to output a link as a button, code has to manually specify an array of classes, which

    1. means duplicate code
    2. can become inconsistent
    3. is borderline impossible to detect + alter for themes.

Proposed solution

  1. Allow a #type link to have an optional #button_type, so that the following works:

    array(
      '#type' => 'link',
      '#title' => 'Delete',
      '#button_type' => 'danger',
    );
    
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sun’s picture

Status: Active » Needs review
FileSize
4.73 KB

Working implementation, including proper test coverage.

sun’s picture

sun’s picture

2: link.button.2.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, 2: link.button.2.patch, failed testing.

sun’s picture

Status: Needs work » Needs review
FileSize
5.65 KB

Merged HEAD

marvil07’s picture

Status: Needs review » Needs work

After this patch was created a new class get into D8, RenderTest, I guess we want to reuse it.

joelpittet’s picture

I"m not sure this is inline with the classy theme to move classes to the classy theme and remove them from stark. I'll send @mortendk and @davidhernandez over here to check into this.

joelpittet’s picture

Assigned: sun » Unassigned

Is there a prevision for the case of not wanting any classes on buttons? Or removing the 'button' class?

mortendk’s picture

Issue tags: +Classy

ooooh these prerendered classes are a pita to work with later on & one of the things that have haunted themers down when they wanted to add in other frameworks, that lets say used the .button for something specific (and you dont wanna maintain your own version of that framework offcourse)

Heres an idea - what if we prefix that kinda stuff with, so its clear where it comes from, and dont end up taking common classnames (yes i know im anal about this)

  1. +++ b/core/includes/common.inc
    @@ -3105,6 +3106,17 @@ function drupal_pre_render_link($element) {
    +    $element['#options']['attributes']['class'][] = 'button';
    

    drupal-button ?

  2. +++ b/core/includes/common.inc
    @@ -3105,6 +3106,17 @@ function drupal_pre_render_link($element) {
    +      $element['#options']['attributes']['class'][] = 'button--' . $element['#button_type'];
    

    drupal-button--

By at least using some kind of name spacing we know where it comes from & the chance of it colliding with an exisiting css framework is small.

What i would Looooooooove to see was instead button.html.twig and used addClass(' button--mucho-danger') instead, that would make it clear for the themer where to fix this class thingie

davidhernandez’s picture

Yeah, I was going to say the exact same thing as Morten. Not the class prefix part ;) but the template part. We are trying to eliminate, as much as possible, classes being generated, so I don't think we want to add more. The problem is how we are styling/creating buttons in core. It would be much nicer if we had a button template, and pass a variable of the button type to it. Then themers could deal with it as they want, including changing how the markup works.

marvil07’s picture

Status: Needs work » Needs review
FileSize
7.79 KB

I was wrong about RenderTest, it's not a base test as the one added here.

Here an updated patch, based on what sun proposed, creates a twig template for links, which is needed in order to add classes on the template.

I modified the implementation to follow several drupal changes like link theme variables.
Also I'm using it on the LinkGenerator class.

Notes:

  • I'm not sure how it will impact overall performance.
  • I would not expect this to past all tests.
  • This can be divided in different patches if needed.
  • Notice original patch is providing a new abstract test base class, which seems to be useful, but maybe also worth to mention it in the commit.

Status: Needs review » Needs work

The last submitted patch, 11: add_button_type-2243575-11.patch, failed testing.

mortendk’s picture

Status: Needs work » Needs review

@marvil yeah for templates ! - could we call it button-link.html.twig in that its clear for the themer that dont know anything what the template might is about.

joelpittet’s picture

What about just link--button-danger.html.twig and just add to the template suggestions of the existing template?

marvil07’s picture

A new patch, here I'm trying to use theme suggestions to pick either link.html.twig or link--button.html.twig depending on the use of the new '#button_type' property, BTW since logic is now in php we can again differentiate between isset() and empty() cases, which seems to be not possible in twig.

In any case, I'm not sure if I'm using theme suggestions correctly, since they seem to be picked up, but the template in use is always link.html.twig, any suggestion is welcome.

marvil07’s picture

FileSize
2.31 KB

I forgot the interdiff

Status: Needs review » Needs work

The last submitted patch, 15: add_button_type-2243575-15.patch, failed testing.

marvil07’s picture

Status: Needs work » Needs review
FileSize
7.92 KB
39 bytes

KernelTestBase already have a render(), reuse it, question about how to use twig templates is still open.

Status: Needs review » Needs work

The last submitted patch, 18: add_button_type-2243575-18.patch, failed testing.

The last submitted patch, 18: add_button_type-2243575-18.patch, failed testing.

marvil07’s picture

Actually use \Drupal\Tests\Core\Render\RendererTestBase

tim.plunkett’s picture

  1. +++ b/core/lib/Drupal/Core/Utility/LinkGenerator.php
    @@ -137,7 +137,13 @@ public function generate($text, Url $url) {
    +    return \Drupal::service('renderer')->render($link);
    

    This should be injected.

  2. +++ b/core/modules/system/src/Tests/Render/LinkTest.php
    @@ -0,0 +1,53 @@
    +  public static function getInfo() {
    +    return array(
    +      'name' => '#type link',
    +      'description' => 'Tests rendering of #type link.',
    +      'group' => 'Render',
    +    );
    +  }
    

    This can be removed

  3. +++ b/core/modules/system/src/Tests/Render/LinkTest.php
    @@ -0,0 +1,53 @@
    +  function testButtonType() {
    

    public function

  4. +++ b/core/modules/system/src/Tests/Render/RenderTestBase.php
    @@ -0,0 +1,63 @@
    +  protected function assertRaw($string, $message = NULL) {
    

    Why is this redclaring assertRaw and friends? Please use AssertContentTrait.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.