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

Old link domain remains in link type cache after setting another

$
0
0

Problem/Motivation

The link manager service allows to set a specific link domain by calling the method 'ConfigurableLinkManagerInterface::setLinkDomain($domain)'.

On the other hand, the type link manager manages a cache of type links present in the system. Each type link is identified by a URI that is based on the link domain setted at the moment that the cache is written.

If the link domain name changes by calling setLinkDomain, the link type cache remains as it was.

Steps to reproduce

  1. fresh install of 8.5-dev Drupal with standard profile
  2. enable the HAL module. Will ask to enable serialization as well by dependency. Also enable the 'rest' module needed as a new dependency, see [#1155816]
  3. download and enable the devel module
  4. try at /devel/php this working-well PHP snippet, that serializes and un-serializes a node:
    $node = \Drupal\node\Entity\Node::create([
      'type' => 'page',
      'title' => 'Test node',
    ]);
    
    $serialized_node = \Drupal::service('serializer')->serialize($node, 'hal_json');
    
    $new_node = \Drupal::service('serializer')->deserialize($serialized_node, 'Drupal\node\Entity\Node', 'hal_json');
    echo $new_node->get('title')->getString();
    
  5. at the same place, replace previous test code by this one that does the same but changing the link domain, it causes a "Type http://example.com/rest/type/node/page does not correspond to an entity on this site." exception:
    \Drupal::service('hal.link_manager')->setLinkDomain('http://example.com');
    
    $node = \Drupal\node\Entity\Node::create([
      'type' => 'page',
      'title' => 'Test node',
    ]);
    
    $serialized_node = \Drupal::service('serializer')->serialize($node, 'hal_json');
    
    $new_node = \Drupal::service('serializer')->deserialize($serialized_node, 'Drupal\node\Entity\Node', 'hal_json');
    echo $new_node->get('title')->getString();
    
    \Drupal::service('hal.link_manager')->setLinkDomain('');
    

Rebuilding the cache and retrying the last step will work, because the type links cache is write again with the setted link domain.

Note that it only affects the de-serialization process, in serialization the last setted link domain is always used.

Proposed resolution

  1. Clear the type links cache when a new link domain is set.
  2. Write the type link by absolute URI (with no domain) and add it in getters.

Remaining tasks

Notify about it in docs (until solved) to module developers that makes usage of serialization. Currently, any module that changes the link domain should clear the "hal:links:types" cache to avoid this issue and also prevent malfunctioning of any other module that works with HAL, since type links cache remains with unexpected URI.

API changes

Depending on how it is solved, the API could be affected.


d7_language_content_comment_settings triggers MigrateException if the source bundle is longer than 32 chars: use migration_lookup

$
0
0

Problem/Motivation

If the source comment type ID (bundle) is longer 32 characters, then the related language content settings migration d7_language_content_comment_settings triggers MigrateException (and fails migration)

The logged migration message is:

Missing bundle entity, entity type comment_type, entity id comment_node_a_random_node_type_id. ([docroot]/core/lib/Drupal/Core/Entity/EntityType.php:877)

Steps to reproduce

Create a content type with a long bundle name (at least 21 chars), enable translation for this particular type, and migrate.

Proposed resolution

The process pipeline of the target_bundle destination property has to use migration_lookup.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

[Support request|Bug report] d7_field_formatter_settings maps full view mode to default

$
0
0

Problem/Motivation

The d7_field_formatter_settings migration maps formatters used in full view mode to the default entity view display on the destination. This means that right now, the formatter migration rows of the same field are overriding each other's migrated configuration if the actual field has formatter data for both of these view modes on the source Drupal(7?) site.

Proposed resolution

If this is not considered as a bug by the migration maintainers: Document why d7_field_formatter_settings overrides the formatter settings used in default/full view modes.
If this is a bug: Don't map full view display mode's formatter settings to the default view mode.

For now, let me aggressively evaluate this as a bug 🧐.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Remove DependencySerializationTrait from JSON API exceptions

$
0
0

Problem/Motivation

Discovered by @alexpott in #3224523: [PHP 8.1] Add ReturnTypeWillChange attribute where necessary, we include DependencySerializationTrait in the JSON API exceptions EntityAccessDeniedHttpException and UnprocessableHttpEntityException. The code has existed since these exceptions were first commited.

However, this seems unnecessary as neither exception stores anything which requires special handling if the exceptions are serialized. @alexpott already proved this does not break tests in #2561915-24: alexpott's test issue.

Steps to reproduce

Proposed resolution

Remove DependencySerializationTrait from the exceptions.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

[PP-1] Implement a generic revision UI

$
0
0

Problem/Motivation

At the moment there is no generic revision UI, this means that every module with revisionable entities will need to create their own UI similar to the Node revision overview page (node/{node_id}/revisions. This means quite a bit of boilerplate code, especially for modules with multiply revisionable entities.

Proposed resolution

Create a route provider for generating revision list, revision revert form, revision delete form based derived from link templates.

Remaining tasks

  • Decide if we want to improve this in core
  • Create a plan
  • Implement the plan
  • Direction/decisions

    Items needing discussion

    • ✅Whether to continue blocking this issue on #3043321: Use generic access API for node and media revision UI, an access checker will be added and immediately deprecated.
    • ❌Whether Node should use this in this issue.
    • ✅Whether we should generate local tasks, or if entities should add their own.
    • Revert terminology updated to be agnostic of target revision' time.
    • Should we adopt Version terminology (per patch)?

    Blockers

    Patch to date for this issue relies on patches in these.

    User interface changes

    New opt-in UI based on features already established by Node.

    API changes

    None

    Data model changes

    None.

    Release notes snippet

    Remove LayoutBuilderTest::testRemovingAllSections()' QuickEdit dependency

    $
    0
    0

    Problem/Motivation

    #3228634: Move tests for integrations between QuickEdit and other modules into QuickEdit so that it can more easily be moved into contrib moved all known QuickEdit integration tests into the QuickEdit module, but we missed one method: Drupal\Tests\layout_builder\Functional\LayoutBuilderTest::testRemovingAllSections() still requires permission to use QuickEdit.

    Proposed resolution

    Move this method to a test in QuickEdit, and/or alter the test to decouple it from QuickEdit.

    Remaining tasks

    TBD

    Add option for visually-hidden block titles

    $
    0
    0

    Problem/Motivation

    Block titles can currently be displayed or hidden by site-builders. When hidden, the heading element is omitted from the HTML entirely. Hiding titles might be desirable for a visual design, however block titles can be useful for visually impaired users, providing contextual clarity and navigational cues via screenreaders.

    Proposed resolution

    Add another option in block configuration, to output visually-hidden block titles, with a "visually-hidden" class.
    In D7 this functionality is provided by the a11y_titles module.

    We have already added equivalent functionality to D8 for the FieldAPI label display. Offering visually-hidden block titles will extend the options available for site builders to fine-tune the page structure.

    Before

    After

    Remaining tasks

    Contributor tasks needed
    TaskNovice task?Contributor instructionsComplete?
    Create a patchInstructionsDone
    Reroll the patch if it no longer applies.InstructionsDone
    Add automated testsInstructionsDone
    Update the patch to incorporate feedback from reviews (include an interdiff)InstructionsDone
    Manually test the patch NoviceInstructionsDone
    Embed before and after screenshots in the issue summary NoviceInstructionsDone
    Review patch to ensure that it fixes the issue, stays within scope, is properly documented, and follows coding standardsInstructions
    • Usability review: this accomodates an additional option by replacing a checkbox with a select element, similar to the label display for field formatters.
    • Documentation: explain the visually-hidden option on the block help page?
    • Update settings form in \Drupal\Core\Block\BlockBase::buildConfigurationForm()
    • Update HTML output in block module, adding "visually-hidden" class to title_attribute twig variable via template_preprocess_block. The block twig template does not need to be changed.
    • Update block settings config schema. Not necessary - block_settings.label_display is already type: string, not boolean.
    • Update installation config in core profiles/modules, changing block_settings.label_display values of '0' to explicit 'hidden'. It would be a BC break so keep the '0' value for hidden titles.
    • hook_update(). Change block_settings.label_display values of '0' to explicit 'hidden'. Not usefull anymore (see previous)
    • Write tests.
    • Some blocks have custom behaviour, e.g. menu blocks already have visually hidden titles, and Bartik uses it's own CSS to hide block titles in the header region. Come up with an approach for these - we might be able to remove custom templates and CSS, relying instead on installation config. Should be done in follow-up issues.

    User interface changes

    Block title display option changes from a boolean checkbox option to 3 options in a select element: Visible, Visually Hidden, Hidden.
    Aim for consistency with the Field API options in entity manage-display settings.

    Also descriptive help text may change (D7 a11y_titles module says "Block titles can provide context to users who can’t rely on visual cues").

    API changes

    None expected.

    Data model changes

    We are introducing a third option to Block title display: 'visually-hidden'. Effect on data model are as follows:

    • Config Schema: NO CHANGE. While we are introducing an additional option ('visually-hidden') for the core data type block_settings.label_display, this is already of type: string, which accommodates all proposed values (visible, visually-hidden, hidden).
    • Installation Config: CHANGED. Block configuration files in config/install folders will need to be updated, changing block_settings.label_display values of '0' to explicit 'hidden'. Removed for BC
    • Existing Sites' Config: UPDATE HOOK required, changing block_settings.label_display values of '0' to explicit 'hidden'. Removed for BC

    Olivero: Wide search form should close on blur

    $
    0
    0

    Similar to #3191692: Have secondary menus close on blur, the search form dropdown should close on when focus is removed from the search form.

    This can problem reduce or eliminate issues such as #3209871: Olivero's: The header is showing odd behavior when the search bar is opened.

    Testing instructions

    1. Load the patch or visit the tugboat link: https://3226785-wide-search-blur-2-u5r32gkuptbfrviscfbruwee2wditkcl.tugb...
    2. Load the page at wide widths
    3. Open the search form (can be either click or via keyboard)
    4. Tab outside of the search form - verify the form closes after you tab away.
    5. Shift-tab to before the search form. Verify the form will close after either the form or the form's disclosure button loses focus.

    Entity validation does not always prevent concurrent editing of pending revisions

    $
    0
    0

    Problem/Motivation

    Normal workflow in HEAD without pending revisions:

    1. Create a page
    2. Open the edit page
    3. Open another edit page in another tab to simulate a concurrent edit
    4. Change the title and save a new revision
    5. Now in the other tab without refreshing the page change the title again and save a new revision
    6. Verify a validation error is displayed

    Steps to reproduce with Content Moderation in HEAD:

    1. Enable the Content Moderation module
    2. Enable the Editorial workflow for articles
    3. Create an article and save it as draft
    4. Open the edit page
    5. Open another edit page in another tab to simulate a concurrent edit
    6. Change the title and save a draft
    7. Now in the other tab without refreshing the page change the title again and save as draft
    8. Verify a validation error is displayed
    9. Create another article and save it as published
    10. Open the edit page
    11. Open another edit page in another tab to simulate a concurrent edit
    12. Change the title and save a draft
    13. Now in the other tab without refreshing the page change the title again and save as draft

    Expected result: a validation error is displayed.
    Actual result: the second draft "overrides" the first one, although both revisions are correctly stored, so there is no actual data loss.

    Proposed resolution

    Keep track of the entity revision at the moment the form is built and verify the latest revision matches it when saving the entity via a dedicated constraint validator.

    The ultimate goal for this issue is to bring consistency in the entity validation logic when it comes to pending revisions. This solution assumes sequential creation is the default intended behavior for pending revisions, at least for Content Moderation.

    Remaining tasks

    User interface changes

    None

    API changes

    Only additions

    Data model changes

    None

    Links with "@" are converted into email addresses even if there is no domain suffix present.

    $
    0
    0

    Problem/Motivation

    It is typical these days to type eg. Lean@Tieto. When the "Convert URLs into links" option is enabled in the filter settings, the link gets converted into an email address even though it is not a complete email address(without ".com" present in them) .

    Proposed resolution

    Require email address patterns to have at least one subdomain, since emails are usually with subdomain. This allows for the conventional discussion forms like 'working@home today'. Patches available.

    Remaining tasks

    Patch for both D8 & D7 available.

    User interface changes

    None

    API changes

    None

    Remove QuickEdit from the test formatter annotation and test image formatter.

    $
    0
    0

    Problem/Motivation

    #3228634: Move tests for integrations between QuickEdit and other modules into QuickEdit so that it can more easily be moved into contrib moved all known QuickEdit integration tests into the QuickEdit module, but we missed some methods:

    - Remove quickedit annotation from test formatter plugin TestTextTrimmedFormatter.php (Relevant commit message, exhibit A)

    - Remove quickedit annotation from test formatter plugin DummyImageFormatter: (Relevant commit message, exhibit B)

    Proposed resolution

    Alter the test to decouple it from QuickEdit.

    AKA: Steal the commits made by @dww in the parent issue.

    Remaining tasks

    TBD

    Indirect modification of overloaded element with Views responsive table

    $
    0
    0

    Problem/Motivation

    When you enable priorities in the Views UI under Table settings, it begins to trigger PHP warnings, along the lines of:

    Notice: Indirect modification of overloaded element of Drupal\Core\Template\Attribute has no effect in template_preprocess_views_view_table() (line 555 of core/modules/views/views.theme.inc).
    

    Proposed resolution

    Merge into an attribute object.

    Remaining tasks

    • Add test coverage

    ConnectionUnitTest should be skipped for any database not psql or mysql

    $
    0
    0

    Problem/Motivation

    In Drupal 8, Drupal\KernelTests\Core\Database\ConnectionUnitTest was skipped for all database other than mysql. In drupal 9, the test was expanded to be able to be run on psql, but the condition was now to only skip for sqlite. A more universal approach would be to skip for any non-mysql and non-psql database.

    Steps to reproduce

    Run this test on sqlsrv database. it was skipped in D8, but throws exceptions on D9.

    Proposed resolution

    change:

    if ($this->connection->databaseType() == 'sqlite') {
          $this->markTestSkipped("This tests can not run with an SQLite database.");
        }
    

    To

    $database_type = $this->connection->databaseType();
    if ($database_type != 'mysql'&& $database_type != 'pgsql') {
          $this->markTestSkipped("This tests only runs on MySQL and PostgreSQL");
        }
    

    Remaining tasks

    User interface changes

    API changes

    Data model changes

    Release notes snippet

    Can't Not Insert Selected Media

    $
    0
    0

    Problem/Motivation

    We can not add media in the body using the CKeditor media button. When the popup comes up, we can select a media to insert, but then when we hit insert selected nothing happens.

    The only way this works is if we upload a new file right on the popup and click insert. But any existing media be that images, video, or files else can not be inserted.

    What can be wrong? This issue has persisted even as we have updated through different drupal versions. Currently, we are on the latest D8 release.

    Uncaught Drupal.AjaxError with empty response text

    $
    0
    0

    There is uncaught error with empty responsetext in modal popup window with response 200

    ajax.js?v=8.6.15:500 Uncaught Drupal.AjaxError {message: "↵An AJAX HTTP error occurred.↵HTTP Result Code: 20…form/↵StatusText: OK↵ResponseText: ", name: "AjaxError"}


    [meta] Ensure compatibility of Drupal 9 with PHP 8.1 (as it evolves)

    $
    0
    0

    Problem/Motivation

    Make sure Drupal 9 keeps being compatible with PHP 8.1. Work with dependencies as needed. See #3109885: [meta] Ensure compatibility of Drupal 9 with PHP 8.0 (as it evolves) for how we did it with PHP 8.0. PHP 8.1-alpha1 is now released, see https://www.php.net/archive/2021.php#2021-06-10-1

    Proposed resolution

    Figure out what breaks. Itemize and resolve one by one.

    1. Dependency updates to support PHP 8

    To produce a list of dependencies that are blocking PHP 8.1 support, you can do the following. Make sure you use PHP 8 to run it.

    $ git clone --branch 9.3.x https://git.drupalcode.org/project/drupal.git whynotphp81
    $ cd whynotphp81/
    $ composer install
    $ composer update
    $ composer why-not php 8.1

    This returns:

    laminas/laminas-diactoros  2.6.0   requires  php (^7.3 || ~8.0.0)
    laminas/laminas-escaper    2.8.0   requires  php (^7.3 || ~8.0.0)
    laminas/laminas-feed       2.14.1  requires  php (^7.3 || ~8.0.0)
    phpspec/prophecy           1.13.0  requires  php (^7.2 || ~8.0, <8.1)
    

    List of upstream updates in progress

    List of upstream dependencies that are likely to lack PHP 8.1 support

    Upstream fixes that are merged but need a release:

    Released but waiting composer update:
    None

    DONE

    2. Internal Drupal issues

    List of issues
    Still need to split out tasks from this merge request into separate issues.

    • #3230801

    DONE

    Release notes snippet

    TBD

    Write tour integration for People page

    EntityBase::getTypedData() does not return the correct data type for configuration entities due to lack of consideration for data type derivatives

    $
    0
    0

    Problem/Motivation

    Currently, \Drupal\Core\Entity\EntityBase::getTypedData() does not consider the derivatives generated by \Drupal\Core\Entity\Plugin\DataType\Deriver\EntityDeriver. Instead, an EntityAdapter is returned for all entities (e.g., instead of a ConfigEntityAdapter for configuration entities).

    Proposed resolution

    EntityBase::getTypedData() should be updated to consider all entity data type derivatives - not only for entity types, but also entity type bundles (e.g., entity:node and entity:node:article).

    Doing so will cause the correct typed data object to be returned by EntityBase::getTypedData().

    Remaining tasks

    RTBC & commit

    Uninstalled custom theme stuck in config blocking config import

    $
    0
    0

    Problem/Motivation

    During an attempted drush cim, I get the following error messages:

    array_keys() expects parameter 1 to be array, null given ConfigImportSubscriber.php:173 [warning]
    Invalid argument supplied for foreach() ConfigImportSubscriber.php:173

    and

    exception 'InvalidArgumentException' with message 'Unknown theme: w2w.' in [error]
    /Users/rppowell/Sites/women2women/core/lib/Drupal/Core/Extension/ThemeInstaller.php:220

    This theme has been uninstalled but it looks like it has gotten stuck in config. I have tried different strategies to find the corrupt data but so far no luck. Here are some suggestions from people in slack channel and various pages which I have tried.

    • Confirmed theme was uninstalled
    • Searched config files for dependencies to the theme
      • Ran queries to check database
      • select * from key_value where collection = 'state' and name = 'system.theme.files';
      • select name from config where name like ('%theme%');

    Using xdebug I have determined that these lines are what are retrieving the corrupt data.

    ConfigImportSubscriber.php#171

    $uninstalls = $config_importer->getExtensionChangelist('theme', 'uninstall');
    

    ThemeInstaller.php#214

    public function uninstall(array $theme_list) {
    

    I cannot determine what calls uninstall but it is after the batch kicks off. Just to clarify, if I do a drush cex w2w is listed under themes. If I try to delete that record and drush cim I will get this error. I would love it if someone could clarify how $config_importer is getting the theme name.

    Unfortunately, I am at the point where I don't know how else to troubleshoot this and am starting to get really opinionated about why I don't think a deleted theme should break CIM. I will supply a patch on whatever work-around I commit to but really hoping to learn how to fix this the right way.

    Proposed resolution

    Two solutions:

    1. In ConfigImportSubscriber, check if key exist before foreach
    2. In ThemeInstaller.php, if the key is the known bad theme, return

    Remaining tasks

    User interface changes

    API changes

    Data model changes

    [ignore] Patch Testing Only

    Viewing all 305842 articles
    Browse latest View live


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