Node properties are not retained

Hi gaddman,
We did make some changes to the "save" process when working on Scheduler 2.x, but I think this was because 1.x was doing too many saves, and doing them in the wrong places. It might be that the property you had was being saved as a side-effect of Scheduler 1.x doing the wrong thing.

Here are some issues that might be related

• #2824038: Node is saved twice → was in May 2020 and was therefore in 8.x-1.2, before 2.0 branch was created
• #2977887: Nodes not publishing after Cron - conflict with Workbench Moderation → has changes relating to node->save(), these were done in May 2022 and therefore were in 8.x-1.5 and 2.0.0
• #3273938: Maintain backwards compatibility with 8.x-1.x action hooks and improve hook log messages → was only in 2.x

Can you give a bit more detail on the example you have, so that I can replicate it - is the property simply being created in a presave hook, or is it defined in a schema and just being set a value in the presave hook?

Thanks Jonathon,
Still doing some debugging but perhaps this will help point in the right direction. To answer your question though, I'm creating the property in that presave hook, literally just copying a field value (defined in the schema) to a node property (not in schema):

$node->my_property = $node->field_myfield->value;

I mentioned a postsave hook earlier but the value has already been lost in the presave hook so I think it's safe to ignore that. Although I've included it just in case it may be relevant. And I may well be getting confused, but it seems as though the value of my node's field has been lost.

In v1.5:
On initial save:

1. scheduler_node_presave: myfield=x
2. mymodule_node_presave: published=false so do nothing (don't copy myfield to node->my_property)
3. mymodule_node_postsave: published=false so do nothing

On scheduled publish:

1. scheduler_cron
2. scheduler_node_presave: myfield=x
3. mymodule_node_presave: published=true so copy myfield to node->my_property
4. mymodule_node_postsave: published=true and node->my_property=x so do some stuff

In v2.0.1:
On initial save:

1. mymodule_node_presave: published=false so do nothing (don't copy myfield to node->my_property)
2. scheduler_entity_presave: myfield has no value!
3. mymodule_node_postsave: published=false so do nothing

On scheduled publish:

1. scheduler_cron: myfield has no value
2. mymodule_node_presave: published=true, myfield empty so nothing to copy to node->my_property
3. scheduler_entity_presave: myfield has no value
4. mymodule_node_postsave: published=true, node->my_property not present so do nothing

Maybe some difference between the entity presave hook and the previous version's node presave hook? Or the order (scheduler module vs my module)?
thanks a heap!
chris

I've got some other funky stuff going on with form_alter hooks and trying to ensure my node_presave hook runs after the scheduler_presave hook, so I'll dig about with that. Most likely something I've done wrong here.

Found the problem. Version 1.5 uses a node presave hook and v2.0 uses an entity presave hook. My own node hook was originally getting called after the scheduler hook, and with the change to an entity hook it ended up being called before. That messed up my check for the published state, so changed how I do that and it's all fine now.

Thanks @jonathan1055 for the help!

Hey that's good, pleased you have solved it for your scenario. Do you think there is anything that should/could be done in Scheduler to avoid others having this problem?

Mmm, good question. If I generalise what tripped me up it'd be the following:

1. Using a custom module with a node presave hook; and
2. That custom module's hook must be run before or after Scheduler's presave hook.

I'm guessing that's not particularly common, so I don't think it'd make sense to change any code for this scenario.

Aside from that, some ideas from a documentation viewpoint that may have helped (I say these with no appreciation for what might be involved and also conscious that many people won't read it):

• A highlight list of the major, and especially breaking, changes upgrading from 1.5 to 2.0.
• Some guidance on choosing 1.5 vs 2.0 (besides core compatibility).
• Renaming this issue to something more related to the cause than the symptom.