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

Umami's language-switcher as a drop-down menu

$
0
0

Problem/Motivation

Umami comes with a new language switcher.
When adding more languages (beyond the existing English and Spanish) it will break the nice flow of the header.

Proposed resolution

Add the list of available languages into a dropdown menu.

Remaining tasks

Create dropdown menu.
Figure out best positioning and a visual representation that will be easy to identify as "Here's where I can switch to another language"


Mark Layout Builder as a stable module

$
0
0

Problem/Motivation

Take the final steps to mark Layout Builder as a stable module

Proposed resolution

Swap Core (Experimental) for Core in the info file
Remove the @internal tag when only used because the module is experimental (and clarify the tag for the cases it is kept)
Copy the CSS and templates to Stable theme
Add an entry to MAINTAINERS.txt

Remaining tasks

Any remaining "Needs ____" tags, as applicable

Release management checklist

  1. Security
  2. Data integrity
  3. Impact on stable functionality

    Integrations

    • QuickEdit
    • Contextual Links
    • Content Moderation
    • Custom Blocks
    • REST
    • JSON:API
  4. Maintenance and technical debt
  5. BC policy
  6. Core gates

User interface changes

API changes

Data model changes

Release notes snippet

For sites that have made layout overrides prior to 8.7.0 or sites that manually enable translation of the layout override field, add UI warnings

$
0
0

Problem/Motivation

Layout Builder does not support translated layout overrides currently. Any new sites installing Layout Builder will not be able to enable translation on Layout field through Content Translation.

But some sites that had both content translations and Layout Builder enabled before #3041659: Remove the layout tab from translations because Layout Builder does not support translations yetand had both translations and layout overrides on the same bundles maybe have Translations still enabled on the Layout field.

It could be not safe for them to just turn off translations because they may need the current values they have in the translated fields.

Proposed resolution

On Content Translation admin form add a warning to all Layout fields with a link to the handbook page https://www.drupal.org/docs/8/core/modules/layout-builder/layout-builder...

Only sites that were installed when Layout Builder was still beta will see this warning.

Remaining tasks

None

User interface changes

@see Proposed resolution

API changes

None

Data model changes

None

Release notes snippet

SQLSTATE[40001]: Serialization failure: 1213 Deadlock

$
0
0

Hi All,

I am working on Drupal 8.2.0-dev for website on linux server with MariaDB as database server. The site setup is based on 3 instances of website setup or file system using one database. Whenever updates are made to the site cache is cleared from all 3 instances / nodes for changes to work properly esp. twig template changes.

Here is more detail about site configuration on server :-

The website is actually a 3-node cluster behind a load balancer.
Each node (node1,node2 and node3) are part of a MariaDB Galera Cluster, and each node is hosting the Drupal website.
Each drupal website communicates with it’s own DB. So this means when node1 is serving a page, it is reading/writing to the DB on node1. Likewise, node2 read/writes to node2’s DB and so on.
The website files on main location are replicated between the nodes using lsyncd and csync2.

So, when a visitor hits the website, traffic flow is :
HTTP Traffic -> HAPROXY Load Balancer -> (one of the 3 Nodes)
a. Node1 website communication to MariaDB on node1 (localhost)
b. Node2 website communication to MariaDB on node2 (localhost)
c. Node3 website communication to MariaDB on node3 (localhost)

I face an error :-
1. While using drupal admin interface for making updates or inserts website admin often gets error below.
2. Wen cache is cleared using Drush on website on the frontend also.

Uncaught PHP Exception Drupal\\Core\\Database\\DatabaseExceptionWrapper: "SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction: INSERT INTO {cache_entity} (cid, expire, created, tags, checksum, data, serialized) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6) ON DUPLICATE KEY UPDATE cid = VALUES(cid), expire = VALUES(expire), created = VALUES(created), tags = VALUES(tags), checksum = VALUES(checksum), data = VALUES(data), serialized = VALUES(serialized); Array, referer:

After searching on similar issues I found that solution suggested are using modules which are not ported to Drupal 8 yet e.g. https://www.drupal.org/project/apdqc. This issue was reported for Drupal 7 several times but not Drupal 8. I am not sure if its bug so adding support request.

Have not been able to find any reliable solution for this.

Just to add in my case the deadlock always is related to cache tables. Also can "Entity/field definitions" , " Mismatched entity and/or field definitions " as on page /admin/reports/status has any relation to this?

Any suggestions would be appreciated.

Thanks
Atul

Unnecessary <strong> element in Classy's form-element template may produce invalid markup

$
0
0

Problem/Motivation

The form-element.html.twig template in Classy wraps inline error messages in a <strong> element.

  • The minor issue is that it makes no sense to denote the whole error message.
  • The bigger one is that inline form errors may contain html elements, such as an item list, and in that case, the raw markup breaks validation: <strong> cannot contain grouping elements such as <div> or ul, these can be used only where flow content is expected.

