@snater

Thank you for your offer. I'm very fine adding co-maintainers making substantial contributions to the project.

There was co-maintainership at some point in the past which, back then, had lead to some degradation of code quality as well as scope creep. Therefore, I'm cautious on adding additional maintainers for the time being, though I would very much like to share responsibilities.

As of now, though I am not here on a daily basis, I will still be able to review and merge patches. From my perspective, co-maintainership will be more of a topic whenever there is need for another larger rewrite of the module like it had to be done for porting it to CKEditor 5.

I have not yet looked into changes required for Drupal 11 in addition to #3491913 📌 Drupal 11 compatibility fixes for insert Active . What more is there to do beyond that?

Thanks!

Thanks for the patch and test!

I'd prefer not using >=10 as there is no way to be sure this module will instantly be compatible with any future major version. In the scope of this module, I would consider ^10 || ^11 better practice, unless there is a good reason to be sure the module will be compatible to any future major version.

Closing this issue after four weeks of inactivity. Feel free to reopen if there is additional input.

Thanks for the comment. It does not seem that the attributes are being removed at the moment when switching to the source view. Consulting the CKEditor Inspector, the attributes are still there (attached screenshot). However, the attributes are not rendered in the source. Now, when just toggling back to the rendered output without manipulating the source code, the attributes are still attached. Yet, when doing any change to the source, the attributes are dropped when switching back to the rendered output. That is what I can reproduce.

What I just tested is that transferring the Insert attributes manually from the CKEditor Inspector to the source code will retain the attributes when switching back to the rendered view, even when manipulating the source code otherwise. However, the synchronisation of the field's input elements with the field value instances already placed in the editor seems to be lost anyway when switching back to the rendered view. Even inserting a new instance of the field value back in the rendered view, the synchronisation (i.e. updating the text of the link from the title field) seems to be just gone.

Seems like there'd be two tasks:

• render the custom Insert attributes in the source view, and
• re-attach the Insert sync event when switching back to the rendered view (assuming the event is just dropped when switching to the source view).

Though it may also turn out, that supporting the CKEditor source code plugin is just generally out of scope for the Insert module as the source code view sports some different behaviour, which might just be too complex to tie all the knots together. For example: Insert a link, switch to source code, update the link title. Result: The text in the source code is not updated. However, switching back the the rendered output, the link text is updated. These are behaviours which there is most likely no time to make things perfect as well as there does not seem to be a lot of demand for supporting the source view.

Thanks for the patch. When applying the patch, there is a duplicate Insert plugin with a missing icon in the CKEditor text format configuration as per the attached screenshot, because the patch is registering a second CKEditor plugin.

To investigate more and try out the patch, I have set up a fresh Drupal installation with version 10.3.5, running no other third-party module than the Insert module, and then installing the Insert Media submodule. For me, inserting media content into the body editor works without the patch, just as soon as I turn on the "Embed media" filter on the text format. No other action, I do not even need to enable the Insert CKEditor plugin, because the "Embed media" filter is probably already allowing all necessary tags.

The Insert CKEditor module is just enabling specific tags and attributes to be used in the CKEditor. But what happens to you is that the CKEditor instances are not detected at all. If the Insert CKEditor plugin not being loaded would be the source of the problem, the expected behaviour would be that the media content is still tried to be inserted into the body editor, but it would not be rendered there, so it would appear as if nothing happens when clicking the Insert button. However, what happens in your case is that the CKEditor instance (the body editor) is not even detected, and the content is inserted into the summary textarea instead.

One thing I can think of being the problem is that there is a conflict with another module. This conflict might just get resolved as a side-effect of your patch. Yet the patch does not seem to be fixing the original issue, unfortunately. Maybe you could let me know which other modules you have installed (particularly third-party modules), then I could try to figure out reproducing the issue having one of those modules installed.

Thanks for checking.

After some more trying, I can see a circumstance that could be related to your problem: Inserting Drupal Media content will work only when the "Embed media" filter is enabled in the configuration of the text format being used. Maybe this is the missing piece.
However, the behaviour I can reproduce is different to yours in the way that when the filter is not activated, the media content is still inserted into the body editor, the content is just not visibly rendered. So for me, the content does not end up in the summary text area instead.

