Quantcast
Channel: Issues for Drupal core
Viewing all 295116 articles
Browse latest View live

Drupal Usability Meeting 2020-06-30

$
0
0

This meeting takes place every Tuesday, usually at 14:00 UTC (10:00am ET, 7:00am PT). See Time.is to see what that is in your timezone.

The meetings are held using Zoom, and a link is posted in the #ux Slack channel just prior. Agenda is first come, first serve and set by attendees. Use Needs usability review tag for issues that need review and/or suggest issues in comments here.

Recording of this week's meeting: TODO

We discussed the following issues:

TODO


FieldItemNormalizer to not flatten if one property and getMainPropertyName is NULL

$
0
0

Problem/Motivation

JSON:API has a nice feature in that it flattens a Drupal field value so we don't have pesky value sub-properties on things like string, boolean, email, etc fields. This is great, except when you want your field type to have a forced sub-property.

In the Commerce API module being developed we have a billing_information field that has at least an address property and may have more, such as a tax number or phone number.

Currently, the billing_information field just displays all of the address item values as root properties, causing a broken schema.

The relevant code is: https://git.drupalcode.org/project/drupal/blob/8.8.x/core/modules/jsonap...

      $field_properties = TypedDataInternalPropertiesHelper::getNonInternalProperties($field_item);
      // Flatten if there is only a single property to normalize.
      $values = static::rasterizeValueRecursive(count($field_properties) == 1 ? reset($values) : $values);

getNonInternalProperties will return properties that are not computed or marked internal.

I had to make this workaround for myself:

  /**
   * {@inheritdoc}
   */
  public function normalize($object, $format = NULL, array $context = []) {
    assert($object instanceof Address);
    // Work around for JSON:API's normalization of FieldItems. If there is only
    // one root property in the field item, it will flatten the values. We do
    // not want that for the OrderProfile field, as `address` should be present.
    // This only happens if there is one field on the profile.
    // @see \Drupal\jsonapi\Normalizer\FieldItemNormalizer::normalize
    // @todo open issue FieldItemNormalizer::normalize should ignore if mainPropertyName is NULL.
    $parent = $object->getParent();
    if ($parent instanceof OrderProfile) {
      $field_properties = TypedDataInternalPropertiesHelper::getNonInternalProperties($parent);
      if (count($field_properties) === 1) {
        // This ensures the value is always under an `address` property.
        return ['address' => array_filter($object->getValue())];
      }
    }
    return array_filter($object->getValue());
  }

Proposed resolution

If there is one property returned by TypedDataInternalPropertiesHelper::getNonInternalProperties, check if it matches the main property value. In most cases it will, or getMainPropertyName wil be NULL. If it doesn't match, then do not flatten the field values. Often times getMainPropertyName returns NULL If the field type has multiple properties for its value and there cannot be a single property used (ie: price field, you need the number and currency.)

Remaining tasks

User interface changes

None.

API changes

JSON:API will no longer flatten field types which return NULL or a main property name which does not match the single property returned.

Data model changes

None.

Release notes snippet

Allow a button in an exposed forms to trigger ajax.

Lock issues when clearing cache on Percona XtraDB cluster

$
0
0

When using database cache on an Percona XtraDB cluster Truncate's are quite blocking. This means all requests for the cache will wait for the tabel to finish.

When a SST (an initial sync to a new node) is running this can result in waiting for a lock indefinitely which means the sync will fail and the cluster will go down. Other than changing the caching backend to another service, we think not allowing TRUNCATE will aliviate the issues at least. Then we can at least be sure deploying multiple Drupal sites will not result in unfortunate issues where you run into a deadlock situation.

Not too sure what the proper way to fix this would be, but i think removing the possibility for TRUNCATE is at least a start.

AccountForm should read pass-reset-token only from query string

BasicAuth::authenticate() does not respect the implemented interface

drupal_get_schema_versions() should return integer versions

$
0
0

Problem/Motivation

The drupal_get_schema_versions() parsing update hooks from .install files
After clean standard profile install I'm getting following versions in database

> select * from key_value where collection='system.schema' and name like's%';
system.schema|search|i:8000;
system.schema|shortcut|i:8000;
system.schema|standard|i:8000;
system.schema|system|s:4:"8901";

It means that updates are serialized with wrong type

Proposed resolution

- typecast the parsed value
- write update hook to fix values
- add upgrade test

Remaining tasks

