Problem/Motivation

Some accessibility concerns about the use of sticky table headers were brought up in #3070558: Implement bulk operation designs.

@andrewmacpherson pointed out that the use of a sticky header obscures content. There are two categories of issues this causes:

1. In a table such as admin/content users can can navigate to an items hidden beneath a sticky header, so there's no longer a visual indication of the item in focus.
2. Speech control users may encounter a problem with "show numbers" functionality, which displays a number label for each control on the page. These labels would also be applied to items concealed by the sticky and cause confusion.

Steps to reproduce

In admin/content, get the page in a position where the header is sticky, then tab-navigate through the table. Note that items hidden underneath the sticky header can still be focused, but the item+focus state is not visible.

Proposed resolution

This issue was discussed with @rain. There was agreement that there are UX benefits to sticky headers (and potentially other sticky elements such as the one proposed in #3070558). While are several straightforward ways to address concern #1 (keyboard users) while retaining the benefits of Sticky navigation, this doesn't seem possible for addressing #2 (Speech control "show numbers"). @rain suggested adding a toggle that allows enabling/disabling of sticky headers. This would allow the subset of users adversely impacted by sticky headers to bypass that functionality.

Remaining tasks

Determine if this is an acceptable change to core
Review the patch

User interface changes

A new toggle button above tables with sticky headers.

Release notes snippet

Problem/Motivation

The bulk operation form takes space on top of the form and in some cases pushes the content of the view below the fold, meaning that to see any content on the page, the user has to scroll (see #2 for a screenshot). Presumably in most cases the bulk operation form is not being utilized most of the time users access a view. However, this could be the opposite for some views such as moderate comments view.

The connection between checkboxes and the bulk operation form could be also unclear. The checkboxes don't have any label and the bulk operation form is lacking a legend.

Proposed resolution

Move the bulk operation form below the view content. After a user has clicked a checkbox, make the bulk operations form position fixed. After user has clicked a checkbox the bulk operations form becomes the primary actions on the page and there's a strong reason to believe that the user wants to trigger an action. This will also add some clarity on the connection to checkboxes, as well as make it easier to activate an action.

An animated example to show the interaction behavior is linked to in #6
Designs can be found here: https://www.figma.com/file/NpZUAp8BEkMJvm5gKBCDBB/Claro?node-id=16591%3A...

Remaining tasks

Before full implementation, there are several things that must be figured out that aren't covered by the design.

• Consider how the implementation will impact the Views Bulk Operations contrib module. This redesign may require VBO to make some changes, but ideally these changes should not require anything too convoluted.
• How do screenreaders respond - particularly when the bulk operations become sticky on the bottom of the screen.
• How are bulk operations accessed via tab navigation, and are there tab order concerns since this is sticky? Should there be a way to easily access bulk operations without having to key through an entire table?

After the above considerations are figured out, determine if any changes to the design are needed.

Implement the design.

To reproduce:

Make a site that has Content Type A with an entity reference field to Content Type B
Make some content that has this reference as a sample
Make a view that shows content of Type A
Add an exposed grouped filter on Content Type A's ER field to Content Type B
Fill in a few examples of Content type B as options for the grouped filter. Use the Type B nid as the value.
Save and look at the view on a page. You should see the following:

"Notice: Undefined index: value in Drupal\views\Plugin\views\filter\NumericFilter->acceptExposedInput()"

I have the following code in form

$share_type[] = 'value1';
$share_type[] = 'value2';
$share_type[] = 'value3';

  $form['share'] = array(
    '#type' => 'radios',
    '#options' => $share_type,
    '#default_value' => 0,
);
$form['document'] = array(
      '#type' => 'managed_file',
      '#upload_location' => 'public:/document/',
      '#upload_validators' => array(
        'file_validate_extensions' => array('txt doc docx xls xlsx pdf ppt pptx'),
        'file_validate_size' => array(1024 * 1024 * 5),
      ),
       '#states' => array(
        'visible' => array(
          ':input[name="share"]' => array('value' => "2"),
        )
      ), 
      '#title' => t('Choose a file'),
      '#title_display' => 'invisible',
      '#size' => 22,
    );  

I want to display document field when the radio button field is having a value 2 . Its working for fields when its having a text area as a type . Its not working for managed_file as a type .

Hm. Perhaps I'm doing sth. wrong, but after upgrading a few sites to Drupal 8.8 I found that I cannot save newly translated nodes anymore. The error message is "Either the path '/node/[nid]' is invalid or you do not have access to it." where [nid] is of course the corresponding NID.

Steps to reproduce:

* Use sth. other than the administrator account. You should have the usual editor permissions to create nodes and create/update translations and translate any entity, of course. You should not have any url alias permissions.
* Create a new node in the original language (in my case: German)
* Save the node
* Edit the node again
* Click on translation, add translation (English)
* Try to save
=> Error.

I found that this error comes from "ValidPathConstraintValidator::validate". If I insert a return statement in the first line of that method, everything works as expected.

I don't have pathauto installed or sth. I *would* like to set/assign an automatic alias in a custom hook_node_presave, but the validation error seems to be trigged before this hook is even called. I checked pathauto and they are also using that hook to do their auto-path magic.

I don't understand the error message to be honest. Yes "/node/123" is of course not a valid alias, because it's reserved for the nodes. But I didn't assign anything. I don't even have permissions to assign any manual alias.

It used to work with 8.7 but not with 8.8.

Problem/Motivation

All system emails, sent from drupal, use "site name" as the "from" name. But if the name is in non-latin language (tested on cyrillic one) and is a bit longer than usual (approx. more than 24 characters) - it gets cut. Though in the mail's subject and body the same name is written fully.

Steps to reproduce

1. get latest drupal 8 installation package
2. at the beginning of install select drupal's language (tested in Ukrainian, but most likely can be any other non-latin language)
3. continue installation with Standard profile
4. MySQL database selected, but most likely doesn't matter
5. put site's name longer than 24 letters at the end of the process
6. right after installation - log out, navigate to [site]/user/password, enter your username and submit
7. receive a recovery password email with sender's name been cut

P.S. Worked fine in Drupal 7

Problem/Motivation

I've installed a clean version of Drupal 8.9.2. Whenever I add a block it's not visible in the source code when a user is logged in. For example, I've added multiple languages and added a language selector block.

When I look at the source code the block content is not visible. Instead, it shows the following code:
<span data-big-pipe-placeholder-id="callback=Drupal%5Cblock%5CBlockViewBuilder%3A%3AlazyBuilder&amp;args%5B0%5D=taalkeuze&amp;args%5B1%5D=full&amp;args%5B2%5D&amp;token=xoiSRTIeMcL8BPxkV-Evi_wOyBdyIGidq-G8edZjWtA"></span>

This causes problems when I want to use JQuery on elements within a block.

The content is visible in the source for anonymous users. It's also visible for logged in users when I disable the Big Pipe module.

Problem/Motivation

Just randomly noticed this. The comment of DeprecatedServicePropertyTrait::__get uses the word Alows instead of Allows. English is not my first language, but I am pretty sure this is not on purpose, and that seems like a small typo.

Steps to reproduce

Open the file and look at it.

Proposed resolution

Fix the typo.

Remaining tasks

- Create a patch
- Commit

User interface changes

-

API changes

-

Data model changes

-

Release notes snippet

-

Problem/Motivation

NodeAccessControlHandler::acquireGrants() does not consider translations with different published states. It stores grants for whichever translation you are currently saving and applies it to all translations, regardless of their individual published states.

Steps to reproduce

1. Setup a translatable node type and make sure the published flag is also translatable.
2. Create a node and publish it
3. Create a translation for this node and save it as unpublished.
You can now observer that the original node, which is published, is not accessible.

Proposed resolution

Extend NodeAccessControlHandler::acquireGrants() function to include grants on a per translation basis instead of only the translation being saved.

Remaining tasks

Review attached patch

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Problem/Motivation

At the moment every content entity type must implement hook_user_cancel() to do updates when a user is cancelled. We have comment_user_cancel() and node_user_cancel() but we are missing implementation for other Core Entities, including: taxonomy_user_cancel(), file_user_cancel() and media_user_cancel(). We need to handle both user_cancel_block_unpublish and user_cancel_reassign.

Also we have node_user_predelete() and comment_user_predelete() that will delete all the nodes and comments if the user is deleted. We might need something generic for that too.

In addition, many custom/contrib Content Entity Types likely have missing or incomplete implementations of the relevant hooks to properly react when a user is cancelled.

Proposed resolution

It has been decided to provide a generic solution using a Entity Handler dedicated to reacting on the cancelation a user.

The proposed handler will support each option that the administrator has for cancelling a user (mainly deleting all associated content or making that content anonymous). Additionally a implementation will also be provided which will support batch processing.

Each Content Entity Type will have to add this new handler to their Entity Type Annotation, developers can take advantage of the handlers provided by core, or can extend those handlers to define their own custom functionality. The latter is not required for custom Entity Types and the handlers provided will work with custom Entity Types.

Remaining tasks

• Continue to refine the proposed resolution and review associated patches.
• Framework manager decision is required on which namespace these new handler classes should use, see #39.

User interface changes

@todo - perhaps the user cancel form should give more indication of how many and what entities are going to be affected.

API changes

1. Modifications to User module to provide new handlers.
2. Modifications to some core modules to replace the usage of hook_user_cancel() with these new handlers.

Data model changes

No data model changes.

Release notes snippet

TODO.

Problem/Motivation

Redesign the current modules page. MVP provides the same interaction with updated styles / components.

Proposed resolution

Initial proposal can be found here https://www.figma.com/file/NpZUAp8BEkMJvm5gKBCDBB/Claro?node-id=16542%3A34

General specs

Design in progress

Remaining tasks

• Standardize the Details component across pages
• Determine design pattern for the module filter

User interface changes

Style changes to Details components, and possible style changes to filter component

Test Pages

• /admin/modules

Problem/Motivation

In preparation for adding JSON:API to Drupal core, we released the 2.x branch. In it, we tried to clean up many of JSON:API's rough edges. One of which was that while we represented entities as "resource objects" that don't directly match the structure of the underlying entity, when you filtered collections, one would have to filter by entities using their exact structure, even bits that were missing from the resource object representation. We published a change record to this effect.

That change introduced and unintended consequence, anyone filtering by the target_id property of an entity reference item would have their clients broken. This target_id property is omitted from resource identifiers because it was believed that it was unnecessary because it sort of duplicated the id member.

This was a wrong assumption, it may be necessary to filter a the target ID when filtering for an entity referencing a config entity. This might be the case if your client is filtering users by a role machine name, for example.

Proposed resolution

Add a drupal_internal__target_id property to resource identifiers and make it possible to filter by this value (this ensures that filters still closely match JSON:API's output structure (the purpose of the CR that broke this behavior))

User interface changes

None.

API changes

A new property will be added to JSON:API's output. This is not a breaking change.

Data model changes

None.

Release notes snippet

TBD

Original report

:

I am trying to upgrade my site from the 1.x branch to 2.x but am running in to some confusion and a bit of a performance problem.

When filtering by an entity reference field, I used to be able to do something as simple as /api/entity_type?filter[ref_field]=123, where 123 is the ID of the entity. This is beneficial to using the UUID because it does not require a JOIN on the referenced entity table. The query would be something like:

SELECT base_table.id AS id, base_table.id AS base_table_id FROM {entity_type} WHERE ref_field = 123

Now, when trying to perform the same API request, I get this error: "Invalid nested filtering. The field `ref_field`, given in the path `ref_field` is incomplete, it must end with one of the following specifiers: `id`."

If I change the filter to ?filter[ref_field.id]=123, the query becomes overly complex and performance degrades seriously (we have over 2M entities):

SELECT base_table.id AS id, base_table.id AS base_table_id FROM @entity_type base_table INNER JOIN @entity_type entity_type ON entity_type.id = base_table.id LEFT OUTER JOIN @ref_field ref_field ON ref_field.id = entity_type.ref_field INNER JOIN @ref_field ref_field_2 ON ref_field_2.id = ref_field.id WHERE ref_field_2.uuid LIKE :db_condition_placeholder_0

I am curious: 1) Why was this change added? and 2) Is there anyway I can force the former, more simple approach?

Problem/Motivation

Lets remove usage of "blacklist" and "whitelist" in \Drupal\Core\Security\RequestSanitizer and its test

They are:

• An historic bad labelling of people
• Provide no context: "what is listed in them"?

Proposed resolution

TBD

Remaining tasks

User interface changes

None

API changes

@see The CR:

• The sanitize_input_whitelist site setting has been renamed to sanitize_input_safe_keys
• Similarly, the Drupal\Core\Security\RequestSanitizer::SANITIZE_WHITELIST constant has been replaced with RequestSanitizer::SANITIZE_INPUT_SAFE_KEYS.

Data model changes

@todo

Release notes snippet

@todo

Problem/Motivation

User password reset URLs can be used to enumerate usernames.

For example [site_url}/user/reset/[user_id]/1/1

For Drupal 7 or Drupal 8, if you're logged in and visit a URL like the above it happens via this message:

Another user (%other_user) is already logged into the site on this computer, but you tried to use a one-time link for user %resetting_user.

For Drupal 8 only, if you're logged out and visit a URL like the above, you get a "Reset password" form with the following content (which includes the username):

This is a one-time login for %user_name and will expire on %expiration_date.

Click on this button to log in to the site and change your password.

When you submit the form it tells you then that the link is invalid. But it never should have shown the form in the first place.

I am reporting this issue because a customer(bank) pointed out it was a leakage of customer information in their scenario. It is currently possible (v7.51 + v8.19) to get the username of user in the system by requesting a password reset for that UID with a random timestamp and hash.

I reported this issue to the security team already and they concluded the following :

I believe this issue can be fixed in public without a security advisory because of our policy on username disclosure: https://www.drupal.org/node/1004778

Problem/Motivation

Any time a migration is run, the code loops over every row in the source. There is no way to migrate an individual row, or a few selected rows.

There are some source plugins that cannot support anything better, but any source plugin that extends SqlBase should be able to access individual rows efficiently. There may be other sources that can also do this.

Steps to reproduce

Using drush and the Migrate Tools module, try drush mim my_migration --idlist=123. The migration loops over all rows. If there are enough rows, then this can take a long time.

Proposed resolution

Provide an API that some source plugins can implement, allowing specific rows to be migrated.

Remaining tasks

• Design an API.
• Implement the API.

User interface changes

None

API changes

Add an API for selective migrations.

Data model changes

None

Release notes snippet

Original report

The D7 migrate system has a great feature whereby you can import specific IDs, and not have to loop over all IDS in the source query. This is vital for speed when testing a migration and you need to test and entity that has a certain field or odd values. SQLBase should support that by looking for an 'idlist' and altering the source query accordingly. The first user of this feature will be the --idlist option of drush migrate-import (see migrate_plus module).

Problem/Motivation

It would be great to be able to use conditions to narrow down your SQL source data for content/config entity types. The resulting functionality would provide similar capabilities to how you can migrate nodes one content type at a time, and the same for taxonomy terms -- but for users (by role), menu links (by menu), and so on.

The functionality would let you narrow your data during the source/extraction phase, instead of during the process/transformation phase (which you can do using skip_on_value/empty + method: row).

Benefits would include general tidiness of data :) And! Speed/performance!

