Go to global configuration -> Logging and check that the Log Priorities field is not empty, All is the standard value. Save and then try to change the configuration again. It should work.

That was also one of the issues. When we entered 'Critical' into the Log Priorities field we got the same error {Invalid field: Log Priorities} and Joomla wouldn't save the option. The only way we could save ANY config on this teb was to make the changes directly in the configuration.php file.

I had no problem setting the log priorities to critical and saving

I had a similiar error some days ago. After moving a 4.05 installation from one server to a new one. In the original application the value was "all". After installation on the new server (akeeba backup), the field was empty and gave the error message mentioned above when I wanted to change the configuration settings.

Why doesn't Joomla 4 have 'All' be default instead of leaving it empty and then flagging up an error to totally confuse new J4 users?

Default in new installations is "All". Otherwise there were thousands of issues.
The question is - what happens that the params settings for log properties get lost in some cases? I tried to replicate the issue with different installations but without success.

It just got lost in my case. I had a 4.0.6 on php 7.3.31
I created a backup and extracted it locally on php 8.0. If I go to global configuration now, my field log priorities is empty.
I just checked - on the server it is set - but locally it is empty.
I did not save the configuration in between.

How did you make the backup?

Akeeba Backup - just checking again with newest versions and reporting there as well.

Ok, I did the backup again with the newest Akeeba Backup Pro 9.1.0, now after extracting the backup the field is set as before. So, it seems it was a backup problem. @chmst maybe that helps to reproduce (or not ;-)).

Just to confirm that I have replicated this bug - now trying to find the cause

Think I found it

I don't know if the problem is in core or in akeeba backup so I am posting here AND notifying @nikosdion

When you extract the backup the configuration.php is used in the "Akeeba Backup Site Restoration Script v.9.0.11" but it does replaced the file in the backup with its own version of configuration.php - obviously as there are changed values.

It would be expected that other than path and db details the values are identical but they are not.

I strongly suspect that none of the differences matter EXCEPT for the highlighted one below which is causing the reported problem.

So I should have checked more carefully.

The problem is indeed coming from akeeba backup but it has been resolved with Akeeba Backup 9.1.0 as documented in the changelog.

Fixed [MEDIUM] Log Priorities global configuration option got mangled restoring a Joomla 4 site

It doesnt say but I assume that any backup created with a version of akeeba backup with this bug will be impacted.

Thanks for clearing. As I wrote above, I also had an older version of akeeba backup.

@brianteeman This has already been fixed in 9.1.0. See https://www.akeeba.com/download/akeeba-backup/9-1-0.html and click on Release Notes under Bug Fixes, last item. This only happened with array values of which there's only one, log priorities. I just saw your emails where you told me that you just saw the changelogs but I am leaving this here so people know there's transparency in this kind of bug fixes :)

Now a bit of a technical explanation. Unlike Joomla itself we can't directly include the configuration.php file because we have seen several sites where the file contains executable PHP code, typically with several assumptions about the execution environment being on a specific server.

In the past we used a bit of rather naïve code which looks for var or public in the file, splits the rest on = and assumes the right hand side is a scalar (integer, string, float). This assumption has worked very well because the only non-scalar value in previous versions of Joomla was the memcache configuration which was subsequently removed.

Seeing the problem with Joomla 4 I wrote a bit of specialised code which uses PHP's Tokenizer to parse the right hand side of the assignment, therefore adding support for arrays (both Joomla's legacy array() syntax and PHP 5.4+ short array syntax). If the Tokenizer is not available — typically because your host doesn't really understand security and disables random, useful and secure stuff — we use in-memory patching of the file and include it with a custom file wrapper. If THAT fails we fall back to direct inclusion — but it happens in the background, on a page called via XmlHttpRequest to make sure that a fatal PHP error in case the file has weird stuff in it doesn't break the restoration. Finally, if even that fails we fall back to the stock Joomla 4 configuration.php example as the source of configuration values.

That's just about a tenth of what happens in the first second of the restoration script's execution. Whoever said that restoring backups was a straightforward, almost trivial process?

Can be closed as a non-core bug

Thanks all for co-operation.