Error 404 after changing language of an article in frontend article view edit.

[cyrez]

Steps to reproduce the issue

On a Joomla install with at least 2 languages, and language plugins enabled.

1. In frontend, log in with an edit-article-permission account
2. Open an article view.
3. Click on Edit
4. Change language
5. Save and Close

Expected result

Return an empty page at least with the enqueued message 'Article saved'.

Note: if you edit from the list of articles, the return page is ok.

Actual result

Return a 404 error page with 'Article not found'.

System information (as much as possible)

Joomla 4 at least -> Joomla 5.1.1

[ghost]

@cyrezdev Can't confirm the issue. Change the language and article saved as expected.

Test System Information

• Todays Nightly Build
• Sample Data: Multilingual, Blog
• Languages: Farsi, German

Setting	Value
PHP Built On	Darwin Air.local 23.6.0 Darwin Kernel Version 23.6.0: Mon Jul 29 21:13:00 PDT 2024; root:xnu-10063.141.2~1/RELEASE_X86_64 x86_64
Database Type	mysql
Database Version	8.0.35
Database Collation	utf8mb4_unicode_ci
Database Connection Collation	utf8mb4_0900_ai_ci
Database Connection Encryption	None
Database Server Supports Connection Encryption	Yes
PHP Version	8.3.9
Web Server	Apache/2.4.58 (Unix) OpenSSL/1.1.1u mod_fastcgi/mod_fastcgi-SNAP-0910052141
WebServer to PHP Interface	cgi-fcgi
J Version	Joomla! 5.3.0-alpha1-dev Development [ Uthabiti ] 26-November-2024 00:00 GMT
J Backward Compatibility Plugin	Disabled
User Agent	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:131.0) Gecko/20100101 Firefox/131.0

[brianteeman]

I can confirm this but I am not sure if it is not expected behaviour.

When you press save and close it returns you to the page you were on before you clicked edit. But that page no longer exists because you changed the language hence the 404

[MacJoom]

Thanks for contribution - but closed as expected behaviour.

[cyrez]

Thanks for contribution - but closed as expected behaviour.

Ok. Expected behavior, but is it user friendly? I don't think returning an error 404 page could be an expected behavior for a valid process. Or i miss the point...