🇦🇹Austria @mvonfrie

mvonfrie → created an issue.

Sorry for the confusion with the many branches, I probably am to tired now.

• 3501869-undefined-array-key and MR !54 are for the 3.0.x development as this was the base branch suggested by the Git integration.
• 3501869-undefined-array-key-3.1.x and MR !55 are for the 3.1.x development as I've seen too late that that branch already exists.

For now I would keep both branches/MRs open as I've only fixes the occurrences reported to me and I'm not sure whether there are more.

mvonfrie → changed the visibility of the branch 3501869-undefined-array-key to active.

mvonfrie → changed the visibility of the branch 3501869-undefined-array-key_3.1.x to hidden.

mvonfrie → changed the visibility of the branch 3501869-undefined-array-key to hidden.

I have the same error and get a lot of

Warning: Undefined array key...

colors in src/Plugin/views/style/FullCalendar.php on line 302
title_field in src/Plugin/fullcalendar/type/FullCalendar.php on line 229
url_field in src/Plugin/fullcalendar/type/FullCalendar.php on line 253
date_field in src/Plugin/fullcalendar/type/FullCalendar.php on line 277
bundle_type in src/Plugin/fullcalendar/type/FullCalendar.php on line 371
createTarget in src/Plugin/fullcalendar/type/FullCalendar.php on line 403
bundle_type in src/Plugin/fullcalendar/type/FullCalendar.php on line 1477
[numeric value] in src/Plugin/fullcalendar/type/FullCalendar.php on line 1704

mvonfrie → created an issue.

My problem is that I want to use the account menu as custom menu with some added items, which includes the default items like "My account", "My profile" or "Logout". But when I assign the custom menu to the authenticated role, administrators don't have access to the admin menu anymore. Thus, another option would be to add an role exclusion list:

Use the custom menu, if the user has any of the configured roles but none of the exclusion roles, i.e.

Configured roles:
[ ] Anonymous
[x] Authenticated user
[x] Editor
[ ] Site Manager
[ ] Administrator

Exclusion roles:
[ ] Anonymous
[ ] Authenticated user
[ ] Editor
[x] Site Manager
[x] Administrator

So, every authenticated user (and editors in special) get the custom menu, except they are admins or site managers.

Any updates on this?

We have a similar use case but with nodes (articles and events). Groups are state level branches of the organization and subgroups local/city-level sub-branches. Every subgroup should have a news feed/blog with their articles and event calendar, every group should have a news feed/blog with all articles of their group and all subgroups, same for their event calendar.

mvonfrie → created an issue.

@joseph.olstad, view modes should not be affected by this if they weren't by patch #7 and #8 individually. In the MR I see two older commits merged by you starting with "Issue #3470578 and Issue #3465159" and two older commits starting with "Issue #3456918". So the branch dedicated for this issue (3465159-error-call-to) contains changes for two other issues as well. Maybe the additional test failures are related to those commits, or maybe there are incompatible changes on the main branch and the working branch 3465159-error-call-to should be rebased to incorporate those changes?

Yes, I'm referring to the date input, see attached screenshot.

Created ✨ [PP-1] Add $entity->uuid() methods to allowed methods list in Twig sandbox policy Postponed .

Should be postponed until 📌 Harden TwigSandbox methods Needs work is committed.

mvonfrie → created an issue.

Same for me, but a combination of #7 and #8 works. In addition we have to consider that the change from page_manager_page to _page_manager_page only has been introduced recently: 🐛 Path has unnecessary query appended. Fixed . I try to create a new patch by tomorrow.

Not directly related to the topic of this issue, but related:

Why is ::uuid not allowed as well for the types where ::id is allowed? At least this would make sense in relation to #1726734: Replace serial entity IDs with UUIDs in URLs, or even globally? → , ✨ Make it possible to link to an entity by UUID Active and related issues.

mvonfrie → created an issue.

It is more a problem with Webform module doing it's own mail handling and it doesn't know about symfony_mailer. So maybe it is more a problem of Webform than Symfony Mailer. But Symfony Mailer should handle this case, maybe defaulting to symfony_mailer because the core implementation of course doesn't know about Symfony Mailer.

I just got a report that it doesn't work when uploading a single media item via a media field and investigated further. Found out that the missing fields were only configured for the default form display mode but not for the media_library form display mode. Therefore closing as "works as designed".

