CCK date field shows blank after the node is published.

This seems to affect version 5.x-1.12 too. AFAICT, the problem is that function scheduler_cron invokes node_submit before node_save. Node_submit removes some fields, including cck date fields. See also http://drupal.org/node/217862 which says that node_submit should be called before node_save.

So what exactly is going on here? First I'm told node_save() is basicaly broken because it doesn't save CCK fields unless I call node_submit() before it.

Imho node_save() should do exactly what it says, save a node, CCK and all. if it doesn't save everything about a node, it's broken.

@skiminki, so I'm told that I must call node_submit() in the previous issue. But you're saying that's the problem? Please explain as these two issues conflict.

I agree you with that node_load() / node_save() should be enough. But the practice is to call node_submit before node_save, it seems. It's what node_form_submit does in node.module and that's what modules rely when saving custom node fields.

I'm still looking into this, and this is a bit elusive to me. It seems that some CCK-widgets behave badly on node_submit by killing values for some reason. More info later.

skiminki, thanks for looking into it. I have to say that it seems a mine field this one. Why's it not come up before I wonder? Is it rare to want to load a node, alter one item and then save it again? Imho this workflow is broken (buggy in Core?) if node_save() doesn't do what it should. Maybe we should provide a Core patch which changes to the name of node_save() to node_save_almost() ;)

But I have to say, the problem really isn't in the Scheduler module. I'd also like to say that at one time _cron() operated directly on the node table altering the status bit directly. I only added the node_load()/alter/node_save() because a couple of other module writers complained that their modules never got the chance to see the node alteration taking place by hook_nodeapi().

I'm seriously thinking of going back to direct table manipulation as I'd rather have a happy large end user base and just a few moaning developers rather than the other way around as it is now ;) As they say, "if the API doesn't work for you, work around it".

Ok, I'm beginning to think that node_load() / node_save() should be enough and it's actually not good to call node_submit() in between. By API docs:

• node_load() constructs the node from db
• node_save() saves the node to db

So far so good. But node_submit() is intended to process values after the core has updated the node object using HTML POST data when user submits a node form. This converts checkboxes to int values, dates from user-friendly form to seconds after epoch, etc. Just as it should. But it breaks when the HTML POST data is not inserted to the node object. This is specifically why CCK Options and CCK Date fields lose their values at node_submit().

Anyway, we need to fix this in our site sooner than later and I think we're just going to drop the calls to node_submit() in scheduler_cron() until a better fix is available. CCK Taxonomy is not our concern and a previous version of Scheduler worked just fine using node_load() and node_save() without node_submit().

I think that the habit to call node_submit() before node_save() comes from when creating new nodes. This gives default values to some fields. Unfortunately, there's no node_instantiate() or some such in Drupal 5.x-series which would clarify this issue.

Was there more modules than CCK Taxonomy that got broken when calls to node_submit() weren't there? Maybe it's just CCK Taxonomy that should get fixed?

Was there more modules than CCK Taxonomy that got broken when calls to node_submit() weren't there? Maybe it's just CCK Taxonomy that should get fixed?

No idea. But your logic is sound. I will rollback that other commit on the other issue and if the original poster want's it then they can explain in full details the problem and why they think node_submit() is the fix to their problems.

It does seem a dumb a55 "fix" to me anyway.

The following patch (against current DRUPAL-5 branch) removes node_submit calls from scheduler_cron.

Hi there, I'm having the same problem and I've fixed it with the supplied patch in comment #7. But my taxonomy field on the node is empty after the scheduler cron published the node. So what can we do in order to fix this problem? I really need the taxonomy entry...

Thanks for any help, BJoern

@skiminki I have added you as a co-maintainer. If you want to commit patches to scheduler feel free :) If you want to take over scheduler then let me know, it's up for grabs.

Appreciated. I think I'm going to apply scheduler-module-230836-7.patch, scheduler-module-236841-3.patch and then make a release, if they fix more than they break :)

About the maintainership: I'd be willing to maintain 5.X-branch for few months.

http://drupal.org/cvs?commit=112669

Released in 5.x-1.13.

Folks,

I've had a similar issue with CCK image fields, and traced the problem down to a premature node_load,
which causes a premature (read "empty") CCk field to be cached. Here's a fix that works for me.
Please review and suggest.

*** node.module 26 Aug 2008 09:20:05 -0000
--- node.module 27 Aug 2008 05:53:45 -0000
*************** function node_save(&$node) {
*** 655,660 ****
--- 655,670 ----
if ($node->is_new) {
node_invoke($node, 'insert');
node_invoke_nodeapi($node, 'insert');
+
+ // There are modules (e.g. advpoll) that call node_load DURING
+ // the 'insert' nodeapi hook call. This node_load cases some node content
+ // (e.g. CCK fields) to be prematurely cached (i.e. the fields have
+ // empty values). The best time for a node_load is AFTER the node is
+ // completely created.
+ // To clear the caches setup by premature node_load calls, we
+ // call the update nodeapi hook. This call should be a no-op other
+ // than clearing the caches.
+ node_invoke_nodeapi($node, 'update');
}
else {
node_invoke($node, 'update');

The patch in #7 cannot work for installations that do not use the scheduler module.

@skiminki, @AjK: Thank you for this useful post and fix. The descriptive and constructive discussion helped me identify and fix the problem in my site.