Drupal CMS

svendecabooter created an issue. See original summary.

Renamed issue for clarity.

Adding a simple patch file to just restore the canonical link, to fix this issue via Composer patching workflow (only recommended for websites not using the flattened site settings loader obviously), while awaiting a more robust solution in the next release.

I have added a new MR now, to attempt to fix this issue. In the first commit, I just restore the canonical link for SiteSettingEntity.

In the second commit, I add a configuration setting to not render the site entity on its canonical link, but its edit form instead. I have added an option in the config form to disable this.

I'm not really sure why site settings shouldn't have a canonical view actually... When you use the revision system of that entity (by deselecting the config option "Hide the administrative advanced options"), it would make sense that you can view the latest revision of the entity + earlier revisions, for comparison. They are only viewable for people with the "view published site setting entities" or "view unpublished site setting entities" permissions...

I'm not sure what the exact issue with the flattened site settings loader is exactly, that causes an infinite loop, but there might be another way to fix that, rather than messing too much with the default Drupal entity link templates...

Can someone check if my solution that renders the edit form instead, fixes the flattened site settings loader issue? And could use some extra thoughts on whether the edit form rendering is a good idea to begin with...

We are encountering similar issues. Site settings entities are no longer translatable after #3522947: Remove the canonical route of the site setting entity type has been committed.

The translatability of an entity is checked by \Drupal\content_translation\ContentTranslationManager::isSupported(). This checks if there is a link template "drupal:content-translation-overview".

Looking into where this template is defined - \Drupal\content_translation\Hook\ContentTranslationHooks::entityTypeAlter, we see it is only defined after the following logical check: if ($entity_type->hasLinkTemplate('canonical')) {}

Which is now no longer the case.

I think the safest solution would be to restore the canonical route, and perhaps just load the entity "edit" form for that route?

I think, usually when removing the canonical route, it's not "actually removed" but instead redirects or links to the edit link template? I feel like that should solve the initial issue along with this issue. The canonical "route" remains, but it's not an actual route and just sends you to the edit page.

Tested this update, and it works well with #3531717: Add text extractor plugins for image, file, text_with_summary and link field types.

