Media entity support now in Drupal 8.4.x, what does this mean for the future of Insert Module?

https://groups.drupal.org/node/516820

Comments

Tytest created an issue. See original summary.

Snater’s picture

There seems to be quite some work left before making plans about adapting the Insert module, for example Re-create Image field widget on top of media entity to begin with. Ideally for any user of the Insert module, the Insert module's functionality would be replaced by some more integrated approach (see Support WYSIWYG embedding of entities other than files, the turnout of that ticket may be very relevant regarding the Insert module).

Of course, I am aware that there are other modules that allow embedding content inline, like Entity Embed which seems to inherit the principles of the Media entity architecture. However, those other modules lack particular use cases covered by the Insert module, especially in terms of usability. On the other hand, the Insert module, definitely, is not the ultimate solution itself.

From my (far away) perspective, Media entity is still in a stage to early to decide on the future of the Insert module. I suppose that, in the long term, it would make sense to adapt the Insert module to the Media entity module, if possible. Unless, of course, Media entity does not offer some equivalent usable functionality natively.

Additionally, a major and general problem of the Insert module is that the module's prosperity is very much driven by individual contribution. The D6 and D7 versions were, basically, coded by one single person, same for the D8 version. With that in mind, it is hardly possible to make long-term plans for the module.

Rewted’s picture

Thank you for the detailed response. My concern is more so am I making the right choice by implementing the insert module, I don't want it come back to bite me if/when Drupal has similar core functionality.

Snater’s picture

You are welcome. Your concern is totally valid.

I think it will take quite a while until the influence of Media entity on the Insert module's future can be determined. That said, by dropping the Insert module in the future, nothing would just break, since the content inserted using the Insert module is plain HTML stored in the content entities. Nevertheless, there may by some undesired effects, i.e. CSS classes getting dropped by the WYSIWYG editor's HTML clean-up routine, when editing existing content after uninstalling the Insert module and resetting the HTML white list.

But creating a migration routine should not be too hard because in the Drupal 8 version (not sure about the D7 version) every object placed using the Insert module can be tracked easily in the HTML via the "insert-type" data attribute. The principle would be to scan through all HTML content and shuffle around the particular HTML as required.

One thing left to mention is that the HTML placed by the Insert module is not very "individual". File links are plain <a> tags and as for images, the Insert module basically acts as a proxy for using the image button in CKEditor's toolbar. If you do not configure any custom CSS classes to be added in the Insert module configuration, do not enable icon links (as that HTML structure cannot be generated by CKEditor natively) and leave the image button in CKEditor's toolbar (see Notes on the Insert module's project page), there should be no problems at all regarding compatibility after uninstalling the Insert module and resetting the HTML white list, as far as I am aware. Because the image HTML placed using the Insert button is compatible to the HTML placed using the toolbar's image button. I will add that to the documentation after having done some testing.

Snater’s picture

Component: Code » Documentation
Status: Active » Closed (works as designed)

I updated the module documentation to better reflect the outcomings of this ticket. Closing this ticket as proper Media entity support is rather far future and cannot really be planned from the Insert module's perspective at the moment. It will be dealt with as soon as possible.