- create patch and test
- add upgrade path and test
- review/commit

User interface changes

no

API changes

no

Data model changes

Data stored in key_value tables for system.schema serialized as integers for modules having update hooks defined

Release notes snippet

no

Nested Paragraphs create multiple drag handles

$
0
0

Problem/Motivation

Using nested paragraphs creates multiple drag handles.

What it looks like with Paragraphs module:
multiple drag handles

What it looks like with CD_Tools module "tabledrag" test page:

Expected layoutActual layout

Scope of the bug:

This issue does not happen with the Seven theme and is scoped to the Claro tabledrag, which has overriden the core tabledrag and added some wrappers and other divs to the html so that we end up with 3 drag handles. The problem doesn't come up with any other place in admin UI, but the nested paragraphs use the "multiple drag".

DOM inspector analysis

The output for the Seven admin theme:

<td class="field-multiple-drag">
  <a href="#" class="tabledrag-handle" title="Drag to re-order">
    <div class="handle">&nbsp;</div>
  </a>
</td>

And the output for the Claro theme:

<td class="field-multiple-drag tabledrag-cell tabledrag-cell--only-drag">
  <div class="tabledrag-cell-content js-tabledrag-cell-content">
    <a href="#" class="tabledrag-handle js-tabledrag-handle" title="Drag to re-order"></a>
    <div class="tabledrag-cell-content__item">
      <div class="tabledrag-cell-content js-tabledrag-cell-content">
        <a href="#" class="tabledrag-handle js-tabledrag-handle" title="Drag to re-order"></a>
        <a href="#" class="tabledrag-handle js-tabledrag-handle menu-item__link" title="Drag to re-order"></a>
          <div class="tabledrag-cell-content__item"></div>
      </div>
    </div>
  </div>
</td>

It adds the handle three times.

Steps to reproduce with Paragraphs:
1. Create a new paragraph type (sub paragraph) (can be empty without fields)
2. Create two other paragraphs (main paragraphs) (the other one can be empty without fields)
3. Add a Paragraph field to the other main paragraph and include to sub paragraph in the reference type.
4. Add a Paragraph field to basic page and include the two main paragraphs in the reference type
5. Add a basic page and add there the paragraph type which has the sub field. It shows the three drag handles for the sub paragraph

Steps to reproduce with CD_Tools:
1. Install and enable https://github.com/zolhorvath/cd_tools and enable the "Tabledrag" submodule packaged with it.
2. Visit url /tabledrag/nested and /tabledrag/nested-hierarchy, which shows several nested tabledrag handles.

Proposed resolution

TODO

Remaining tasks

  • Refactor initColumns() function to replace jQuery.each() with javascript iterator.

User interface changes

Nested tabledrag tables will not display duplicate tabledrag handle icons.

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A


Add Views EntityReference filter to be available for all entity reference fields

$
0
0

Problem/Motivation

One major piece of functionality from the D7 Entity Reference module was left out entirely in #1801304: Add Entity reference field: the ability to render exposed views filters as a select list or autocomplete of available entities.

Proposed resolution

Create a new Views Entity Reference filter plugin to be available for all entity reference fields and migrate the existing taxonomy filters to be based on the new generic filter plugin.

How to use

  1. Add on an entity type / bundle an entity reference field, ex field_test_reference.
  2. Create a view displaying this entity type.
  3. Add a filter on the view for field_test_reference.
  4. Configure the entity selection mode and the widget display mode.
  5. Configure the filter behavior (ex: required, multiple, etc.)
  6. Finally use the filter field for filtering the results based on the selected entity from the autocomplete or select list.

