Several sites were updated from 3.9.0 to 3.9.1 and all of them are using Dutch as the default language.
However, after the update the default language was reset to English.

I have never seen this happen before on an update. The only difference might be that the last update was done by Installatron, while previous updates always had been done manually when an admin was logged into the backend.

I am not sure I should run the FPA assistant for this, as I have manually corrected the language. Maybe it would make more sense to run the FPA on a site that is still on 3.9.0 and then run it again after the update to 3.9.1?

Unfortunately that is not an option to do a restore, as there were too many days between the actual update and when we found out what had happened and then started to research and found zip. Too many things were changed and new users and forum posts would have gone missing.

If it is a known issue that such auto update does nasty things, there should have been a warning and I would have expected to find a warning in these forums or docs somewhere.

Well some people learn the hard way. When things went wrong on the update then the obvious thing to do is to recover using a backup.

"The recommended way to update installations of Joomla! is to use the Joomla Updater component found in the Components menu of your site Administrator."https://docs.joomla.org/J3.x:Updating_f ... ng_version
I doubt it would be possible to list the 3rd party update methods that fail.

But the thing is, there is no warning, not even in the link you provided, that says that there are 3rd party installers that can screw up your joomla update. If one isn't even aware that such a thing like Installatron is capable of doing that, how is one to know? If one always used the Joomla updater in the backend, and you know that there is an update, but you don't want to install it yet, and suddenly a few days later you find that somebody, something somehow installed that update and you can't find a damn thing about it? So it will take a few days before one realizes that Joomla was updated, then another day to find out that something was reset, then another day to find the culprit etcetera. By the time you guess that the update in Joomla must have caused it, you are trying to find if other users might have experienced the same thing. And hey, this might be a bug that nobody noticed yet.
So several days pass, but the site is working and new stuff is added and restoring is not an option anymore. And there you are.

So there is no warning about the 3rd party installers, and apparently Joomla allows these 3rd party apps to update Joomla without any consent at all. This begs the question as to why is Joomla allowing this and can Joomla do something to prevent it?
To me it is like allowing Windows to update Apple apps if you get my point. Maybe a bad comparison, but I hope you get my point.

Yes, I found out the hard way, and thank goodness that the things it screwed up were easy to repair, and I immediately turned off these installatron auto updates right away

I have sympathy for the OP in discovering that problems occurred days after an event. I understand the hurt that people must feel when they discover these things; many people seek to place the blame on others for failing to forewarn them of dangers. Unfortunately (and as much as we wish that people were not hurt by failing to notice or failing to heed warnings) people are hurt everyday.

We don't know everything (as I've written elsewhere); and even if some of us think that we know more than others, people ignore our advice. Remember, too, one important point: there is no official support for Joomla! This is a volunteer-operated forum; there are opinions that we're all entitled to agree with or disagree with but the fact remains that everyone can choose.

Thank you for understanding. I thought I had taken quite a few precautions to prevent problems. Hence I have a test website where I install updates first on to see if they work out or might cause problems. I simply hadn't foreseen, even less expected, that there was such a thing as Installatron. The only advantage it does have is that it will create a backup, then do the update, then create another backup. But I didn't even know that it existed and that it even could update Joomla, as it was given the setting (by hoster??) to update minor versions.

So I knew there was an update waiting but when I logged in on a site, I quickly noticed, "hey, where is that Joomla update notification??" And hey, at the bottom it is now telling me 3.9.1. Hey, who did that? Logs didn't reveal anything. Asked my co-webmaster, he hadn't done anything. So start looking closer in the logs and what not. Nothing. WTH is going on here? So when did this happen? No idea. Looking at the time stamps then helped in finding out. It was done in the middle of the night 2 days ago.
Then looking back and finding some things had changed. They weren't quite that obvious.
Anyways, I do quite a bit of homework before asking for help, and to me it seemed that the update was to blame. So now it seems that not so much the update itself caused the issues, but the updater app Installatron did. Should I have known about the 3rd party app?

It is just something I hadn't expected whatsoever. But I still feel that Joomla should try something to prevent 3rd party apps from doing such a major thing as trying to update Joomla from outside Joomla. Might that be a valid suggestion for the Joomla developers maybe?
I know and I understand that there is no official support for Joomla and that it is all community driven etcetera. But still, official or not, you would want the platform to be as good as it can be, right?

For what it's worth, I do appreciate your contributions and as stated in the other topic, I am more than happy to provide FPA results or whatever if that is helping. Just say the word.

You got me on one of my better days when my account balance in the "sympathy bank" was in credit.

