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

Views table settings exposes "Details" field even when empty

$
0
0

After recent update from 8.8 to 8.9 a field now shows up when ever a a grouping is used. it matters not what field is exposed. It is a collapsed field directly above the table and says "details" It is in a collapsed field/element.

I narrowed it down to the field in TABLE:SETTINGS at the bottom called "Table Details", there is nothing in it but there is also no way to disable it.

details

Step to reproduce:

  • Take a view with table display (say the content view)
  • Go to the table settings
  • set Grouping field Nr.1 to 'content type'
  • save settings
  • check the preview and see that this now shows the 'detail' as shown in the screenshot

Font-your-face view display

$
0
0

Just a quick report about Font-your-face module and Claro, the view display seems to have problems (cf screenshot).
(Not quite sure about the Claro version, I have activated the one in Drupal 8.8.6)
Thanks anyway for this admin theme, really nice to use on a daily basis.

Replace usages of AssertLegacyTrait::assert(No)Escaped, that is deprecated

$
0
0

Problem/Motivation

AssertLegacyTrait::assertEscaped() is deprecated in drupal:8.2.0 and is removed from drupal:10.0.0. Use $this->assertSession()->assertEscaped() instead. See https://www.drupal.org/node/3129738

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

"Printer-friendly version" of unpublished book pages is blank

$
0
0

Steps to reproduce

(description of the proposed solution, the rationale behind it, and workarounds for people who cannot use the patch)

  1. Enable book module
  2. Create an unpublished book page
  3. Click the "Printer-friendly version" link
  4. Expected result: See print-friendly version
  5. Actual result: Empty white page

This issue exists in core Book module Drupal 7 & Drupal 8
No need for contributed module. The printer-friendly feature exists in core book module.

Remaining tasks

Patch at: http://drupal.org/node/50680#comment-4715114 not correct, need to write tests and fix the same.

Original report by [he_who_shall_no...]

This patch is for users who don't want to see an empty page when they click on the "printer-friendly version" link (unpublished/not in moderation queue book pages).

'Field discovery failed for Drupal core version 7' errors if migration source database key is not 'migrate'

$
0
0

In the migrate upgrade using Drush documentation, it shows an example of the database settings for a migration. In this example it uses the settings.php database key migrate. But in my own site, I was using the key drupal7 for my Drupal 7 database.

Everything seemed to work correctly, and indeed most (if not all?) of my content, comments, settings, etc. were migrated after running migrate-upgrade and migrate-import

