localconf.php gets set to 0 (empty) when permissions are set wrong and do changes in em
|Priority:||Should have||Due date:|
It seems that in 4.5.2 a localconf.php gets set to 0 - complete empty, when you are deleting or installing an extension from extension manager and the permissions of typo3conf are wrong. We were able to recreate this issue if the permissions are i.e. user:root and 777 if they are user:user. The agency who called us had a site were the localconf had no content at all and the install tool was called after inserting ENABLE_INSTALL_TOOL.
It seems that typo3 is deleting the complete file and replacing it with a 0 file without making a copy of localconf.php.
IMHO it would actuially be good to have some routine which always produces at least one copy of the localconf.php if a value in localconf.php gets changed. This would help to switch back much easier.
Does someone else has experrienced also this behaviour?
(issue imported from #M17832)
Updated by Andreas Becker (Andi) about 2 years ago
I could not believe it either but it happened again.
1. when I get on the scene the site was broken because the localconf.php hat 0B. When you called the site the installtool opened with ENABLE_INSTAL_TOOL and after creating this file manually (as no way to access backend due to missing localconf) than the 123 Install started.
2. As we have a localconf setting like described on http://secure.t3sec.info/tutorials/typo3/credentials-outside-of-webroot/
we were able to get the site started again - but of course no extensions where installed beside the standard once.
3. So we asked the provider to do a backup of the former localconf.php. Unfortunately he played back a complete older Version of the site. Anyway we accessed the backend here as usual and checked what might has to be updated again in content. Some extensions where to much and no more in use. So we went to the Extension Manager and deleted an extension. Than suddenly the thirs pane (content pane) showed an error that he can't connect. First we thought it might be due to Internet Connectivity but after checking we realized that the localconf.php was again 0B and nowhere a copy of the localconf. I have seen this behaviour before in Version 4.something don't know which version unfortunately at a shared hoster (imhosted) about 1 1/2 years ago. It came back to my mind that there was a problem with permissions and that they had played it back as their root (group which I could not access (on shared). But yesterday this was a managed server and the agency had root access. I checked the settings and they were similar to those of imhosted. user:root (after restor the backup)
So we tried again a backup to see step by step what happens. In deed after the backup the site had not the setting it actually should have like user:user or user:t3usergroup and the additional setting of this t3usergroup in localconf. This t3usergroup setting is existing in localconf.
4. when you now enter the backend and do the same like before - change something in extension manager which writes into localconf.php than the localconf.php gets deleted and set to 0B.
5. Therfore it would be adviced to have an automatic backup for a localconf.php so you can easily switch to the backup if something goes wrong in the clive localconf.php.