Tested exporting and importing with this MR checked out, together with the MR in default_content (https://www.drupal.org/project/default_content/issues/3532596)

I was able to export and import all custom_field data, including entity references (tested with Media and Taxonomy term) + custom_field file and image properties.

Everything worked as expected.

@apmsooner

I have tested with the following setup:

- Drupal 10.5.1 - AI module with this MR branch checked out - Core patch applied: https://www.drupal.org/project/drupal/issues/3386915#comment-16174131 - Configured core content_translation and language modules. - Enabled AI Translate module + set up "Entity reference translation" settings to include Content block / File / Content / Paragraph / Taxonomy term - max reference depth set to 5. - Created content type with a bunch of fields (plain text, body, image, term reference) + Paragraphs module entity reference (paragraph had same type of fields added: plain text, body, image, term reference). - Created a 2nd content type with a bunch of fields (plain text, body, image, term reference) + enabled Layout Builder. Created a block type with plain text field, body field, image field, term reference field

I encountered 2 issues: - "Warning: Undefined array key 0" PHP warning - although functionality kept working. Fixed now - Symmetric layout builder translation didn't work fully yet (since it was untested as stated above). Added fix for that as well now.

I'm unsure how to reproduce your behaviour that translation doesn't work at all. Maybe there is some specific configuration that is interfering, since it requires a bit of setup to get all pieces in place... Perhaps you can share a config export of your installation via Slack, so I can try to reproduce the unwanted behavior.

I have tested now with 2 different setups (D10.5 with Paragraphs & symmetric LB + D11.2 with asymmetric LB + custom_field) and can get everything translated as expected...

Sven Decabooter added a comment on drupal.org: Add Set fetcher method

Sven Decabooter added a comment on drupal.org: Add Fetcher support for more then objects

Sven Decabooter added a comment on drupal.org: Document module API

Sven Decabooter added a comment on drupal.org: collectiveaccess_feeds_fetch_all_total doesn't work

Done

Sven Decabooter added a comment on drupal.org: Port Feeds mappers from D6 to D7

Sven Decabooter added a comment on drupal.org: AES encrypted passwords don't work with Features

Sven Decabooter added a comment on drupal.org: Document module API

Sven Decabooter added a comment on drupal.org: Collective access

Sven Decabooter added a comment on drupal.org: Mark CollectiveAccess Project as Unsupported

Can this perhaps be added as a merge request? That would make it easier for reviewing...

Agreed, these can all be disabled. Specific websites can reactivate them via config_split if needed, but I don't see a particular reason for that currently.

It's a lot of config changes, but they seem sensible to me as a basis for the different sites, which can use config_split to update configuration specifically for their instance.

Here's a patch that applies the change that works for us.

Hi,

Thanks for the issue, it already got us closer to a solution as well. However, I notice a small issue in the `commerce_checkout.schema.yml` file.

commerce_checkout_pane_configuration:
  type: mapping
  mapping:
    display_label:
      type: string
      label: 'Display label'
      translatable: true
    step:
      type: string
      label: 'Step'
    weight:
      type: integer
      label: 'Weight'
    wrapper_element:
      type: string
      label: 'Wrapper element'

I *think* the `display_label`'s type should be "label" rather than string. Currently, the display label is editable in the UI but not translatable. Not every plugin provides a display label from its attribute/annotation, and since it is editable in the UI it should also be translatable in the UI.

I'm not sure if the combination of `type: string` with `translatable: true` does anything, though? I checked the "config schema cheat sheet" PDF file and couldn't find anything.

FYI: I have not tested the latest version of the MR yet with a regular Layout Builder setup (without layout_builder_at module installed).

Based on feedback above, I have also incorporated the logic of the ai_translate_lb_asymmetric module into the LbFieldExtractor. This provides a single FieldTextExtractor for the Layout Builder field type, reducing conflicts between modules / plugins. Based on the selected Layout Builder strategy for a given installation, it takes care of the proper AI translation.

This eliminates the use of the separate ai_translate_lb_asymmetric module. When this improvement gets committed, it seems fair to credit author(s) of that module as well.

Thanks for your work on this refactor / improvement @apmsooner. I've been testing it out, and it works very well.

Tested with simple fields on a node, with a custom_field setup (with mentioned custom_field branch checkout), and a complex entity reference setup multiple levels deep.

I have added an additional commit for ReferenceFieldExtractor, that implements the logic I described in the MR comments. It removes the needs for translatable_properties annotations, since it infers whether they are translatable or not, from the relevant (recursive) FieldTextExtractor plugin that gets called for that field.

Tested the same scenario's as described above after this change, and functionality kept working. Let me know if you think this isn't a correct approach, then the commit can be reverted in the MR I guess.

I tried applying MR 103 on a Drupal 11.2 website, but am getting the following errors when setting up a current environment:

Drupal\Core\Render\Component\Exception\InvalidComponentException: [navigation:toolbar-button/icon] String value found, but an object is required. The provided value is: "development". in Drupal\Core\Theme\Component\ComponentValidator->validateProps() (line 234 of /var/www/html/web/core/lib/Drupal/Core/Theme/Component/ComponentValidator.php)
#0 /var/www/html/web/core/lib/Drupal/Core/Template/ComponentsTwigExtension.php(124): Drupal\Core\Theme\Component\ComponentValidator->validateProps()
#1 /var/www/html/web/core/lib/Drupal/Core/Template/ComponentsTwigExtension.php(106): Drupal\Core\Template\ComponentsTwigExtension->doValidateProps()
#2 /var/www/html/vendor/twig/twig/src/Environment.php(420) : eval()'d code(48): Drupal\Core\Template\ComponentsTwigExtension->validateProps()
#3 /var/www/html/vendor/twig/twig/src/Template.php(402): __TwigTemplate_644fe1f4d3b3cc70a78b679130cdd653->doDisplay()
#4 /var/www/html/vendor/twig/twig/src/Environment.php(420) : eval()'d code(136): Twig\Template->yield()
#5 /var/www/html/vendor/twig/twig/src/Template.php(402): __TwigTemplate_4bb116eb700f12a2c42b5883d177516f->doDisplay()
#6 /var/www/html/vendor/twig/twig/src/Template.php(358): Twig\Template->yield()
#7 /var/www/html/vendor/twig/twig/src/Template.php(373): Twig\Template->display()
#8 /var/www/html/vendor/twig/twig/src/TemplateWrapper.php(51): Twig\Template->render()
#9 /var/www/html/web/core/themes/engines/twig/twig.engine(34): Twig\TemplateWrapper->render()
#10 /var/www/html/web/core/lib/Drupal/Core/Theme/ThemeManager.php(380): twig_render_template()

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...