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.My entities appear to be "energizing" and decaying according to my decay profile, however I can only tell when I look at the database tables for the radioactivity fields. When I edit the entity, the field always shows an initial value that I set. It never changes. The same when I allow the value of the energy to be displayed on the Fields Display or from a view.
In field_data_field_radioactivity, the column field_radioactivity_radioactivity_energy shows various random float values indicating that the energy level has been rising and falling over time.
However, in field_revision_field_radioactivity, the column field_radioactivity_radioactivity_energy shows either 0 or 100 (my initial value).
It makes sense not to store the actual data in the revision tables as you would likely not want to reset the energy on each revision, but these values need to be overridden when the entity is loaded in order to display the correct energy values.
I am using the revisioning module, which I fear may be the culprit. I have not yet tested with it turned off. I'll post any follow up information I can.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | bootstrap-radioactive.patch | 4.03 KB | netsensei |
| #1 | revisions-1.patch | 1.92 KB | kid_icarus |
Comments
Comment #1
kid_icarus CreditAttribution: kid_icarus commentedSo here's a patch that should fix the issue at least for nodes using revision. This needs to be abstracted to use any entity with revisions, but this is a step in the right direction and solves the issue for me.
Feedback appreciated :) <333
Comment #2
arcaneadam CreditAttribution: arcaneadam commentedI can confirm that this is an issue.
This really needs to be merged in. Using a entity_id in the revision_id column is wrong and breaks even on some sites that don't use revisioning extensively.
Comment #4
tcmug CreditAttribution: tcmug commentedI tested this very briefly and found that it did not break any existing functionality and that it actually fixes the issue - so I've committed this to the head.
Closing, thanks!
Comment #5
amcgowanca CreditAttribution: amcgowanca commentedAwesome! Great work!
Comment #6
japerryUnfortunately this commit breaks commons, and any other site that uses OG when posting content with revisions. See #2249263: Cannot add post to group for more info.
Comment #7
netsensei CreditAttribution: netsensei commentedI'm looking at a similar case: we use revisions/workbench for our content but radioactivity can't deal with them without a fix since it does a revision_id = entity_id.
I note two issues here:
1/ japerry makes a good point: Radioactivity should be able to deal with revisions without breaking other modules
2/ the patch of kid_icarus is indeed a band aid fix and should cover other entity types too.
The biggest hurdle here is that this part of code is executed from a DRUPAL_BOOTSTRAP_VARIABLES bootstrap context. So we don't have access to easy to use API's like the Field API or the Entity API. I don't think we should re-implement whole parts of an existing proven API because we can't access them.
I think we can do a better job at loading the stuff we need in radioactivity-boostrap.inc
https://www.drupal.org/project/js does a great job at providing a light, configurable alternative to a full bootstrap.
I think it's worth looking how that module bootstraps Drupal.
Either we re-implement their logic to create a more elegant bootstrap, or we depend on their API to bootstrap Drupal for us through hook_js().
Comment #8
netsensei CreditAttribution: netsensei commentedI went ahead and merged some parts of the JS module into the bootstrap. This will only bootstrap the essentials.
Notes:
1/
The $dependencies array defines which modules get loaded. Obviously, we don't know which modules are required to load an entity. Field collection, Entity Reference, etc. need to be added to $dependencies. Perhaps we need to expose a hook or something, like the JS module does?
2/
I still use node_load and node_save to save my entity. entity_load / entity_save would be better since that would also allow us to add radioactivity to terms, commerce products, etc.
3/
Related to 2: come to think of it, Radioactivity uses the Field API so we can add a radioactivity field to any fieldable entity type. Technically, you could do crazy stuff like add radioactivity fields to field collections or fieldable panel panes. Not something you would want to do, but theoretically possible. Do we want to go so far as to put effort in covering those use cases too?