However, every time I ran migrations, I'd get notices like:

 [notice] Field discovery failed for Drupal core version 7. Did this site have the CCK or Field module installed? Error: No database connection configured for source plugin d7_field_instance
 [notice] Processed 1 item (1 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_user'
...
 [notice] Field discovery failed for Drupal core version 7. Did this site have the CCK or Field module installed? Error: No database connection configured for source plugin d7_field_instance
 [notice] Processed 15 items (15 created, 0 updated, 0 failed, 0 ignored) - done with 'upgrade_d7_field_instance'

I was worried this might be pointing at some errors during migration. I spot-checked the migrate_map_* tables and didn't see anything strange going on. I spot-checked some of the migrated data from the Drupal 7 site, and again, nothing seemed wrong there.

In the end, after digging through the FieldDiscovery class, I gave up, but before closing out of the session I did one more Google search in desparation, and found this thread by DelishCreative. In it, she mentioned she was having similar strange behavior with her migrations, until she renamed her source database key to migrate:

So the moral of the story kids: Don't name your migration DB group anything other than "migrate".

So... it seems that having the database key be migrate is not an actual requirement (and hasn't been in the past, when I've done other migrations). It seems like it's a bug that migrations throw these errors when a database is set up with a different key (like drupal7, in my case).

If you must name your database key migrate for everything to work, then maybe that should be made explicit in the migration documentation...

(Fix on my Drupal 8 site was here: https://github.com/geerlingguy/jeffgeerling-com/commit/3f6ad0efa24768453...).

Improve horizontal alignment so that elements are aligned on a vertical line

Required fields are not identifiable on Internet Explorer 11 high contrast

$
0
0

Problem/Motivation

Required fields are not identifiable on Internet Explorer 11 because the required marker is not visible. This field is supposed to have the required marker:

This is how this field looks like in Edge:

Proposed resolution

Ensure that required fields are identifiable on Internet Explorer 11 high contrast.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Text area with a summary should displayed by default when summary field is required.

$
0
0

Text area with a summary should displayed by default when summary field is required.
Currently field is hide with link `Edit Summary`.. this should be open by default when user select summary field required.


A negative pager throws SQL error when using entity query

$
0
0

Problem/Motivation

Using entity query with a negative pager throws a MYSQL error.
Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '-10' at line 8:

Proposed resolution

Return an absolute value when fetching the pager value.

Migrations don't have an accessor for requirements

$
0
0

Problem/Motivation

in Drupal 8 there was a Migration::get() method. It was appropriately deprecated but I missed that It was being used in Migrate Manifest to bypass the lack of an accessor for listing requirements. Since it is removed in Drupal 9 and there is not replacement, Migrate Manifest is not currently able to upgrade.

Proposed resolution

Add a "getRequirements()" method to Migration class and the MigrationsInterface

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Allow synced Layout default Translations: translating labels and inline blocks

No error messages are shown for applied validation on a view exposed filter with on "AJAX"

$
0
0

The applied validation error messages are not shown for a view exposed filter on failure when "Ajax" is on.

ajax-option

the messages are displayed again on next page load.

There is an older issue opened for Drupal 7

https://www.drupal.org/node/1833322

Recommended solution:


function MODULE_views_ajax_data_alter(&$commands, $view) {
$commands[] = ajax_command_prepend($commands[0]['selector'], theme('status_messages'));
}

Is the correct way to solve the problem or solution should be implemented in views module itself ?

Remove weight field from Media Library widget when only single media can be attached

$
0
0

Problem/Motivation

Media Library widget has a weight field that allows specifying order of the attached media entities. The weight field doesn't have any effect when only single media can be attached to the field.

Proposed resolution

Remove weight field from the Media Library widget when only single media can be attached.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Update dropbuttons in tables because of various table cell alignments

$
0
0

Problem/Motivation

Dropbuttons in tables are not positioned correctly because of various table cell alignments.
For example: /admin/structure/display-modes/view

problem

Proposed resolution

We would probably something more like this:

problem

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Incorrect error text in EntityViewBuilder constructor

$
0
0

Since 8.7.0, EntityViewBuilder::__construct() takes an optional fifth argument (non-optional after 9.0.0), which is an EntityDisplayRepositoryInterface implementation.

It then checks whether that argument was indeed passed and triggers a warning if it wasn't. However the message in the warning is incorrect: it mentions Calling EntityViewBuilder::__construct() with the $entity_repository argument [...], but:

  • there is already an EntityRepositoryInterface implementation as the second argument
  • the warning should actually refer to the fifth argument which is an EntityDisplayRepositoryInterface instead of EntityRepositoryInterface.

Fix: change the wording to Calling EntityViewBuilder::__construct() with the $entity_display_repository argument [...].


[Plan] Remove the usage of deprecated methods in tests

$
0
0

Problem/Motivation

During the conversion in #2735005: Convert all Simpletest web tests to BrowserTestBase (or UnitTestBase/KernelTestBase), in order to keep the patches reviewable and changes to the minimum the usage of the deprecated methods was not removed.

It's time to properly deprecate and remove the legacy method for D10.

Proposed resolution

Deprecate the legacy assert* methods, and silence the depracations while individual sub-issues will remove the usage of deprecated methods in tests, and add deprecation tests.

Remaining tasks

  • Decide between creating a big bang patch or per module bases.
  • Come up with the regex for search and replace.
Visit the kanban board here for more.
(Note: Adding the "Deprecated assertions" tag to child issues, it shows up on the kanban board automatically)

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

None

Allow synced Layout override Translations: translating labels and inline blocks

$
0
0

Problem/Motivation

follow up #3041659: Remove the layout tab from translations because Layout Builder does not support translations yet

Part of #3044386: [META] Make Layout Builder layouts translatable

Right now you are not able to translate layouts at all.

The most common use case is probably translating the block labels and inline blocks but having the actual layouts not change from language to language. For different layout per language: see #3040487: Allow Independent Layout Override Translations

Proposed resolution

  1. Provide access to the Layout table on translations
  2. On Translations the Layout builder would only allow translating labels and inline blocks
  3. Translated settings for block would be stored a new field that would be translatable(the current Layout field would still be untranslatable)
  4. Most blocks could only have labels as translated settings
  5. Inline blocks could additionally have a block revision ID stored.

Remaining tasks

User interface changes

API changes

Data model changes

entity_test_revpub has invalid link templates

$
0
0

Link templates for entity_test_revpub test entity type, containing an unexpected parameter name.

This entity type also doesnt use a route provider.

Use it or lose it!

Mark a couple of asset services as non public

$
0
0

Problem/Motivation

If you look at the following services definitions you will see that there are quite of them which don't need to be public:

  asset.css.collection_optimizer:
    class: Drupal\Core\Asset\CssCollectionOptimizer
    arguments: [ '@asset.css.collection_grouper', '@asset.css.optimizer', '@asset.css.dumper', '@state' ]
  asset.css.optimizer:
    class: Drupal\Core\Asset\CssOptimizer
  asset.css.collection_grouper:
    class: Drupal\Core\Asset\CssCollectionGrouper
  asset.css.dumper:
    class: Drupal\Core\Asset\AssetDumper
  asset.js.collection_renderer:
    class: Drupal\Core\Asset\JsCollectionRenderer
    arguments: [ '@state' ]
  asset.js.collection_optimizer:
    class: Drupal\Core\Asset\JsCollectionOptimizer
    arguments: [ '@asset.js.collection_grouper', '@asset.js.optimizer', '@asset.js.dumper', '@state' ]
  asset.js.optimizer:
    class: Drupal\Core\Asset\JsOptimizer
  asset.js.collection_grouper:
    class: Drupal\Core\Asset\JsCollectionGrouper
  asset.js.dumper:
    class: Drupal\Core\Asset\AssetDumper
  library.discovery:
    class: Drupal\Core\Asset\LibraryDiscovery
    arguments: ['@library.discovery.collector']

The following could be marked as public: false

  • library.discovery.parser
  • library.discovery.collector
  • asset.js.collection_grouper
  • asset.js.dumper
  • asset.js.optimizer
  • asset.css.collection_grouper
  • asset.css.dumper
  • asset.css.optimizer

Proposed resolution

Mark them as public: falseand let the testbot decide whether this is okay.

Remaining tasks

User interface changes

API changes

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue categoryTask, because there is no real problem
Issue priorityNormal because the impact is not high
Prioritized changesThe main goal of this issue is
to improve performance.

Entity reference (autocomplete) field widget in Layout builder off canvas form is inaccessible

$
0
0

Problem/Motivation

Using the autocomplete field widget in a block content type with layout builder is inaccessible due to a styling issue with the autocomplete results.

Steps to reproduce:
1) Add an entity reference field to a block type
2) Add that block type via Layout builder
3) Start typing in the ER field and view the resulting list.

Screenshot of bug

Proposed resolution

Fix the styling
Check if this affects other widgets

Remaining tasks

User interface changes

Better UI for autocomplete dropdown in the off-canvas window.

Viewing all 292343 articles
Browse latest View live


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