I'm a bit puzzled why Drupal.CKEditor5Instances would not be set, even after the whole page has loaded, as far as I understand that is the case. That global should be provided by core's ckeditor5 module, while the CSS class to detect the first editor element is assigned directly by CKEditor itself.

Thanks for filing the issue. I'm not instantly sure what could be the cause as I am struggling to reproduce the problem.

What appears to be happening in your case is that either the CKEditor instances are generally not detected by the Insert module, or the focus handlers attached to the editor instances by the Insert module are either not attached properly, or not working as they should.

To get a better idea, maybe you could answer some of the following questions:

• What browser are you using, or is the issue independent of the browser anyway?
• Does the issue also appear without first focussing the body editor, so directly clicking "Insert" after the page has loaded without focussing any textarea or editor? (The expected result would be the content being inserted into the body editor as Insert is supposed to pick the first CKEditor instance on the page.)
• Initialising the CKEditor instances relies on the global Drupal.CKEditor5Instances being defined and populated with the CKEditor instances present on the page. This global is maintained by Drupal core's CKEditor 5 module. So maybe you could check if Drupal.CKEditor5Instances is actually defined in your case checking in the browser's dev tools?

For reference, the relevant lines of code where the issue could surface are here and here.

Thanks for filing the issue. Insert 3.0.0 does not support CKEditor 4. For using CKEditor 4 with Drupal 10, you may want to try Insert 3.0.0-beta3 → , which supports that combination.

Because of the fundamentally different APIs of CKEditor 4 and 5, there is unfortunately no backwards compatibility of the Insert module.

There is good support for adding captions in the core Drupal image CKEditor plugin, which is why I had decided to drop the complexity from the Insert module for version 3.x.

The Insert module also does not expose JavaScript APIs anymore as no one was using them and removing helped reducing complexity in respect to making version 3.x happen. However, if you want to achieve inserting captions, you should be able to implement your own module, which would need to depend on both the Insert module and the Image field caption module. In that module, you would overwrite Drupal.insert.ImageHandler with your custom extended version of just the same class. The concept of hooking up to the caption field should be similar to Drupal.insert.ImageHandler hooking up to the alt field.

Additionally, the insert-image.html.twig template would need to be overridden attaching the caption field to the HTML output.

This is just some pointers. Unfortunately, I cannot guarantee it would work just like that, and I do not have capacity to work on a submodule at this point. But feel free to open a new feature request to maybe join forces with others interested in that feature.

Since there were no more fundamental issues reported with the module, version 3.0.0 → is finally released. Please open separate issue tickets in case of any errors or bugs. Thanks to everyone for the input and feedback along the way!

Thank you for the patch!

Updated instructions for Insert 3.x.

Removed issue obsolete as per Insert module 3.x / CKEditor 5.

Revisiting tickets preparing for the 3.x release, I guess this seems to be figured thanks to the input by nitrocad.

If there is still some issue around this topic in the most current 3.x version, feel free to reopen the issue or create a new one.

Updated instructions for Insert version 3.x.

Note: Enabling the plugins is necessary only when the "Limit allowed HTML tags and correct faulty HTML" filter is enabled for the text format.

Module documentation will be updated along the next release.

Thanks for opening the ticket. If you had troubles, others might very well have the same; I have added the CKEditor support matrix to the module page.

I had kind of assumed anyone using Drupal 10 having dropped CKEditor 4 by now, because that CKEditor 4 legacy module had given me never-ending deprecation warnings… Unfortunately, it would be difficult to keep both CKEditor 4 and 5 support alive at the same time, resulting in upgrading being a bit inconvenient.

@jjancel: Thanks for the feedback. It appears you have a bit of a strange state there. If you use the CKEditor plugin, which I can confirm being referenced in the error of your first message, you seem to be using the dev release, because the CKEditor module is not part of 3.0.0-beta6 and there has not been a beta release since then. At the same time, the function _insert_allowed_html_validate referenced in your most recent message is removed in the dev release as it has become obsolete along implementing the CKEditor plugin; that was the old method of extending the allowed HTML. The "text formats" option itself was removed along implementing the CKEditor plugin, there is an update hook that is supposed to remove the setting's value.

Could you make sure you have the latest dev release and have also cleared the cache? Thanks!

Snater → created an issue.

