🇨🇦Canada @teknocat

@stborchert ah ok! Sorry I don't think I fully understood the possibilities with that merge request.

I'll try that out.

I'd really like a way to set icons that don't have to be uploaded and stored in the files directory. It would be ideal to be able to just specify a path to an icon, so it could be included with the theme. I would also like the option of using something like fontawesome to provide icons, so being able to just put in an HTML tag that displays an icon would be great. Then it's on me to make sure that the icon font is included with the admin theme for the sites I build, which I already do and use in other areas.

Ok, so the patch derived from either of the merge requests here won't apply to the current release because it includes changes from other patches that haven't all been merged and added to a release yet.

So using the 2.0.x-dev branch with the patch from either of these merge requests should do the trick for now and cover you on the other issues that haven't been included in a new release version yet (I think).

Looking forward to a new release soon so we can do away with the patches.

By the way, casting $value as a string will just result in an empty string if it's null, so that's not an issue.

@bramdriesen I just ran into this and reviewed the fix provided by @deepali.

Firstly, I the only code sniff issue is with the lack of a space between (string) and $value, but that's just a coding standards issue and quick to fix. There's also a sniff error on the elseif, which is meant to be on the next line per Drupal coding standards, but that wasn't a result of the patch.

Wrapping the turnery in parentheses is required to fix the issue, though I'm not exactly sure why that makes a difference. If there's a concern about $value being null when trying to type it as a string, then the second part of the ternary could have a second turnery instead, to be safe, as such:

$user_input .= ' ' . (is_array($value) ? implode(' ', $value) : ($value ?: ''));

So either that, or @deepali's, change works fine to resolve the error.

I'd just like to add that this module is AWESOME and just the thing we've been looking for to give content managers more of a WYSIWYG experience.

Thanks so much for the response with all the helpful information.

I installed the patch for the paragraphs edit module and that has resolved the attribution issue. Having installed that and tested editing and saving a paragraph again, I can see it creating new revisions of the parent entity.

I think I was just unable to tell if that was happening since it wasn't updating the date and author for the revision. Or, perhaps it was in fact not saving new revisions because of the issue with the date/attribution? I'm not sure, but in any case that one patch seems to fix both those issues for me.

I even tested with nested paragraphs, where I just changed the order of the sub-paragraphs without editing and even that did indeed create a new revision with the expected author and timestamp on it.

I also installed the all entity preview module and it works great! So thank you for that.

Both of these things are needed either way and the ability to preview paragraphs will cover the majority of our use cases. Until workflow/content moderation is properly integrated, we'll just have to disable front end editing for cases where content moderation has to be enforced. At least it's easy to disable access to it for specific user roles.

By the way, I have also tried enabling frontend editing for the node types using the paragraphs as well as the paragraphs themselves, AND enabling frontend editing for the Content Moderation State.

If you enable the hover highlight mode then having both the paragraphs and node editing enabled is fine in terms of the UI, as they don't overlap and interfere. With that you can have a live preview, except that modifications to the paragraphs themselves (their content or display order) is not reflected in the preview.

I also found that, with the Gin theme, if you do not expand the sidebar then the content moderation and all the other items normally in sidebar tabs on the normal edit page don't show up. If you scroll down in the frontend editing sidebar there's a big space where that would be. But that would be a separate issue to address.

In any case, editing the entire node is currently the only way to access the moderation state and still doesn't help if you just want to change the display order of paragraphs in the page without editing the whole node.

teknocat → created an issue.

That's fantastic! When we perform the next round of updates on the website that I linked in this issue, we'll be sure to white-list the ID of the form that handles the open ID connect functionality.

Hello @pedro-alves,

Thank you for the fast response and the advice! I really appreciate how responsive you are to issues on this module and how quickly you implement changes and updates.

I will go and change the HAF firewall rule to relaxed and advise my team so we can see if that's appropriate in our other sites as well.

That other IP address you mentioned was white-listed by accident and I removed it already. I just copied and pasted the wrong one by mistake when trying to white list the client's IP address.