Remaining tasks

  • ☑ support for content entity reference
  • ☑ support for configuration entity reference
  • ☑ support for content with and without bundles
  • ☑ taxonomy filter rebased on generic entity reference
  • ☑ settings forms to configure the filter
  • ☑ display widget in select or autocomplete
  • ☑ filter values based on reference view
  • ☑ filter values based on bundles
  • ☑ maximum filter values in select list for performance concerns
  • ☑ sort for filter values when in bundle selection handler mode
  • ☑ argument support for when view selection handler is used
  • ☑ views configuration schema update
  • ☐ existing configuration migration (no longer needed if we create a new filter only)
  • ☐ fix select option (#208, #215)
  • ☑ tests
  • ☐ get framework manager approval
  • ☐ write change record

Post tasks

  • ☐ follow-up task to have TaxonomyIndexTid use this entity reference plugin
  • ☐ conversion of the "authored by" filter to use the entity reference filter
  • ☐ extract selection handler form logic in separate plugins that will specialize for rendering and validating the filter selection config form
  • ☐ caching of the value form?
  • ☐ documentation updates

User interface

UI
UI

UIUI

Known issues

  • CANNOT REPRODUCE ATM sometimes when switching between widget it gets stuck on the previous selected one
  • FIXED when switching between the widget types the previous value is left in the exposed form and it's incompatible with the other widget type
  • FIXED triggering ajax requests on the extra options form right after adding the filter brings you back to the add handler form fixed

API changes

None.

Implement Server Timing performance metrics

$
0
0

Problem/Motivation

Providing server timing would help developers estimate site performance.
The corresponding W3C specification is currently in "Working Draft" status and its already supported by Google Chrome and Firefox.
https://www.w3.org/TR/server-timing/
Symfony adopted it in https://github.com/symfony/symfony/pull/27985

Proposed resolution

Add Server-Timing header with relevant timing information.

Remaining tasks

Decide how enable the Server-Timing.

Proposals

  1. Add it to develoment.services.yml (#2)
  2. Enable it be default, for example by adding it to core.services.yml (#7)
  3. Create a new module for it (#24)
  4. Toggle it via service parameter (#27)
  5. Toggle it via configuration option (#38)

Move error handlers to an Error class

$
0
0

Followup #2999721: [META] Deprecate the legacy include files before Drupal 9

Problem/Motivation

There is already an existing utility Error class. So lets keep things together.
Deprecate legacy errors.inc file functions. Just get rid of errors.inc file in drupal:10.0.x.

Proposed resolution

Convert all error handler related functions to the methods in the Error class.
That will help to work on the next step of modernizing Drupal error handler in #1722694: Replace Drupal's error handling with Symfony/HttpKernel's without carrying out of legacy errors.inc file loading BC layer in Drupal 10.0.0.

Remaining tasks

  • Deprecate functions
  • Replace usages in the code
  • Add legacy tests

User interface changes

-

API changes

  • new methods in \Drupal\Core\Utility\Error class
  • deprecated error handler related functions

Data model changes

-

Release notes snippet

-

Tables overflow on mobile

$
0
0

Problem/motivation

Currently there is a overflow/scrollbar for the entire page, if the page is viewed on a mobile device and the page contains a table. Even with the responsive tables feature.

Proposal

Instead of hiding columns, display all columns and introduce a mobile-friendly horizontal scroll on large tables.

Currently discussing if we should let claro override the responsive table feature with this new behavior, or introduce a dedicated #scrollable property to all tables to trigger this behavior when necessary. So one could have a responsive table that scrolls if too large.

List of books at "admin/content/book" doesn't show Unpublished books

$
0
0

The table currently only shows books that are published in the list.
Ideally, I (and I'm sure a few others) would like this to show both published and unpublished books.

Some translation strings skipped because of disallowed or malformed HTML during install.

$
0
0

/admin/reports/dblog/

Type: locale
User: Anonymous (not verified)
Location: .../core/install.php/?id=2&langcode=cs&op=do_nojs&op=finished&profile=standard&rewrite=ok&rewrite=ok
Referrer: .../core/install.php?rewrite=ok&langcode=cs&profile=standard&id=2&op=start
Message: 1 disallowed HTML string(s) in files: translations://drupal-8.7.6.cs.po.
Severity: Warning

Existing uses of #links should not rely on array keys to add classes to list items

$
0
0

Postponed on #3115223: Remove Stable as a base theme of core themes

Problem/Motivation

The issue #2402165: #theme => 'links' renders <li class="_"> when the #links array is not associative removed the ability to add classes to list items in #links via the array key. This is detailed in the change record. This had some unwanted side effects that weren't apparent until the BC layer in Stable was no longer available to core themes in #3115223: Remove Stable as a base theme of core themes
The issue focused on a bug that occurred when #links items were not associative: the list item would include class="_". However, the issue did not take into account that core has existing code that relied on this functionality.

At least one use case is clearly impacted by this, which was discovered in #3115223, and discovered while manually testing System Tray. Core has several CSS rules including the selector #drupal-off-canvas td .dropbutton-single li.edit (and children of this selector). The .edit class in this selector is added via the keys-become-classes functionality that was removed in #2402165. This is an item added to #links in \Drupal\menu_ui\MenuForm::buildOverviewTreeForm as '#links' => $operations. There is an $operations['edit'] and there is styling that assumes an .edit class will be added.

The result is you get this weirdness:

Instead of the nice pencils:

The BC layer was labeled as deprecated, but it shouldn't have been because there is still core functionality that depends on it.

Proposed resolution

Remove the BC workarounds added to the .theme files of Bartik, Claro, Seven and Umami in #3115223: Remove Stable as a base theme of core themes.

To fully address, it may require finding everywhere an associative array is used for #links and make sure those array keys are added as classes instead. It's also possible it can only be changed as needed.

Remaining tasks

Implement the proposed resolution

Address the @todo items referencing this issue.

User interface changes

API changes

Data model changes

Release notes snippet


Links in the tour tip body are visually the same as the rest of the text

$
0
0

Problem/Motivation

Seven's CSS is written in a way that makes the links in the tip body indistinguishable from the rest of the text:

"I'll teach you more about paragraphs" part is the the link. As the image clearly shows it is almost impossible to notice (unless one hovers it accidentally).

Proposed resolution

  1. Make the links in the tip body blue as Seven does in the other cases:

    The colour should provide contrast of 4.5:1 against the tour tip background to satisfy WCAG 2.0 success criterion 1.4.3 Contrast (minimum).
  2. Underline the links inside tour tip paragraphs, to satisfy WCAG 2.0 success criterion 1.4.1 Use of color, and avoid F73: Failure of Success Criterion 1.4.1 due to creating links that are not visually evident without color vision.

Steps to reproduce

  1. Enable Language module
  2. Visit /admin/config/regional/language/add
  3. Click Tour in the upper right hand corner
  4. Navigate to the third Tour item. This item has a link.

Simplify ReviewForm::buildForm() by using '#prefix' and '#suffix'

Add new Splitbutton render element to eventually replace Dropbutton

$
0
0

Problem

  1. Drupal has adopted Views’ dropbutton in several common places in core. Since its introduction in #1608878: Add CTools dropbutton to core, we've spent lots of time refactoring the existing button: #1799498: Improve dropbutton and others [which?]. This component is now even being used for primary form actions on the new node edit form: #1751606: Move published status checkbox next to "Save". However, the implementation there has made the dropbutton harder to theme by pushing it beyond its initial design. (Specifically, allowing its to consist of buttons instead of links, and by introducing sub-elements using #prefix and #suffix).
  2. From a UX standpoint, the existing dropbutton’s behaviour is sub-optimal. Since the sub-items are contained within the button, when the button is opened it often must grow in width to accommodate the width of the sub-items. This change moves the click target out from under the user’s cursor, forcing them to hit a slightly different spot in order to close the menu again. The standard implementation of this design pattern does not suffer from this issue: Twitter Bootstrap, Zurb Foundation, jQuery UI. Drupal is the odd one out here.
  3. From a code maintenance and re-use point of view, it makes sense to decouple the dropbutton itself from the menu it discloses. This allows the menu component in particular to be used elsewhere in the UI, and both can be themed separately.
  4. The open/closed state of the menu isn't conveyed to assistive technology, it is only apparent visually.
  5. The current focus style for the more-actions button is weak, and won't pass WCAG 1.4.11 Non-text contrast.

Proposed Resolution

Since we cannot change the current Dropbutton (and Operations) implementation for BC reasons, the way to move on is:

  1. Create a new Splitbutton element with the required markup, functionality and (accessibility) features.

  2. Replace core's Dropbutton and Operations usage with the new Splitbutton element.
  3. Deprecate Dropbutton.

Remaining tasks

TBD.

User interface changes

TBD.

API changes

TBD.

Original Proposed Resolution

Status

  • The standard interaction pattern mentioned above (split button with separate menu) and a new style for the Seven theme both have consensus from the UX team: http://groups.drupal.org/node/283223#Split_Buttons_and_Dropbuttons
  • We have prototype markup, CSS and Javascript all working with keyboard and screenreader access in a project sandbox. The Markup and CSS are solid (the CSS has been build with a clear separation between core structure and appearance). However, JS implementation needs work.

Replace assert(Not)Equal() with assert(Not)Equals()

$
0
0

Problem/Motivation

assertEqual() is deprecated for removal in Drupal 10.0.0 as well.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

UnroutedUrlAssembler removes query params array item key in buildExternalUrl()

Viewing all 295116 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>