When changing the text format, the re-instantiated editor is recognised now. However, the default insert target cannot be reliably updated until #3319358 ✨ Trigger event when Text Editor is attached Needs work is resolved in Drupal core. Therefore, after switching the text format, e.g. on the node body editor, it cannot be assumed that the default insertion target is updated with the new editor instance. Therefore, the user needs to click into the editor to have content inserted into it.

Leaving it like that for the moment, since changing the text format is likely more of a rare case. As soon as a resolution is implemented in Drupal core, the default target detection can be improved.

As soon as the three Insert tickets referencing this ticket are closed, I consider the Insert module feature complete for version 3.0.0. All the issues already received change sets. After closing those issues, there will be one more beta version, and subsequently, depending on the bug situation, there will finally be the 3.0.0 release.

The change will require a documentation change:

Allowing required HTML in CKEditor
For proper functionality, some HTML tags an attributes need to be enabled.

By default configuration, specific tags and attributes are stripped from HTML input and output as to the text format's CKEditor configuration. Yet, for proper functionality, some tags (<img>, <a>, <span>) and attributes on those tags need to be allowed. You can have the Insert module automatically add required tags and attributes to the CKEditor configuration per the CKEditor plugin provided by Insert. To do so, via /admin/config/content/formats, go to the text format's settings page, which you want to enable Insert module support for. There, drag the Insert module's CKEditor plugin button from the "Available buttons" into the "Active toolbar". If you have not done so already, you will also need to activate Drupal core's Image plugin.

The Insert module's CKEditor plugin will not show a button in the actual editor toolbar as its only purpose is to enabled support for necessary HTML tags and attributes. However, Drupal core's image plugin will render its button. If you do not like this button to show, you can, for example, use custom CSS added to your admin theme.

Snater → created an issue.

Snater → created an issue.

Thanks for the feedback. You will be able to insert an image if the image plugin is enabled. But there is probably no "tracking" of the inserted image, which is for syncing the alt input element to images already inserted for example.

I have looked into providing a CKEditor plugin that would enable the necessary HTML by dragging a button into the toolbar on the text format edit page. It seems to work out ok, I created a separate ticket 📌 Replace text format setup with custom CKEditor plugin Needs review .

This will replace the shaky logic adding the tags and attribute when saving the text format form. The only downside is that Drupal core's ckeditor5_image plugin is required to be enabled due to image-specific customizations there. The consequence is that ckeditor5_image plugin's button will show up in the editor toolbar, which would need a line of CSS in the admin theme if it is meant to be hidden.

Snater → created an issue.

Thanks for reporting the issue, I can reproduce the problem. Linking to an image style seems to work, but linking to the original image does indeed not work for me either. I have attached a patch that fixes the issue for me.

PR has been merged, closing as outdated as a new issue will be created against the most recent release if there are more automated fixes.

Released 3.0.0-beta6 → , which also contains a fix for the issue mentioned in comment #29 📌 CKEditor 5 compatibility Active that I was able to reproduce now.
Thanks.

Closing this issue as it should be fixed in the more recent beta versions. Feel free to reopen or create a new issue if the problem still exists in the most recent beta.

Thanks a lot for the patch. I was able to reproduce the issue. The fix is part of 3.0.0-beta6 → .

Released 3.0.0-beta5 → that should fix an issue of the page being reloaded when clicking the Insert button.

Unfortunately, I cannot reproduce the issue. Inserting works fine for me on a fresh Drupal installation. The default target should be the main body editor. As soon as focussing an editor or a textarea, that editor or textarea is supposed to become the current target for inserting.

For me, when I upload an image, it is inserted into the main body editor. If I focus the summary input, and then press "Insert", the image is inserted into the summary. Focussing the body editor again, an image is inserted there again.

In the code, the default target is picked here, and then the actual insertion target is selected here. I would need more configuration on the setup for being able to reproduce. If the target sticks to one element, there must be something wrong with the focus tracking in that file. You could try stepping into that function with the debugger. It could also be somehow related to the relevant editor/textarea not added to that FocusManager per addTextarea()/addEditor(). Maybe the editor is loaded asynchronously in your case after the Insert module is initialised, causing the editor to not be added to the FocusManager.

Superseded by https://www.drupal.org/project/insert/issues/3433344 📌 Automated Drupal 11 compatibility fixes for insert Needs review .

