🇸🇪Sweden @peter törnstrand

@alex.bukach if you want help with maintenance/development time for this module I'm willing to become co-maintainer.

Ok, here goes. Documentation for five hooks added to migrate.api.php. Documentation for migrate plugin manager updated to reflect actual possible values for parameter $type.

Also, the migrate plugin manager ( MigratePluginManager ) mentions the types row and field_entity in the constructor documentation. But I don’t think these are actual plugins?

I’m having a hard time coming up with relevant example implementations for these hooks.

My guess is that is why they are not documented. I can’t think of anything you would like to alter in these plugins that is not better suited for a custom implementation in a custom module.

I added some very basic examples now. Basically adding a new plugin, changing the implementing class and unset of a plugin.

Merge request coming later today.

Issue summary updated and test created.

I did a quick scan of the migrate source and as stated in the issue summary documentation for these hooks are missing:

• migrate_destination_info_alter()
• migrate_source_info_alter()
• migrate_process_info_alter()
• migrate_id_map_info_alter()

The migration plugin manager has it's hook documented in hook_migration_plugins_alter() as stated in the summary.

I will document these.

Will be released in 1.0.14.

peter törnstrand → created an issue. See original summary → .

Merge request !3 also incorporates the changes from ✨ No availability to send json response for specific .wellk-nown items. Active . I forked the issue branch from https://git.drupalcode.org/issue/wellknown-3488996/-/tree/3488996-no-ava... as it already contained code for exposing a Response type setting for a path.

peter törnstrand → created an issue.

peter törnstrand → created an issue.

This has changed in core 11.x. Term entities no longer have this problem. Group and media entities still does though.

The way to handle this is to specify a translation handler in the entity type:

#[ContentEntityType(
  id: 'taxonomy_term',
  ...
  handlers: [
    'storage' => TermStorage::class,
    ...
    'translation' => TermTranslationHandler::class,
  ],
  ...
)]

See Drupal\node\NodeTranslationHandler and Drupal\taxonomy\TermTranslationHandler.

I'm closing this as works as designed as there is a solution for this available for contrib and a separate issue for component "media sytem". See related issues.

I did some digging and the way this is handled for node bundles in core is that a dependencies key is added to the permissions array declaring the dependency on the node bundle like this:

dependencies:
  config:
    - node.type.article

The dependencies key is added via trait Drupal\Core\Entity\BundlePermissionHandlerTrait which in turn calls these methods:

Drupal\Core\Entity\EntityInterface::getConfigDependencyKey() // returns 'config' for a node bundle
Drupal\Core\Entity\EntityInterface::getConfigDependencyName() // returns 'node.type.<BUNDLE>' for a node bundle

So I guess the correct way to solve this issue is to add the dependencies key to the permissions array.

I'm attaching a patch for the Test delete field module just to make it clear what I mean.

Using the instructions from the test module. If you add field.field.node.article.field_stillthere as a config dependency in the role you at least get a warning when you delete the file.

Wish I had found that test before. Was a minor fix adding a test for this scenario. Well, I learned something at least.

Yes. That is probably true. I will have a look at the test you mentioned.

Yeah, I tried having the input/output directly in the test case but it was completely unreadable. Concatenated strings with lots of PHP_EOL. It was difficult to spot and fix errors caused by formatting.

I'm using a data provider but the provider reads the input/output from the fixture files.

Regarding the function _filter_autop() in a separate file; that was just something i noticed in the System module.

Should I move the input/output into the test case again?

And perhaps I should go with @berdir's input and move the _filter_autop() to the FilterAutoP plugin and deprecate the global function?

From @berdir in #contribute slack channel

we want to move all functions to classes anyway. with underscored ones, it's a bit unclear if we want to provide BC or not, but you could play it safe and add a deprecated message. and then depending on where it is used, move it to the class, or a trait or static method.

My gut feeling was to put _filter_autop() in the Drupal\filter\Plugin\Filter\FilterAutoP class .. perhaps directly in the ::process() method.

And then just add a deprecation note on _filter_autop() in filter.module:

@deprecated in drupal:11.x.x and is removed from drupal:12.x.x. Use Drupal\filter\Plugin\FilterAutoP::process() instead.

So this was a bit more complex than I imagined as the test requires a call to the global function _filter_autop(). I looked at the documentation at https://www.drupal.org/docs/automated-testing/phpunit-in-drupal/unit-tes... → but I am not sure I got this right. I tried looking at how this is solved in other core modules and found what I believe is relevant examples in system/tests/fixtures.