Looking forward to that next update with the feature to exclude/white-list forms entirely.

Peter

teknocat → created an issue.

I've provided a second merge request to re-roll the same fix onto the 6.3.x branch.

teknocat → created an issue.

The issue is in the submitForm function in the way that it tries to set the given configuration key with the new data merged with ALL the original config data. That array merge is appending the new config that's only for the one $rid to the end of ALL the configuration. Then, it sets that new array in the configuration with that $rid as the configuration key. As a result, every save keeps a nested copy of the original config along with the new config keys. That then throws things off when you try to import the config and use it.

If you want to merge the new config with the original, then instead of $config->getOriginal() you should use $config->get($rid). However, I don't see any need for merging anyway, since you're setting a new array containing ALL the config values that were submitted. Merging the array is only helpful when you want to combine some new data into an existing array, where existing keys that match will be updated while new keys will be added.

Lines 190 to 200 can be changed to the following and it works as expected:

$data = [
  'path'               => $alias,
  'url'                => $source,
  'redirect_path'      => $redirectPath,
  'hidden'             => $isHidden,
  'form_mode_register' => $formModeRegister,
  'form_mode_edit'     => $formModeEdit,
];
$config->set($rid, $data)
  ->save();

I noticed this happening as well, but it's not just if you don't make any changes. Even if you do make changes, it saves a nested configuration set, leaving the parent with the previous values, for example:

community_member:
  community_member:
    path: /user/register-community-member
    url: /user/register/community_member
    redirect_path: /<front>
    hidden: 0
    form_mode_register: register
    form_mode_edit: default
  path: /user/register-community-member
  url: /user/register/community_member
  redirect_path: /user/login
  hidden: 0
  form_mode_register: register
  form_mode_edit: default

Further to this, it seems like it would also be prudent to have per media-type view access for any media types that use private files.

We have built a few sites now that need to have private files. Depending on the requirements for any given site, we might use a paragraph type to attach the files to a node, whereby that paragraph type has access restrictions - thus public users can see the node, but only logged in users see the paragraph. Other times we just have a field directly on a node and that node itself might be restricted view access.

So the tree-concept for access checks certainly makes sense, so that if the media entity was attached a field directly on a private node, or to a paragraph that's attached to a private node, then it's access would be restricted based on the root-level entity access.

However, there may still be cases where that doesn't necessarily work, depending on the individual use cases. So being able to set view access by the media type that uses private files would offer that first level of access restriction. I mean, what happens if you detach a media entity with a private file from it's parent entity that had the access restriction on it, but somebody out there still has a link? If the media entity itself is published and "View media" is allowed by anonymous users, they can download it.

Something we developed for a client was a document library, which provided a custom UI in the form of a Javascript Vue app that mimicked the functionality of a file desktop file explorer. This library widget is provided as a Drupal block and can then be added to a node using a block field in a paragraph, allowing the client to create a page with other content to go along with it as they see fit. We like to allow our clients to be able to manage all pages of their site the same way, add them to menus the same way etc to provide a consistent UX throughout the CMS. This doc library block and paragraph type is ONLY available to be added to a node type that is private, but the media entities themselves are in no way associated with the paragraph or the node. It's just a way to provide access to this fancy media browser, thus even if this tree-type access solution was in place it wouldn't work in this case.

This may well be an edge case, but if there were view permissions per private media type that was used to control download access to it's files, then it would be easy. Since we already had a custom module built to provide this custom block widget, we implemented a custom permission for document library access and then implemented the appropriate hooks for media view operation as well as file download with the logic needed to prevent access based on the file and media entity type and whether or not you have the permission.

The logic in the download hook is a bit messy, but it works.

I was just banging my head over this trying to figure it out and had COMPLETELY forgotten that we always used to use the override node options module in Drupal 7!! Since we have always used content moderation and workflows to handle publishing and unpublishing ever since we started using D8 for all our sites, that aspect was never an issue, and we rarely ever need to provide our client users with access to the promotion options, authoring info etc.