I have created a new beta release 3.0.0-beta4 → . Unfortunately, I am unable to reproduce the issues with the template and the JS error. Please open separate issues for each problem after verifying the issues still exist on the beta release, and provide exact steps to reproduce as back-referencing to individual comments on this issue will become confusing.

There are many different configuration settings (particularly on the text format / CKEditor config) that might have some influence on the behaviour of Insert. Therefore, I need instructions, even better with some screenshot(s), to recreate such individual setups on a pristine Drupal instance. Thanks for testing and using the module!

@nitrocad: Thanks for trying out the dev version. I am unable to reproduce the issue. I have set up a fresh instance with latest Drupal core, installed the Insert module, activated it on a text format where CKEditor image is in the toolbar, saved that text format to have the Insert specific attributes and tags added, with the result of being able to insert an image without any problem. I just experienced a minor issue that would make it to the log, which is fixed with the most recent commit.

Could you please open a separate ticket with steps to reproduce, ideally on a fresh standard Drupal installation? The error appears when saving the text format or when inserting an image?

The attributes should not just be removed because the Insert module might also be set up on a text format that has the CKEditor image module disabled. The function adding the tags and attributes should check if tags are existing already and add the attributes to those if they are not already set, but maybe there is some conflict…

I am going to revisit the existing tests to also work with the updated module code and the plan is to create a beta release right after, so maybe next week.

At least created a dev release for the moment: 3.x-dev →

This should cover basic compatibility. Bugs are very likely, and some things not yet sorted out properly are still in progress. Anyway, feel free to check out the dev release and open issue tickets for it. Please note the sub-modules have not been touched yet.

Please do not report individual issues on this ticket to keep the focus here on the general topic. Thanks.

Thanks for the information. However, I will focus on making a proper release as per #3314446 📌 CKEditor 5 compatibility Active instead of putting more time into this specific issue. I think that makes most sense. Once done, I will create another 3.0.0 beta release which should also sort out this issue. Not sure this will be a matter of next week already, but it should not be away a lot further than that.

I have refactored the code along with attaching to CKEditor 5 instances. This seems to work ok, but it will need some testing before uploading it. I'm trying to reduce complexity for the initial release, therefore:

• The alignment controls are planned to be removed as this can be done very nicely in CKEditor 5.
• Handling of the image caption is also planned to be removed. It can also be done very nicely in CKEditor 5 and safes a lot of complexity in the Insert module code.
• Rotation controls might not be part of the first release.
• Not yet sure about the future of the sub-modules insert_colorbox, insert_media and insert_responsive_image; have not touched those yet.

I've just taken another look into this, and managed to insert an image into a CKEditor 5 instance. It will require some effort to make it work properly without errors, but maybe I can start with a stripped down version really just plain inserting again. As far as I manage to aggregate the necessary time, I plan to trim most of the abstraction to make the module code simpler. After all, it's unlikely there is any other editor used than CKEditor anyway, considering it being so tightly integrated by now. Consequently, I can shape the module to insert into CKEditor instances and textareas only, making things a lot easier.
I can't promise anything just yet, but I'm taking a look at solving this and will give an update as soon as possible—end of February at the latest.

I can also add a check on that line (which I did in the attached patch set), but without steps to reproduce, it's difficult to fix the issue. However, I guess the next step would be to just cut off the Insert module's CKEditor interface as it's obsolete anyway. After all, basically everything needs to be reimplemented if it's supposed to be usable with CKEditor 5 eventually.

Ok, I can see you are using the responsive_image module. I can see the warnings in the log when I activate insert_responsive_image. That said, I have no issue using the Insert module with the a textarea as well as responsive_image and insert_responsive_image being enabled. I can upload images and insert images, also after saving the node and editing again. Please provide exact steps to reproduce the error, ideally starting with a clean and fresh Drupal installation as I need information on the setup. Otherwise, I am unable to help. The insert_responsive_image module is very experimental, does the problem also occur when not using insert_reponsive_image?

I have attached a new patch set that should fix the log warnings, it also contains the contents of the previous patch, yet I unfortunately do not expect it to solve the issue you are experiencing.

