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

Group header rendering may output markup as readable string

$
0
0

Problem/Motivation

Build a view with multiple levels of groups where not only the field value will be printed but also the field label. If the field content of one of those group fields contains markup, e.g. when theme debugging is turned on or a complex field like dates contain regular markup then that will be output as strong and not as markup - but only if you also output the field labels.

Steps to reproduce

Install Drupal 8, enable views and create a view with fields and multiple groups.

Proposed resolution

The issue is caused by \Drupal\views\Plugin\views\style\StylePluginBase::renderGrouping in line 595-598 you find this:

$group_content = $this->getField($index, $field);
if ($this->view->field[$field]->options['label']) {
  $group_content = $this->view->field[$field]->options['label'] . ': ' . $group_content;
}

The group content is markup originally and if the label is turned on, the string concat turns group content from markup into a string.

The solution should be to make this a renderable object with label being their own markup object or prepend the pure string label to the markup object.


hook_install is invoked before the module's default config is installed during config import

$
0
0

Problem/Motivation

When my module is enabled I need some content to be created, so I'm using hook_install() to create it. As content belongs to specific entities bundles I'm adding the required config entities in /config/install.

When installing the module in a running instance all works as expected.

However when module is installed through a configuration import process - either from Config UI or drush ci or config_installer profile - the whole import process while installing the module.

The error - in my case - is "Field field_myfieldname is unknown", which is a field on one of the bundles I create instances for in my hook_install().

I can't find any similar issue in the queue, and this makes me nervous because creating-content-on-module-install looks to me like a common scenario. That let me thinks the system may work as expected and the problem here is hook_install() shouldn't be used for creating content.

Proposed resolution

If this is a real bug, investigate and fix the problem. It may be related to #2451365: ConfigInstaller has the source storage injected by config importer and module installer but it is done incorrectly, although the IS doesn't mention this error as consequence.
If developers shouldn't rely on config/install/* to be available on hook_install(), then this issue should become a Documentation task and we can update the docs about config/install (Include default configuration in your Drupal 8 module& Co.) as well as hook_install() api.

Remaining tasks

  • Confirming if this is a real issue or documentation should be updated
  • Work on a patch

User interface changes

None.

API changes

None(?)

Data model changes

None.

Add Alpha level Experimental Automatic Updates module

$
0
0

Please DO NOT push to this branch. See How to Help for instructions for working in the contrib module.

Problem/Motivation

Automatic Updates is one of Drupal Core current strategic initiatives

For full details of the initiative see #2940731: Automatic Updates Initiative overview and roadmap

Currently the work on the module is happening in 8.x-2.x branch of the Automatic Updates contrib module.

This issue is to bring in the current version of the 8.x-2.x branch of the contrib module into core as an Alpha level experimental module.

Proposed resolution

A merge request will be created on this issue that will mirror the 8.x-2.x branch of the contrib module. Because some things in the module will need to be altered to work in core the merge request commits will be created by a conversion script that will change things like the module machine name from automatic_updates to auto_updates

Since this is will be a very large merge request we will continue to create issues and make improvements in the contrib module 8.x-2.x branch and convert that work via the conversion script to commits here. @tedbow or @phenaproxima will make the conversion daily if there are commits to the contrib module.

How to help

Feel free to leave feedback on this merge request. If you would like to help address the feedback please search the 8.x-2.x issue queue to see if any existing issue exists and if not create one in that project.

Remaining tasks

  1. Review the patch
  2. Framework manager sign-off
  3. Release manager sign-off

User interface changes

API changes

Data model changes

Release notes snippet

Expose Layout Builder data to REST and JSON:API

$
0
0

Problem/Motivation

