Een hart voor de Drupal Community

Dependency on custom_field removed, by explicitly checking if the module is enabled.

FYI: At this point in time I would suggest to include the https://www.drupal.org/project/role_delegation into Drupal CMS, rather than https://www.drupal.org/project/roleassign, given that the former is more actively maintained, and has a wider install base.

This only if there is a need to include anything at all, as per phenaproxima's comment above.

I encountered the same problem recently. Not sure where this got broken, because it seemed to work before. I can confirm the fix by bisonblue resolves the issue. MR is against 1.2.x, but this should also be fixed in 1.1.x

Tried testing the MR, but the changes to the modules/ai_translate/src/FieldTextExtractorInterface.php break contrib FieldTextExtractor plugin implementations, such as in "ai_translate_lb_asymmetric" or "custom_field" module that I'm using. There is no way we can make this work without breaking backwards compatibility?

I think it depends on how you see the sidebar vs the topbar.

Since the sidebar holds the logo I personally feel it should always be 100% height and the header shouldn't overlap it or push it down because the logo wouldn't be in the lefthand top corner in this case which feels visually weird.

I think a plugin system for detecting the current environment would be really helpful. While a lot of people would opt to use URL matching to discover the current environment, I can see other methods being used: - a config override in settings.php - a setting in \Drupal::state() - a system environment variable (retrieved via getenv()) - e.g. set by a CI script targetting a specific environment - ...

Hi @a8w4,

I'm afraid I'm still not able to reproduce this ☹️ I followed these steps: - `composer create-project drupal/recommended-project:10.4.6 sandbox-10` - `ddev config && ddev start` - `ddev composer require drush/drush drupal/msqrole && ddev drush pm:enable msqrole` - `ddev drush pmu msqrole`

I also tried installing and uninstalling via the UI, it seems to always have worked.

Could it be possible there was just some corrupt caching or config in your project at the time? If there's any more clues as to how this could be recreated, I'm happy to look further!

Randal added a comment on drupal.org: Problems when uninstalling the module

Together with the patch to default_content mentioned above, this MR allows custom_field data to be exported by default_content, and imported by default_content import OR core's DefaultContent API, used by recipes.

Attached is a patch file for the current state of the MR, useful for Composer based patching workflows.

A patch has been added to default_content module, to make sure the Default Content exported YML files use the UUID identifiers of referenced entities within a custom_field field, rather than their (numeric) entity ID. The patch can be found at #3532596: Add support for custom_field module

Sven Decabooter added a comment on drupal.org: Add support for custom_field module

On the import side of things, there is a patch for custom_field that makes this work: #3528586: Support Drupal core DefaultContent API.

Created an MR that updates custom_field data in the Default Content export for referenced entities.

Original output without this MR:

field_my_custom_field:
    -
      label: 'Exported label'
      image: 21 # Some random file ID
      image__width: 1024
      image__height: 1024
      image__alt: Sunset
      image__title: ''
      file: 22 # Some random file ID
      term: 4 # Some random taxonomy term ID

After applying this MR. this becomes:

  field_my_custom_field:
    -
      label: 'Exported label'
      image: aa6340f0-0006-4f31-9f2d-5595f5cce028
      image__width: 1024
      image__height: 1024
      image__alt: Sunset
      image__title: ''
      file: c36ea199-cd17-4fe5-bec7-beef1ffb51b4
      term: 78ae1ee7-f2d4-4fc0-871e-1af92730df3b

The referenced UUIDs also get added as a dependency to the "_meta" definition.

svendecabooter created an issue. See original summary.

Problem/Motivation

Add support for the custom_field module, so entities using that field can be exported and imported using Default Content (or Drupal core recipe importer).

Export functionality for most custom_field data types are working out of the box, but the ones referencing entities will export the entity target IDs, rather than UUIDs used by the importer.

Steps to reproduce

- Install Default Content & custom_field - Set up a custom_field field, containing (amongst others) an image field or entity reference field. - Try export / import functionality.

Proposed resolution

- Add support for custom_field entity references in the Normalizer class.

Sven Decabooter added a comment on drupal.org: sourceEditing plugin no longer gets enabled automatically in 1.1.x - followup

Problem/Motivation

This is a followup to #3527899: sourceEditing plugin no longer gets enabled automatically in 1.1.x. Not sure if I missed this previously, or the code has changed in the meantime, but the sourceEditing CKEditor plugin gets enabled for the "Completion" AI CKEditor plugin, but is still throwing errors for other plugins, e.g. Spellfix.

Steps to reproduce

- Same as in #3527899: sourceEditing plugin no longer gets enabled automatically in 1.1.x, but use Spellfix instead of Completion

Proposed resolution

- Fix this by enabling the sourceEditing CKEditor for the "response_text" form element in the AiCKEditorPluginBase class.

svendecabooter created an issue. See original summary.

Can you try if the patch in #3531983: Set block entity values via FieldTextExtractor plugins resolves this issue for you?

A better fix for this issue is implemented in #3531983: Set block entity values via FieldTextExtractor plugins

Tested with the changed that got committed into the ai_translate module. Everything seems to work now!

Hi @a8w4,

Thanks for your report! I'm unable to reproduce this issue though, would it be possible to share the exact steps / paths where this issue occurs? As well as let me know if it's reproduceable on a clean D11?

Thanks in advance!

The suggestion indeed also fixes the problem and seems to me that this is a better solution (delete one line of CSS instead of adding one line of CSS).

Please review!

Fons added a comment on drupal.org: Admin toolbar height is not 100% since upgrading to Drupal 11.2

MR added for this functionality. Also attaching as a patch file, for Composer based patching workflows.

Problem/Motivation

Currently there is logic in LbAsymmetricExtractor that, for each cloned Layout Builder block, loops over the translated data, and sets the values for all fields on the cloned block, via the default Field API ->set() method.

However, a more robust solution would be to use the appropriate FieldTextExtractor plugin for each of the fields to set their value, given their original data was extracted using this plugin, so it would make sense to have the value also being set by the same plugin. This allows each plugin to take care of their own special cases.

This would for example add support for the custom_field module, where a Layout Builder block could contain a custom_field field. The FieldTextExtractor plugin for custom_field (being worked on in #3529794: Add support for AI submodule "ai_translate" FieldTextExtractor plugin would then take care of setting the current values.

svendecabooter created an issue. See original summary.

Seems related to #3529669: Handle link field translation as well

Thank you sir and sorry for the extra hassle. Have a great day and thank you for the new release.