Compatibility to Colorbox module

There has been some talk on that on https://www.drupal.org/node/2872520 : The "Manage display" options of the content type influence the native field output only. Retrieving those options is out of scope for the Insert module and would probably cause more conflicts than benefits.
But if it was possible for the Insert module to have the Colorbox module render the HTML output, the functionality could most likely be implemented. Yet, I do not know the processings of the Colorbox module. At best, the Insert module would just call the Colorbox module's formatter. All in all, some research is required and, maybe, some work in the Colorbox module first.

I acknowledge the Colorbox module being very popular and implementing a sub-module depending on the Colorbox module would probably make sense, yet I am only working on the Insert module in my spare time... And before implementing additional features, I would prefer to release a stable version first. But the D7 migration functionality is still missing implementation and I am not very much into the D7 Insert module processings, which limits my motivation...

Switching the category to feature request as the combination with the Colorbox module was not specifically considered so far. The Insert module is not broken, it is just missing the interface...

Current options

You could override the insert-image template in your theme. However, I would not recommend that as it would reduce the module's flexibility.

For applying some gallery/pop-up functionality the Insert module comes with an image effect mock (see Drupal 8 > New Features on https://www.drupal.org/project/insert) which can be applied to image styles to wrap the images in <a> tags linking to the original full-size images. Then, any gallery/pop-up JS script can be applied quite easily by adding it to the theme.

You can pick one of the two option mentioned above:

• Either overwrite the insert-images template file in your theme an have the inserted HTML match what the Colorbox JavaScript expects;
• Or apply the Insert module's mock image effect to the image style you display the gallery thumbnails with; though I am not sure whether this is compatible to setting the field display widget to Colorbox. Still, you would probably need to initialize the Colorbox JavaScript manually using some small custom JS script in your theme.

In general, there is nothing Colorbox-specific to it. Any JavaScript gallery script may be attached. It is just that, at the moment, it is not possible to use any functionality of some other Drupal module, like Colorbox. Everything is done using plain JavaScript. In that sense, you would not even need the Colorbox module, but could use the Colorbox jQuery script alone by adding just that to your theme.

I use the second option on a site by having the images rendered in the image style I attached the Insert mock effect to. A script in my theme scans the page for that field's content, specifically for the <a> tags and initializes the gallery on those. There is not much to it, it is just that something like the Colorbox module display mode settings cannot be administered via the back-end. (Though that would be a great thing to have.)

For Colorbox it should boil down to something like:

(function($, Drupal) {

  Drupal.behaviors.myThemeGallery = {};

  Drupal.behaviors.myThemeGallery.attach = function(context) {
    $('...image field class...', context).find('a').colorbox({ ...options... });
  }

})(jQuery, Drupal);

Hello
I managed to get over the problem for activate gallery with insert module
by modifying the template insert-image.html.twig
line 48
change
<img src = "{{ url }}"
to
<img href="{{ url_original }}" data-colorbox-gallery="gallery" src="{{ url }}"
I'm happy to share with you

why this code

{% if link_to_original %}
  <a href="{{ url_original }}"{% if class %} class="{{ class }}"{% endif %} data-insert-type="{{ field_type }}">
{% endif %}

...

{% if link_to_original %}
  </a>
{% endif %}

Yes, overriding the template is one solution of how you can achieve attaching a gallery.

As for link_to_original: The Insert module comes with a image effect mock which you can apply to an image style. If you use the Insert module to place an image in a style which the effect is applied to, the image will be linked to the original / full-size image. By making use of that, you can also apply some gallery script. (See also comments above and the short description on the module page under "New features".)

I have implemented a sub-module interfacing to the Colorbox module. It may be configured just like Insert in an image field's widget settings on a content type's "Manage form display" tab. I think that this is a decent solution to interface to the Colorbox module. Would be nice to get some feedback on the functionality.

Applied some improvements that seemed to make sense. (Beware that setting keys had to change, so previous insert_colorbox settings are lost.) Hopefully, that is it for this ticket.

Hi, I gave this a try and it worked quite nicely. However, unless I missed something it appears to be an all or nothing choice. In D7 Insert, colorbox versions of image styles got automatically created and then could be chosen on a case-by-case basis. What I see with what you've done is if I enable the Insert Colorbox option, every image I insert gets the Colorbox treatment whether desired or not. Is that correct? If so, is there a way to make it optional?

Thanks.

Thanks for your feedback. I have to admit I have neither been, nor currently am a Colorbox module user, so I am not sure about getting things right in terms of interfacing to the Colorbox module. Therefore your feedback is greatly appreciated.

First off: Yes, you are right, currently, there is only every image processed for Colorbox or no image.

I did a quick test of Colorbox + Insert in D7 and D8. Since Colorbox's functionality changed considerably from D7 to D8, I am not sure, D7 behviour can be reflected 1:1 in D8. In D7, Insert offered particular hooks (hook_insert_styles, hook_insert_content) that were implemented by the Colorbox module to provide and process custom Insert styles. In D8, Colorbox, as far as I am aware, is meant to only be a formatter. Hence, implementing another module's hook would not be in the scope of Colorbox itself anymore.

Buf of course, it should be possible to implement such a hook-based interface in the insert_colorbox module, so every existing image style would doubled in a Colorbox version, as it appears to have been in D7.

Apart from that, there already is a very similar functionality in Insert, which could also be adapted: Insert features an image effect mock (or dummy image effect) that can be applied to an image style and does nothing to an image itself. Yet applying the effect results in linking the inserted (styled) image to the original (full-size) image. This method could be implemented to make only image styles that have a particular effect mock process images for Colorbox. That might be more flexible but is not as automatic.

The change should reflect the combination of Colorbox and Insert module in D7: Image styles are duplicated in a Colorbox version, their names prefixed with "Colorbox". Using such a style when inserting an image will use the Colorbox template / process the image for Colorbox. Eventually this is the more user-friendly alternative as no additional configuration steps have to be taken after installation.

In D7, Insert-Colorbox settings appear to have been global--you do not have to readjust settings on every content type, but are stuck with that single set of settings. In the current D8 implementation, settings are per field. Changing that is not a big deal, yet I wonder what makes more sense. (In theory, it would also be possible to implement setting defaults globally with the option to adjust per field.) Any opinions/wishes on that?

@Snater, as someone whose level of expertise has its limits, I very much appreciate your thorough explanation. While it would be nice to have a relatively simple 1:1 behavior, that is not necessarily my end goal. My end goal, if possible, was to be able to retain the functionality without having to make a lot of changes to existing code throughout my website. If I can accomplish or come close to accomplishing that by other means, I'm okay with that. However, if, as you say, the purpose of Colorbox changed in Drupal 8, then I may have to find a new solution.

As to your last comment, even I prefer having the settings per field so I would not want that to change.

I was not aware of that functionality you said is currently in Insert. I'm going to take a look at that and see if that might work. I'll let you know.

I took a look at that Insert mock effect and if I could have that effect (or something similar) get, as you suggested in #15 & #17, the Colorbox treatment, that would be ideal. I could easily create image styles for Colorbox that in D7 got created automatically. This would enable me to pretty much provide my site's users with what they're accustomed to and not have every image on the site be Colorbox enabled.

While I like the image effect mock method, I suppose it is not very intuitive. Currently (as per #16), in 8.x-2.x, Colorbox image styles are created automatically like in D7. With the most recent change (#21), I spent another couple of hours moving the insert_colorbox settings from the field to the global Insert module configuration. Basically this is just like it was in D7 and that implementation also made it possible to easily implement migration from D7 to D8. I hope this feature to be functionally complete now.

I installed your updated dev version and now seem to have lost the Insert button. When I go to /admin/config/content/insert, I see the Insert Colorbox section. However, when I go to a node and upload an image, no Insert button. Perhaps I missed a step?

I just installed the modules on a new Drupal instance and the Insert button is there. If you pulled the new dev version or overwrote the Insert module files without reinstalling the Insert module in the Drupal instance, I could imagine the most recent change on #2976986: Make Insert extend File/Image field widgets causing some interference: On the Insert module configuration page, there is a new section "Supported Widgets". The text field for image widgets should be filled with "image_image" by default. Can't think of anything else at the moment, as the only default configuration step to make the Insert button appear is to enable at least on style in the Insert section of the field widget configuration.

That was it. I had just overwritten the module files. After uninstalling and re-installing the Insert module, the button returned and all the new functionality was there. As you said, pretty much like it was in D7.

For someone who admitted not being a Colorbox user, you have my utmost appreciation and thanks for taking this on and developing a solution. I also have some pretty picky users who will be quite pleased. For that, I also thank you. :-)

Sounds great. Thank you for testing and assuring proper behaviour of the feature. If you and your users are pleased, others will be as well. I will have the ticket rest for another couple of days to allow some more time for others to give feedback and eventually set the ticket to fixed.

Hi, this is just a curiosity question. Could any of the changes you made to the Insert and your Insert Colorbox module have had any impact on text formats? I recently had a situation here where it was discovered that one of text formats I had defined was deleted. I'm investigating this and looking at everything that might have been going on around that time. Thanks.

I cannot imagine any change deleting a text format, but that does not mean, it could not happen. :-/ I would be extremely surprised and might just stop developing forever in utter shame!

I could imagine that the "allowed HTML tags" setting gets messed up somehow when activating Insert on a text format and then saving the text format. But that functionality did not change from 1.x to 2.x (apart from for some additional tags/attributes required by Insert 2.x) and it is the only direct manipulation on text formats. That said, I have only done tests with the default text formats.

In 2.x, I have made assigning the process callback to form elements more generic (https://cgit.drupalcode.org/insert/commit/?id=2a8da51), so, in the future, Insert could be attached to any kind of field. But I cannot imagine that functionality doing any harm to a text format.

Thanks for the reply. I realized that I could have worded my post better. It was not meant to imply anything so I hope I didn't offend you. I was just looking at everything that was going on around the time of the discovery and working on the Insert was one of those things.

As I investigated further I found that the timing didn't fit. The text format was found to be missing a few days before I moved the updated Insert module up to my production server.

No, don't worry. I did not feel offended at all. On the one hand, I was just afraid of having made a mistake leading to data loss, on the other hand, I could not imagine such behaviour. The Insert module is not supposed to do operations that could lead to data loss, so I would have made a really big mistake… which would indeed be quite embarrassing.

I really appreciate testing Insert 8.x-2.x. But I am not sure, whether I would recommend using it in production yet. As far as I can tell, it runs stable, but interfaces and configuration might still change - on the other hand, Insert is not that hard to (re)configure.

I would really like to roll out 8.x-2.0 as soon as possible but, although 2.x is that much better than 1.0 already, I would also like to strip down the list of tickets along. It is not easy to aggregate that much time just out of idealism, but I like useful things and, while I do not need most of the features by myself, I think Insert is just a very, very useful extension that can become even more useful.
I am off for a few weeks now and will continue working on Insert then.

Setting to fixed; I don't plan to put more work into that as I think this feature is complete. For additional changes, individual issues should be created.