@franz-wohlkoenig
Please add this one to todo list to replace #23222

You did it fine, thanks.

I can confirm this issue and to my unskilled eye the problem is that the value selected is NOT being stored in the session - so as soon as the page changes it reverts to the default because the code to get the value from the session always returns empty

In fact, I think it is stored in the session. Tested by dumping Factory::getSession()->get('setup.options.language'); towards the end of InitialiseApp method.
It looks therefore that the session is deleted or reinitialized (new session) further down the process.

What I have found so far is that the return session_name(); in the libraries/vendor/joomla/session/src/Storage/NativeStorage.php file a different session name returns when we get to the index.php?view=remove&layout=default page. This results in that the $_SESSION is not there with the Joomla data. Which results in Joomla not knowing the language for example.

I have yet to understand/find out why session_name returns a different name on this page.

@mbabker Any ideas?

Off the top of my head I think there’s something in the install app between
after the normal install finishes and the language install starts that
causes the session to be wiped. Maybe check the seed for the session name
in the config (DI service provider).

On Sat, Jun 8, 2019 at 10:46 AM Roland Dalmulder notifications@github.com
wrote:

What I have found so far is that the return session_name(); in the
libraries/vendor/joomla/session/src/Storage/NativeStorage.php file a
different session name returns when we get to the
index.php?view=remove&layout=default page. This results in that the
$_SESSION is not there with the Joomla data. Which results in Joomla not
knowing the language for example.

I have yet to understand/find out why session_name returns a different
name on this page.

@mbabker https://github.com/mbabker Any ideas?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/joomla/joomla-cms/issues/25130?email_source=notifications&email_token=AACZ7IJNWIPKI5TT3EW7RT3PZPH5XA5CNFSM4HU5NW5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHXBVQ#issuecomment-500134102,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACZ7IJC2SNGJTIOMS3VC3TPZPH5XANCNFSM4HU5NW5A
.

--

• Michael Please pardon any errors, this message was sent from my iPhone.

Blegh, still haven't been able to pinpoint the exact issue. A few more things have come to light. In the file libraries/src/Service/Provider/Session.php the getHash() of ApplicationHelperis called on line 102. The getHash() function gets the secret key from the config by doing Factory::getApplication()->get('secret') and this is a null value before Joomla is installed. After Joomla is installed this has a random value. This causes the 2 different session cookies/names.

By adding $config->set('secret', null); in the file installation/src/Application/InstallationApplication.php after line 65, we ensure the secret is always null in the installation. This gets us the same session name.

This is not enough. After the installation is done, Joomla wipes the configuration data including the language chosen by the user. What I need to find next is where this data is wiped so we can leave the language in there ensuring the language for the site remains.

$config->set('secret', null);

Please add a release blocker label to this on github

For the installation app we might need to enforce not having the secret part of the session hash. As it's and known thing that it's going to change half way through the application.

Fix #27439