[#45014] - [5.3] Unpublish/Run transition article when saving as copy
- Fixed in Code Base
- 13 May 2025
- Medium
- Build: 5.3-dev
- # 45014
- Diff
- weeblr:patch-1
User tests: Successful: Unsuccessful:
Pull Request for Issue #37351
Summary of Changes
Second attempt at fixing #37351.
Previous PR (#38810) was reverted (in #41790) because it would not work if Workflow was enabled.
This super simple PR checks if workflows are enabled and if so set a transition value of 1. If workflows not enabled, it sets state to 0, as in #38810.
Testing Instructions
- Save an article as a copy. The new copy is directly published.
- Apply patch.
- Save an article as a copy. The new copy is unpublished.
Repeat 1-3 with Workflow enabled and disabled (System -> Global Configuration -> Articles -> Integrations -> Workflow.
Result should be the same.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_content |
QuyTon
- | Labels |
Added:
PR-5.3-dev
|
||
Hi
I'd be with @crystalenka here (#38810 (comment)) and say that this change reverts to a "safe" behavior, hence I don't see the need for a setting.
When this was changed from "unpublish on copy" to "keep published on copy", it may have needed a setting, as the change was disruptive and would cause invalid content to be published.
None was added at the time.
Going back means at worst the article is not going to be published. But that would hardly go unnoticed as I'd expect "Save copy" was done on purpose, to modify the original content.
So I'd vote to keep it simple and jsut revert to the safe behavior.
@weeblr Could you check the log of the PHPCS check here https://ci.joomla.org/joomla/joomla-cms/82592/1/7 ? It reports a syntax error.
Sorry, fixed now.
AndySDH
- 
I have tested this item ✅ successfully on dc24644
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45014.
| Status | Pending | ⇒ | Ready to Commit |
RTC
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45014.
I have tested this item 🔴 unsuccessfully on dc24644
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45014.
chrome_gui5xWudwZ.mp4
opened an article for editing
saved as copy
status did not change it was still published
I have tested this item 🔴 unsuccessfully on dc24644
Without pull request
- Disabled workflow:
Save as Copygive status "Published" - Enabled workflow:
Save as Copygive status "Unpublished"
With pull request
Same as without pull request.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45014.
| Status | Ready to Commit | ⇒ | Pending |
@brianteeman @fgsw Which Joomla version are you testing this on?
@brianteeman @fgsw Forget my last question, I did a quick change late yesterday and used the wrong variable name. I have fixed that now.
I have tested this item 🔴 unsuccessfully on 16e2056
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45014.
This does now work for non-workflow content.
However for workflow content it is hard coded that transition 1 is unpublished. So it works for the default workflow but fails for any other (such as the blog workflow from the sample data)
Which Joomla version are you testing this on?
I use the prebuilt package custom update server.
However for workflow content it is hard coded that transition 1 is unpublished. So it works for the default workflow but fails for any other (such as the blog workflow from the sample data)
Suspected there'd be something like that coming up. In essence, we should not set to unpublish but to the starting stage I guess.
Starting to be tricky and requires much more work. Maybe the thing to do at this stage is to only unpublish if workflow is not enabled and be done with it.
However for workflow content it is hard coded that transition 1 is unpublished. So it works for the default workflow but fails for any other (such as the blog workflow from the sample data)
Suspected there'd be something like that coming up. In essence, we should not set to unpublish but to the starting stage I guess.
Starting to be tricky and requires much more work. Maybe the thing to do at this stage is to only unpublish if workflow is not enabled and be done with it.
that would be my preference together with completely removing workflow
with completely removing workflow
from the CMS ?
with completely removing workflow
from the CMS ?
yes
Well, won't comment on that.
For now I have found that I can easily revert to Basic stage by setting the transition to an empty string instead of the hardcode 1. This works for me with the Blog sample data, workflow enabled or not.
HLeithner
- | Title |
|
||||||
I have tested this item ✅ successfully on d1e1ec2
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45014.
I have tested this item ✅ successfully on d1e1ec2
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45014.
I have tested this item ✅ successfully on d1e1ec2
Tested this successfully without workflow
-before patch, Save as Copy is saved as 'Published'
https://snipboard.io/zop2D1.jpg
-after patch, Save as Copy is saved as 'Unpublished'
https://snipboard.io/QOKpxB.jpg
After I reverted the patch, turned on Workflow
-patch not applied, Save as Copy is saved as 'Unpublished'
https://snipboard.io/2sI8qT.jpg
tested on jdayusa-25 testing server, as well as my own testing site
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45014.
| Status | Pending | ⇒ | Ready to Commit |
RTC
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45014.
| Labels |
Added:
RTC
bug
|
||
| Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2025-05-13 06:47:47 |
| Closed_By | ⇒ | rdeutz |
Thanks
Much as I hate to say add an option for this changed behaviour in this case I think it is necessary as the behaviour has been not to unpublish for such a long time (even if that was a bug) that it would be a disruptive change in expected behaviour