Project

General

Profile

Actions
Copy link

Bug #94673

open

Install Tool not accessible when entry in PackageStates.php is missing

Added by Marco Kuprat over 3 years ago. Updated over 2 years ago.

Status:
Needs Feedback
Priority:
Should have
Assignee:
-
Category:
Install Tool
Target version:
-
Start date:
2021-07-30
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
10
PHP Version:
7.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

When the entry for 'install' is missing in the PackageStates.php, The install tool is not accessible.
Trying to access domain.xy/typo3/install.php produces a TYPO3 exception:
Container entry "TYPO3\CMS\Install\Http\Application" is not available

Actions
Copy link
 #1

Updated by Simon Gilli over 3 years ago

  • Status changed from New to Needs Feedback

Thanks for your report. Can you please provide more information about how to reproduce this issue? Also the information if it's a Composer install or not is missing, I currently guess it's a Composer install. If yes, how do you create the PackageStates.php, with scripts like shown in the typo3/cms-base-distribution or do you use typo3-console/composer-auto-commands?

Actions
Copy link
 #2

Updated by Marco Kuprat over 3 years ago

It is a non-composer installation. I had to find out why the install tool is not accessible on a TYPO3 site from a different provider. That web seems to have been updated from a prior TYPO3 version to 9.5.28, but I don't know what actually was done.
I saw that the entry for 'install' (and also for 'backend') was missing in the PackageStates.php, so neither backend nor install tool were accessible.
In order to reproduce this, I manually deleted these entries in a local TYPO3 10.4.18 instance and got the same result.

Actions
Copy link
 #3

Updated by Riccardo De Contardi over 3 years ago

  • Category set to Install Tool
Actions
Copy link
 #4

Updated by Benni Mack almost 3 years ago

Hmm, but how can a PackageStates.php be created without these entries? If no PackageStates.php exists, then these entries are ALWAYS added. I mean, sure we can add a check for "always installed extensions" when we have a corrupted PackageStates.php but this would add a huge complexity for our code-base, when people manually modify this file. This isn't intended, maybe we need to clarify this in the Documentation?

Actions
Copy link
 #5

Updated by Xavier Perseguers over 2 years ago

Just had this bug with a composer-based installation. Info here helped me fix the problem.

I made a copy-paste typo in my AdditionalConfiguration.php with something like that:

$GLOBALS['TYPO3_CONF_VARS']['BE'] = 'be_MYPROJECT_user';
$GLOBALS['TYPO3_CONF_VARS']['FE'] = 'fe_MYPROJECT_user';

instead of

$GLOBALS['TYPO3_CONF_VARS']['BE']['cookieName'] = 'be_MYPROJECT_user';
$GLOBALS['TYPO3_CONF_VARS']['FE']['cookieName'] = 'fe_MYPROJECT_user';

Running composer update broke the loading of extensions and generated a nearly empty typo3conf/PackageStates.php but I didn't see it.

From there on, no way to get back to a working install until I deleted that file PackageStates.php. Only then could it be properly regenerated after my typo.

Possibly this helps someone else.

Actions
Copy link

Also available in: Atom PDF