1. You can leave the non-English translations alone for now.
2. There are two things I see missing from the screenshots that probably should be there: the "backup/restore database" option and the database table prefix field (I do a lot of installs against the git repo and would find it somewhat irritating if I had to manually clear the database each time I reset or end up with a database with 1000 tables because I didn't reset after 15 times)

This needs updating as there is no confirm box
https://github.com/dgt41/joomla-cms/blob/1f2d660105562f12f0148433984ac93cc61d7fc0/installation/language/en-GB/en-GB.ini#L84

The language strings need updating to reflect the changes made in 3.8 for the word installation

@mbabker

1. all the languages need a total rewrite, there's no point to try to clean them out, we're using a small fraction of all the strings that 3.x is got there.
2. The backup/restore is now always Backup!
3. The table prefix is randomly generated in the client side, I don't see a reason to have that as an option, as it's something that most less experienced will be always confused with it, also the advanced users can do whatever they want, they don't need a GUI for that.

@brianteeman the language file needs a very good clean up, most strings should be deleted

I dont understand the reasoning in the final screenshot for the words "Complete and ..."
We already know it is complete as the page title says so

The table prefix is randomly generated in the client side, I don't see a reason to have that as an option, as it's something that most less experienced will be always confused with it, also the advanced users can do whatever they want, they don't need a GUI for that.

let me disagree, even for non advanced users should be usefull to have a chance to change it

Even if the backup/rename and prefix things are hidden under an "advanced settings" area, they're power tools that I feel like flat out removing would be more annoying to myself and contributors working from git.

Another possible option is we use the Joomla\CMS\Version::DEV_STATUS constant and do a check to show these only for development state (so only nightly builds and when running from git would see it, packages at tagged milestones wouldn't). Because to an extent for absolute new installations those options have less meaning.

show these only for development state (so only nightly builds and when running from git would see it, packages at tagged milestones wouldn't). Because to an extent for absolute new installations those options have less meaning.

That makes sense

let me disagree, even for non advanced users should be usefull to have a chance to change it

I agree. Sometimes concrete prefix is necessary, it's really useful to have ability to change it during installation.

The backup/restore is now always Backup!

If the prefix is always random then is there even any needed for the backup. That only serves a purpose if you choose to install in the same db with the same prefix

Sometimes concrete prefix is necessary, it's really useful to have ability to change it during installation.

Let's clear up something here, the more options the worse the UX. You cannot have both, either the installer will be nice and easy or it will be something like the old one with plethora of options but not really attractive to new users. Obviously I'm not the one that will decide that, but the people worked on this believe on the few options, easy part...

Less options is user friendly as long as it's not crippling the system. In my case though, I've shown where dropping those options from at least development environments has disruptive consequences. I can get on board with hiding them both for milestoned releases (but then IMO it becomes more important to either make the DB prefix readonly in the backend or implement code to handle prefix changes if you change it in the UI), but I'm personally not 100% sold on removing them at all times.

but I'm personally not 100% sold on removing them at all times.

I guess that's the purpose of this PR, highlight the cases the we're overseeing and handle them appropriately.

i suggest to put more effort on the usabilty for the multilaguage install side
maybe adding some kind of autosuggest/search field instaed of scrolling the whole list of languages avaible
my 0.02 €

@alikon on the roadmap is http://choices.dev but neither me or @ciaran have much spare time at the moment to do the needed changes, but you're right the long list is not really helping anyone!

EDIT: also I started this for the tags: https://codepen.io/dgt41/pen/KvbbdE (check it with Chrome!) which is based on web components/custom elements but it's not there yet (no autocomplete functionality ATM), which can also cover this case

1. A great advantage of the project - everything can only be done with the keyboard!
2. Problem: Use the fieldset tag to mark each group of controls instead of the div tag. Then use the legend tag to mark the heading of a group of controls instead of the div tag.
   This is important for screen reader users. The screen reader will inform you about the change of context, announce that there is a new group of fields and announce its name. The blind person will be informed accurately.
3. Note on language keys. The name Joomla in all the language sequences should be without an exclamation mark. Screen readers treat the exclamation mark as the end of the sentence. This confuses screen reader users.
4. I support @brianteeman proposal] (#17019)

if the installer is in greek then the greek language is automatically installed (with english) without any user input and then you can optionally install more languages as you do now

5. Consider: don't you abandon the installation of sample data in the installer? They could be offered after logging into the backend.
   The result would be a very simple installer. And accessible.

I can't even test this to comment...

Error displaying the error page

@infograf768 Error when wrong access data are given to the database. Unfortunately, you must reload the installation package (or only files in the root directory and tmp folder).

@zwiastunsw
Hello Stefan

What do you mean, this is a clean install.
4.0 patched with this PR
Exported to htdocs in MAMP.

Without this PR I can install although there are errors for multilang (including for installing some languages (I have to think what is different between fr-FR, de-DE, fa-IR which can be installed, and not others.)

This error occurred in me after the wrong login details to BD were given. The first time I removed the entire installation package and loaded it again. The second time I deleted only files from the main folder and tmp folder.

@zwiastunsw
This happens to me when I first load installation/index.php. I mean I did not enter anything yet as the first page of installation does not show.
PHP 7.1.0

@infograf768 : Hmm. I don't know what I could advise.

I'm still getting the following error stopping me from installing when i go to install the database (are you missing the commits from this fix? because we discussed this before in skype)

This text needs to be put in white or something? Because even for me it's not very visible

Some of the validation strings aren't quite right either

Let's get the merge conflicts sorted, remove the word crap like @brianteeman said and get my issues sorted :)

I guess @laneo pushed some code and reverted some stuff, will sort it later on

Would that explain the error I get?

Fixes:

• language selector lost it's style
• validation message was inline

• db option undefined
  @wilsonge should be ok now, again

@infograf768 the error message you're getting is weird, it means that the class InstallationModelSetup doesn't exist, which shouldn't be the case: https://github.com/joomla/joomla-cms/pull/17964/files#diff-01b99bd659cdb05e7e11892ccb1f4e49R90

Thanks for credits, but i just leaded @svom made all the nice things :)

Is it intended that the language selection shows on every page, and doesn't disappear after the first set of options?

Also with the validation message thing - I was more pointing out if there was a reason it shows "Field value cannot be empty" when you have an invalid email?

We are missing a language string too

Finally I can't install a language OR sample data because I'm failing the CSRF checks :( I'll try and find some time to look at this later

The table prefix is randomly generated in the client side, I don't see a reason to have that as an option, as it's something that most less experienced will be always confused with it, also the advanced users can do whatever they want, they don't need a GUI for that.

I should be able to change the prefix.
Random prefix is fine for less experienced user, but advanced user will hate us for it 😄

And, advanced user also like to have GUI 😋

@dgt41
If I download your branch, then I do not have the error displaying the error page.
I really wonder what's going on with applying the .diff
(I also remarked you delete most installation languages and that there are errors for 2 of them (Khmer and Esperanto) when applying the patch.)

I did not understand how I can
Set the password for your Super User account and confirm it in the field below.
There is only one field. How does one confirm?

Then I get to database creation:
Some hosts allow only a certain DB name per site. Use table prefix in this case for distinct Joomla! sites. *

I remarked that this is the name of the db and not the prefix of the tables anymore as that one is indeed randomly created.
I installed using jos_db because it failed using jos_
When I usedjos_ next page gave this error
An error has occurred while processing your request. 1045 Access denied for user 'root'@'localhost' (using password: NO)

But, no more tip to explain people what can be entered in that field. and no validation to prevent going to next page.

Why this change?

We MUST be able decide a table name and modify a table prefix.
It should not be limited to -dev- version as we need to also test with the released versions to be able to help people in the forums and anywhere else.
Losing the ability to delete the existing tables in a db when choosing the same database name is also lost in this PR.

Also I get this error from start
JLIB_UPDATER_ERROR_OPEN_UPDATE_SITE
And obvioulsy I can't either install languages.

That string need to be changed. We do not use password confirm fields in J4 as the user can now see their password by clicking the 'eye' icon

You should be able to drop the whole code for sample data now that we have the ability to install sample data from within the installed CMS. It's the whole point of mod_sampledata 😄
Just thinking loud, one could also drop the additional language part and add a sample data set which sets up a basic multilanguage site (including home menuitems and stuff).

@Bakual and that will happen but does not need to go into this PR.

Lets just make sure this allows us to actually install Joomla without any drastic error and get it merged. We're not in stable so it doesnt need to be perfect

Using fieldset and legend elements

Once again, I would like to call for the following:
(a) designation of the sets of fields (conttrols) by means of a fieldset mark
(b) each set has a legend marker field added to it.
This will not change the code too much, it will not cause problems with the appearance, and will significantly improve accessibility for people using screen readers.
For example instead:

	<form action="index.php" method="post" id="adminForm" class="form-validate">
		<div id="installStep1" class="j-install-step active">
			<div class="j-install-step-header">
				<span class="fa fa-cog" aria-hidden="true"></span> <?php echo JText::_('INSTL_SETUP_LOGIN_DATA'); ?>
			</div>
...
              </div>

write:

	<form action="index.php" method="post" id="adminForm" class="form-validate">
		<fieldset id="installStep1" class="j-install-step active">
			<legend class="j-install-step-header">
				<span class="fa fa-cog" aria-hidden="true"></span> <?php echo JText::_('INSTL_SETUP_LOGIN_DATA'); ?>
			</legend>
...
              </fieldset>

The result I wrote earlier about it. The reference to WCAG:

• SC 1.3.1 Info and Relationships
• SC 3.3.2 Labels or Instructions
• H71 Providing a description for groups of form controls using fieldset and legend elements

Label and instruction

Replacing the label with an instruction manual is not always a sensible solution. For example:

• This is probably "MySQLi". * does not explain at all what should be entered in the field. Similarly:
• This is usually "localhost" or a name provided by your host. * and:
• Some hosts allow only a certain DB name per site. Use table prefix in this case for distinct Joomla! sites. *
  Clear labels are needed here.

Table with list of languages for installation

A person who does not use the mouse must press more than 50 times the Tab key to reach the SKIP or NEXT button. This is unacceptable!

one could also drop the additional language part and add a sample data set which sets up a basic multilanguage site (including home menuitems and stuff).

This is only possible if some specific languages have been installed first and without any error.

What is the purpose of the installation process?
Install the system.
Can you do more during installation?
You can!

• additional languages could be installed.
• multilingualism could be configured.
• example data could be installed.
• selected extensions could be installed.
• selected templates could be installed.
• and more more more...

But all these things can be done later, after installation.
They are not part of the system installation process. They are additional operations.
They complicate what should be simple.
I believe that the installation process needs to be simplified as much as possible. It should cover only what is necessary. Everything that can be done after installation should be done after installation.

@zwiastunsw That is exactly the concept that @dgt41 and others were trying to achieve here

@brianteeman : I know. But there is a tendency to expand functions. And that is why my commentary.

@C-Lodder and others

Lets just make sure this allows us to actually install Joomla without any drastic error and get it merged. We're not in stable so it doesnt need to be perfect

I think it has been made clear by many of us that the way this PR deals with database is not only imperfect but has to be modified.
I guess this could be done by having an advanced button when getting to that page:

Newbies could just chose the database name (They would get automatic table prefix).
Some instructions should be given or a validation to prevent entering a name that would not work (as it did above with jos_)
Advanced users would also be able to define a table prefix AND the possibility to delete the database, as we have now.

Merging as it is now would be an error imho

The table prefix is the only concern? Cmon, if people want that added back in, it can be added back in.

In my opinion: The installer can check on the fly that tables with random prefixes are available. If so, it can automatically archive them. If not, there is no problem.
When is it necessary to archive or delete existing tables? The only logical case: only if the installation of table names in the same database was unsuccessful for a moment before. Otherwise, you simply need to prepare the database for installing a new application, e. g. delete or archived old tables. This is safer.

why should be archived if already exists??
maybe are related to a different application or another joomla site, who knows ??
in the same database can coexists a lot of applications, the probabilty of prefix conflict is not so negligible imo
i like semplicity but this way is a little bit too much

OK Chill. We get that there is something to be revisited on table prefixes. Let's now focus on other issues for now, because I'm convinced that's not going to be the only one :)

Patching with eclipse does not create the includes folder

[06-Oct-2017 09:21:53 Europe/Berlin] PHP Fatal error: require_once(): Failed opening required '/Applications/MAMP/htdocs/joomla40/installation/includes/app.php' (include_path='.:/Applications/MAMP/bin/php/php7.1.6/lib/php') in /Applications/MAMP/htdocs/joomla40/installation/index.php on line 30

Before I start fixing the sample data task. Should it even be included in the new installer as we have a module which does the job? Any opinions?

My 2c is that is should not be in the new installer

Imho, it shouldn't be part of the installer. With the new Sample Data Module it can already be done after installation from the Control Panel and I don't see a reason to have it in installer anymore in J4.

There's discussions to be had with the theme provider community about that (Ref: #7680 (comment)) - we almost certainly will still remove it - but I'd rather keep it working as part of this redesign and remove it in a subsequent Pull Request with discussion with relevant parties

Looks nice good work! About the sample data, I will not miss it when it isn't part of the installation process.

@wilsonge the problem is that it needs some hours to migrate it to be inline with the sample module. So when it will be thrown away anyway later on, then It makes no sense to fix it now. Thats my main issue here.

The sample data option in the installer is a convenient solution for template providers regarding template demo content. Without this option then what is the alternative? Create a sample data plugin, have users upload all demo images with the same folder structure and install all related modules/components?

The sample data option in the installer is a convenient solution for template providers regarding template demo content. Without this option then what is the alternative? Create a sample data plugin, have users upload all demo images with the same folder structure and install all related modules/components?

Yep, template providers can now create a sampledata plugin which can be installed by the users and lets them install the sample data also in an already installed Joomla. There is no need for a customised installer package anymore. Of course it's still possible to create such a package with an already installed sampledata plugin, but I think it's a bit pointless. Better just make it part of the regular template package.
The plugin is able to install the demo images as well. You're free to do whatever you want in that plugin, unlike the old sample data solution. In theory, you would even be able to copy the media files directly from your site to the customers site so the plugin doesn't necessary have to contain it. It would also possible to install other extensions from that plugin. The possibilities are there..

In that case, as long as creating the sample data plugin is a relatively easy task, I'd say remove it from the installer.

I'm also in favor to remove it. Sample data can be made as an option of the guided tour or whatever.

I still can't update via eclipse.
I have to download the .zip from this branch and install.
I tried to install the fr-FR language (as we have only 3 languages that can be installed — fr, de, fa — (voluntary limitations of the update languages xml)

Many errors

[21-Oct-2017 18:08:11 Europe/Berlin] PHP Warning:  mysqli::real_escape_string(): invalid object or resource mysqli
 in /Applications/MAMP/htdocs/joomla-cms-4.0-dev-installation-PR/libraries/vendor/joomla/database/src/Mysqli/MysqliDriver.php on line 330
[21-Oct-2017 18:08:11 Europe/Berlin] PHP Warning:  mysqli::real_escape_string(): invalid object or resource mysqli
 in /Applications/MAMP/htdocs/joomla-cms-4.0-dev-installation-PR/libraries/vendor/joomla/database/src/Mysqli/MysqliDriver.php on line 330
[21-Oct-2017 18:08:11 Europe/Berlin] PHP Warning:  mysqli::prepare(): invalid object or resource mysqli
 in /Applications/MAMP/htdocs/joomla-cms-4.0-dev-installation-PR/libraries/vendor/joomla/database/src/Mysqli/MysqliDriver.php on line 841
[21-Oct-2017 18:08:11 Europe/Berlin] PHP Warning:  mysqli::ping(): invalid object or resource mysqli
 in /Applications/MAMP/htdocs/joomla-cms-4.0-dev-installation-PR/libraries/vendor/joomla/database/src/Mysqli/MysqliDriver.php on line 364
[21-Oct-2017 18:08:41 Europe/Berlin] PHP Notice:  Trying to get property of non-object in /Applications/MAMP/htdocs/joomla-cms-4.0-dev-installation-PR/installation/src/Model/LanguagesModel.php on line 253

[21-Oct-2017 18:09:11 Europe/Berlin] PHP Warning:  file_put_contents(/fr-FR_joomla_lang_full_3.8.1v1.zip): failed to open stream: Permission denied in /Applications/MAMP/htdocs/joomla-cms-4.0-dev-installation-PR/libraries/joomla/filesystem/file.php on line 440
[21-Oct-2017 18:09:20 Europe/Berlin] PHP Warning:  file_put_contents(/de-DE_joomla_lang_full_3.8.1v1.zip): failed to open stream: Permission denied in /Applications/MAMP/htdocs/joomla-cms-4.0-dev-installation-PR/libraries/joomla/filesystem/file.php on line 440
[21-Oct-2017 18:09:42 Europe/Berlin] PHP Warning:  file_put_contents(/fa-IR_joomla_lang_full_3.8.1v1.zip): failed to open stream: Permission denied in /Applications/MAMP/htdocs/joomla-cms-4.0-dev-installation-PR/libraries/joomla/filesystem/file.php on line 440

Language was not installed.
Therefore I could not test install as multilang with simple multilang sample data.
THAT sample data one at least has to be installable as a choice after installing languages as it looks like the sample data plugin would not do the job correctly in its present state (admin language only atm).

I still can't chose a table prefix and decide to delete db and reuse again.

THAT sample data one at least has to be installable as a choice after installing languages as it looks like the sample data plugin would not do the job correctly in its present state

Personally, I would go for a multilanguage sampledata plugin which sets up a correct multilanguage site (eg creating/enabling content languages, creating home menuitems, publishing language switcher and creating a sample article and category per language. Menuitems, categories and articles associated.).

There is no reason for multilingual to be handled any differenyptly

Guys - let's invest the time in getting the sample data fixed for now

We know the plugin works. That's what we should use. Once j4 is nearer we can easily create the sample data. Doing it now would be a waste of energy.

@wilsonge do you mean sample data in the installer? If yes then it is not a fast fix as the code is still the old one which runs the SQL scripts and not the one which uses the same logic as the module.

Just keep it with sql as it is for now

So what about the extra languages? Keep or remove?

@zwiastunsw I think I patched all your requests

EDIT Most of your requests...

please follow the code style for the xml files https://developer.joomla.org/coding-standards/xml.html

please follow the code style for the xml files https://developer.joomla.org/coding-standards/xml.html

there are a lot of other code style issues

Extra languages definitely has to stay at least until we have a backend alternative

1. I tested with Chrome+NVDA, Chrome+ChomeVox, Firefox+NVDA. Keyboard support - perfect. Screen reader - annotates labels of fieldset and fields. Minor problems occur in Chrome+NVDA, but these are errors Chrome, not code.
2. The installation of such a language is unacceptable. The keyboard user must use the tab key more than 50 times to install the language.

@zwiastunsw thanks!

About 2: As I stated before this is not what the final design for the languages page. We will either use the choices.js or a custom element (similar to tags, I've already shared some code in codpen.io). Again this is temporary and also we might end up totally removing the sample data an extra languages from the installer, so it makes no sense spending a great amount of time to fix it right now. Let's wait and see what the decision will be for those two grey areas.

Thanks again!

About 2: I agree :)
3. If I make a mistake (e. g. I enter an existing database prefix), the error page appears only for a short while and then the installer returns to step 1 (Select installation language)

@zwiastunsw the first version of the code is very close to the existing codebase for couple reasons:

• easier to review
• easier to debug

Once this workflow, design, approach is accepted the next steps is to modularise even further the whole procedure, so it becomes more maintainable and less error prone. That mean every action will have an ajax call, right now is like one call for all actions, which is really bad

@dgt41: I understand. It only indicates what I noticed. He knows that the project is being created (in statu nascendi).

@wilsone the languages part is working again thanks to @laoneo

Can you fix conflicts please and I'll give another quick test :)

I still have the same issue here. I can, via eclipse, update the local 4.0 branch, but if I do that, I just can't install J anymore. I get a blank page.
Also, Eclipse tells me some of the "deleted" installation language files have errors in the patch.

In any case please, DO keep the 3 languages that can be used in multilanguage, i.e. de-DE, fa-IR and fr-FR, languages packs that, if it works, can be can installed during J installation.

@infograf768 well one solution is to not use Eclipse, just git fetch, pull should do the trick. I have no clue why Eclipse is messing up here...

The en-UK needs clean up, which obviously is not a task that I can do. Once this is done (probably in another PR) then we can figure out what's the best course of action for the rest languages (I need to state that the way this is handled currently in J3 is really bad, from maintenance point of view).
Anyways you can still check the multilingual part by copying some languages for the 3.x repo

@dgt41 en-GB - we are not in the Ukraine ;)

@brianteeman oops, sorry en-GB is the right one. But you never know with this Brexit where you will end up at the end 😂

UK is an EU thing ;)

@dgt41
I tested again by downloading your branch.
Before even getting to install languages I get

[28-Oct-2017 08:01:15 Europe/Berlin] PHP Warning:  mysqli::real_escape_string(): invalid object or resource mysqli
 in /Applications/MAMP/htdocs/joomla-cms-4.0-dev-installation-PR/libraries/vendor/joomla/database/src/Mysqli/MysqliDriver.php on line 330
[28-Oct-2017 08:01:15 Europe/Berlin] PHP Warning:  mysqli::real_escape_string(): invalid object or resource mysqli
 in /Applications/MAMP/htdocs/joomla-cms-4.0-dev-installation-PR/libraries/vendor/joomla/database/src/Mysqli/MysqliDriver.php on line 330
[28-Oct-2017 08:01:15 Europe/Berlin] PHP Warning:  mysqli::prepare(): invalid object or resource mysqli
 in /Applications/MAMP/htdocs/joomla-cms-4.0-dev-installation-PR/libraries/vendor/joomla/database/src/Mysqli/MysqliDriver.php on line 841
[28-Oct-2017 08:01:15 Europe/Berlin] PHP Warning:  mysqli::ping(): invalid object or resource mysqli
 in /Applications/MAMP/htdocs/joomla-cms-4.0-dev-installation-PR/libraries/vendor/joomla/database/src/Mysqli/MysqliDriver.php on line 364

The configuration.php file is created OK.

Then after choosing a language to download/install I get in a loop (Remember: de-DE, fr-FR and fa-IR CAN be installed in j4 and do install fine when J4 is installed and we use Install Languages from Installation)

Then if I delete configuration.php AND the db created and start again installing, I get this.

hard to read, but the text is

An error has occurred while processing your request.

    1045 Access denied for user 'root'@'localhost' (using password: NO) 

Hmm, session issue maybe?
Now trying to install with Safari.
Can't switch language.

Going on and using a different database name and prefix, I get again
1045 Access denied for user 'root'@'localhost' (using password: NO)

and this error

[28-Oct-2017 08:27:30 Europe/Berlin] PHP Notice:  Undefined variable: return in /Applications/MAMP/htdocs/joomla-cms-4.0-dev-installation-PR/installation/src/Controller/LanguageController.php on line 54
[28-Oct-2017 08:27:30 Europe/Berlin] PHP Notice:  Undefined variable: return in /Applications/MAMP/htdocs/joomla-cms-4.0-dev-installation-PR/installation/src/Controller/LanguageController.php on line 65
[28-Oct-2017 08:27:30 Europe/Berlin] PHP Notice:  Undefined variable: return in /Applications/MAMP/htdocs/joomla-cms-4.0-dev-installation-PR/installation/src/Controller/LanguageController.php on line 68

Concerning the Undefined variable: return Notice, it looks like is missing the validate.
i.e. we should have

		// Must load after serving service-requests
		$form = $model->getForm();

		// Get the posted values from the request and validate them.
		$data   = $this->input->post->get('jform', [], 'array');
		
		// Validate the posted data.
		$return = $model->validate($form, $data);

But it will not change the results I got.

Then if I delete configuration.php AND the db created and start again installing, I get this.

That's not enough, you need to clean also the session in installation/cache (or session I don't remember this on top of my head)

Now trying to install with Safari

Well my dev browser is safari...

@dgt41
deleted all and started from scratch
On Safari OR Firefox, I can't change installation language.
Included in this screenshot is the session which was empty before starting installation.

Let's talk on glip please.

I've done a quick test. I've done a nasty hack for en-US

Occasionally I got this 1045 - but never reproducibly - I could force it with incorrect authentication information to the database - and we need to improve the styling of the error page. But I couldn't reliably do it otherwise.

I'm going to merge this so we have a base to work with. Please feel free to create further issues so we can improve further

@dgt41

Hi,

The table prefix is randomly generated in the client side, I don't see a reason to have that as an option, as it's something that most less experienced will be always confused with it, also the advanced users can do whatever they want, they don't need a GUI for that.

Maybe I don't understand it correctly, but what will be the way for advanced users to change the prefix while installing Joomla!?

Thank you.

Agree with @PhocaCz AND in any case, as I reported to @dgt41 I CAN'T INSTALL anymore locally.

URL:
http://localhost:8888/joomla40/installation/index.php?view=setup

Result

It is not a minor bug...

but what will be the way for advanced users to change the prefix while installing Joomla!?

Ehm, we already change that. Now that field exists in the form (pre filled with a random prefix, but users can change it to whatever they like)

I CAN'T INSTALL anymore locally.

Please make sure that you delete all all the session files in your installation/sessions folder and clear your browser's cookies!

I DID, as I already told you privately the other day!!
And this is a totally clean install. So I did clear again all sessions cookies.
This thing is just badly broken here.
You were wondering if it was related to the use of the port. Time to look where is the real problem.

@infograf768 can you provide some info (phpinfo, and your actual installation URL) maybe in glip

See #18560