A possible workaround is the attached patch for symfony/dependency-injection which let's the container cache the parameter definitions like %app.root% instead of the resolved parameter and therefore resolves the parameter at service resolution.

Because the result is the same for the "Group Types" condition from the group module and the for "Group Type" condition provided by ctools for all entity types, the cause must be in core and not in the group module.

Notes about issue metadata:

• I've observed the issue with Drupal 10.4.1 and selected this as version. Feel free to change it to 11.x but keep backporting to 10.4.x in mind.
• I'm not sure whether this is more related to the plugin system or the configuration system. Change the component if necessary.

mvonfrie → created an issue.

I'm having another variant of the problem. No matter whether displaying the entity browser as modal or iFrame, similar to the Content Browser → module I disable the admin theme to be able to render the displayed entities using a template and CSS from my custom theme. I've enabled Twig debug to get information which templates are used for rendering.

What I expect to be used is themes/custom/my_theme/templates/content/node--entity-browser.html.twig but what I get is core/themes/claro/templates/classy/content/node.html.twig. This means, when not using the admin theme (which in my case is Gin) not even the active frontend theme is used but Drupal's default theme (Claro).

mvonfrie → created an issue.

A customer reported that only the first of multiple images got uploaded. Environment is a shared webhosting (from netcup.de), so the workaround #8 doesn't apply as it's a single server and not a cloud environment.

This seems to be related to 🐛 Static menu link override saving double encodes configurations resulting configuration loss Needs work .

It seems that my comment #2996410-14: Review Drupal\Core\Menu\StaticMenuLinkOverrides::saveOverrides for performance improvements → belongs more to this issue which I just found after posting there. Repeating and crosslinking the issues.

When changing an override on the test system and exporting config I observe constant changes in the order of keys per overridden menu item. Especially weight and enabled always change their position between local dev and test environment.

Could this be related to the line

$all_overrides[$id] = $definition + $this->loadOverride($id);

as well?

Furthermore, in my opinion the config should only include what actually can be overridden, aka filter $expected with Drupal\Core\Menu\MenuLinkBase::$overrideAllowed (if applicable).

When changing an override on the test system and exporting config I observe constant changes in the order of keys per overridden menu item. Especially weight and enabled always change their position between local dev and test environment.

Could this be related to the line

$all_overrides[$id] = $definition + $this->loadOverride($id);

as well?

Furthermore, in my opinion the config should only include what actually can be overridden, aka filter $expected with Drupal\Core\Menu\MenuLinkBase::$overrideAllowed (if applicable).

This might be related to ✨ Dashboards should have the ability to customize path (alias) Postponed and require a meta discussion before implementation.

mvonfrie → created an issue.

For now it would seem correct that the add menu item also requires the existing manage group_content_menu permission.

This should not be the case. It should be possible that users with a specific group role can create/edit/delete group menu items but not group menus itself! See 🐛 Permission "Manage menus Create, update and delete menus" not working Active for details.

I have the same problem with 3.0.5. My customer wants to have exactly one group menu per group and only admins should be allowed to create/delete groups and their related menus, but group members with specific group roles (group admin, group content manager) should be able to create/edit/delete group menu items.

mvonfrie → created an issue.

I changed the z-index. But a Bootstrap still is widely used even in Drupal projects (see usage statistics for Bootstrap → , Barrio Bootstrap 5 Theme → , Bootstrap5 → and potentially upcoming Bootstrap Drupal CMS → themes) I would expect this to be correct out of the box.

mvonfrie → created an issue.

mvonfrie → created an issue.

Another option would be putting a clear statement in the 2.2.0 release notes that the old update hooks will be removed and one must update to 2.1.4. first. Ofc the change is listed there but in my opinion that is not prominent enough amongst the list of all changes.

I agree with @martinstadelmann, this is totally unexpected and can cause some trouble i.e. if it works locally (because you updated somewhen to 2.1.4) during active development (of customer change request etc.) and then before preparing the deployment to test/production you install al available updates, including 2.2.0. Then on the test/production system during install (possibly with a scheduled maintenance window) you do the update from like 2.1.3 to 2.2.0 in one step instead of two and it fails.

Also, @mglaman stumbled over this and wrote a blog post about it: https://mglaman.dev/blog/restrict-composer-dependency-updates-only-patch....

