Drupal CMS

Then I can’t think of a case where you need to calc the height dynamically where it’s not 100% of the height for the sidebar.

This change might need a warning that it depends on ai 1.2.x, and including it into custom_field might need to be timed together with the first (stable?) release in that branch... I don't suppose it would be possible to both support 1.1.x-style FieldTextExtractor plugins, as well as 1.2.x-style...

@apmsooner:

Yeah I reckoned the module would need to be updated. Was just checking if there might be ways for backwards compatibility that I didn't think about. If this refactor goes into 1.2.x branch, I guess modules that extend this functionality, would need to create a separate branch for AI 1.2.x compatibility. There is also https://www.drupal.org/project/ai_translate_paragraph_asymetric that provides a similar plugin.

The custom FieldTextExtractor plugins for the assymetric modules could probably also be included into the ai_translate module, rather than a separate module, but then the FieldTextExtractor plugin might need some extra logic to decide whether the plugin needs to kick in or not. E.g.: - for asymmetric LB translation --> check if layout_builder_at module is enabled - for asymmetric Paragraphs translation --> check if paragraphs_asymmetric_translation_widgets module is enabled Or could that logic go into shouldExtract()? Guess not, since that's more about logic on field level, than general condition checking... Now this logic is enforced by those separate ai_translate_* modules having the dependencies set in their info.yml file. If they got included in ai_translate itself, they might be activated where they shouldn't (i.e. if translation logic is symmetric instead)

Sven Decabooter added a comment on drupal.org: Add schema validation

@eelkeblok: I have merged issue #3519842: Support OOP hooks, so this functionality could be implemented with OOP hooks in mind. Haven't reviewed the code yet, but described functionality looks promising :)

Remaining issues have been resolved, and this has been added to 1.0.x branch. @eelkeblok would be good if you could rebase your MR branch on 1.0.x and also add support for OOP hooks. Sorry for the extra work.

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.

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.

svendecabooter created an issue. See original summary.

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!