Bij make it fly geloven we sterk in Drupal en Open Source software in het algemeen. We maken dagelijks gebruik van vele open source componenten en de vele Drupal modules die beschikbaar zijn. We dragen actief ons steentje bij aan de community door zelf patches, modules en documentatie te voorzien, daarnaast zijn enkele teamleden ook actief in de Drupal User Group vzw.
Een overzicht van onze bijdragen aan de Drupal community vind je terug op onze Drupal.org pagina. Naast het actief meerwerken aan de Drupal community, zetten we ook andere ontwikkelaars op weg door vragen te beantwoorden op Drupal Answers.
The current workflow with the upstream la_eu repository, as well as our Dropsolid hosting-specific repository is a bit difficult to follow, at least in my head. So we should document the current state, to make sure everyone can understand how it's set up.
When the option "Automatically show Groups in the admin menu" is selected, a menu item is added for each Group, linking to the Site Settings entity listing, with the "Group" exposed filter prefilled.
The prefilled value is the Group ID, but the produces an error when clicked:
Example:
When the group name is used in the URL, instead of the ID, this works again:
/admin/content/site-settings?group=Company+information
Followup from issue #3541876: Allow collapsing / expanding of multivalue items:
Furthermore it would be nice if we could optionally select a (text) property of the custom_field field that functions as the details label, instead of Item (1), Item (2), etc...
- In the form widget settings, add an optional setting to select the property whose value should be used as the details wrapper label - This setting is only shown when the "Details" wrapper is selected - The setting shows a select list of properties available on that custom_field field - probably only string values should be in that list - If selected, some Javascript code should be added to the widget form, which copies the text from the selected property and uses it as details label. When the text of the selected property changes in the form, the details label should be updated. The text should probably be sanitized and have a maximum length set (if too long, append "..." at the end?)
Glad to read the fix works!
No idea why the test in the MR failed.
Thanks for the patch.
Oops, like we cross posted.
Also fixed it here:
https://www.drupal.org/project/webform/issues/3556348
I just upgraded to Drupal 11.2.6 and I get the following errog:
Fatal error: Declaration of Drupal\webform\EntityStorage\WebformEntityStorageTrait::__get($name) must be compatible with Drupal\Core\Entity\ContentEntityStorageBase::__get(string $name): mixed
Had to shuffle some code around to make it reusable
Aside from having the bulk update form, we needed a Drush script for a customer.
bceyssens created an issue. See original summary.
The HTMX Extras module adds some lazy loading functionality to your website.
Currently, these elements are implemented:
More functionality will be added once the need arises, feel free to create a ticket if you have a use case that could fall under this module's scope.
For replacing Drupal's AJAX API with HTMX, we gladly refer to the excellent HTMX-project
I have it running on 3 websites in production and all is well (it's also a minor change) so I've changed the status to reviewed & tested.
Would love to get this change in so I can get rid of the patches.
Thanks in advance!
I tested the upcoming 11.3 functionality to export Drupal content to a directory. This with the purpose the import it again on other websites through recipes.
While #3532951: Support exporting content and its dependencies to a folder structure on disk and https://www.drupal.org/project/default_content/issues/3160146#comment-16... seem to imply that Layout Builder content export will be possible, this seems to be only half the case.
When I create a Layout Builder section that contains an inline block component, I would expect the block_content entity to be exported as well.
For this to work previously with the Default Content contrib module, I needed to apply several patches, including https://www.drupal.org/project/default_content/issues/3160146. I assume the logic in that patch was not moved over to the Drupal core default content system yet.
Since Layout Builder, inline blocks and default content export are all in core, it seems less acceptable to me that this wouldn't work out of the box.
- Install Layout Builder and activate it for a content type
- Create a new block type containing a field
- Configure Layout Builder to allow adding that block type to a LB section on a test node
- Export the test node (through php core/scripts/drupal content:export node [NID] --dir=../test_default_content --with-dependencies)
Example simple node with an inline LB block:
After exporting, I get the following file: test_default_content/node/4f651b20-2513-4a64-889d-1aa0e721f75b.yml
_meta:
version: '1.0'
entity_type: node
uuid: 4f651b20-2513-4a64-889d-1aa0e721f75b
bundle: page
default_langcode: nl
default:
revision_uid:
-
target_id: 1
status:
-
value: true
uid:
-
target_id: 1
title:
-
value: 'Test page with an inline layout builder block'
created:
-
value: 1760792440
promote:
-
value: false
sticky:
-
value: false
path:
-
alias: /test-page-inline-layout-builder-block
langcode: nl
content_translation_source:
-
value: und
content_translation_outdated:
-
value: false
layout_builder__layout:
-
section:
layout_id: layout_onecol
layout_settings:
label: ''
components:
558dca26-6728-4bb6-97e5-587cced0f198:
uuid: 558dca26-6728-4bb6-97e5-587cced0f198
region: content
configuration:
id: 'inline_block:test_block_type'
label: 'Test block type'
label_display: false
provider: layout_builder
view_mode: full
block_id: '18'
block_revision_id: '18'
block_serialized: null
context_mapping: { }
weight: 0
additional: { }
third_party_settings: { }
Note that the text "This text should be exported" is nowhere to be found.
This would have to added to a test_default_content/block_content/558dca26-6728-4bb6-97e5-587cced0f198.yml file....
@loparev closing this one as well. I'll reopen or create a new ticket when needed.
Reapplied patch #15 to version 3.6
Apologies, the last patch missed some changes to the entity's interface.
Another possible edge case would be if one entity's field is translatable and the other isn't, then the one to many relationship should also be reworked so it updates all translations of the translatable entity rather than just the current translation.
I updated the MR to allow one-to-many translation relationships.
I can reproduce the issue you're talking about, furthermore I also run into an issue where the values are added to the default translation of the corresponding entity.
I added a merge request that fixes these issues for me locally.
It: - Retrieves the translated version of the original entity, if it exists - Retrieves the translated version of the referenced (corresponding) entity, if it exists
This should also not affect untranslated fields, if the field is untranslated and you retrieve a translation of an entity, the values will just be saved to the default translation.
I also added a static patch of the MR in its current state.
randalv made their first commit to this issue’s fork.
Thank you!
It's a minor but important change.
All the best, Fons
You can see it in action on my live site here:
https://webhaven.io/documentation/theming/theme-structure
Hi @loparev,
The code still needs an improvement for translating locale strings, it's not an entity so context can't be send to Smartling.
We receive this error in the logs:
Failed to alter contextUrl= with the following message: The "default" entity type does not exist.
Maybe just check if the entity type exists? https://git.drupalcode.org/project/tmgmt_smartling/-/blob/8.x-9.x/tmgmt_...
As a followup to #3549657: AI CKEditor: use prompt entities instead of custom configurations, I noticed the ai_ckeditor prompts are stored in global settings for the module. However, other settings (such as the selected provider) are stored in the AiCKEditor plugin settings, on a per filter_format basis.
Is there a specific reason for this? And is that reason still valid after prompts are stored as ai_prompt entities, rather than just textual prompts in config?
It might be interesting to store a reference to the selected ai_prompt entity on a per filter_format basis. That way, users can decide to provide alternative prompts, based on the filter format that is chosen.
Especially since the AI provider can also be changed per filter format, it seems logical you might want to provide a different prompt per filter format as well (e.g. to tailor it towards the selected AI provider).
@loparev, you are correct, we weren't using the new metatag_computed field. We're also looking in detail why the other fields are still there, but it should also be somewhere in our part of the configuration. I close the issue when we get this validated by our client. Thanks!
"Onze teamleden bouwen zelf ook mee aan ons geliefde Drupal, en daar zijn we trots op"