Thanks for the stack trace. I can see there might be a problem in the code. I attached a patch potentially fixing the problem. It would be great, if you could try out the patch. If it does not work, it would be good to have the steps to reproduce the error starting with a fresh and clean Drupal installation. For whatever reason, the Insert module works for me on plain text areas in Drupal 10. But there is no CKEditor instance supposed to be anywhere on the page.

@sd123: This issue is about inserting images in textareas. If you are using textareas, please reopen the issue and provide the steps to reproduce the issue. If you are not using textareas, but CKEditor instances, please note the Insert module is not yet compatible to CKEditor 5. If you are using CKEditor 4, please create a separate issue. If you are using CKEditor 5, please refer to issue #3314446 📌 CKEditor 5 compatibility Active . Thanks.

Fixed in 8.x-2.1 → and 3.0.0-beta3 → .

Fixed in 8.x-2.1 → and 3.0.0-beta3 → .

Thanks for filing the issue. This should already be fixed in 3.0.0-beta2 → per issue #3381683 🐛 Duplicate function error insert media module Fixed . Please reopen if the problem still exists in 3.0.0-beta2.

@joro78: Unfortunately, the Insert module is not compatible to CKEditor 5 at the time of writing. Please check #3314446 📌 CKEditor 5 compatibility Active for more information.

Thanks for submitting the issue. It appears to be a bug, because it should be possible to insert an image as a link without having to apply any changes. The idea of the insert-link.html.twig template though is to be specific for files, in the sense of being agnostic to image specifics. If image specific attributes are to be picked up, the idea would be to create a custom template override per (admin) theme.

However, there was supposed to be a proper default with the link text being the file name. This does not work at the moment. The attached patch fixes the issue, so now the file name should be picked as the link text by default.

Optimised the patch. The global CKEDITOR variable is still supposed to be there even though there are no instances. That is why the editors/CKEditor.check() function returns true detecting CKEDITOR. However, CKEDITOR.currentInstance is not set, which is what to detect has been missing in the Insert module code so far. If that has worked before Drupal version 10, maybe the CKEditor contributed module has a different way of setting CKEDITOR.currentInstance. Anyways, the patch fixes that.

Thanks for submitting the issue. I am able to reproduce the problem when there is no CKEditor instance in the form. It does not look like something introduced recently. I have attached a patch that should fix the issue, though it would be nice to test the patch a bit more before merging. Along with fixing the error, I also added the behaviour to automatically pick the first text area for inserting if no text area had been focused yet, just like it works for CKEditor instances. That functionality was just also missing, so it seems the case there being only text areas, but no CKEditor instances in the form was just not covered so far.

Thanks for creating the ticket.

Since this issue is related to another third-party module, it would be a new feature, rather than a bug in Insert.

The purpose of the Insert module is to provide client-side functionality easing placing an uploaded image in a text field/editor. Adding manipulations at the time of saving a node is out of scope for the Insert base module. That said, I could imagine a sub-module to Insert that would have the Insert core module and File (Field) Paths as dependencies, which would then apply the path alteration upon saving the node. (Or even just manipulate the paths provided by File (Field) Paths client-side, so the designated paths of the uploaded files would already be placed by Insert before saving the node.)

However, I regard this more an issue to be solved by File (Field) Paths itself as per the linked issue 🐛 CKEditor Image Insert with FFP not (quite) working Active , because the circumstance of paths being temporary until saving the node already exists in File (Field) Paths without using Insert, it just becomes more prominent by using Insert and other modules similar to Insert would also be affected by the behaviour of File (Field) Paths—I can see there is a patch on the linked issue. It would be best to be solved in File (Field) Paths.

Released 8.x-2.0 → .

Released 3.0.0-beta2 → .

There have been no updates to the insert_media module, so there are no hooks that could have been skipped. Have you tried reinstalling the insert_media module?

Not sure what might be the issue here as I did not run into that myself locally yet. Does the error also appear on a clean installation? What would be the exact steps to reproduce the error from a clean Drupal installation?

Thanks for filing the issue. I've attached a patch altering the hook name as mentioned, hopefully fixing the issue.

Confirming that Insert currently works with CKEditor 4 only. Upgrading to Drupal 10 is possible using Insert module version 3 → now, so there is no need to install the relevant patch separately. However, it is not yet compatible to CKEditor 5 unfortunately. Please refer to the related issue #3314446 📌 CKEditor 5 compatibility Active for potential updates on that matter.