As much as we would like J! to be as good as possible, there are other less well-intentioned purveyors of goods who provide "value add" to their customers and the results are unpredictable. As far as I know (and everyone can jump in to tell me I'm mistaken), Installatron is not an extension for Joomla.

The FPA report displays the "environment" of a website as well as installed extensions used by a Joomla website. As far as I know, the FPA report will not display whether you are using or have used Installatron. It's a bit like saying "you can't tell which way the train went by looking at the tracks."

As far as I'm concerned, I wouldn't bother posting the FPA report in this case but, you never know until you've tried, hmmm? I don't often ask to see the FPA report myself; it's not because I can't understand these reports or that I distrust them. I don't often ask to see the FPA report because, chances are, the person asking the question will argue the merits of doing it. Therefore I usually try to allow these things to sort themselves out.

When someone does post a FPA report on the forum I usually give the matter my 100% attention and offer my advice (or opinions) as best I can.

Only one question I have: is there still a problem that continues to affect the default language?

Perhaps a warning about 3rd party updates could be prominent on the forum. But there are other no no's that could be stated also.

1. Using 3rd party quickstart/Template installs can cause future updates to fail.
2. Overwriting the site files with the update files can break your site.
3. Viruses are often included in 3rd party Templates.
4. Failure to update 3rd party extensions can cause your site to get hacked.
The list goes on ...

Where is the room to make prominent warnings for every possible catastrophic mistake?

I am also sympathetic that's why I take the time to help out on here. I may appear harsh but being direct is the quickest way I know to highlight a problem.

Thank you both. I appreciate you being direct, and I am being direct as well, hence I questioned if the FPA would be of any help here at all ;-)
There is no problem with the default language at this point, and I accept the fact that the dreaded installatron caused this problem in the first place.

I can't find the button to PM you, but I have no problem posting the results of the FPA here. I have one site that is at 3.9.1 and couldn't be restored because too much new stuff on it. And I have a test site that is now at 3.9.0 after restore. Which FPA do you want, or do you want them both?

Great, thanks.
For my understanding, why should the Joomla config be set to read only, and how does that affect the config settings? As in, what settings are being set to read only and can't be changed anymore? Because you would then have to ask the domain host to set that to writable first, correct?

What is the Session path writable about and what am I missing because it isn't set to writable now?

That is the configuration.php in the root (same where the fpa-en.php was uploaded to), correct? And the 600 means it is only readable and rewritable for the owner? If I uncheck the write, than it is giving me 400, not 444.

And I noticed in the Core Folders Permissions Check it says it couldn't find the Logs folder. Indeed it isn't there, but is that an issue? If not an issue, why is it looking for that folder?

The "obvious reasons" may not be obvious; let's just say that there are good reasons and if one wants to immerse oneself in the technicalities of why then one can research the internet to one's heart's content. This is a self-help forum: it's not Wikipedia or Google.

I don't know why Session Path Writable has to be enabled. All the other experts on this forum have written thousands of times saying that this should be enabled (because, if it's not enabled, it can cause problems with Joomla updates); it just happens to be enabled by my webhosting provider. I'm cool with that.

The standard, normal, usual, everyone-else-does-it, it-works-for-me, default permission setting for the file configuration.php is 444. If you want to use something else (and it works) then go ahead and use something else. We will probably mention what we consider to be normal if you ask about this again.

The FPA report also shows a few extensions that are outdated (Kunena is one of them in this case); that's your business. Just saying.

the logs folder was in the root folder but now is in the /administrator folder. The fpa checks both places.

If 'Ownership' is set correctly then Joomla saves the configuration.php 444. As 'Owner' Joomla can delete a file and replace it with another. There have been a few instances where the fpa has reported no 'Ownership' issues when the server has been badly set up. The fact that the configuration.php is 600 not 444 is not the 'norm'. So that is why I suggested
Save Global config save ... check configuration.php is 444 ... then see if Global config can save again. If not you have 'Ownership' issues that the fpa is not showing.

Well, I just did the global save, and checked again, and suddenly the config.php file does have the 444 permissions. Went back to the global config, changed something and that was saved (meaning no error), and permissions were still 444.
No idea why the permissions were at 600 before and how that could have happened, and definitely no idea why the config could be saved even with no write permissions. Confusing.

And yes @sozzled, I know about the outdated Kunena extension. We have imported an old forum from an older Kunena version, and set that to read only completely. It is just being used as archive. I got sick and tired of redoing all kinds of things that were botched by every Kunena update.

...
No idea why the permissions were at 600 before and how that could have happened, and definitely no idea why the config could be saved even with no write permissions. ...

'Owner' can delete files that are read only and replace them with another file of the same name and set it 444.
'Owner' can change 444 to 644 then write a new file (of the same name) to replace it. Then set it 444.

When the server is set correctly then Joomla (or perhaps more precisely php) is 'Owner'. Not sure which of the above Joomla does but as your Joomla can do it then there are no issues with 'Ownership'. the 600 setting must remain a mystery.

Don't forget sozzled has pointed out that your version of kunena is out of date.