core.edit and core.edit.state permissions for the relevant article/category.The editor can still access the edit form for the article (e.g. to change its status back to Published), the same way they could before it was archived.
The frontend edit icon/link that is normally shown on the article view for Published/Unpublished articles is no longer rendered at all once the article's status is Archived. There is no way for the editor to reach the edit form for that article via the frontend anymore, even though their ACL permissions (core.edit, core.edit.state) are unchanged and correct.
templates/cassiopeia/html/com_content/.access-edit parameter (used pre-5.4 to gate the edit icon) returns zero results, consistent with #46677 ("[5.4] Remove 'layouts' folder and add presets") having replaced that rendering mechanism — this may be where the regression for the Archived state was introduced.5.4
No response
No response
No response
No response
| Labels |
Added:
No Code Attached Yet
bug
|
||
Tested this on Joomla 3 as well — same behaviour there, no frontend edit access for archived articles. So "regression" was the wrong framing on my part; this has apparently been the behaviour all along, not something introduced by #46677.
I'll leave it to you whether the underlying point (a user with explicit core.edit.state having no frontend path to reverse an archive transition) is worth a separate feature request, or whether that's considered out of scope / backend-only by design. Feel free to close this one — appreciate you taking the time to look at it either way.
Thanks for confirming its not a regression.
I will leave it to others to decide if this is something that should be changed or not
Just to clarify:
One concrete use case to illustrate why this matters in practice: since the Status field in the frontend editor does include "Archived" as a selectable option, an editor-level user can set an article to Archived themselves. If they then change their mind (e.g. they picked the wrong status by mistake), they have no way to undo that via the frontend — only a backend user can revert it.
This also affects sites using an auto-archive extension that moves older articles to Archived automatically after a set period. If an editor later wants to update and republish one of those older articles, they hit the same wall — even though nothing about their permissions or the content itself has changed, just its age.
So in both cases, the gap isn't "can archived content be edited" (fair enough that it can't by default) but "a user who was allowed to move an article into Archived has no path to move it back out again" — which feels inconsistent regardless of whether it's by design.
Same as with trashed items. It is by design, not a bug but a feature request.
You say it is a regression. What version do you know it worked in.
I would suggest that it is by design and intended behavour that an archived article can not be edited - to me at least thats the purpose of archive