Patch provided in MR !551.

mvonfrie → created an issue.

@cilefen, this definitely is a CKeditor behavior. To get some context, why that happens in CKeditor5, please read https://github.com/ckeditor/ckeditor5/issues/16203.

Some support from the Drupal Core team there might be helpful.

To get some context, why that happens in CKeditor5, please read https://github.com/ckeditor/ckeditor5/issues/16203.

mvonfrie → created an issue.

MR !32 works, but this is only half of the truth. In my case the image was not corrupted but the thumbnail of a document media entity embedded in a body field via CKeditor.

Steps to reproduce

1. Create an image style with at least one aspect switcher effect.
2. Enable Drupal Media with the Document media type including thumbnails.
3. Configure a text format using CKeditor5 to allow adding Drupal media documents.
4. Configure media documents default view mode to include the thumbnail image using the image style created before.
5. Upload a document via Drupal media and ensure it has a valid, non-corrupted thumbnail image.
6. Edit the body of any content using the configured text format, add the uploaded document via the Drupal Media button.
7. Observe an error message in the CKeditor preview.
8. Save and attempt to view the content with the included document.

I have a similar use case where I get the same error:

I have a Drupal 10.3 site with Media and Media Library enabled and the media types image and document set up and configured according to the needs of the customer. Because the didn't need the other media types like remote video they have been completely removed. Now he needs to embed Youtube videos via CKeditor.

So I thought, ok I will apply the remote_video_media_type recipe, adjust it and that's it. But applying that recipe failed because media library already is installed and configured, aka some of it's configuration has changed compared to the module's version. But adding another media type (or entity type in general) is a legit use case for recipes and should be possible.

I think sth. like skippable configuration imports is needed. So if configuration exists we just take it as is, without trying to import it. In case of a media type it doesn't matter how the core.entity_view_mode.media.media_library or views.view.media_library actually look, right?

• For core.entity_view_mode.media.media_library the only important thing is that the view mode exists with this machine name. If the label has been changed doesn't matter. (In my case the site has no English language but German only, so I guess that's the difference the recipe importer is complaining about).
• The views.view.media_library config is even more likely to change as it might get customized to site owner needs. But again the important thing here is that the view exists not how it is configured, except maybe a constraint that the defined view displays must exist.

And I got a warning regarding missing properties in Drupal\media_bulk_upload\Entity\MediaBulkConfig regarding edit_after_upload and edit_finish_path.

See PHP 8.2: Dynamic Properties are deprecated for details and how to fix it.

The patch from #77 doesn't work because MR !14 is not mergeable into 3.0.2. This is because it contains changes in Commit 9e79aa9b which should not be included in a feature MR:

• Adding the LICENSE.txt file
• Adding auto-generated "Information added by Drupal.org packaging script on 2023-04-12" for version 3.0.2 in multiple *.info.yml files.
• src/Form/MediaBulkUploadForm.php.rej containing rejected merge hunks

In addition I would like to suggest for the "Redirect to this path after finishing editing" the option to use Drupal's standard destination parameter to return to the page from where the media bulk upload has been triggered. This is especially useful when the media library opens as modal overlay. There it doesn't make sense to redirect to the default front page.

I'm looking ahead to using this change.

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to our policies.

Of course, but in my opinion it still makes sense to report the version I observed it and then you change it as needed. Maybe due to other changes the problem doesn't exist anymore in 11.x.

@cilefen, for simpler steps just skip installing the group modile and modify the views.view.media view in a similar manner.

Why is this a bug and not a feature request?

Because when I change one view (or a config entity in general) I don't expect another virw config entity to be modified with the same change. And there are even cases where having different labels (or other values) for the same field on different displays are needed, i. e. a table display with abbreviations for column labels vs. full name for a grid display.

And why is a translation context needed?