When accessing Layout Builder overrides via REST (i.e. when accessing an overridden entity's layout field), the contents of sections are empty.

Proposed resolution

Add a normalizer for the layout_section DataType, which ensures that sections can be properly serialized and unserialized via the serialization API (and REST).

Remaining tasks

N/A

User interface changes

N/A

API changes

A new normalizer will be added for the layout_section DataType.
Layout section data will be exposed for all serialization types.

Data model changes

N/A

[Symfony 6] Add typehints to Drupal\Core\Validation\DrupalTranslator

$
0
0

Problem/Motivation

From #3197482: Update Drupal 10 to depend on Symfony 5.4 (as a stepping stone to Symfony 6, for deprecation checking support)

Method "Symfony\Contracts\Translation\TranslatorInterface::trans()" might add "string" as a native return type declaration in the future. Do the same in implementation "Drupal\Core\Validation\DrupalTranslator" now to avoid errors or add an explicit @return annotation to suppress this message.

Method "Symfony\Contracts\Translation\TranslatorInterface::getLocale()" might add "string" as a native return type declaration in the future. Do the same in implementation "Drupal\Core\Validation\DrupalTranslator" now to avoid errors or add an explicit @return annotation to suppress this message.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Store all installable releases in update_calculate_project_update_status()

$
0
0

Problem/Motivation

Right now the Update module will always recommend the latest version in the current major that is installable, meaning published, secure, in a supported branch and support itself.

though there are some bugs, like #3227518: Never show a "Not supported!" version as "Recommended"

This is going to be problem for Automatic Updates when it is in core because the MVP will only support patch release not upgrading to different minor. see #3252187: Deal with Core UPdate module recommending the latest release in the major version not the latest in the Minor version

For example if:

  • the site is on Drupal core 9.5.1
  • 9.5.x and 9.6.x are the 2 supported branches of core
  • The latest release in each branch is 9.5.2 and 9.6.2
  • Then the UPdate module will use 9.6.2 as the "Recommended version"
  • This will not be supported by the MVP for Automatic Updates because this would be updating to different minor. We will only support patch updates

Steps to reproduce

currently based on https://updates.drupal.org/release-history/drupal/current

If a site where on 9.1.13 the Update would not recommend 9.1.14. It would recommend 9.2.10. You can test by faking the drupal version Drupal.php

Proposed resolution

in the long term it would be good if the Update module recommend a version in the current minor and then in any other minor that is supported(for core that will usually be 2) in the same major. But this will major need refactoring of the Update reports.

For now we should simple change update_calculate_project_update_status() to store all the info about installable releases in $project_data which it modifies. This will allow other modules like Automatic Updates in contrib and in the core version which should be started soon to pick a version in the current minor that we know is secure and supported.

update_calculate_project_update_status() already has all the information it needs to do this.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

editor_form_filter_format_form_alter() does not remove "editor_plugin" from form state when needed

$
0
0

Problem/Motivation

While working on CKEditor 5, I noticed that I kept getting a CKEditor 5 validation error even after I was no longer on CKEditor 5. I first blamed the CKEditor 5 module.

Then I learned it's a bug in editor.module.

editor_form_filter_admin_format_validate

Steps to reproduce

  1. Install ckeditor.module + ckeditor5.module
  2. Go to /admin/config/content/formats/add
  3. Switch to CKEditor 5
  4. Switch to None
  5. Switch to CKEditor (4)
  6. Expected: CKEditor 4 admin UI
    Actual: CKEditor 5 validation error (Invalid toolbar value.) and no CKEditor 4 admin UI

Proposed resolution

Upon switching text editors (including to '' aka "None"), editor_form_filter_admin_format_validate() gets called beforeeditor_form_filter_format_form_alter()… which means that $form_state still contains the old editor plugin.

Remaining tasks

  1. Passing fix-only patch
  2. Failing test-only patch; test can simply match the steps to reproduce above
  3. Passing fix+test patch

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A

migrate_state_finished_test's FieldLeft and FieldRight plugins are not namespaced correctly

$
0
0

Problem/Motivation

The files core/modules/migrate_drupal/tests/modules/migrate_state_finished_test/src/Plugin/migrate/field/FieldLeft.php and core/modules/migrate_drupal/tests/modules/migrate_state_finished_test/src/Plugin/migrate/field/FieldRight.php break PSR-2 and PSR-4 and cannot be autoloaded correctly.

Steps to reproduce

Proposed resolution

Determine if they are even needed anymore.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet


Use sniff DrupalPractice.CodeAnalysis.VariableAnalysis on */tests/*

$
0
0

Problem/Motivation

In #3106216: Remove unused variables from core we introduced the sniff DrupalPractice.CodeAnalysis.VariableAnalysis to detect unused variables in Drupal Core.
To narrow the scope the decision was made to exclude all the test-classes.

This issue is created to make that sniff run without errors on all test-classes.

Steps to reproduce

Proposed resolution

- Remove the line <exclude-pattern>*/tests/*</exclude-pattern> from sniff DrupalPractice.CodeAnalysis.VariableAnalysis in core/phpcs.xml.dist
- Fix all and any errors

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Fix plugin deprecations

$
0
0

Problem/Motivation

Plugins should be deprecated in the constructor and not the main section of the class. This is because discovery and instantiation can result in triggering unwanted deprecations.

Steps to reproduce

See tests runs on #3252386: Use PHP attributes instead of doctrine annotations where all plugins have been reflected on for discovery.

Proposed resolution

Move deprecation to constructor,

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

N/a

Document standards for config files

$
0
0

Problem/Motivation

Other issues have established standards for configuration files and filenames.
Can find by searching for issues and change records.
But should be all in one place.

Proposed resolution

Document already decided things in a coding standard page.
https://www.drupal.org/node/2315769

Remaining tasks

See #6
find the related issues and change records and link to them here and/or when updating the doc page in the revision log.

Related issues and change records and other things to aggregate

User interface changes

No.

API changes

No.

[drupalImage] Make image alt text required

$
0
0

Problem/Motivation

CKEditor 4 requires setting alt text for all images when they are being inserted using the CKEditor Drupal image plugin. In CKEditor 5 the user needs to remember to insert the alt text manually since the process of adding images never even displays the form where alt text can be inserted. Since the process in CKEditor 5 could end up having images accidentally not having alt texts, it could be considered as an accessibility regression.

Render blocks later, so they can be placed individually in a region template

$
0
0

Problem/Motivation

Every region template (eg. core/modules/system/templates/region.html.twig) uses {{ content }} to render the blocks in that region. But unlike node templates (eg. core/modules/node/templates/node.html.twig), where you can do things like {{ content|without('field_example') }}, the content of a region cannot be manipulated. This is because the content variable of a region is not an array of renderable elements, but just a string of rendered HTML.

Sometimes you want to be able to have access to the separate blocks, for instance to do something like this:

<div class="grid-container">
    {{ content|without('special-block') }}
  </div>
  {{ content.special-block }}

Proposed resolution

The reason why blocks arrive in the template as an already rendered blob of HTML, can be found in the comments on line 439 and 440 of core/lib/Drupal/Core/Render/Renderer.php:

// If #theme is not implemented or #render_children is set and the element
// has an empty #children attribute, render the children now. [...]

This also points us in the direction of a solution: Build the render array of a region with a #theme property instead of a #theme_wrapper. As far as I can see, this results in the exact same output as the current situation, requiring no changes to twig templates, while adding additional flexibility for those who need it.

Remaining tasks

I did not find any downsides yet, but we have to think of reasons to not do this.
No reasons have been brought forward.

Are there performance implications?
None, except that a little more function nesting (still well within reasonable limits) might theoretically slow down xDebug.

Could caching be a problem when region output is made more dynamic? And if so, is that a problem for Drupal core to solve, or just a case of "with great power..."?
Manual testing has shown that caching works as expected, also when making use of the new capabilities we are adding. Also, all automated tests pass.

Decide what to do about regions that contain blocks, but eventually render to an empty string. Currently they skip rendering the div.region wrapper, but after the patch the wrapper is rendered. See comment #43.

User interface changes

none

API changes

none (see also comment #34)

Data model changes

none

Release notes snippet

Do we need one?

User can't reference unpublished content even when they have access to it

$
0
0

Problem/Motivation

User gets an error when trying to reference an unpublished entity that they have just created and that he has full access to. This basically makes it impossible for a user to submit a set of unpublished interreferencing entities (e.g. artefact/architect/city).

Steps to reproduce:

  1. Create content type A, make sure Published is unchecked in the Publishing options.
  2. Create content type B, add an ER field referencing A, choose Autocomplete widget in Form display.
  3. Create a test user, give permissions to View own unpublished content, to Create A and B, to Edit own A and B.
  4. Log in as that user.
  5. Create a test node of type A, verify that it is Unpublished and the user can see it.
  6. Create a test node of type B, start typing the label of the A node just created, verify that it's not recognised and suggested by the system.
  7. Type the complete label and hit Save, get the "No such entity" error.
  8. Type the entity label followed by its nid in parentheses, still get the "This entity (node: N) cannot be referenced”

This issue also prevents the user w/ appropriate permissions from referencing unpublished entities authored by other users.

Proposed resolution

Allow referencing unpublished entities if the current user has access to them.

Remaining tasks

Resolve what to do for entities that are created via an entity-reference field. (See comments #43–46)

The gist of the problem: The existing kludge that Core had before this patch misleads site builders and content creators into inadvertently exposing private content. Is it more important to fix that, or is it more important to avoid changing existing behaviour (because some people may be relying on that).

Options include:

  • Do not make any changes to entity creation.
  • Roll a separate issue for this, possibly bump to Drupal 10.
  • Decide that fixing the problem is more important than maintaining existing behaviour.

Secondly, some changes to tests were recommended in comment #43 that still need to be addressed.

User interface changes

none

API changes

none

Data model changes

none

Release notes snippet

Migrate UI tests should provide the complete log message on failure

$
0
0

Postponed on #3193189: Get only translations for localized vocabularies d6/TermLocalizedTranslation.php

Problem/Motivation

When running a migration with the UI, failures are logged to watchdog but that table is deleted as part of tearing down the test setup. That leaves the developer with no information to find the migration causing the failure, as seen in this screenshot at #2746541-153: Migrate D6 and D7 node revision translations to D8:

We need a way to save and report those errors.

Proposed resolution

Access all pages of /admin/reports/dblog in the test site so the results are saved in the BROWSERTEST_OUTPUT_DIRECTORY directory.

Remaining tasks

Patch
Review
Commit


Add the process plugin ID and index to migration exception message

$
0
0

Problem/Motivation

In #2976098: MigrateExecutable should add details for the migration & destination property to exceptions that cause a row failure, the migration ID and destination property was added to migration failure messages.

For a process pipeline with several plugins, that can still leave some detective work finding the source of the problem.

It would be useful to add the process plugin ID, and also the index number, since the same process plugin can occur several times in a single pipeline.

Steps to reproduce

Proposed resolution

Move the catch in import():

        catch (MigrateException $e) {
          $this->getIdMap()->saveIdMapping($row, [], $e->getStatus());
          $msg = sprintf("%s:%s: %s", $this->migration->getPluginId(), $destination_property_name, $e->getMessage());
          $this->saveMessage($msg, $e->getLevel());
          $save = FALSE;
        }

to processPipeline(), which has the plugin name, and add an $index to the foreach loop.

This should then re-throw the exception with the process plugin details prefixed to the message.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Add README to composer project templates

$
0
0

Problem/Motivation

Composer templates do not have README documentation.

Proposed resolution

Add README documentation.

Each template directory should have its own README.txt file, which gives an explanation of how to use the project, and also links to documentation.

The goal is that the end-user has this README file available after they have issued a composer create-project command.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Postgres driver issue with nested savepoints mimic_implicit_commit duplicated

$
0
0

We're having an issue with Workbench Moderation and Group installed and have traced it back to an issue with the Postgres db driver. The Postgres driver automatically creates savepoints named "mimic_implicit_commit" for most queries running inside of an ongoing transaction.

The problem occurs when a DB query is run that triggers another DB query in the first's preExecute() phase (typically a hook such as hook_node_grants). This creates a situation where a new savepoint also called "mimic_implicit_commit" is added before the original "mimic_implicit_commit" savepoint is released. pushTransaction() doesn't allow for duplicate savepoint names.

The easiest way to re-create is to install/enable Workbench Moderation and then have any module that implements hook_node_grants() with a DB query using the ->execute() method enabled as well (such as Group/Group Node). When you add try to add content as a user without "bypass node access", you'll get this error message when you try to save:

Drupal\Core\Entity\EntityStorageException: mimic_implicit_commit is already in use. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 777 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

Here's some additional information about the problem. Basically all DB queries funnel into the pgsql\Select class's execute() method, which arbitrarily runs addSavepoint($savepoint_name = 'mimic_implicit_commit')

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Database%...

# Drupal\Core\Database\Driver\pgsql\Select
public function execute() {
  $this->connection->addSavepoint();
  try {
    $result = parent::execute();
  }
  catch (\Exception $e) {
    $this->connection->rollbackSavepoint();
    throw $e;
  }
  $this->connection->releaseSavepoint();

  return $result;
}

pgsql\Select\execute() is called from many different places. Only one path via the pgsql/Connection query() method does it actually check for the duplicate 'mimic_implicit_commit' name:
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Database%...

# Drupal\Core\Database\Driver\pgsql\Connection
public function query($query, array $args = [], $options = []) {
  $options += $this->defaultOptions();

  // The PDO PostgreSQL driver has a bug which doesn't type cast booleans
  // correctly when parameters are bound using associative arrays.
  // @see http://bugs.php.net/bug.php?id=48383
  foreach ($args as &$value) {
    if (is_bool($value)) {
      $value = (int) $value;
    }
  }

  // We need to wrap queries with a savepoint if:
  // - Currently in a transaction.
  // - A 'mimic_implicit_commit' does not exist already.
  // - The query is not a savepoint query.
  $wrap_with_savepoint = $this->inTransaction() &&
    !isset($this->transactionLayers['mimic_implicit_commit']) &&
    !(is_string($query) && (
    stripos($query, 'ROLLBACK TO SAVEPOINT ') === 0 ||
    stripos($query, 'RELEASE SAVEPOINT ') === 0 ||
    stripos($query, 'SAVEPOINT ') === 0
    )
    );
  if ($wrap_with_savepoint) {
    // Create a savepoint so we can rollback a failed query. This is so we can
    // mimic MySQL and SQLite transactions which don't fail if a single query
    // fails. This is important for tables that are created on demand. For
    // example, \Drupal\Core\Cache\DatabaseBackend.
    $this->addSavepoint();
    try {
      $return = parent::query($query, $args, $options);
      $this->releaseSavepoint();
    }
    catch (\Exception $e) {
      $this->rollbackSavepoint();
      throw $e;
    }
  }
  else {
    $return = parent::query($query, $args, $options);
  }

  return $return;
}

However, both Groups and Workbench moderation call the pgsql/Select execute() method directly, bypassing the duplicate check for mimic_implicit_commit in pgsql/Connection query().

Groups:

#0  Drupal\Core\Database\Driver\pgsql\Select->execute() called at [/opt/tbs/wcms/open_gov/web/current/html/core/lib/Drupal/Core/Config/DatabaseStorage.php:273]
#1  Drupal\Core\Config\DatabaseStorage->listAll() called at [/opt/tbs/wcms/open_gov/web/current/html/core/lib/Drupal/Core/Config/CachedStorage.php:207]
#2  Drupal\Core\Config\CachedStorage->findByPrefix() called at [/opt/tbs/wcms/open_gov/web/current/html/core/lib/Drupal/Core/Config/CachedStorage.php:183]
#3  Drupal\Core\Config\CachedStorage->listAll() called at [/opt/tbs/wcms/open_gov/web/current/html/core/lib/Drupal/Core/Config/ConfigFactory.php:328]
#4  Drupal\Core\Config\ConfigFactory->listAll() called at [/opt/tbs/wcms/open_gov/web/current/html/core/lib/Drupal/Core/Config/Entity/Query/Query.php:172]
#5  Drupal\Core\Config\Entity\Query\Query->loadRecords() called at [/opt/tbs/wcms/open_gov/web/current/html/core/lib/Drupal/Core/Config/Entity/Query/Query.php:82]
#6  Drupal\Core\Config\Entity\Query\Query->execute() called at [/opt/tbs/wcms/open_gov/web/current/html/core/lib/Drupal/Core/Entity/EntityStorageBase.php:503]
#7  Drupal\Core\Entity\EntityStorageBase->loadByProperties() called at [/opt/tbs/wcms/open_gov/web/current/html/modules/contrib/group/src/GroupMembershipLoader.php:146]
#8  Drupal\group\GroupMembershipLoader->loadByUser() called at [/opt/tbs/wcms/open_gov/web/current/html/modules/contrib/group/modules/gnode/gnode.module:169]

Workbench:

#0  Drupal\Core\Database\Driver\pgsql\Select->execute() called at [/opt/tbs/wcms/open_gov/web/current/html/core/lib/Drupal/Core/Entity/Query/Sql/Query.php:250]
#1  Drupal\Core\Entity\Query\Sql\Query->result() called at [/opt/tbs/wcms/open_gov/web/current/html/core/lib/Drupal/Core/Entity/Query/Sql/Query.php:77]
#2  Drupal\Core\Entity\Query\Sql\Query->execute() called at [/opt/tbs/wcms/open_gov/web/current/html/modules/contrib/workbench_moderation/src/ModerationInformation.php:166]
#3  Drupal\workbench_moderation\ModerationInformation->getLatestRevisionId() called at [/opt/tbs/wcms/open_gov/web/current/html/modules/contrib/workbench_moderation/src/ModerationInformation.php:151]

The pgsql driver may need to be patched to handle the duplicate savepoint condition when Query class's execute() function are accessed directly.

Make it possible to install dependent modules when installing theme

$
0
0

Problem/Motivation

It became possible to have themes depend on modules in #474684: Allow themes to declare dependencies on modules. In this implementation, the dependee-modules must be enabled in admin/modules before a module-depending theme can be enabled.
Ideally, it would be possible to enable the dependent modules as part of enabling the theme. This was not part of the initial implementation due to the complexities of permissions and confirmation forms when both themes and modules are being enabled.
A partial implementation was added in an earlier iteration of the patch #474684: Allow themes to declare dependencies on modules, once it was apparent that additional validation (including experimental modules) was needed, it was decided that this was better addressed in a followup.

Proposed resolution

Determine how to best implement module-enabling validation in both admin/modules and when enabling module-dependent themes.

Then implement that.

Remaining tasks

?

User interface changes

...

API changes

...

Data model changes

...

Release notes snippet

...

Autoload classes of database drivers modules' dependencies

$
0
0

Problem/Motivation

Database drivers that extend another database driver have to add the line with something like: include_once dirname(__DIR__, 8) . '/mysql/src/Driver/Database/mysql/Connection.php';. When this line is not added, the database driver will fail the installation proces. The extending database driver is then using a class that is not autoloaded and therefor does not exist.
The include_once only works when the module with the extending database driver is in the same level in the directory structure. This is not very practical for sitebuilders. It is also not to the standard Drupal Core would like its code to be.
Example database drivers that extend another database driver are: https://www.drupal.org/project/mysql56 and https://www.drupal.org/project/pgsql_fallback.

Proposed resolution

Improve the autoloading for the parent database driver during installation.

Remaining tasks

TBD

User interface changes

None

API changes

Extending database driver do not have to add include_once statement with every driver class they extend.

Data model changes

None

Release notes snippet

TBD

Viewing all 291245 articles
Browse latest View live


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