However, I don't remember ever needing the override node options module in D7 just to give users access to the published status. Maybe that was always an issue and we either used override node options or granted "administer content" back then, I can't recall. Anyway, I do think it makes sense for core to have dedicated permissions for publish status access as well as for these other options.

But in the meantime, override node options is a great solution.

Ok so I see why the access hook is needed in the system module because something needs to allow access by default. Then other modules can, when appropriate, implement the hook to forbid access when appropriate.

Anyway, I think this is a good start to a solution but it probably needs to be more robustly implemented to be really useful. This change on it's own isn't super useful unless it can be somehow tied to the access checks for specific action plugins, or add permissions for bulk execution, or something along those lines.

Also as per my other comment it needs to hide the form entirely from the view if there are no available actions, so there's a little extra logic needed for that as well.

Attached is a patch to get the solution one step closer, that works against the 10.3.x branch. With this patch I can implement hook_action_access in my own custom module to apply the logic I need in my use case.

I know this issue is really old and doesn't seem to haven gotten much traction, but it really is an issue that should be resolved.

I don't see the need for implementing the access hook in system.module, as actual access to actions is checked before running it. It's just the form that needs altering to exclude actions the user doesn't have access to from the drop-down list. It would also be prudent for the form to not display at all if no actions are available.

The same fix also needs to be applied to AdminToolbarToolsSettingsForm.

The patch provided here does not make sense. The access checks should simply remove the condition that the user has a role named "administrator", as this is a straight up security access bypass issue.

If the "administrator" role has the "is_admin" flag, then it will automatically have no access restrictions. This is already taken care of properly by this module when doing the actual field access checking. So why there is a need to bypass the proper checks based on the configured permissions if the user has the role called "administrator", I do not know. Any sites that have a different role with the "is_admin" flag set to true but want to let the role called "administrator" still bypass all field access restrictions are configuring their sites incorrectly.

This hasn't come up as an issue for us before because we typically grant full access to any restricted fields to the "administrator" role anyway. However, we currently have a use case where only our "developer" role (which has the is_admin flag set to true) has access to certain fields, not the "administrator". So now this is an access bypass issue that's a problem, but simply removing the check for the role "administrator" from the if statement makes it work exactly as expected.

@caspervoogt, to solve your issue you should not give the end user the "administrator" role if it has the all powerful "is_admin" flag and instead do like we do and have a developer role to reserve that access for you so you can then give your site's users the "administrator" role if you want to and then still be able to restrict their access to certain things. Except this issue will still be a problem for you so long as you keep the role with that name.

Now, if there are use cases where you do want a certain role that doesn't have the "is_admin" flag to still be able to have no field access restrictions, then this module should provide a "Bypass field access control" permission that can be granted to any role, just like the core node module has a "Bypass content access control" permission you can grant if you want to.

For now, though, IMO this security hole should be plugged and if doing so breaks a lot of sites out there that are relying on it then it's their problem to deal with. It's not uncommon for a module update to break something in the sites we manage and it's up to me as the developer to deal with that when it happens. It's my job to adjust configuration to accommodate changes in behaviour of modules, especially if a change has been done to address a security issue. I feel very strongly that it's more important for a module developer to make sure their module is secure than worry about breaking sites.

That said, if you want to make sure devs of existing sites relying on this functionality are aware of what could break and can deal with it, then make a new major version release that includes this fix and update the module description to flag it when upgrading to that new version. And then at the same time you could add in a "Bypass field access control" permission so that way users upgrading can make use of it if they want or need to.

I will create an issue fork and a merge request to at least remove the access bypass for now.

In reviewing my current codebase, I can't seem to get drupal/coder 8.3.24 due to the following dependency chain:

• drush/drush requires chi-teck/drupal-code-generator:^3.0, which installs v3.2 (at the time of this writing)
• chi-teck/drupal-code-generator 3.2 requires drupal/coder:3.2.23

I have Drush 12.5.2 installed which, at the time of this writing, is the latest version. I'm currently running Drupal 10.3.

