?
avatar ankush-maherwal
ankush-maherwal
24 May 2016

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

Votes

# of Users Experiencing Issue
3/3
Average Importance Score
3.33

avatar ankush-maherwal ankush-maherwal - open - 24 May 2016
avatar brianteeman
brianteeman - comment - 27 May 2016

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.

avatar conconnl
conconnl - comment - 2 Jul 2016

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.


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/10610.

avatar brianteeman brianteeman - close - 3 Aug 2016
avatar brianteeman brianteeman - change - 3 Aug 2016
Status New Expected Behaviour
Closed_Date 0000-00-00 00:00:00 2016-08-03 16:05:45
Closed_By brianteeman
avatar brianteeman
brianteeman - comment - 3 Aug 2016

Closed as expected behaviour


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/10610.

avatar csytsma
csytsma - comment - 13 Sep 2026

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.

avatar csytsma
csytsma - comment - 13 Sep 2026

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.

Add a Comment

Login with GitHub to post a comment