Patch is merged and 3.0.0 beta release → is created.
If things are fine, will make a final 3.0.0 release within the next few weeks.
Thanks to everyone involved here.

(Feel free to reopen the ticket if there are additional questions, for me to notice there is continuing activity on the ticket. I just close tickets if there is no more response after a while as it's unfortunately very common that communication just stops at some point.)

@VasyOK: It seems you did like I confirmed things to be working. There are problems if the image is encapsulated in an a though, such will not work unfortunately, but I'm not sure about you whole template setup. Can you post your whole custom template, so I can try to reproduce the issue you are experiencing?

@useernamee: As to what I understand about what you'd like to achieve, this is a feature that works by just activating the description on a file upload field. It's preconfigured in Insert for when inserting files that the description is used as link title instead of the filename, if the description is enabled on the file upload field. You can look into the insert-link.html.twig to see the default mechanism. Or is the description supposed to be taken from some other input element?

Did you follow the configuration instructions → to set up the Insert module?
Please note Insert does not work with CKEditor 5 and works with Drupal 10 using this patch → only.
If you've checked all this, there should be at least some output in the dev console and/or in the Drupal logs regarding the failure. Please provide that and, ideally, the exact steps to reproduce from a fresh Drupal installation. Thanks.
I'd also recommend rather using the latest 8.x-2.x version, although it's in beta.

(Switching this to a support request as until it's confirmed that it's not a configuration issue.)

Since some time passed on this issue, I have submitted the patch set from comment #5 and am setting the issue to fixed. Feel free to open a new feature request if additional functionality is desired. Just be sure to include a detailed description of the desired functionality as mentioned in comment #7.

Snater → created an issue. See original summary → .

@priyankabehera: This issue is about migrating the Insert module to CKEditor 5. Please understand this is not the place for general migration support. I am not a Drupal expert who would be the proper person to provide such. Generally, you should upgrade your Drupal 7 instances to Drupal 10 until January 2025. Otherwise, your site will potentially be vulnerable to malicious attacks.

As for the Insert module, it is possible to upgrade to Drupal 10 as per the patch set provided on a separate issue ( https://www.drupal.org/project/insert/issues/3354931 📌 Drupal 10 compatibility Fixed ). A Drupal 10 compatible release of the Insert module featuring that patch set is ahead. However, so far, you will need to run the CKEditor 4 legacy module ( https://www.drupal.org/project/ckeditor → ), which, as of now, is supported until end of 2023 only.

If you want to continue running Insert, it is possible to upgrade to Drupal 10, though an upgrade to CKEditor 5 is not possible at the moment.

Thanks for the patch!

Feel free to reopen if the issue is still relevant.

Just released 8.x-2.0-beta4 → . In about four weeks, unless there are no serious bugs, there will be another beta removing code deprecated per issue 3264463 🐛 Fix bugs of D7->D9 insert settings migration Fixed . That will then, hopefully, be the base for the final 8.x-2.0 release. As soon as that is done, this issue can be closed.

While 8.x-2.0 will be compatible to Drupal core < 10, version 3.0 will be compatible to Drupal core 10 only and contain necessary fixes as per issue 3354931 📌 Drupal 10 compatibility Fixed .

Feel free to reopen if there is still an issue.

I'm not precisely sure what you are trying to achieve.

With the patch set I had attached earlier, I can place the alt tag into the template, the same should work for the title. It also works in insert-colorbox-image.html.twig:

...
{%
  set attach_content = {
  id: id,
  content: ['alt'],
}
%}

<div data-insert-attach='{{ attach_content|json_encode() }}' data-insert-type="{{ field_type }}"> </div>
<img .../>
...

However, it's not yet possible to have the element in the a tag. The following does not work at the moment if that is what you trying to achieve, the synchronisation removes necessary DOM structure. Achieving this would require some more look and I'm not sure whether this would actually be out of scope because the module might become too complex:

...
<a ...>
  <div data-insert-attach='{{ attach_content|json_encode() }}' data-insert-type="{{ field_type }}"> </div>
  <img .../>
</a>
...

Could you post some code how you would image your customised template to look like?

Thanks for checking. Forgot about the submodules, there is also another occurrence of hook_field_widget_form_alter. Updated patch attached.

The Insert module is dead simple which is what I need because most of my users are not tech-savvy.

I absolutely agree with that statement. On point. 🙂

Drupal 10 by itself is probably not so much of a problem, I made a patch on the separate issue 📌 Drupal 10 compatibility Fixed , but the switch to CKEditor 5 is. For now, anyone upgrading to Drupal 10 could install the CKEditor 4 legacy module → along with that patch (which will eventually be released in a separate new major version), but that is not a sustainable solution of course.

Unfortunately, the module is currently maintained by me only, and I'm just spending my spare time on it. 🙈 It would be nice to keep the module alive, not just because I put in a lot of effort to create the Drupal 8 version, but because I still see a valid purpose of the module, yet it's not a situation to make promises.

The Insert module is kind of an interface between Drupal core's field widgets and CKEditor. So far, I had been most struggling with documentation on the Drupal side in terms of the CKEditor integration. I had tried rebuilding on top of the starter template of the CKEditor 5 Dev Tools module → , but there was no success back then. It's cumbersome scanning through core's source code figuring out how to interact with CKEditor instances from the Drupal environment.

Attached a patch set that fixes the issues for me, although I just did some little testing if the Insert button shows up again and inserting an image basically works.

The core requirement would need to be bumped directly to version 10 without backward compatibility, because Twig has been upgraded to version 3 along with Drupal 10, which requires changes to be made in the template files. Drupal 9.2 had deprecated hook_field_widget_form_alter, which is superseded by hook_field_widget_single_element_form_alter.

Of course, the CKEditor legacy module has to be used as of now. As for upgrading the CKEditor dependency, there is a separate issue: https://www.drupal.org/project/insert/issues/3314446 📌 CKEditor 5 compatibility Active

Setting this ticket to major priority, which I'll also assign to the CKEditor issue to draw attention.

Let's still keep this one fixed as it's purpose specifically refers to automated fixes by the Project Update Bot, which is kind of finished subject. Let's rather have a separate task where we bundle any compatibility issues that need to be resolved manually.
Please open a separate task with your findings, otherwise I will create the separate task when I get to checking Drupal 10 compatibility. Thanks!

Having a bit of time to try this out, it does not work just out of the box unfortunately. But I have attached a patch set that would achieve being able to use the way I described in the previous message. Using the patch, I can simply copy insert-button-widget.html.twig into my backend theme's folder and move the checked attribute to another radio button which would then be the default alignment.
If there is no custom backend theme yet, creating a sub theme is pretty straight forward: https://www.drupal.org/docs/theming-drupal/creating-sub-themes →

I spend the time trying the solution I suggested in my previous message. Unfortunately, it does not just work at the moment because the JSON passed to data-insert-attach expects attributes to be provided. Fortunately, it's easy to fix, which is what I attached a change set for.

Also important to note is that, in the template file which I placed in my backend theme's folder, I eventually used:

<div data-insert-attach='{{ attach_content|json_encode() }}' data-insert-type="{{ field_type }}"> </div>

Note the space inside the div node. If the code is empty, or a self-closing tag is used, the placed template will be messed up resulting in erroneous behaviour. Therefore, the tag should just not be empty.

Yes, I guess this one can be closed with Drupal 10 being release. I was just not sure if it is supposed to remain open for the version 10 release cycle, but I guess not. Last patch is also more than half a year ago.

Feel free to reopen if the issue is still relevant.

You very likely have image uploads enabled in the CKEditor plugin settings of the text format you are using (see attached screenshot). This is documented in the Insert module documentation: https://www.drupal.org/docs/contributed-modules/insert/configuration#s-c... →

You have to turn off this setting in order to use the image properties dialogue in combination with the Insert module. Go to /admin/config/content/formats and configure your text format unticking the checkbox at "Enable image uploads" in the CKEditor plugin settings section.

Thanks for using the Insert module. You could try to just overwrite insert-button-widget.html.twig, putting a copy of the file into your backend theme's folder and moving the checked attribute to your desired default radio input. That could already do the trick.

If there was a module or field setting for it, it would not work much differently, just that the setting would then be injected into the template file instead of having to overwrite template. If overwriting the template works, I would suggest using that method for now rather than adding a setting as this is so far the first time the feature is requested.

Just scanning through the code—after all it has been a while since I looked at it in depth—I came across a functionality that actually seems to set a node's content in Insert version 2.x: https://git.drupalcode.org/project/insert/-/blob/8.x-2.x/js/Handler.js#L205

In your template file overwrite, you should be able to define an object similar to attach like so:

{%
  set attach_content = {
    id: id,
    content: ['title'],
  }
%}

And attach the object to the node in the same template overwrite:

<div data-insert-attach='{{ attach_content|json_encode() }}' data-insert-type="{{ field_type }}" />

If your code works for you and you are fine using Insert version 1.x, that's just alright of course. But I would not want to merge in the patch because it will also remove the wrapping node if there is no text. '<div>__title__</div>' would become ''. And what about the node having attributes etc. The Insert module placeholders should be agnostic to their environment. '<div>__title__</div>' becoming '<div></div>' would be expected behaviour. Altering the behaviour with a custom patch would of course be one way to customize the functionality.

Since it is a prerequisite for me to use image styles on the images inserted into the body, I had to figure this out using the Media module. Although the UX is not good, it is possible:

What I did is adding view modes on the image media for each image style I would like images to be inserted with. Each view mode is assigned a corresponding image style. These view modes then need to be enabled in the relevant text format configuration.
Now, an image can be placed using the Media Library button in the CKEditor toolbar. After placing, the "Edit media" button next to the image will need to be clicked in order to change the view mode that corresponds to an image style. Here is a good video with more elaborate instructions: https://youtu.be/JuCbL8g96Iw
Overriding a specific view mode template, it should be possible to also insert the structure required for Colorbox.

However, while the UX of the Insert module is not perfect, so far it's still better than using the Media Library for tasks like applying image styles on inserted images. Activating the Media Library, images can be placed in any editor / body field which is not what I would prefer to be possible. Also, the view modes added for the image might not be desired to show up when using the Media Library for placing entities other than images. And then of course the UX of having to adjust the view mode after inserting the image, instead of at the moment of inserting, is problematic. I also agree to what is mentioned, that it might also not be desired to have images stored centrally in the library, but rather have them uploaded and managed on node level.

While I took the bite of compromising on the UX by using the Media module, I can certainly see reasons for the Insert module to continue existing at this point.

Feel free to reopen if still relevant.

It's been a while since the ticket was created, yet I have tried reproducing the issue. The Insert module appears to work for me in combination with the IEF module. I have set up a content type that has an image field with the Insert module configured, as well as having a reference to another page/node that features an editor. Uploading an image, it is possible to insert the image into the editor field of the referenced node.

Relevant documentation on the Insert module is here: https://www.drupal.org/docs/contributed-modules/insert →
Please note that the Insert module does not work with CKEditor 5 at this point.

If the ticket is still relevant, it would need more information on the actual setup of combining the Insert module with the IEF module in order to provide more specific support.

It's a a while ago, sorry, but if it's still relevant, are you making sure the Colorbox libraries provided by the Colorbox module → are loaded as per the Insert module documentation → ?

Thanks for the patch. Merged with small adjustments.

I just tested setting up Drupal 9 with the Insert module from the branch 8.x-2.x on PHP 7.4 and then switching to PHP 8. I did not experience a particular issue, not in general, and neither related to the Insert module. It would be interesting to examine the logs when that error appears, that should give a good hint about the issue.

Thanks for the patch, it does not look to be PHP 8 related unless I miss out on something; but it might make sense to have a check there anyway. I attached an optimised version, because it would not make sense to even process the foreach when there are no $text_formats if that is indeed the problem.

Improved patch.

Been a while since the bug report, but here's a patch that should fix the issue.

I assume you tried to switch from Insert module version 8.x-1.x to 8.x-2.x.

8.x-1.x used custom widgets like the "insert_image" widget. These have been removed in version 8.x-2.x, see also the release notes of the latest release (section "Updating from 8.x-1.x"): https://www.drupal.org/project/insert/releases/8.x-2.0-beta3 →

As per https://www.drupal.org/project/insert/issues/2976986 → , the Insert module would first need to be set up on the relevant fields again, then it should work and you should be able access the form display management page. Unfortunately, there is no smoother update due to that basic architectural change.