Can somebody advise me on how to update? Alternatively I could update my phpcs.dist.xml file to reference globally installed drupal/coder sniffs as well, where I have 8.3.24 installed. However, that doesn't seem like the best approach and is less portable if other devs working on the same project don't also have the sniffs installed globally in the same location as me.

teknocat → created an issue.

teknocat → created an issue.

Yeah this seems to be nicely resolved now, either using the experimental navigation integration without the core navigation module, or with the core navigation module enabled. Tooltips in the sidebar menu look consistent in both cases and are not affected by my site theme's bootstrap tooltips.

I just ran into exactly this issue. I used the patch from the linked issue and it solves the problem.

I had been using the lightning workflow module, but it's lightning scheduler submodule had other issues already resolved in this module plus the workflow module itself is pretty much superfluous now anyway.

So I uninstalled and removed that one and installed this one instead in a couple of Drupal 10.3 sites that have been using the other module for ages. I started getting loads of these errors when running cron.

@saschaeggi ok good to know. Hopefully that makes it into another release candidate soon :)

This feature is nice, but when the sidebar is closed it leaves a gap where the sidebar was - the page width doesn't adjust to maximize the space when it's closed.

By the way, it looks like the latest release of the standalone module has this whole problem and other related issues resolved.

Hey folks, is it just me or does it seem silly that this module and the submodule of lightning wokrflow are maintained independently?

I didn't realise this standalone scheduler module existed until I ran into these issues when upgrading to D10.3. We had a patch for the workflow submodule and had to switch to a different temporary one to address this particular problem and we still have to uninstall it, then do composer updates and then re-enable it to work around the database errors. This module has the issues all resolved, but the workflow module seems to be getting updates more slowly.

Why not work together to just have this one as a dependency of the other?

Hey everyone, what's the difference between the lightning scheduler sub-module of this module and the standalone lightning scheduler → module? The standalone module seems to have addressed the issue.

Why not simply make that module a dependency of this one via composer? Or remove it completely, leaving it to the person building the Drupal site to decide what scheduling module they want to use and add it explicitly to their project?