W3C Current recommendation, W3C Working draft

Proposed resolution

Remove the <strong> element from the core/themes/classy/templates/form/form-element.html.twig template and add `font-weight: bold;` for `.form-item--error-message`.

Remaining tasks

Provide a patch.

User interface changes

Themes that extending Classy should (must?) be reviewed.

API changes

Nothing.

Data model changes

Nothing.

Complete the KV content entity storage implementation

$
0
0

Problem/Motivation

KeyValueContentEntityStorage is a plain extension of KeyValueEntityStorage and thus is missing most of the abstract logic provided by ContentEntityStorageBase.

Proposed resolution

Add an implementation for all the missing content-entity-specific use cases and add further test coverage.

Remaining tasks

  • Identify missing use cases
  • Write a patch
  • Reviews

User interface changes

None

API changes

None

Data model changes

None

Invalid CSS pseudo selector

Add ability to select a timezone for datetime field

$
0
0

Problem/Motivation

Imagine an organisation WidgetCo with editors and users in a variety of different time zones. They commonly face 2 problems trying to use the Date module. Support for some of this was present in D7's date but lost as it went to D8 core.

A. When creating session entities as part of their annual conference in New York, the times of the sessions as input by the editor are interpreted by Drupal in terms of the time zone of the editor who is creating or updating it, not New York. In this case their sitebuilder needs to be able to control the time zone used by the widget to interpret the times the editors input.

B. When creating meeting entities to describe meetings held at various locations across the world, the same problem happens. But in this case the intended time zone needs to specified for each meeting by the editor, and that preference needs to be stored with the date/time.

Proposed resolution

  • Refactor datetime formatters to simplify the logic.
  • Give settings to the datetime widgets (shared in common with the formatters, and date_range) that allow sitebuilders to control the time zone used to interpret input.
  • Add a new (optional) property to the date field (and date_range) that stores the preferred time zone.
  • Create thorough tests to verify that all this arcane time zone handling is working correctly everywhere.

Remaining tasks

User interface changes

A timezone handling configuration drop down on field storage configuration, and if configured for per-date storage, a timezone selector on the date widget.

API changes

  • The datetime form element will have an optional #expose_timezone boolean, that if TRUE, will add a timezone selector to the element.
  • Date time widgets and formatters will have various new methods. Possibly getDefaultValue() should be public.

    Data model changes

    Datetime storage will store a timezone per date.

    Screenshots


view with an exposed group filter for a date field generate a warning

$
0
0

hi,

step to repeat
-create a view for a content type with a (required) date field
- add a filter 'that field value is greater than -7days'
- filter-expose that field
- choose group filters to have a select-option between ALL or -7days

it works but generate:

Warning: Illegal string offset 'value' in Drupal\views\Plugin\views\filter\Date->validateValidTime() (line 83 of core/modules/views/src/Plugin/views/filter/Date.php).

Drupal\views\Plugin\views\filter\Date->validateValidTime('field_seminary_end_date_value', Object, '>', '1') (Line: 72)
Drupal\views\Plugin\views\filter\Date->validateExposed(Array, Object) (Line: 140)

Do not throw an exception when a context is missing while applying context mapping to a plugin if that context was previously set

$
0
0

Problem/Motivation

\Drupal\Core\Plugin\Context\ContextHandlerInterface::applyContextMapping() applies a set of contexts to a given plugin.
If any of the contexts required by the plugin are not present in those passed to the method, an exception is thrown.

However, if the plugin already had that context set, there is no reason to throw the exception

Proposed resolution

If a context is "missing" from those being applied, only throw an exception if the plugin doesn't already have that context

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Possible wrong token assignment on display modes

$
0
0

When accessing admin/structure/display-modes/view at the end of each entity type there's a link for adding a new view mode. Here are some examples:
Add new Custom block view mode
Add new Comment view mode
Add new Taxonomy term view mode

The problem is that the string used to create this output and also used for translation is: Add new %label @entity-type which looking above @entity-type should be 'Custom block', 'Comment' and 'Taxonomy term' not 'view mode' and %label should be 'view mode' not the actual entity types.

This is confusing when translating the UI and should be an easy fix.

Add a heading & subheading for the Promoted section

$
0
0

Problem/Motivation

This is a followup issue of #2994915: Remove Page Title block from homepage .

There is a title given to the Recipes sections along with a subheading which gives information about the whole section. IMO the Promoted section needs to have a heading & a subheading to define the section which will keep the design consistent.
Homepage promoted section heading

Proposed resolution

In the `Header` in the Promoted view to add the heading and the subheading with the appropriate heading tags.

Remaining tasks

Discuss to come up with a solution since it's a design issue.

User interface changes

Heading and subheading will be added to the promoted section.

API changes

None

Data model changes

None

Selecting the same day in a date between filter returns no results

$
0
0

Problem/Motivation

