User tests: Successful: Unsuccessful:
In J3 when saving an article as copy, the article was automatically unpublished. When introducing the workflow in August 2018, the line from this PR was removed and never returned. This means that articles, which are saved as a copy, that article is directly published. I hope that this is fixing an issue and not intentional. But I definitely want to hear the opinion from @bembelimen about this.
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_content |
Labels |
Added:
PR-4.3-dev
|
For my unpublish a copy on save article is a bad user experience anyway...
@HLeithner that may well be but we need to be consistent. If you use batch copy on an article then the state is changed to unpublished. Batch copy and save as copy should use the same state
I was wrong see #38810 (comment)
it was just a comment, I already accepted this for years so being consistent make sense.
The logic behind it was that if you are making a copy then you are probably doing it so that you can use the article as a basis for a new article. So at the point of copying you are not ready to publish
The logic behind it was that if you are making a copy then you are probably doing it so that you can use the article as a basis for a new article. So at the point of copying you are not ready to publish
I understand this, but that's not how I work, I modify an "old" article with everything I need and then click "save as copy", then I'm always irritated that I have to change the publish state again and have to save again, if you do this for a 10 articles initially on the website it's a pain. But yeah I then use batch publish and it's working too...
It's only an unexpected behavior from my point of view. But as I say already, I can life with it...
Actually now that I think about it I do exactly the same as you unless I am copying a bach of articles to edit individually later. So actually the current behaviour be fore this PR is how we both work and the PR is not needed.
Maybe the JET team should make aa decision on this one (assuming the bugs in this PR is fixed).
I notified them
In my personal opinion we need something like "Start a draft with a copy" only when I save it it would be saved then. So it does not matter if its published or not because it's only saved when I click on Save.
thats what workflows are for
But As I understand from the discussion here "save as copy" immediatelly saves and publishes the article. It should not be saved in this moment but a boilerplate for the new content and only saved when someone clicks on save.
But As I understand from the discussion here "save as copy" immediatelly saves and publishes the article. It should not be saved in this moment but a boilerplate for the new content and only saved when someone clicks on save.
That was the status in Joomla 3, Having an additional button would work too but we already have 5 "Save" buttons
I never said additional button ...
I think this is one of those things that's subjective and depends on how an individual is used to working.
Option 1: You go into an article, make changes, and then save the changes as copy. In this case, it makes sense for the article to be immediately published.
Option 2: You go into an article, save as copy, and then make changes. In this case, it makes sense for the article to be a draft.
Since it's subjective which is best, it might be better to look at which option causes the least harm if it works in a way someone doesn't expect.
With option 1, if you follow this process and it's saved as draft, it's a minor annoyance but just another couple of clicks to publish it.
With option 2, if you follow this process and it's immediately published, it means that you have (at best) a duplicated page and (at worst, depending on the template etc) a site that appears broken until you either unpublish it (if you notice it immediately) or make the changes you were intending.
So, we can see that saving a copy as draft causes the least harm.
Additionally, it's worth considering that saving as copy saves as draft in other core components even in J4 (custom fields, modules, etc) so the behavior should be consistent across the core components.
The fact that it's broken with the workflow doesn't change the fact that it should be consistent; I'd call it a bug in workflows to be honest. There's a default stage in workflows, so I would imagine that saving as copy should save it to the default stage in the appropriate workflow. That way people can determine the best default behavior for their use case, as is intended with workflows.
Finally, to mitigate the annoyance for people who follow the option 1 process without workflows and find it saved as draft, it would be helpful in the success message to say "Saved copy as draft. Set to published? [Publish]" or something like that across ALL core components.
Hope this helps!
Labels |
Added:
?
|
@crystalenka there have been no commits since I tested
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2023-04-18 12:06:29 |
Closed_By | ⇒ | Hackwar | |
Labels |
Added:
bug
?
|
Status | Closed | ⇒ | New |
Closed_Date | 2023-04-18 12:06:29 | ⇒ | |
Closed_By | Hackwar | ⇒ |
Status | New | ⇒ | Pending |
Title |
|
I have tested this item ✅ successfully on 32fe22c
I have tested this item ✅ successfully on 32fe22c
In contrast to some of you, when I save as copy I always do that first to avoid accidentally saving changes to the original.
Status | Pending | ⇒ | Ready to Commit |
RTC
Labels |
Added:
?
PR-5.0-dev
Removed: PR-4.3-dev |
Issue was unrelated to this PR. After updating branch, it now seems to work.
Status | Ready to Commit | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2023-09-18 12:59:59 |
Closed_By | ⇒ | HLeithner |
sorry I reverted this merge because breaking another working part of the cms without a proposed fix is not an option
Should this be re-opened then?
do we have an original issue for this? if we have one then we should reopen it or create a new one
Unfortunately this breaks the ability to save as copy when you are using workflows