Steps to reproduce the issue
1) Create an article from backend
2) Check the created date
3) Create copy of that article
4) Check the created date of copied article
Expected result
Created date for copied article should be date on which copy is made
Actual result
created date of newly created copy article is same as that of article being copied
System information
Operating System : ubuntu 14.04
PHP Version : 5.5.9-1ubuntu4.16
Web Server : Apache/2.4.7
I would say, add a extra option to the batch function.
For example: Reset Created and Publishing date.
Copy means Copy but it's annoying that you need to change the dates manually.
| Status | New | ⇒ | Expected Behaviour |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-08-03 16:05:45 |
| Closed_By | ⇒ | brianteeman |
Closed as expected behaviour
I know this is an old issue, but seemed better to keep the discussion on the original issue instead of opening a new one.
I’d disagree that this is expected behavior. Why would someone want to do Save as Copy? I highly doubt that anyone is making a copy for the purpose of having an exact copy of the original article. They are duplicating the article so that they can create a new article, but default most of the settings and content, to make it easier. For that use case, it would always make sense to set the Created Date to the date it was duplicated.
I’m still copying an article I created in 2013, so everyone one of my articles shows that I created it back in 2013, which is ridiculous. Other systems always reset the Created Date for this functionality.
I’d be happy to update the code and submit the Pull Request if that would be helpful.
I know this is an old issue, but seemed better to keep the discussion on the original issue instead of opening a new one.
I’d disagree that this is expected behavior. Why would someone want to do Save as Copy? I highly doubt that anyone is making a copy for the purpose of having an exact copy of the original article. They are duplicating the article so that they can create a new article, but default most of the settings and content, to make it easier. For that use case, it would always make sense to set the Created Date to the date it was duplicated.
I’m still copying an article I created in 2013, so everyone one of my articles shows that I created it back in 2013, which is ridiculous. Other systems always reset the Created Date for this functionality.
If you cloned (copy/duplicate) a row in a Database, would you expect the metadata of Created Date for that row to keep the original, or reflect when the actual row was created? Created Date is not content, it is metadata, and should reflect the data on the object.
I’d be happy to update the code and submit the Pull Request if that would be helpful.
My expected result is that a copy is a copy so the date would not be changed
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/10610.