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.content.crud.inc Line 516:
module_invoke_all('content_fieldapi', 'read instance', $field);
But module_invoke_all do not pass arguments into hook function by reference. So, this call does not have any effect.
I'm suggest to replace this call with:
foreach (module_implements('content_fieldapi') as $module) {
$function = $module.'_content_fieldapi';
$function('read instance', $field);
}
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | content_599224_content_fieldapi_by_reference.patch | 3.13 KB | hefox |
Comments
Comment #1
markus_petrux CreditAttribution: markus_petrux commentedThis is intentional. External modules are not supposed to alter the field structure from here. This hook is implemented more like a broadcast message, to let other modules know a field instance is being read.
If you want to alter the field, you can use hook_field_settings_alter() and hook_widget_settings_alter(). These allow you to add form elements, and save values in the $field structure. That will be saved in the content field tables, and it will be available when an instance is read.
Comment #2
Anton Petrunich CreditAttribution: Anton Petrunich commentedhook_field_settings_alter() and hook_widget_settings_alter() can affect only new/edited field. But have can i change workflow for existing field?
For example, i have some taxonomy based files hierarchy. Each term is a file type with extension. When admin add new term in File Types vocabulary, i'm need to allow users to upload files with new extension. I'm prefer to implement this with cck fields cache rebuild and content_fieldapi hook (after patch applied).
Are easier solution exists?
Comment #3
Alan D. CreditAttribution: Alan D. commentedIs there a db column alter? There seems to be no way to actually change the data structure with the alter hooks. This could lead to a quick clean explosion of extensions of existing fields without the need to extend or create new ones.
Current use case, I have extended the geo module POINT widget to hook into a GMap popup. Easy and fast loading, as 100 coords will never have more than 1 google map at any one time, but I need to store the zoom level too.
Currently it looks like I will either have to extend the field (and break potential integration with other modules) or hook in with custom submit handlers inserted somewhere and handle the data myself. [I'll probably just hack the module as it is for my custom site with limited time to get it up and running]
The first is a dead end, as seen in the endless mods required by imagefield_crop, imagefield_extended, filefield_sources, ... for integration as each was a new widget. But in the case of imagefield_extended with the integrated data serialization of imagefield, the alter hooks made this absolutely painless and seamlessly integrates with just about any other module (cck 2.5+).
As such, I've reopened as a feature request for db columns / save data alters too.
Sadly, D7 fields do not appear to support dynamic columns, so I guess this is limited to the d6 releases...
Comment #4
hefox CreditAttribution: hefox commentedUse case: altering database columns for performance in a generic manner (changing blogs to rather large varchars, etc.). Can alter it via mysql, but not really the most sustainable choice.
Comment #5
hefox CreditAttribution: hefox commentedComment #6
markus_petrux CreditAttribution: markus_petrux commentedThere is an alternative method: use a separate table to record your data. Nodeapi allows you to keep it in sync with the node, etc.
Comment #7
hefox CreditAttribution: hefox commentedThat addresses Alan D's need (though I suspect he knows about it already by now), though unideal solution (performance, clutter, etc.), but doesn't address mine. There are other ways that address mine of course, but none very sustainable.