Because otherwise all translations with the same value will get changed. The group module's group members view doesn't show insider scoped roles as user inherits from a global Drupal role he has but just manually assigned group roles (there's an issue for that, no need to discuss it here). To circumvent this until a fix is available I've added a column with the (global) Drupal roles and changed the label translation (German) of the other column to "Gruppen-Rollen". Then I noticed that the page title of admin/people/roles changed to "Gruppen-Rollen" as well.

mvonfrie → created an issue.

For documentation purposes, to help others with the same problem finding the solution: today I asked for help on Slack and @kristiaanvandeneynde pointed me to this issue while he was working on the hotfix release.

@mvonfrie
As site administrator and group administrator, on the group contents view, I see the action "Add existing content" but not the action "Add new content". The user has all available permissions on the group. I found that the add existing content route requires _group_relationship_create_any_access while the add new content route requires _group_relationship_create_any_entity_access. And the corresponding access checks return different results: Drupal\group\Access\GroupRelationshipCreateAnyAccessCheck returns allow while Drupal\group\Access\GroupRelationshipCreateAnyEntityAccessCheck returns neutral.
What am I missing? Drupal is 10.3.8 and group is 3.3.0.

@kristiaanvandeneynde
Do you have group_support_revisions enabled?

@mvonfrie
Yes.
BTW, I have a similar problem with the "Add member" action on the group members view. The access result is neutral as well.

+1 for @richarddavies

This is similar to ✨ Display implicit roles of group memberships Active , you must not assign insider/outsider roles, but it should be visible that the user implicitely "has" these roles.

See my comment 📌 Disallow the programmatic assignment of insider/outsider roles to members Active for the reason of this issue.

mvonfrie → created an issue.

Thanks, that seems to work. At least when debugging the SynchronizedGroupPermissionCalculator the calculated permissions look correct.

But still, the information about the implicit (outsider, insider, inherited) roles is missing. I will create a follow-up issue as feature request.

I stumbled upon this issue when executing a migration from a Drupal 7 site with organic groups which I implemented several months ago and the new site is almost ready for production now. I changed my plugin to filter out all non-individual roles from the mapping and that works. But I observe a strange behavior related to this and would like to ask if that is intended or not.

The Drupal 7 site has an og level "Author" role, which now is a global "Author" role with outsider and insider mappings for the group type. Users, organic groups and almost all contents get migrated from Drupal 7, except migrating the og-level roles to corresponding global roles. The admins have to do this manually. After running the migration I have the following in Drupal 10:

• User A created
• Group B created, Insider "Author" role bound to the global "Author" role is defined.
• Membership of user A in group B created

Now when I assign the global "Author" role to user A, I nowhere see that it also got the "Author (insider)" role in group B implicitely assigned. Neither in the group members view, nor as read-only information in the group membership edit form. How can I check whether the outsider/insider scoped group roles actually are assigned?

mvonfrie → created an issue.

I'm getting the exact same error on the admin page admin/reports/updates/settings.

I just got this error on Drupal 10.3.1 with PHP 8.2.2.

Instead of fully disabling/uninstalling Big Pipe it also works to disable it just for the affected blocks (if that is deterministic). in my case I just disabled it for all views blocks:

/**
 * Implements hook_block_build_BASE_BLOCK_ID_alter().
 */
function mymodule_block_build_views_block_alter(array &$build, \Drupal\Core\Block\BlockPluginInterface $block) {
  // Disable placeholdering of this block.
  // @todo Remove this when "big_pipe sometimes fails to load blocks" is solved. See: https://www.drupal.org/project/drupal/issues/3390178#comment-15742673
  $build['#create_placeholder'] = FALSE;
}

Hello, I am facing same issue as well. On 10.3.1 with Group 3.2.2 I have a view which shows group contents of a given group (via contextual filter). The view page works fine, the view block (limited to 10 nodes) rendered on the group page doesn't show, there is just the BigPipe placeholder. When disabling Big Pipe the block is rendered correctly. This is for admin user. I cannot provide information for anonymous user as I haven't configured group permissions for that yet.

Using Core 10.3.1, Group 3.2.2 and Flexible Permissions 1.10, I repeatedly but not really reproducable get the following (unhandled) errors:

Symfony\Component\DependencyInjection\Exception\ServiceCircularReferenceException: Circular reference detected for service "group.anonymous_user_response_subscriber", path: "group.anonymous_user_response_subscriber -> group_permission.calculator -> flexible_permissions.chain_calculator". in Drupal\Component\DependencyInjection\Container->get() (Zeile 149 in /var/www/html/web/core/lib/Drupal/Component/DependencyInjection/Container.php)

TypeError: Drupal\flexible_permissions\ChainPermissionCalculator::__construct(): Argument #1 ($cache) must be of type Drupal\variationcache\Cache\VariationCacheInterface, Drupal\Core\Cache\VariationCache given, called in /var/www/html/web/core/lib/Drupal/Component/DependencyInjection/Container.php on line 261 in Drupal\flexible_permissions\ChainPermissionCalculator->__construct() (Zeile 63 in /var/www/html/web/modules/contrib/flexible_permissions/src/ChainPermissionCalculator.php).

They always appear together in the logs.

Maybe they will be resolved when upgrading to Flexible Permissions V2? If not please let me know to open a separate issue.

Addition: I had this problem already with 1.1.3 but just updated to 1.2.1 to check if it is still there.

mvonfrie → created an issue.

I understand that Gin should care only about core as there are tons of contrib modules which might need to adapt themselves to Gin as well, which would bloat the module to handle all or even many of them. On the other hand, should all those contrib modules be aware of Gin and maybe other themes which need adjustments of he modules to work with them? That's the same problem just from the other side.

What about a more generic approach, like the Gin everywhere → module does? It even enables Gin for some core forms which are not covered by Gin itself (Block Content, Media, Menu). Why not integrating Gin everywhere completely into Gin?

And additionally, please document it better how to enable Gin for your own custom entity type. At least put a section in the project documentation which points to the proper hooks in the gin.api.php. Thanks.

Why is your first example <a href="#">&nbsp;</a> (obviously) wrong? Syntactically it is totally correct, but of course semantically this doesn't make sense because the user will never be able to click this link. If this for some reason is used as a trap link (kind of honeypot) with a special url, you would know that the link has been "clicked"/followed by a robot and not a human, then it makes sense again.

Would be interesting what CKeditor5 does with this? <a name="top">&nbsp;</a> This is an invisible anchor which can be used as jump target (a "Top" button at the end of the page or floating at the bottom to jump back to the start of the page (after header, banner image etc.).

In my opinion, CKeditor5 should correct syntactically wrong markup but not interpret syntactically correct markup which maybe makes no sense, as it cannot know a developer's intentions.

MR !13 has a conflict with ✨ Allow enabling vite for all components and libraries in theme/module RTBC which is already RTBC.

@wotnak, at first not but then I created a file with simple test code. No change.

But I've skipped this approach due to other problems with Vite itself. Read https://www.drupal.org/project/vite/issues/3349311#comment-15657697 📌 Example configurations/starting points Active to see how I configured it for now.

I found a solution using Yarn workspaces. In addition I'm using Typescript.

In each module/theme you need the following files:

package.json
Eventually it makes sense to remove a common prefix from [module_or_theme_name] in the package.json. If i.e. all modules start with myproject_ like myproject_ui I would name the package @myproject/ui. The package names just need to be unique though.

{
  "name": "@myproject/[module_or_theme_name]",
  "type": "module",
  "engines": {
    "node": "^20.14",
    "yarn": "^4.3"
  },
  "private": true,
  "scripts": {
    "dev": "vite",
    "build": "tsc && vite build"
  },
  "devDependencies": {
    "@rollup/plugin-node-resolve": "^15.2.3",
    "@types/node": "^20.14.8",
    "fast-glob": "^3.3.2",
    "typescript": "^5.2.2",
    "vite": "^5.3.1"
  }
}

vite.config.ts

in the vite config the server part is important, so we skip the rest of the file here for simplicity:

export default defineConfig({
  server: {
    host: true, // "Set this to 0.0.0.0 or true to listen on all addresses, including LAN and public addresses." --> Needed for DDEV.
    port: xyz, // Every module/theme needs its own port, and all of them must be exposed from DDEV or Docker in general. We start with the default port 5173.
    strictPort: true // Ensure that every module/theme uses it's own port. "Set to true to exit if port is already in use, instead of automatically trying the next available port." --> If something doesn't work/some ports are already in use lets fail here as our dev servers would not be reachable.
  }
})

tsconfig.json
The tsconfig file for the module/theme (Vite application). To not duplicate all the settings, compiler options etc. we extend it from a base tsconfig in the project root.

Here the important part is the includes.

{
  "extends": "../../../../tsconfig.base",
  "include": [
    "components/**/*",
    "src/**/*"
  ],
  "references": [
    {
      "path": "tsconfig.node.json"
    }
  ]
}

tsconfig.node.json
The tsconfig file for the Vite config compilation step (this is only using for compiling the vite.config.ts).

{
  "compilerOptions": {
    "composite": true,
    "module": "ESNext",
    "moduleResolution": "Node",
    "allowSyntheticDefaultImports": true
  },
  "include": ["vite.config.ts"]
}

Root package.json
The Yarn workspace definition.

{
  "name": "@myproject/workspace",
  "type": "module",
  "packageManager": "yarn@4.3.0",
  "engines": {
    "node": "^20.14",
    "yarn": "^4.3"
  },
  "private": true,
  "scripts": {
    "dev": "yarn workspaces foreach -Rpi --topological-dev --from '@myproject/*' run dev",
    "build": "yarn workspaces foreach -Rp --topological-dev --from '@myproject/*' run build"
  },
  "workspaces": [
    "web/modules/custom/*",
    "web/themes/custom/*"
  ]
}

In the global dev and build scripts we run the corresponding scripts of all workspaces recursively (-R) in parallel (-p). We restrict them to a scope (--from '@myproject/*', the root package will be automatically excluded as Yarn detects that it would lead to an endless recursion). With --topological-dev Yarn will only run the command after all workspaces that it depends on through the dependencies and devDependencies field have successfully finished executing. This way the themes for example can depend on any of the modules.

In the dev script we additionally print the lines from the output as it receives them with the -i option. Without it (as in the build script) Yarn buffer the output from each process and print the resulting buffers only after their source processes have exited which makes more sense for scripts executed by a CI pipeline for example.

@ChrisScrumping I have a working webpack configuration in other projects. What I don't like with webpack is, that it builds dev and prod outputs into the same folder & files, which often leads to stupid git diffs (especially during development, even if you don't commit the changes). When you commit only prod builds, during development almost all generated files appear as changed because for prod they get minified and for dev not.

Of course there should be a configuration to create dist/style.css as non-minified during dev and prod build and an additional dist/style.min.css during prod build. But then still you do not have solved the issue which file Drupal should take (style.css or style.min.css) right now because the library definition is static. This is where the Vite module comes in very handy.

And integrating webpack with storybook might be another topic...

I spent over 8 hours to get Vite working in the project root. It is not possible, at least not yet. Maybe it will be in the future with the new Vite 6 Environment API.

<root> means the Vite project root, not the Drupal one. By default Vite generates the output in a dist folder, which would be in <root>/dist/. Even if I change it to <root>/web/dist/ to have the generated files in Drupal's web-root I have no chance to get the files where they need to be (<root>/web/[modules|themes]/custom/[module_name|theme_name]/dist/) as output.entryFileNames, output.assetFileNames etc. must not contain ../ to get out of the dist folder.

error during build:
Invalid pattern "../themes/custom/theme_name/components/title/style" for "output.entryFileNames", patterns can be neither absolute nor relative paths. If you want your files to be stored in a subdirectory, write its name without a leading slash like this: subdirectory/pattern.

The documentation regarding the Vite configuration example needs to be updated as well.

* in `<theme>/vite.config.ts`:

```diff
 import { defineConfig } from "vite"
 import multiInput from "rollup-plugin-multi-input"

 export default defineConfig({
   plugins: [multiInput.default()],
   build: {
     manifest: true,
     rollupOptions: {
       input: [
         [...]
+        "components/**/*.pcss.css",
+        "components/**/*.ts",
       ],
     },
   },
   [...]
 })
```

The import multiInput from "rollup-plugin-multi-input" and then loading the plugin with multiInput.default() no longer works for me> I'm getting the following error:

You must supply options.input to rollup

If I change this to multiInput() as in the examples from the rollup-plugin-multi-input repo itself, I get another error:

failed to load config from /var/www/html/vite.config.js
error during build:
TypeError: multiInput is not a function

I don't have a solution for this yet.

Version info:

Node 18.20 or 20.14.8
Yarn: 4.3.0
Vite: 5.3.1
Typescript: 5.2.2
rollup-plugin-multi-input: 1.4.1

@ChrisScrumping even if your module is not up to date, it still looks helpful. What I'm trying to achieve at the moment is a Drupal site with two themes and one module all using Vite together. That would mean having vite.config.js in the repo root instead of the theme's or module's folder, especially as it would be much easier to run only a single Vite dev server and not multiple ones in DDEV.

mvonfrie → created an issue.

mvonfrie → created an issue.

+1 for me as well.

I have similar use cases as @joachim.

My first use case is developing a migration from D7 Scald (using the migrate_source_scald_atom source which is completely undocumented and drush migrate:fields-source not really a help) to D10 Media.

My second use case is migrating user memberships from D7 organic groups to D10 groups, but I can't migrate the organic groups to groups as well. So I have to write a custom source plugin which reads the membership relations from the D7 database together with the D10 group UUIDs which will be added in the D7 instance. It is a bit too complicated to explain why we can't migrate organic groups to groups, lets simply say there are too big structural changes and the customer decided to use the migration to implement organizational changes already existing in real-life as well.

For both use cases it is really helpful to have a destination which doesn't create any data in the site until the plugins and migrations are ready and the real destination plugins can be used.

@Jaypan, that sounds legit. More helpful would be a proper documentation with examples how to do things (adding, removing, ...) subgroups correctly via API.

Typo in issue title corrected.

I found a lot of code depending on the system.mail configuration which is not used by Symfony Mailer, especially in the WebformEmailProvider class. This needs to be adapted by a check whether Symfony Mailer is active (and then an alternative implementation utilizing Symfony Mailer) or if it should use the old system.

There might be changes in the Symfony Mailer module needed as well, I've linked the one which I found.

mvonfrie → created an issue.

mvonfrie → created an issue.

$parent_entity = $this->entityTypeManager->getHandler('group', 'subgroup')->getParent($child_entity);

doesn't work for me. It throws MalformedLeafExceptions, at least for subgroups added programmatically.

Addition: Removing the recipients to prevent sending updates was the only way when Drupal used swiftmailer, as the update manager only has two options for the email notification threshold: all updates or only security updates, but no option to not send a notification.

After applying the MR on my site and looking into the policy I found the "skip sending" adjuster which is the correct way of not sending notifications on the test environment. But still there might be other use cases where the recipients are evaluated dynamically (or defined by users) and can be none, so the code still should handle that properly.

mvonfrie → created an issue.

That is related to the HTML normalization "feature" of CKeditor 5. See https://github.com/ckeditor/ckeditor5/issues/16203 for more examples.

mvonfrie → created an issue.

Using 2.0.1 on Drupal 10.2.5 and Drush 12.5.1.0, MR !11 breaks the functionality as described in #11 and #16.

I don't re-open because this already gets fixed by 🐛 There are no commands defined in the "ckeditor_media_embed" namespace. Needs review

Using 2.0.1, MR !14 works for me on Drupal 10.2.5 and Drush 12.5.1.0.

This partially reverts and therefore fixes ✨ Add Drush 12 compatibility for custom CKEditor Media Embed Plugin commands RTBC .

mvonfrie → created an issue.

I just got the following warning after upgrading a site from 9.5 to 10.2:

Warning: file_get_contents(themes/custom/my_theme/../../../../../modules/contrib/colorbox/styles/default/colorbox_style.css): Failed to open stream: No such file or directory in Drupal\Core\Asset\CssCollectionOptimizerLazy->generateHash() (line 43 of core/lib/Drupal/Core/Asset/AssetGroupSetHashTrait.php).
Warning: file_get_contents(themes/custom/my_theme/../../../../../modules/contrib/colorbox/styles/default/colorbox_style.css): Failed to open stream: No such file or directory in Drupal\system\Controller\CssAssetController->generateHash() (line 43 of core/lib/Drupal/Core/Asset/AssetGroupSetHashTrait.php).

I can fix that by patching the colorbox.libraries.yml file like this:

plain:
  version: VERSION
  js:
    styles/plain/colorbox_style.js: {}
  css:
    theme:
-      styles/plain/colorbox_style.css: {}
+      styles/plain/colorbox_style.css: { preprocess: file }
  dependencies:
    - colorbox/init

But that doesn't really solve the issue here. The Drupal site is located at /var/www/html/ (web root is at /var/www/html/web/) which means that the ../../../../../

resolves to /var/www/modules/contrib/colorbox/styles/default/colorbox_style.css
instead of /var/www/html/web/modules/contrib/colorbox/styles/default/colorbox_style.css
and of course that file doesn't exist. I'm not sure whether this (the ../../ too much) is a bug in core or in the colorbox module. Therefore I didn't create an issue for that yet.