Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.In the insert_element_process() function, the insert_content() is called to get the HTML for insertion.
I do not understand why is the variable $field['widget'] used instead of simplyu $field, that would allow for example to know the name of the processed field.
This could be very signifiant for modules like lightbox, for which it could be possible to use the field name for grouping.
I understand that modifying such a thing means lots of changes, even in related modules :(
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | insert-field-variable-for-insert_content-function-1275930-4.patch | 7.21 KB | B-Prod |
| #2 | insert-field-variable-for-insert_content-function-1275930-2.patch | 1.1 KB | B-Prod |
Comments
Comment #1
quicksketchInsert module is only related to the field on the add or edit forms (e.g. the "widget"). It doesn't matter in any way if Insert has been used when viewing a piece of content on output. Typically injecting settings into $field should only be done with that has an effect on the data itself.
Also by saving the values in $field['widget'], it makes it so those settings are appropriately removed if the user changes the widget later (such as to a widget that doesn't support Insert, like Plupload).
Comment #2
B-Prod CreditAttribution: B-Prod commentedActually I do not want to save anything in the $field settings.
The purpose is to give to other contributed modules the $field variable entirely, so these module could use the populoated value in $field variable, like field_name for example.
This only concerns the element processing operation, nothing else.
Here is a patch to show you what I am speaking about.
The real problem of this change is to update the others related modules so they use the $field variable and not the $widget one. I can help you for that if you need, I understand it could be a big work.
Comment #3
quicksketchHm. I know I had a reason for using $widget instead of $field, it seems odd that I would intentionally restrict down the information.
To start, you could go through all the integrations that Insert module includes (all the .inc files in "includes") and update those. Right now this would be a sloppy change not updating any of our own variables.
Comment #4
B-Prod CreditAttribution: B-Prod commentedI also updated the theme arguments in hook_theme() function, so those who use for example some classes with field name to style their contents could now avoid to duplicate their CSS rules.
I added $field variable explanation in the applicable template files.
Comment #5
quicksketchI don't think we can change these settings at this point without breaking a lot of sites, both in theming and in add-on contrib/custom modules. At least as far as D6 is concerned, we're not going to undertake major API changes at this point.
Comment #6
B-Prod CreditAttribution: B-Prod commentedThis is very sad, since it causes a big restriction in the possible way to react on an insert action. Could we hope to ever see such improvement in the 7.x version though?
Comment #7
quicksketchIn Drupal 7, widget and field settings are very explicitly separated, they're even on separate screens in the UI (field settings first, then widget + field settings on the second page). In that situation I don't think we could move them at all, and if we did, it would have to be in a 2.x branch.
Comment #8
B-Prod CreditAttribution: B-Prod commentedBoth can easily be retrieved from the field instance. If you need some help to work on a 2.x branch, I would be glad to help. In such case a list of other improvements/new features would be a good start for thinking about this new branch. Just let me know...
Comment #9
Snater CreditAttribution: Snater commentedBrowsing through old tickets while working on the module's D8 version, I am closing this ticket due to its age. I had a look at the desired change and, although it is reasonable, it would require a new major version (7.x-2.0), as pointed out. That said, I am sure quite some modules relying on the interface that would be changed, might not adapt that interface change, as module administration is abandoned or module maintainers concentrate on D8 versions by now. Site owners, upgrading Insert in good faith might end up with a broken page. I think time is up for implementing interface changes in the module's D7 version.