Frontend edit access lost once an article is set to "Archived" (works fine for Published/Unpublished)

[Pinkeltje]

What happened?

Steps to reproduce the issue

1. Log in on the frontend as a user with core.edit and core.edit.state permissions for the relevant article/category.
2. Open the frontend edit form for an existing Published article. This works as expected — the edit icon/link on the article view is shown, and the edit form opens and saves correctly.
3. In the edit form, set Status to "Archived" and save. This succeeds ("Article saved successfully").
4. Try to reach the edit form for that same article again from the frontend (e.g. via the article view where the edit icon used to appear).

Expected result

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.

Actual result

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.

System information

• Joomla! version: 5.4.8

Additional comments

• Reproduced on the default Cassiopeia template with no template overrides present under templates/cassiopeia/html/com_content/.
• Not a permissions issue: the exact same user/permissions can edit and archive the article without problems; it's specifically after the state becomes Archived that frontend access to the edit form disappears.
• A site-wide code search for the legacy access-edit parameter (used pre-5.4 to gate the edit icon) returns zero results, consistent with [5.4] Remove 'layouts' folder and add presets #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.
• Current workaround: site administrator republishes the article from the backend so the editor can reach the edit form again via the frontend.

Version

5.4

Expected result

No response

Actual result

No response

System Information

No response

Additional Comments

No response

[brianteeman]

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

[Pinkeltje]

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.

[brianteeman]

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

[Pinkeltje]

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.