(discussion of ideas/concerns/etc. started on Slack in mid-July 2019)

Proposed resolution

Ideas so far...

• Generic system for skipping rows based on arbitrary/arbitrary-ish conditionals.
• ^^ in SourcePluginBase and/or SqlBase.
• Migration yml would have a conditions array with keyed values that get passed to the SQL source plugin.

Remaining tasks

(reviews needed, tests to be written or run, documentation to be written, etc.)

User interface changes

(New or changed features/functionality in the user interface, modules added or removed, changes to URL paths, changes to user interface text.)

API changes

(API changes/additions that would affect module, install profile, and theme developers, including examples of before/after code if appropriate.)

Data model changes

(Database or configuration data changes that would make stored data on an existing site incompatible with the site's updated codebase, including changes to hook_schema(), configuration schema or keys, or the expected format of stored data, etc.)

Release notes snippet

(Major and critical issues should have a snippet that can be pulled into the release notes when a release is created that includes the fix)

The new design looks great, but why change the arrow orientation for closed-state?
As seen in the evolvingweb blog:

The new arrows seem to try follow the logic of the arrows for accordions in the content area. But as is standard in menus, being placed right vs. left.

This takes some meaning out of the right-pointing closed-state arrow i think, because it points away from the box, giving some "forward", or "go somewhere" notion, as it is present in the Navigation-PAGES:

Sometimes menu designs use up-down arrows, sometimes down-up arrows, so there's quite some inconsistency, non-standardness on how to use arrows.
Why did you dismiss the logic from before?
Did you also considerk the + - (or + x)scheme? Seems this has less ambiguity and more logic to it (increase/decrease no. of menu items).

On a simple form with use-ajax-submit, the rendered content includes content of the AJAX wrapper parent. This means that the content outside the AJAX wrapper is multiplied by the times I submit the form.

Also, after the first successful submit, if I submit the form again, there will be 2 requests and 2 responses. The number of requests made to the server is equal to the number of successful submits.

Same behavior on 8.7.9 and 8.7.10.

Here's my code:

The controller

<?php

namespace Drupal\formtest\Controller;

use Drupal\Core\Controller\ControllerBase;

class FormTestController extends ControllerBase {

  public function test() {
    $output = array();

    $output['markup'] = array(
      '#markup' => '<p>There should be only one paragraph before the form.</p>'
    );

    $output['test_form'] = \Drupal::formBuilder()->getForm('Drupal\formtest\Form\FormTest');

    return $output;
  }

}

The form

<?php

namespace Drupal\formtest\Form;

use Drupal\Core\Form\FormBase;
use Drupal\Core\Form\FormStateInterface;


class FormTest extends FormBase {
  public function getFormId() {
    return 'test_form';
  }

  public function buildForm(array $form, FormStateInterface $form_state) {
    $form['#prefix'] = '<div id="test-form-wrapper">';
    $form['#suffix'] = '</div>';

    $form['mail'] = array(
      '#title' => 'Name',
      '#type' => 'textfield',
      '#required' => TRUE,
    );

    $form['actions'] = array(
      '#type' => 'actions'
    );

    $form['actions']['submit'] = array(
      '#type' => 'submit',
      '#value' => 'Submit',
      '#attributes' => array(
        'class' => array(
          'btn',
          'btn-success',
          'use-ajax-submit'
        ),
      ),
      '#ajax' => array(
        'wrapper' => 'test-form-wrapper'
      )
    );

    return $form;
  }

  public function submitForm(array &$form, FormStateInterface $form_state) {
    \Drupal::messenger()->addMessage(t('Submitted.'), 'status');
  }
}

Problem/Motivation

We want to be sure focus is absolutely visible in every possible permutation in Claro
This needs to be confirmed before Claro can be considered stable.

Steps to evaluate

Find every possible place where an item can be focused in Claro. Confirm the focus state is visible in desktop, mobile, and high-contrast modes (IE/Edge and Firefox).

Proposed resolution

This doesn't have to be done all at once, but anything that gets evaluated should be documented here so the work isn't repeated unnecessarily. If issues are found, they should be opened as child issues of this one.

Remaining tasks

Evaluate
Add issues as needed.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Claro is aimed to be an experimental admin theme in Drupal 8.8.0 which according to Drupal development roadmap is aimed to be released on December 4, 2019. Drupal 8.8.0 feature freeze is on the week of October 14, 2019. Claro must reach at least beta status by then to be included in a stable release.

Claro beta criteria

Once the following level of feature completeness has been reached, we will consider tagging beta release for Claro:

• No known data integrity or security issues
• Everything that requires a big BC break has been solved
• Claro supports complex content authoring tasks including most prominent contrib modules (limited validation done by maintainers of Claro acceptable at this point)
• Claro supports most commonly used admin pages
• All commonly used global components have been designed and implemented

Must-haves for the beta release:

Features

• #3023319: Card Style Update
• #3036732: Action link component
• #3023310: Vertical Tabs style update
• #3023301: Messages style update
• #3024395: Password Field Style Update
• #3049321: Mini pager
• #3023326: Field Cardinality Style Update
• #3032365: Table drag style update
• #3021092: Image field style update
• #3021094: File field style update
• #3023320: Entity Reference Style Update
• #3074893: Change the delete button to use an action link
• #3083256: Create smaller variations for form elements

Bugs

• #3067386: AJAX rebuild of Views UI form re-renders parts of the form without using Form API, so additional hooks are needed in lieu of hook_form_view_edit_form_alter()
• #3067085: Views top dropbutton breaks when editing a view

Core inclusion

• #3084069: Allow marking themes as experimental - Drupal Core issue for adding necessary tooling for marking themes as experimental.
• #3084189: Import variables.css manually - Claro issue to make PostCSS build comatible with Drupal Core.
• #3060153: Use PostCSS in core, initially only for Claro - Drupal Core issue for adding PostCSS tooling.
• #3084388: Document for theme regions in claro as compared to seven's
• #3086435: Add automated test coverage for Claro
• #3087189: Resolve or work around claro.settings.yml implicit dependency on Shortcut

Should-haves for beta stability

Accessibility

• #3079134: Add underline on links by default
• #3054689: Implement green focus ring on text field

Claro stable criteria

Once the following level of feature completeness has been reached, we will consider tagging stable release for Claro:

• All core-gates are met
• Claro supports complex content authoring tasks including most prominent contrib modules (with more extensive validation that includes maintainers of contrib projects)
• Claro supports all Drupal core admin interfaces
• All global components supported by Seven have been designed and implemented
• Drupal module designs align with the new Drupal Design System (Quickedit, Contextual Links, Settings Tray, Toolbar)

Must-have issues for stable release:

Features

• #3062751: Media and media library
• #3023311: Modal dialog style update
• #3023322: Contextual Links Style Update, blocked on #3070493: Provide alternative design for Claro in Toolbar module (this is a toolbar issue, but its implementation will inform how Contextual Links are implemented)
• #3020422: Toolbar style update blocked on
  • #3057772: Ambiguous icons for collapsing/expanding menu items
  • #3070493: Provide alternative design for Claro in Toolbar module
• #3066006: Convert Views UI to new design system
• #3061042: [PP-1] Status Report Page Update
• #3072772: Modules page
• #3029675: Add support for the inline variation of form elements
• #3085219: Redesign Installer
• #3085212: [PP-1] Redesign maintenance page
• #3083176: Make sidebar region available in main page template

Accessibility

• WCAG Conformance surveys (start these as early as possible):
  • #3080100: Assess accessibility of Claro in Windows High Contrast
  • #3087225: Assess Claro's conformance with WCAG Text spacing, Text resize, and Reflow.. Includes detailed test approach.
  • #3088562: [META] Assess Claro for WCAG colour contrast AA conformance
  • #3163810: [META] Assess conformance with WCAG SC 2.4.7 "Focus Visible"
  • #3127466: Required fields are not identifiable on Internet Explorer 11 high contrast (could potentially be addressed if #2921627: Drupal should not use full CSS required marker in forms according to WCAG 2.0 lands and Claro adopts the practice implemented there)
• #3083657: Devise strategy to address several SVG loading+usage issues
• #3078524: Focus styling of WYSIWYG field inputs should be consistent with other inputs
• #3083570: Do not hide the label for the text format select input.
• #3123811: Grey text in Claro theme failed accessibility
• #3154539: Implement new Gray scale on Claro

Usability improvements

• #3068696: Tables overflow on mobile
• #3070558: Implement bulk operation designs
• #3158854: Node form: address chasm between main form and meta

Design improvements

• #3082685: Action links on admin/appearance
• #3082688: Excess space between details summary and details content does not match design.
• #3082691: Excess space on tables with action links and "show row weights" toggle. Does not match design.
• #3082672: Form prefix/suffix redesign

Technical debt

• #1899236: Add new Splitbutton render element to eventually replace Dropbutton (if this can't land then it would be necessary to address several dropbutton issues. Splitbutton is preferable)
• #3057577: Provide a way to add Buttons to Dropbutton
• #3024975: Add Drupal JavaScript theme function for checkbox
• #3067523: Add Drupal JavaScript theme functions for password confirm widget
• #3081521: Refactor vertical tabs, remove vertical-tabs.js replacement when core issues are resolved depends on:
  • #1936708: Current element values missing from vertical tabs when shown in 2-column layout
  • #3081500: Accessibility bugs with vertical tabs
  • #3081519: Truly responsive vertical tabs
  • #3081489: Move hard coded vertical tabs classes to a theme function and use js-prefixed classes for functionality
• #3083051: Remove tabledrag.js replacement when core issues are resolved depends on:
  • #3077938: Add a new Drupal.theme JavaScript function for tabledrag handle to allow themes customize the handle's markup
  • #3083039: Allow tabledrag to be disabled
  • #3083044: Prevent line breaks in draggable (first) table cells
  • #197641: Drag and drop is not RTL aware

Bugs

• #3081191: Select elements do not fully display letters with descenders
• #3092296: Limit width of form elements (max-width)
• #3005403: Cannot delete or edit a block that is placed in a section of the layout_builder
• #3084724: Regression on table select checkbox
• #3056046: SVG Problem with AdvAgg aggregation
• #3105597: [PP-1] Copy block configuration from admin theme when enabling an admin theme

Performance

• #3085245: Un-inline SVGs in pcss.css files, add build tool to inline them when compiled

Should-have issues for stable release:

• #3072771: Color editor
• #3072773: [PP-1 ]Image style edit page
• #3023325: Help Style Updates
• #3057281: Add js- prefixed classes for separation of JS functionality & CSS of Dropbutton element
• #3053449: Style removal button for multi-value field widget items
• #3045467: Allow overriding module CSS without overriding their toolbar styles
• #3082694: Extra space between message and content when content has elements with margin-top
• #3080994: spacing means that admin views don't show content above the fold on laptop screens
• #3025646: Create a Style Guide
• #3083003: Remove default no-screenshot image on appearance page
• #3068698: Better shortcut action link styles when there's limited horizontal space
• #3092296: Limit width of form elements (max-width)
• #3085794: Remove Firefox workaround for details focus effect
• #3023308: Iconography style update
• #3127469: Form element error state not visible on Windows high contrast
• #3114910: Improve Claro styles for core compatibility details on available updates report
• #3057772: Ambiguous icons for collapsing/expanding menu items
• #3067697: Dropbutton is broken on small screen when text is split to multiple lines
• #3133639: Fix Claro styles for exposed views filters wrapped in fieldsets

Could-have issues for stable release:

• #3048785: IE focuses elements on click that should not be focusable, and Claro makes this very apparent.
• #3072660: Allow white transparent pngs to be seen in image-preview
• #3036742: CTA - Call to action component
• #3076820: Layout redesign
• #2958478: Toolbar height calculation is faulty in multiple cases
• #3056089: Provide a new render element for accordion
• #3051605: Create new template for rendering Views UI tabs.
• #3053707: Views pager arrows should be easier to override in themes.
• #3084388: Document for theme regions in claro as compared to seven's
• #3084712: Improve content table design
• #3067273: Provide form for customizable settings
• #3045797: Use fluid typography in Claro
• #3025911: Quick Edit Style Update
• #3072770: Available updates page
• #3033852: Redesign range input

Post-stable

• #3085219: Redesign Installer
• #3084814: Deprecate Seven theme
• #3084816: Determine how to deprecate themes
• #3084820: [meta] Update documentation screenshots to use Claro instead of Seven

Not scoped