Seems silly to maintain this independently as part of the lightning workflow codebase when the other is having the same kinds of issues being addressed separately ( https://www.drupal.org/project/lightning_scheduler/issues/3297525 📌 Automated Drupal 10 compatibility fixes Needs work ).

So how does this module relate to one by the same name that is a sub-module of the lightning workflow module?

We use the latter, but that doesn't seem to be getting updates to it's submodule that are being applied to this standalone module.

It seems like this should be used on it's own and removed from lightning workflow...

The provided patch won't apply - it just times out after a while. I will try doing a re-roll of this patch, test it and then attach to this comment shortly.

The issue on the lightning scheduler module is also discussed in more detail at https://www.drupal.org/project/lightning_scheduler/issues/3297525 📌 Automated Drupal 10 compatibility fixes Needs work , down in the comment section.

So the workaround I found, of course, was to set $settings['cache']['bins']['bootstrap'] to 'cache.backend.null' in the short term. However, upon further investigation it looks like this issue was ultimate due to the Lightning Scheduler submodule of Lightning Workflow, as detailed at https://www.drupal.org/project/lightning_workflow/issues/3457016 🐛 Circular reference detected for service "cache.backend.database". Active .

I'll close this issue, since it's not a core issue after all, but hopefully having it documented here will help others with the same problem find it more easily.

I will also add that I have the same results if I do this on my local dev environment, where I have a settings.local.php file that disables caching by setting various cache bins to cache.backend.null, or in an environment where I don't have any caching disabled. However, since this appears to bootstrap caching, which is using the cache.backend.database, that is likely irrelevant.

teknocat → created an issue.

The eslint error in the merge pipeline applies to Javascript that I didn't touch. I don't quite know why it's flagging ONLY the call to .val() in that one spot when it calls the jQuery .val() method several places prior to that. Anyway, it's not an issue in terms of merging and then releasing a new version with the compatibility fix in place.

teknocat → changed the visibility of the branch 3456062-the-coreversionrequirement-constraint to hidden.

teknocat → created an issue.

teknocat → created an issue.

No problem. I figured there might be other code like that, but didn't have time yet to go through the rest of the code. If I do, I'll submit additional issues and merge requests.

Sounds good all. In the meantime, I found the standard Gin sidebar works great until the new Navigation is available in core.

I was going to create a new issue for this if you hadn't already.

Yes, this is very frustrating, actually. I've enabled the experimental nav on a couple of sites to see how well it works and this is one of the first things my colleagues pointed out.

Another example is that I frequently need to go to the top-level Views admin page. It's nice that all the views appear to click on when expanded, but that can get really long, so it's more convenient (and also a bit of a force of habit for me) to just go to the top level and look for the view from there. Part of the problem is because I use the admin toolbar module and admin toolbar tools to generate additional admin menu links that we like to have there as developers.

I don't seem to find any issues with the new Drupal Navigation in the Starshot protytpe project using core 10.3 beta, but it's not using the admin toolbar tools and thus only generating the standard core links for the admin menu. Will have to see how things work out with our sites once 10.3 is fully released and we start using the final version of the navigation sidebar.

teknocat → created an issue.

teknocat → created an issue.

Yes we also figured out the license thing and made sure that we are using a different license key for each site.

I could also see various ways this code could be refactored to shorten and simplify it, so if you're interested I could create a separate issue for that and commit some changes for consideration. It would help make the code more maintainable in the long run.

teknocat → created an issue.

@djsagar if you give me push access to your forked repo I'll sort out the merge conflict. I have it fixed up on my local already.

teknocat → created an issue.

In my Drupal projects I've got "bower-asset" and "npm-asset" configured in "installer-types" and added to "installer-paths" in composer.json under [webroot]/libraries/{$name} along with with "type:drupal-library". Thus I can simply do "composer require npm-asset/fontawesome-iconpicker" and Bob's your uncle.

Actually the ->toString() isn't needed and it doesn't need to be set in a variable. It can just follow the same pattern as for media and blocks:

foreach ($content_types as $item) {
  $content_type_items[] = [
    'title' => $item->label(),
    'class' => $item->id(),
    'url' => Url::fromRoute('node.add', ['node_type' => $item->id()]),
  ];
}

teknocat → created an issue.

Why doesn't this work at all when applied as a patch to Drupal 10?

These patches are not the correct solution to the problem. The issue is that "single" and "single_all_day" options were added to the settings form, but not defined in the schema YML or provided with the default options. They also weren't displayed in the summary.

I'll create another issue fork that makes those corrections.

The last several commits to my issue fork seem to have this now working fully. Some things from patch #4 were correct and thus incorporated.

I have tested a form using test values, then edited the submission and the widget seems to be working so far.

So it seems that this widget simply doesn't function fully, with either patch #4 or the version I've put together in my branch. The default value can never seem to be set, nor does it return the selected value(s) correctly in the webform.

Inspecting the rendered form reveals why - the field name has some complexities to it that will require the implementation of setValueCallback and getValueCallback in the webform element class. This is taken care of in the Term Reference Tree widget for use with fieldable entities, so that needs to be replicated for the webform module.

I'll try to get this figured out and comment when I've got something that actually works.

Damn, I just did my own thing from scratch in my own custom module before seeing this. However, I went a slightly different way by extending the OptionsBase webform field type and using WebformEntityReferenceTrait and WebformEntityOptionsTrait. I started by looking at what the Webform Entity Checkboxes field type did, then figured out how to use the bits of that that made the most sense to turn it into a checkbox tree using this module.

I'll create an issue fork and submit a merge request with my idea so everyone can review and figure out what makes the most sense.

teknocat → created an issue.

teknocat → created an issue.

teknocat → created an issue.

Ok I'm confused now because after reviewing the code and "fixing" it in a couple of different ways, as well as re-saving some form components, it started behaving as expected and the weird issues went away. I saw how the getFormElementAccess() method works if the component is not found at the top level of the elements array and that takes care of the recursive search, so I'm not sure why it didn't seem to be finding the right elements at first and gave an error about a component that wasn't even in the list to be compared for equality.

Seems it was just something wonky about the webform config on my side, so this issue can likely be closed.

teknocat → created an issue.

I'm really glad somebody posted this as an issue, because I ran into the same thing because of some custom code I didn't realise needed updating for Symfony 6. It's not really a deprecation so much as how you need to use the request object and its functions. Very hard to otherwise find an answer on.

teknocat → made their first commit to this issue’s fork.

This really ought to be included as part of issue #3390107.

teknocat → made their first commit to this issue’s fork.

Can somebody explain to me how you apply the patch using composer and then get composer to actually install the newer square SDK dependency without using some weird trickery?

When can we expect a new release of this module with the dependency updated?

The provided patch also makes sense, given the 2 core issues have since been fixed. However, since this module is included with lightning_core, it's not possible to apply the patch as is using composer. This issues should be moved to the lightning core project and a patch for that setup accordingly.

Yes, simply running on PHP 8.2 triggers this warning. I have tested both versions and can verify it.

Plus 1 on this! I have a client with many rows to export and it canney handle it.

After reviewing the source code, I'm not even sure how the action could be updated to work with Views Bulk Operations properly. The action just wants to stream it directly out.

The patch in #5 is not really the correct solution. It prevents the error, but it doesn't make the code work correctly, which is to ensure that the live preview is disabled for the PDF display. I don't quite know why it still successfully disables the live preview, but the correct syntax should be as follows:

if ('pdf' === $view->getDisplay()->getPluginId()) {

I will create an issue fork and submit a merge request for this.

teknocat → created an issue.

I've had this module running on a site for some time now and it just started producing this error the other day.

It seems to me that it would be prudent for this module to catch and handle any type of guzzlehttp errors more gracefully, especially if it's preventing users from being able to login to their site. This error may not be a fault of this module at all. This particular cURL error could be an issue with the server environment, or a problem on Google's side, or various other things. Regardless, it does not seem acceptable from a user standpoint to just get a white page with the generic error message and have to contact the web developer to sort it out. The short term solution for the site I'm working with currently was to just disable CAPTCHA altogether on the login and password reset forms, at least in the short-term.

I think the ideal solution would be to add some configuration for what to do in case the reCAPTCHA service fails in some way that prevents it from validating the CAPTCHA in the first place. One option could be to fallback on another configured CAPTCHA, or simply ignore the CAPTCHA and just allow the form to be submitted. That way the developer can choose the most desirable behaviour for their client.

It would be even better if a test could be done against the reCAPTCHA service to determine if it's working and available and working BEFORE the form loads and displays to the user to make the user experience even smoother. Either way, regular users should not have a bad experience if there's a way to handle it gracefully and ensure the UX remains smooth.

If I have time to come up with a decent solution to this I will submit a merge request.

Oh wait I think that's just me being dumb. Should use PNG rather than JPEG to leave backgrounds transparent.

Image format selection doesn't solve the problem. I have PDFs that have transparent background, using JPEG format for thumbnails, they still have a black background. Perhaps it would be prudent to add a config option to specify a default background colour to use?

By the way, if this is ONLY an issue with the very latest Drupal core 10.1 version and the change does not work in previous versions, then it might be prudent to do a new release version of this theme that is only compatible with the latest release and update the version compatibility of the previous release.

This is not the actual problem nor is this the provided patch (#5) the correct fix for the problem.

Drupal core no longer includes the jQuery once library because it is trying to move away from the dependency on jQuery altogether in the long run. jQuery once was replaced by a new core/once library that is independent of jQuery or other third-party libraries. If switching affix.js back to using jQuery once works for you then that library must be getting included in your particular Drupal site, either directly by you because you chose to include it or because another module still depends on it and has it as a composer dependency and thus includes it.

I found that affix.js stopped working for me as of the upgrade to Drupal 10.1.2 (from 10.1.0, so it's possible that 10.1.1 breaks it as well). After some investigation, I found that in this version of core, the once library has changed a bit, such that it is no longer possible to get the matched element using "this" within the foreach function. Instead, you have to update use of once to get the element passed into the function.

Lines 29 and 30 of affix.js just need to be changed to this:

      once('affixed', '[data-toggle="affix"]', context).forEach((element) => {
        var ele = $(element),

And Bob's your uncle. I will try to submit a merge request with the changes so the diff from that can be used as a patch.

OK, apologies for making a fuss, seems it had something to do with caching - browser and/or Drupal.

What's even more weird is that I have 3 different sites I can see this problem with, but one where I installed all the latest updates and it works just fine. I will have to look into what's different between them to see if I can narrow it down and determine whether it's actually still a bug in this module, or a conflict with something else.

Oh and I'm using version 2.2.4 of this module.

This issue still does not seem to be fixed.

Testing on the latest Drupal 9.5 as well as Drupal 10.1 and I get:

Drupal 9.5.9:
TypeError: this.editor.plugins.get('LinkUI')._createViews is not a function. (In 'this.editor.plugins.get('LinkUI')._createViews()', 'this.editor.plugins.get('LinkUI')._createViews' is undefined) (anonymous function) (ckeditor5.js:201)

Drupal 10.1:
TypeError: null is not an object (evaluating 'this.editor.plugins.get("LinkUI").formView.extendTemplate') - editorAdvancedLink.js:1:3969

Disabling the module is the only thing that fixes the problem.

While the PNG option worked fine on my local machine on macOS, I found I still got a black background on my web server. This could just be due to the version of ImageMagick, so if that's the case then the first patch on this issue is better and it could be expanded on later if needed.

The only problem I see with this patch is that it does away with the use of the Spatie PDF to Image library, which accounts for various other things and additional options during the process of generating thumbnails, including an allowance for generating thumbnails for remote images.

It is advantageous to keep using the spatie pdf library, but there isn't an easy way to use that and composite it onto a white background outside of that library (I tried that). However, if it uses the PNG format then transparency is allowed and you don't get a white background. This introduces a different issue, in that the thumbnails might not look good against whatever background colour they are on, but that problem can be easily resolved with CSS.

It's a very simple solution and, if desired, the settings form could be updated to allow the developer to choose the desired format for any given thumbnail format. However, that means you'd then have to make sure you set it consistently in all places.

As such, I suggest simply changing it to use PNG format as a default and I will submit a merge request with that solution for people to try out.

Ah yes thank you! This is very helpful and hopefully helpful to others as well.

Yes I have the global minimum stability set to "dev" because I sometimes have to use dev versions of modules for one reason or another. I didn't know you could still specify the desired stability for individual packages. So now I've done that and it's solved the problem.

teknocat → created an issue.

Yes I agree there is no reason for this module to wipe out all the submit handlers just to be able to do it's thing. @prudloff's solution looks great. I don't think I would have thought of that.

Ah yes, indeed I was using the patch from that related core issue.

If I remove that patch, then I can use the latest version of this module without issue and that provides the reset permissions and it all works.

So options for anyone until the release of 10.1.x and the appropriate update to this module to go along with that are either:

a) Use the core patch and use a workaround to continue using version 3.3 of this module, or
b) Don't use the core patch and use the latest version of this module

While there are other related issues that would be ideal to solve in core all with one solution, in the meantime I think the Media Library Edit contrib module is a great solution to this particular problem. It works very well, supports D10 and appears to be fairly actively maintained.

I'm sorry I don't know how to update the automated tests, so that will likely need work, plus some other tweaks before these changes can be accepted. However, upon apply my second patch to my current live D10 installation, it does work and the status report page does indeed show it as correctly configured. It says it's using Libraries API files even though I'm using the composer merge plugin, so that's one of the minor things that might be prudent to update as well.

But suffice it to say, the patch works to eliminate errors and get it working fully in D10 for now.