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

Hide and disable Drupal Migrate Multilingual

$
0
0

Problem/Motivation

Once the multilingual migration path is fully stable (#2208401: [META] Stabilise Migrate Drupal Multilingual module ), we have no need for the separate Migrate Drupal Multilingual module.

Proposed resolution

Hide the module from the UI, disable it and let migrate discover multilingual migrations normally.

Remaining tasks

User interface changes

No more Migrate Drupal Multilingual module visible.

API changes

None. We keep the module for backwards compatibility.

Data model changes


system_maintenance migrations uses incorrect maintenance mode variable in Drupal 7 migrations

$
0
0

Problem/Motivation

The system_maintenance migration lists:

source:
  plugin: variable
  variables:
    - site_offline_message
  source_module: system

But site_offline_message hasn't been in use since #201415: Add permission to access site in maintenance mode, which was committed over a decade ago in https://git.drupalcode.org/project/drupal/commit/a9762cd3bf93ac8bbcafec2...😬

Proposed resolution

Change it to:

source:
  plugin: variable
  variables:
    - maintenance_mode_message
  source_module: system

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

[PP-2] When Media entities are deleted, the associated files are not deleted.

$
0
0

What are the steps required to reproduce the bug?

  • save a file type media
  • delete it

What behavior were you expecting?

  • the file should be deleted from the server or at least being unnacessible , changing name, folder or status
  • adding and deleting media files should be possible for usage in content types

What happened instead?

  • the file is not deleted from the server, even after cron
  • the status is permanent ( because of this ? https://www.drupal.org/node/2891902)
  • any new update add 0,1 etc , which makes update of files impossible for editors that has been communicating and giving adress of a document

d7_node_title_label migration plugin incorrectly generating base_field_override for every node type, even those that don't have an overridden title label

$
0
0

Problem/Motivation

The migration of the node title label generates a base_field_override config entity in Drupal 8 for every node type, even if its title label was not actually overridden in Drupal 7.

Proposed resolution

Change the migration to skip rows where the title label is 'Title' (the default).

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Migrate D7 i18n taxonomy term field translations

$
0
0

Problem/Motivation

This is a followup to #2979966: Migrate D7 i18n taxonomy term language to make sure that the translations on taxonomy fields are migrated.

Proposed resolution

Add fields to vocabularies.

  • vocabfixed: field_training
  • vocablocalized: field_sector
  • vocabtranslate: field_chancellor

Build and trim the fixture
Add a test of the taxonomy term deriver.
Add assertions of the non translated fields to MigrateTaxonomyTermTest
Make a new test for any translated term fields, MigrateTaxonomyTermTranslationTest

Remaining tasks

Review and testing.

User interface changes

API changes

Data model changes

Release notes snippet

Change ValidateMigrationStateTestTrait to only test one version

$
0
0

Problem/Motivation

There is a d6 and d7 ValidateMigrationStateTest both of which use ValidateMigrationStateTestTrait::testMigrationState() but that actually checks both the d6 and d7 migration states whereas it should only do one. Plus the test will be a bit easier to read without the version index in all the arrays.

Proposed resolution

Get the legacy version from the source database.

Remaining tasks

Patch, review, commit.

Implement Entity::fields() for migration destinations

$
0
0

Went to implement #2630718: Implement drush migrate-fields-destination and got no output, because:

  public function fields(MigrationInterface $migration = NULL) {
    // TODO: Implement fields() method.
  }

D'oh!

Some introspection necessary here. Ideally, if we followed the D7 migration model, the destination instance in a migration would have a specific bundle assigned, so we would be able to retrieve bundle-specific fields here. That's not true in D8, the bundle is assumed to be pulled per-row from the source data so can't be statically determined. That's... unfortunate, and would seem to require an architectural change (I would love if destinations could be configured like entity:node:article). But at least for now we can pull the base properties here.

Migrate UI - use human-friendly module names on the Review form

$
0
0

Problem/Motivation

This is a followup to #2936365: Migrate UI - allow modules to declare the state of their migrations that is the result of a UX meeting about the Review Page, See2936365-#101.

This is simple and straightforward. How do we all miss it? The Review page should use the human readable module name not the module machine name.

Proposed resolution

The original plan was to use the human readable module name in the UI but in #22 Gábor Hojtsy pointed out that some of the names don't 'match' the module_name, for example, "Views translation" is i18nviews. That will make it harder for people to find the source module. In that comment it was suggested to either
(1) add the project name from the module's info data in parenthesis or as a tooltip
(2) add the machine name of the module in parenthesis or as a tooltip

Option 2 with is implemented as per #54. The option with the tooltip is used because the form "i18nviews (Views translation)" was a lot of text on the page and distracting. Unfortunately, there is not a screenshot of that version.

And that changed at DrupalSouth 2019 to adding a third column with the machine name. See #76

Remaining tasks

  • Usability review

User interface changes

Yes, a 'nicer' Review page:

Before
Before screenshot

After
Showing 3 columns sorted but source module human readable name


Allow themes to declare dependencies on modules

$
0
0

Problem/Motivation

Parsing .info files for dependency information is already implemented on the modules administration page. Adding support for the same dependencies in theme.info files, and implementing the same behavior on the admin/build/themes page, would allow designers building heavily customized themes to make safer assumptions about their target sites.

A theme might require the existence of imagecache to auto-generate variations of a header image. This would be a nice compromise between systems like Wordpress and Joomla!, which give themes much greater control over the functionality of the site, and Drupal's module-centric approach.

It also creates following new UX requirements and non UI, API requirements

  1. Represent the list of dependent modules in themes list page. Display of missing/disabled dependent modules.
  2. Extension in Drush to download and enable modules dependent on themse.

Proposed resolution

  • Allow themes to add the dependencies to .info.yml files
  • Show these dependencies on /admin/appearance and make it impossible to install without the requirements
  • Install dependencies automatically on API level.

Original report by [eaton]

Issue Summary
Parsing .info files for dependency information is already implemented on the modules administration page. Adding support for the same dependencies in theme.info files, and implementing the same behavior on the admin/build/themes page, would allow designers building heavily customized themes to make safer assumptions about their target sites.

A theme might require the existence of imagecache to auto-generate variations of a header image. This would be a nice compromise between systems like Wordpress and Joomla!, which give themes much greater control over the functionality of the site, and Drupal's module-centric approach.

migrate_drupal's Variable source plugin always returns a row for processing, even if none of the variables for a migration are set on the source site

$
0
0

Problem/Motivation

Using the migrate_drupal module, I was trying to write a module that has a UI that shows total number of rows processed over the total number of actual rows in the source DB. For example, if I have 42 articles in my Drupal 7 site and I process 13 of them, it would have a textual display that shows: 13/42 rows processed.

As I was doing this, I discovered that the Variable source plugin will return 0 for the total count if the configured variables don't exist, but initializeIterator() will always return an iterator with 1 row. This leads to a weird case where my UI shows 1/0 rows processed, which is nonsensical.

Proposed resolution

Check if the source has rows and return an iterator created from an empty array if the count of source rows is 0

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

Not necessary.

Broken Aria References

$
0
0

Broken Aria References were reported for the following pages:
admin/config/media/file-system
admin/config/search/pages
admin/config/regional/settings

Check ownership of startpage when user is deleted

$
0
0

If Drupal uses a node as startpage, and an admin deletes that user (ignoring that the user has ownership of nodes) the website has no frontpage and gives an error.

I suggest an extra check when a user gets deleted that displays a message like "If you deletes this owner and his/hers content, the website will have no frontpage. Are you sure you want to do that?" or perhaps even a level of security that prevents admin from deleting that particular user and his/hers content.

path_alias.info.yml missing required keys (core) InfoParserDynamic.php

$
0
0

After upgrade to drupal 8.8 and
After login and using the admin menu you will get this error:

The website encountered an unexpected error. Please try again later.Drupal\Core\Extension\InfoParserException: Missing required keys (core) in core/modules/path_alias/path_alias.info.yml in Drupal\Core\Extension\InfoParserDynamic->parse() (line 29 of core/lib/Drupal/Core/Extension/InfoParserDynamic.php).

The content of the path_alias.info.yml file:
name: Path alias
type: module
description: 'Provides the API allowing to rename URLs.'
package: Core
version: VERSION
required: true
hidden: true

A new installation works fine with same content of this file but an upgrade returns errors.
How to fix this?

Simplify Dropbutton markup in line with our CSS standards

$
0
0

Problem/Motivation

The current markup for Dropbutton looks like this:

<div class="dropbutton-wrapper dropbutton-processed dropbutton-multiple">
<div class="dropbutton-widget">
<ul class="dropbutton">
<li class="edit dropbutton-action"><a href="/admin/structure/views/view/content">Edit</a></li>
<li class="dropbutton-toggle"><button type="button"><span class="dropbutton-arrow"><span class="visually-hidden">List additional actions</span></span></button></li>
<li class="clone dropbutton-action secondary-action"><a href="/admin/structure/views/view/content/clone">Clone</a></li>
<li class="disable dropbutton-action secondary-action"><a href="/admin/structure/views/view/content/disable?token=hQ2egsGF5LtsScdw2oQFeoWNKrUi1HHP9W1WZhjehOk" class="use-ajax ajax-processed">Disable</a></li>
<li class="delete dropbutton-action secondary-action"><a href="/admin/structure/views/view/content/delete">Delete</a></li>
</ul>
</div>
</div>

There's a lot we could do we simplify and improve the markup so it's inline with our CSS coding standards

Proposed resolution

<div class="dropbutton dropbutton--modifier"> <!-- whole component is dropbutton. -->
  <a class="button dropbutton__action">Action One</a>
  <button type="button" class="button dropbutton__trigger">
    <span class="visually-hidden">List additional actions</span>
  </button>
  <ul class="dropbutton__menu" role="menu">
    <li><a class="dropbutton__action">Action Two</a></li>
    <li><a class="dropbutton__action">Action Three</a></li>
  </ul>
</div>

Remaining tasks

Decide on a battle plan of improvements
Write a patch
Test a lot

User interface changes

None

API changes

Mark up changes

Editing mode of website without proper styling

$
0
0

When displaying my website (www.lets-plant.org) in read-only mode, everything looks good. As soon as I log in, the Admin-Toolbar and editing functionalites are without styling (s. attachement).

I assume it has something to do with the processing of the css style sheet but I did not yet find out how to fix it.


Sort options for entity reference field are unsorted

$
0
0

Problem/Motivation

This is a portion of #2900409: [Meta] Improve UI of Reference field settings form, separated out after comment #133.

If you create an Entity Reference field, when you get to the Field Settings dialog, you will find that the options for what field to use to sort the entities presented for referencing are unsorted. Here's what they look like:
Sort options for reference field

Proposed resolution

Use the new #sort_options property of Select elements to sort the options. This came from
#3065903: Add label sort ability to Select element

Completed tasks

Remaining tasks

User interface changes

Sort options will be sorted when setting up an Entity Reference field.

API changes

None.

Data model changes

None.

Release notes snippet

Probably not necessary. Small UI fix.

Use styling from Upgrade Status module on Review form

$
0
0

Problem/Motivation

This is a follow up to #3024682: Migrate UI - use human-friendly module names on the Review form.
Here we want to "make the styling 10,000% better and match the Upgrade Status module" , as webchick said in comment #54 of that issue.

Work on this does not need to wait for #3024682: Migrate UI - use human-friendly module names on the Review form to be committed. It is near RTBC and any changes are likely to be small as easy to merge. Finally, setting to Major since this will be a big improvement to that form.

Proposed resolution

The details of the suggestion by webchick, from #45 are:
We could handle that bit like Upgrade Status module does (https://www.drupal.org/files/project-images/UpgradeStatus8UI.png), which is:
1) A full table of all modules in alphabetical order (could indeed group sub-modules under package if you'd like; Update Status module does that: https://www.drupal.org/files/issues/2019-10-09/d8-update-manager.png)
2) Colour + icon the table rows according to their statuses
3) Allow filtering the table to show only rows with a problem

The Upgrade Status Module uses 3 columns and the Review page 2. Should we stay with 2 or add a third?

Remaining tasks

  1. Decide if the table should have 2 or 3 columns?
  2. Modules grouped by project. Functional but needs work from front-end folks.
  3. Add colour + icon. Functional but needs work from front-end folks
  4. Add a filter to show only rows with a problem.

User interface changes

Yes, the Migrate UI review page /upgrade/review

Screenshots

Before
Three columns as it will be once #3024682: Migrate UI - use human-friendly module names on the Review form is committed.
 Drupal 6 module name, Drupal 6 machine name, Drupal 8

After

API changes

Data model changes

Release notes snippet

Dependency injection in permission callbacks

$
0
0

The permissions callback provider class, being handled by the controller resolver, is capable of dependency injection by implementing ContainerInjectionInterface. The following patch adds that for the node module permission provider. The same should be done for other core modules that provide permission callbacks.

There is no way to delete or update file entities of other users incl. user/1

$
0
0

Problem/Motivation

Currently it's only possible to delete a file entity by the owner of an file entity. There is no additional condition defined for any permission or even an exception for user/1 (main admin user).

Proposed resolution

  • Use existing permission to delete file entities.
  • And maybe define an exception for user/1 to delete file entities like other entities.
  • Add a new permission to delete any files (implemented in #45).

Remaining tasks

Direction, Decision, Patch.

User interface changes

TBD

API changes

TBD

Data model changes

None expected.

Original Issue summary:

I've faced with problem when user with id '1' (main admin user) can't delete file entities created by another user. I used view_bulk_operations for deleting file entities. I thought user 1 has absolute access to all entities.

DefaultSelection::buildEntityQuery requires entities to have bundle key.

$
0
0

I came accross this when trying to reference a custom entity without a bundle key present using a contrib module (entityreference_view_mode).
When trying to use the autocomplete function, DefaultSelection::buildEntityQuery is called.

When trying to use the autocomplete function, I got following error:

PHP message: Uncaught PHP Exception Drupal\\Core\\Entity\\Query\\QueryException: "'' not found

I traced it down to this piece of code in Drupal\Core\Entity\Plugin\EntityReferenceSelection\DefaultSelection.

    if (is_array($configuration['target_bundles'])) {
      // If 'target_bundles' is an empty array, no bundle is referenceable,
      // force the query to never return anything and bail out early.
      if ($configuration['target_bundles'] === []) {
        $query->condition($entity_type->getKey('id'), NULL, '=');
        return $query;
      }
      else {
        $query->condition($entity_type->getKey('bundle'), $configuration['target_bundles'], 'IN');
      }
    }

$configuration['target_bundles'] contained a value (perhaps this is an issue with the contrib module). But because my custom entity contained no bundle key in the entity keys, the query caused an error.

I have fixed this by checking if the entity has a bundle key present, and only then adding the condition, in the patch attached.

    if (is_array($configuration['target_bundles'])) {
      // If 'target_bundles' is an empty array, no bundle is referenceable,
      // force the query to never return anything and bail out early.
      if ($configuration['target_bundles'] === []) {
        $query->condition($entity_type->getKey('id'), NULL, '=');
        return $query;
      }

      $bundleKey = $entity_type->getKey('bundle');

      if ($bundleKey) {
        $query->condition($bundleKey, $configuration['target_bundles'], 'IN');
      }
    }
Viewing all 297515 articles
Browse latest View live


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