Steps to reproduce

  • Create a view with an exposed filter of node:created
  • Make just "between" available, and select "date" as 'value type'
  • Now chose twice the same day

Expected output

All entries on that day

Actual output

Empty

Proposed resolution

Increase the range automatically by one day, if twice the same day was created

Remaining tasks

User interface changes

API changes

Data model changes

D7 taxonomy term fields are not migrated with allowed vocabularies

$
0
0

Problem/Motivation

On migration from D7, the taxonomy term fields get migrated fine, but they are set to allow all vocabularies, even though that wasn't the case in source.

Proposed resolution

In D7, the allowed vocabularies is a part of field settings which is not available in instance migration, which is where it needs to be in D8. We should add the settings first and then process it during migration.

For all the allowed vocabularies the vid needs to be added to the row so somewhere in the pipeline a migration_lookup can be done to determine the new, migrated vocabulary name.

Remaining tasks

Patch
Review
Testing - patch confirmed to work in #49
Commit

User interface changes

None

API changes

None

Data model changes

None

Convert ViewRenderTest into a Kernel test

$
0
0

Problem/Motivation

ViewRenderTest makes no HTTP request but is a functional test.

Proposed resolution

Convert ViewRenderTest into a Kernel test.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A


Convert ViewsTemplateTest into a Kernel test

$
0
0

Problem/Motivation

ViewsTemplateTest makes no HTTP requests but is a functional test.

Proposed resolution

Convert ViewsTemplateTest into a Kernel test.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A

Convert UserDeleteTest to kernel test (or get rid of it?)

$
0
0

Problem/Motivation

Test Drupal\Tests\user\Functional\UserDeleteTest neve makes a HTTP request but i sfunctional.

Proposed resolution

Convert it to a kernel test.

Alternative: Remove it. For me looks like a naive test, all the functionality must have been tested somewhere in Entity API tests.

Remaining tasks

Make decision: convert or remove?

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A

Add and configure stylelint-order

$
0
0

Problem/Motivation

Our CSS standards have a recommendation about the order of property declarations so we should apply it to core.

Proposed resolution

Add https://www.npmjs.com/package/stylelint-order and use the existing CSScomb config to configure it and use the --fix option to generate a patch.

Blocked on #3024518: Upgrade stylelint to the latest version

Once that has landed you can:

  1. $ cd core
  2. $ yarn add stylelint-order --dev
  3. Apply the patch here to core/.stylelintrc.json
    For example: $ curl https://www.drupal.org/files/issues/2019-03-08/3024527-4-28.patch | git apply --index --include=core/.stylelintrc.json
  4. $ yarn run lint:css --fix

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

CSS standards for ordering is now enforced using the stylelint-order plugin.

Dynamic Views Arguments via Tokens

$
0
0

For the Drupal 7 version of this issue, see #2010898: Use tokens for entity selection view arguments.

Entity Reference allows using a View of a specific display type to set the available options. This is good.

It's also possible to set arguments (contextual filters) on that view from the ER field config screen. This is also good.

Those arguments must be completely static. This is not good.

Rather, it should be possible to have dynamic, context-aware arguments. The most obvious is "the node that this is on", allowing the view to filter based on the node itself. Ideally, other "relational" contexts (Panels-style, or maybe just via token if that's easier) should be possible, such as "the author of the node this is on", "the OG of the node this is in" (my actual use case), etc.

That would greatly expand the potential flexibility of that view to do all sorts of context-aware select lists.

Of course, there's the obvious problem of what to do when creating a node (or user, or whatever other entity) the first time, since there is no "this" yet to refer to. I see two possible ways to address that:

1) Allow for a default value, or a different context to pull from if null. Eg, if there's no node owner, default to the current user. This would be configurable.

2) Punt that question to the View, where there is already fairly sane default argument capability. As long as we are able to do relational arguments, so that the contextual filter on the View doesn't have to be the entity type that it is on, that's probably sufficient and easier to implement anyway.

In my specific use case, I want to have an ER from a node to other nodes of type Foo that are in the same OG as the node being edited; if the node is being added, default to the user's OGs. The same concept would apply in many other situations, of course, such as related posts by the same author, etc.

(The current alternative involves writing a completely new custom views default argument plugin for every use case, which is highly sub-optimal.)

Thinking about it, I believe tokens would likely be the most straightforward way to specify such values.

So:
1) Is this feature something that would be accepted?

2) I MAY be able to get some time to work on this for the client project that requires it, if I knew it would be accepted so that we're not working with a project fork. :-) Is this doable? (If not, we'd have to fall back to the one-off above.)

Convert FieldGroupRowsTest into a Kernel test

$
0
0

Problem/Motivation

FieldGroupRowsTest make no HTTP requests but is a functional test.

Proposed resolution

Convert FieldGroupRowsTest into a Kernel test

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A

Viewing all 295374 articles
Browse latest View live


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