Oops @franz-wohlkoenig something going wrong.

Accidentally, I made a new PR #19481. Please take a look.

The modified file was meant to be added here.

I have already modified the files locally. Sorry, but how can I easily add the modified files?

@sandewt do you know how the git console works?

I have already modified the files locally. Sorry, but how can I easily add the modified files?

From the git console you can use:

git checkout -b 'systemlogoutmessage'
git commit -am 'Commit the changes for issue #19477'
git push origin systemlogoutmessage

https://github.com/joomla/joomla-cms/compare/staging...sandewt:systemlogoutmessage

Fill the form
Hit publish ?

If not know how git works localy no problem you can take a look here: https://docs.joomla.org/Using_the_Github_UI_to_Make_Pull_Requests

If you want to change multible files using the GitHub GUI you can go here:
https://github.com/sandewt/joomla-cms/tree/patch-x (where x is the number of the patch github shows you) and change the additional files you need.

Than you can hit the "New pull request" Button.

The modified file was meant to be added here.

This is technical not possible yet :) As we are currently in a issue and if we want to change the code we need a pull request. But this issues is going to be referenced by the pull request so the link / connection can be done ?

@sandewt glad that @zero-24 help as i don't know the Stuff about PR.

@zero-24 and @franz-wohlkoenig thanks for the explanation and reaction.

This is the patch with, the added and changed code.
Please take a look, before to make a PR.

Comparing changes

Inside the users controller better not add a new public method getType() as this directly callable as a new task
-- currently it is harmless, but in future it might get code to become dangerous

plus also better avoid it for API consistency (since public methods = 'tasks' as said above)

or you can make the method private,
or instead of $this->getType() you can just use

(!JFactory::getUser()->get('guest') ? 'logout' : '')

@ggppdk I had copy and paste the function getType() in the controller from the mod_login/helper.php file.
I have used in the user.php file: (!JFactory::getUser()->get('guest') ? 'logout' : '')

Something else, in the plugins/system/logout/logout.php file:

public static function handleError(&$error)
{
// Get the application object.
$app = JFactory::getApplication();
// Make sure the error is a 403 and we are in the frontend.
if ($error->getCode() == 403 && $app->isClient('site'))
{

$app should be $this->app (protected application object)

public static function handleError(&$error)
{
// Make sure the error is a 403 and we are in the frontend.
if ($error->getCode() == 403 && $this->app->isClient('site'))
{

Take it with now or is this a new issue?

$app should be $this->app (protected application object)

No, it shouldn't. You can't use $this in a static method.

$app should be $this->app (protected application object)

Oops, I've seen that it is a static method. So thanks, the problem has solved itself.

New insights: without using $url .= $separator . 'logout=true';

I prefer to add the following function in the logout.php file.

public function onUserAfterLogout($options)
{		
	if ((int) $this->params->get('show_message', 0) == 1)
	{	
		$this->app->enqueueMessage(JText::_('PLG_SYSTEM_LOGOUT_SUCCESS'), 'message');
	}
}

Result: Although the function is triggered, NO message is generated. WHY? Solution?

(A working alternative is using the function __construct.)

See: Comparing changes

The constructor shouldn't be used for this.

When the user is logged out, the session is destroyed. Messages are enqueued into the session. So the "right" fix is if you want to enqueue a message you need to force a new session to start after the logout has processed.

The constructor shouldn't be used for this.

So @mbabker I have applied a new function in the logout.php.
With using $url .= $separator . 'logout=true'; (quite handy).
The session ensures that the message does not reappear after a refresh.

	public function onAfterInitialise()
	{
		if (!$this->app->isClient('site'))
		{
			return;
		}

		// Get a message after a logout.
		if ((int) $this->params->get('show_message', 0))
		{
			$session = JFactory::getSession();

			// Get a message only once.
			if ($this->app->input->getWord('logout', '') === 'true' && empty($session->has('session.logout')))
			{
				$session->set('session.logout', true);
				$this->app->enqueueMessage(JText::_('PLG_SYSTEM_LOGOUT_SUCCESS'), 'message');
			}
			else
			{
				$session->set('session.logout', false);
			}
		}
	}

So, to be honest...

1. I don't think relying on a query string parameter for this behavior is the most efficient thing
2. I'd suggest this logic should just live in com_users and be handled directly in the logout controller action, trying to do it in the plugin is causing all sorts of "funny" needs because of the order of operations (you're enqueuing the message when the request is initialized based on the existence of your logout query string parameter, not validating the task also which cannot be done until after the request is routed).

We are passing return URLs via query sting
just then before it is used, it is checked that is a 'safe' URL

This logout URL variable can be used similar way,
after doing some safety checks

• allow adding it only once per session, (like the above code suggested)
• also a 2nd check , should be if user is really not logged, so that someone could not use it to falsely tell a logged user that user is no longer logged

And if you put the logic in com_users, you...

• Remove the need for the query variable
• Remove the need to track in the session whether the logout action was taken (my session was just destroyed, yet my session is also being used to track that I was logged out?)
• Remove the need for everyone who generates a link to the logout action to include this parameter to get the message

And if you put the logic in com_users, you...

yes it is probably a better option,
if it can be done in clean implementation that is not a "hack"
and will not lead to bugs or broken 3rd party extensions

e.g.
-- we will redirect to a 'logout_message' task of com_users ?
which will then redirect to configured logout URL ?

-- a new session will be started before immediately after killing old one ? that be used to store the message ?

:sigh:

You would add the message logic inside the com_users logout task. No need for another task.

$app->logout() triggers the plugins which ultimately destroy the session the request started with. In theory, after that completes you can start a new session as an unauthenticated user if the code is structured correctly, and in that new session (which would be started on the redirected request anyway) is where the message would be persisted. You cannot (nor should you) have two running sessions, that is a major security issue.

Hi,

With the knowledge of now I had not used the helper.php (from mod_login), but I had placed this directly in the user.php of com_users.
Because I have more knowledge of plugins, it was logical for me to include a piece of logic there.

So, if all the logic is to be placed in the com_users, without the query variable, and with the necessary controls, I think that's a good idea.

Thanks all