This seems to be a widespread issue that's not specifically related to one module that I can identify and doesn't happen everywhere, so I am hoping someone else has an idea of where to start.
I've had persistent issues with certain CCK node data not being updated when the node is submitted; I have to go back and edit the node and submit it a second time for changes to take effect. Here are some examples:
-
CCK Computed fields: The values of computed fields are not updated until the 2nd submission. Say I have these fields
Text field:field_a
Text field:field_b
Computed field:$node_field[0]['value'] = $node->field_a[0]['value'] . " and ". $node->field_b[0]['value'];If I make a change to field a and submit the node, the computed field does not change. I have to go back, click edit again, and submit the node form again; then the changes I made the first time will take effect (but not changes made the second time.) This seems to happen regardless of the computed field's weight.
-
CCK Images: When I upload an image, I see only a graphic containing the filename of the image until I edit and submit the node a second time. It's rather strange.
-
CCK File fields: When I upload a field to a field field in a node for the first time, it seems to be alright; however, if I replace the file with a new one, I have to edit and re-submit the node for the old file to be replaced with the new one on the node display.
-
Paths (generated via pathauto): Sometimes when I change the node path, or remove a custom node path to use the default auto-generated one, I have to submit the node form twice for the change to take effect.
-
Web File Manager: When my users upload files with the web file manager, they have to upload the files twice for them to appear in the uploads directory.
I am beginning to suspect that all these things must have some underlying root cause, but I have no idea what that might be. I've tried convoluted workarounds (like using workflow-ng to save nodes twice upon node submit, etc.) but nothing has really worked.
Comments
Further testing
I've noticed that another site in the same codebase does not have the same behavior. (In particular, I was able to confirm that uploaded images do not need to be submitted twice.) The main differences in configuration I've found are as follows:
I will try to determine if a partifular module might be causing the problem by enabling and disabling them on my "working" site.
_
I don't have much to add-- just wanted to say I think you're approaching it the right way. Hopefully enabling and disabling modules will find the culprit.
One question-- when you say you have to submit twice-- are you getting an error message or wsod? Or does it appear to be working and it's just not?
===
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu
"God helps those who help themselves." - Ben Franklin
"Search is your best friend." - Worldfallz
Private download method
I just confirmed that this issue (at least for files and images) is related to my use of the private download method, regardless of the "state" of the modules listed.
There is no error message; the new file/image/whatever simply is not there until the node is resubmitted.
_
meh... i always stay away from the private download setting. There are other ways to protect some or all of the /files directory (http://drupal.org/node/363212#comment-1216785).
===
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu
"God helps those who help themselves." - Ben Franklin
"Search is your best friend." - Worldfallz
.
Unfortunately, I really need to use the private download method on this particular site. The site is a sort of intranet where users upload various documents, some of which contain sensitive information, and who can access what's in the files depends on various access control settings (how the node is tagged + TAC + user roles, etc.). So I really need Drupal to handle who can access which files, since it's all tied in with user roles (and the whole access control process needs to be invisible to these users).
_
Those additional methods in my comment (linked above) allow you to choose the the public file system and yet still create drupal protected file storage that uses drupal node access to handle access control. Basically, you can have the best of both worlds.
My main site is an intranet much like yours so I know what you mean.
===
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu
"God helps those who help themselves." - Ben Franklin
"Search is your best friend." - Worldfallz
.
Thank you, I will look into it. (Although I quail somewhat at the notion of having to make a change like this when some 3000 files will be affected...)
_
always use a test site ;-)
===
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu
"God helps those who help themselves." - Ben Franklin
"Search is your best friend." - Worldfallz
.
We're not live yet (thankfully)... but we'd already had people upload content to our dev site in preparation for launch before we noticed this issue. Add in that I've been working without a systems administrator for six months, which makes anything touching Apache or the filesystem a headache, and it's a grand adventure! :)
_
Ah this is a good time to have caught the problem then.
FYI, there are other issues with using the private file system setting in drupal-- things like imagecache or color module problems, css aggregation issues, and possible performance issues. When you use the private file system, ALL files are served through drupal access control-- including images. When I first setup my intranet 'private' sounded like what I wanted also. Unfortunately, I discovered the consequences only after going live and encountering them first hand, lol.
===
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu
"God helps those who help themselves." - Ben Franklin
"Search is your best friend." - Worldfallz
using downld module resolves issue
Just wanted to add as followup for anyone else who encounters this issue that using the downld module instead of Drupal's private download method resolved this issue for me. Nodes only need to be submitted once for updates to files or images to appear, but users still cannot download files unless they have the correct authorization.
.
Well... the issue persists when there's any sort of access control in play. So it looks like I have further troubleshooting to do.