I also posted in the Drupal Slack channel #contribute but have not gotten any answers yet.

I did however have lots of fun doing this.

Reproducing the problem by following the steps outlined I can also see the node label in the content overview view (/admin/content) although the label is not linked to the node.

The only entity that defines a "view label" permission is Taxonomy with the "view vocabulary labels" permission. Do you propose we introduce a new "view node labels" permission? Should there also be "view block labels", "view user labels"?

As anonymous user I can see the "label" of a user.

I was not able to reproduce this error using latest core 11.x (11.3-dev) and a browser (Web 48.4 - The GNOME project, webkit based) configured with the preferred language English (United Kingdom). The language chosen during installation was English, British.

The translation file drupal-11.3-dev.en-gb.po was downloaded to sites/default/files/translations directory and imported during site installation.

One translation file imported. 829 translations were added, 0 translations were updated and 0 translations were removed.

I could not reproduce this error with latest core 11.x and using the following browser:

• Firefox 141.0.3 (Linux)
• Web (The GNOME project) 48.4
• Chromium 139.0.7258.138 (Linux)

To remove the default value of the timestamp field I could just uncheck the Set default value checkbox.

I'm working on writing a test for this.

Sorry, forgot MR. Will have a look at creating a test. Question, can I include the test in the same MR?

Suggestion:

@param array|string $base
  A list or a single base_table, for example 'node'. Pass '#global' to
  return the global Views handlers for the requested $type.

peter törnstrand → made their first commit to this issue’s fork.

Was able to reproduce this with core 11.2.3. Fix attached.

Markup after fix applied:

<ul>
<li>Here is a list Item.</li>
<li><p>Here is another list item, this time containing a line break which is converted by the filter to a br tag.<br />
This is some more text followed by two line breaks, which the filter converts to a p tag.</p>
<p>And now some more text.</p></li>
</ul>

peter törnstrand → made their first commit to this issue’s fork.

This is now implemented.

Fixed, thank you for reporting this error!

Released in version 2.1.1.

Thanks. Will have a look and create new release ASAP.

peter törnstrand → changed the visibility of the branch 3526923-tests to active.

peter törnstrand → changed the visibility of the branch 3526923-tests to hidden.

peter törnstrand → changed the visibility of the branch 3526923-tests to hidden.

peter törnstrand → created an issue.

Also look into how we can prevent <span class="claro-details__summary-summary"></span> from being injected into our tree widget.

Also have a look at these:

• https://www.digitala11y.com/aria-activedescendant-properties/
• https://www.digitala11y.com/aria-disabled-state/
• https://www.digitala11y.com/aria-expanded-state/
• https://www.digitala11y.com/aria-labelledby-properties/

peter törnstrand → created an issue. See original summary → .

This was fixed in ✨ Compability with other modules modifying the node form Active

Also, the changes in 📌 Disable menu_ui hook implementation Active messes with this.

Se for example 🐛 Missing schema definition for third party entity_browser_block_layout_view_modes setting Fixed for solution

Yes, using $this->moduleHandler->invokeAll('form_node_form_alter', [&$form, &$form_state]); does result in an infinite loop.

peter törnstrand → created an issue.

peter törnstrand → created an issue.

Works like expected. Thanks! Released in 1.0.3.

I think we will leave the UI as is for now. If any great ideas turn up in the future we can create a new issue.

This is being worked on in the same branch as ✨ Drag and drop positioning of new menu item Active ... had a little to many issues going on at once.

peter törnstrand → created an issue.

@jdewit since you have been very active in this modules issue queue perhaps you would like to review this?

I'm not sure how we can improve on the UI for multiple menus. With ✨ Drag and drop positioning of new menu item Active it should be easy to drag an menu item across multiple menus and that would make putting the menus in different tabs for example not work very well.

Ok, this was fixed in 📌 Drupal standarts of JS (Jquery) Active which has not been included in any new release. I will create a new release right away.

I think I have fixed this in branch 3526919-drag-and-drop already. Will backport that fix ASAP.

Made some progress on this in branch 3526919-drag-and-drop ... ran into trouble when calculating a weight for a new item between two existing items with weights having "no room in between".

How do I set a weight between weights -48 and -47?

Released in 2.0.1.

This sounds very resonable. Will have a look.

peter törnstrand → created an issue.

peter törnstrand → created an issue.

peter törnstrand → created an issue.