Using this module, if a user is *not* shown the 'authoring information', we are finding that the created date is being changed to the current date/time. This mimics the action when Authoring Information -> 'Authored On' field is left blank.
I have tried this with node revisions, and without. This is a problem among multiple content types, and because we have Views sorting nodes by created date, it's causing some issues by changing the date.
I believe this line in the node.module is responsible ultimately (there is no $node->date)
$node->created = !empty($node->date) ? strtotime($node->date) : time();
Seems to be that the the node-date is blank when Authoring Information is restricted, and this module is not providing a hidden variable (or other method) for maintaining existing created time.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | Screen Shot 2016-11-28 at 21.32.21.png | 478.74 KB | opdavies |
| #7 | Screen Shot 2016-11-28 at 21.32.17.png | 225.71 KB | opdavies |
| #2 | override_node_options.module.patch | 674 bytes | dicreat |
Comments
Comment #1
Stefano commentedHi, still no news on this bug?
I had a look at the module code and i found that tiptoes was right.
I did a little to change to line 257 of override_modes_options.module as follows:
if (($node->date !== $node->override_authored_on || !empty($node->override_authored_on)) && isset($node->override_authored_on)) {
$node->date = $node->override_authored_on;
$node->created = !empty($node->override_authored_on) ? strtotime($node->override_authored_on) : time();
}
As you may see I just added a parenthesis around the old conditions and then I added "&& isset($node->override_authored_on)"
in this way if the date field wasn't set nothing changes.
I'm testing it on my website and it seems to work correctly.
I would have made a patch but I'm new to drupal and have no idea on how things work here. Just wanted to to add my 2 cents to try to solve this bug. :)
Comment #2
dicreat commentedI have the same problem. Thanks Stefano, your solution works for me and I made patch for it.
Please review.
Comment #3
joachim commentedI think we can just check isset rather than both isset and empty. Wacky ol' PHP!
But also, I wonder if this would be fixed by #644820: Use the same form element names, not new ones.
I'm on crack. Are you, too?
Comment #4
dave reidWill be fixed with #644820: Use the same form element names, not new ones.
Comment #5
dave reidComment #6
askary_amir69 commentedI have a similar issue (drupal 7):
For one of the content types, most of the time, the node created time is also updated after updating a node!
So this results in node created timestamp and node updated timestamp to be the same after updating node(automatically with a custom module) and the node created time is lost.
Is there anyway to stop this behavior and keep the created timestamp intact?
thanks
Comment #7
opdaviesI've added
testNodeCreateDateDoesNotChange()(see http://cgit.drupalcode.org/override_node_options/commit/?id=191667b) to the tests for this module to try and replicate this by creating a new node, saving it and then comparing thecreatedvalues.These tests show that the
changedvalue changes as expected, and that thecreatedvalue remains the same.I'd suggest checking your custom code for updating the node for anything that could be causing it.
If you continue to have the issue, please create a new issue advising how to replicate the issue within the above test.
Comment #8
opdaviesThe method has been renamed to
testNodeCreatedDateDoesNotChange().