Project

General

Profile

Actions

Bug #64234

closed

Error when accessing "Translation overview" with PackageState.php not writable

Added by Tymoteusz Motylewski about 9 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
System/Bootstrap/Configuration
Target version:
-
Start date:
2015-01-10
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

On a fresh v7 installation, where you haven't downloaded any language pack yet, you'll get an error when accessing the "Translation overview" of the new language module.

Actions #1

Updated by Markus Klein about 9 years ago

Did you test current master as of today evening?

Actions #2

Updated by Tymoteusz Motylewski about 9 years ago

  • Subject changed from Error when accessing "Translation overview" without any language selected (downloaded) to Error when accessing "Translation overview" with PackageState.php not writable

Yes, this is the current master 80873de8496156f782a87fbf4523077c687d3bb2

the ajax request like:
http://typo37.local/typo3/mod.php?M=tools_LangLanguage&moduleToken=c0e277b3fc505715e6ebd9d57446d136807ee001&tx_lang_tools_langlanguage%5Baction%5D=getTranslations&tx_lang_tools_langlanguage%5Bcontroller%5D=Language&tx_lang_tools_langlanguage%5Bformat%5D=json&_=1420925878975

is failing with error 500:

"We could not update the list of installed packages because the file PackageStates.php is not writable. Please, check the file system permissions for this file and make sure that the web server can update it."

After making the file writable it works.

Actions #3

Updated by Tymoteusz Motylewski about 9 years ago

For some reason, package manager wants to write to PackageState.php on each page reload (even if the file is writable).
The condition
if ($this->packageStatesConfiguration != $previousPackageStatesConfiguration) {
from line 389 of typo3/sysext/core/Classes/Package/PackageManager.php
is always true...

After comparing both arrays the only difference is 'classesPath' value for
'Doctrine.Instantiator' and 'mikey179.vfsStream' and 'symfony.yaml'

$previousPackageStatesConfiguration

'Doctrine.Instantiator' => 
    array (
      'manifestPath' => '',
      'composerName' => 'doctrine/instantiator',
      'state' => 'inactive',
      'packagePath' => 'Packages/Libraries/doctrine/instantiator/',
      'classesPath' => 'src/',
      'suggestions' => 
      array (
      ),
    ),
...
'mikey179.vfsStream' => 
    array (
      'manifestPath' => '',
      'composerName' => 'mikey179/vfsStream',
      'state' => 'inactive',
      'packagePath' => 'Packages/Libraries/mikey179/vfsStream/',
      'classesPath' => 'src/main/php/',
      'suggestions' => 
      array (
      ),
    ),
...
 'symfony.yaml' => 
    array (
      'manifestPath' => 'Symfony/Component/Yaml/',
      'composerName' => 'symfony/yaml',
      'state' => 'inactive',
      'packagePath' => 'Packages/Libraries/symfony/yaml/',
      'classesPath' => '',
      'suggestions' => 
      array (
      ),
    ),

$this->packageStatesConfiguration

'Doctrine.Instantiator' =>
    array (
      'manifestPath' => '',
      'composerName' => 'doctrine/instantiator',
      'state' => 'inactive',
      'packagePath' => 'Packages/Libraries/doctrine/instantiator/',
      'classesPath' => 'Classes/',
      'suggestions' =>
      array (
      ),
    ),

'mikey179.vfsStream' =>
    array (
      'manifestPath' => '',
      'composerName' => 'mikey179/vfsStream',
      'state' => 'inactive',
      'packagePath' => 'Packages/Libraries/mikey179/vfsStream/',
      'classesPath' => 'Classes/',
      'suggestions' =>
      array (
      ),
    ),
'symfony.yaml' =>
    array (
      'manifestPath' => 'Symfony/Component/Yaml/',
      'composerName' => 'symfony/yaml',
      'state' => 'inactive',
      'packagePath' => 'Packages/Libraries/symfony/yaml/',
      'classesPath' => 'Classes/',
      'suggestions' =>
      array (
      ),
    ),
Actions #4

Updated by Markus Klein about 9 years ago

  • Status changed from New to Needs Feedback

Seems your environment is broken somehow. I set my PackageStates.php to readonly and can navigate the BE without problems

Actions #5

Updated by Tymoteusz Motylewski about 9 years ago

have you run composer update before? e.g. for running unit tests?

Actions #6

Updated by Markus Klein about 9 years ago

I always copy the composer.json from typo3_src into web-root and run composer update.

Actions #7

Updated by Alexander Opitz almost 9 years ago

What's the state of this issue?

Actions #8

Updated by Tymoteusz Motylewski over 8 years ago

  • Category set to 1594
  • Status changed from Needs Feedback to New

I could reproduce it with current v7.4
Steps:
- changed mode of PackageState.php so it's not writable for web server
- try to access "Translation overview"

The ajax request will return 500 error.

Also other parts of the system will not work.
- clear cache in the install tool
- extension manager

Not sure whether writable PackageState is a strong requirement for TYPO3 (then we need to document it),
or it's a bug.

Actions #9

Updated by Helmut Hummel over 8 years ago

  • Category changed from 1594 to 1499
  • Status changed from New to Needs Feedback
  • TYPO3 Version changed from 7 to 6.2

This is now fixed in master (and 7.5) as TYPO3 does not scan composer packages any more.

I fixed it for myself in 6.2: https://github.com/helhum/TYPO3.CMS/commit/acd76c1c7a7c80a6023f6180960a0f5005bec976

Should we include this fix into 6.2?

Actions #10

Updated by Markus Klein over 8 years ago

Can this "break" existing 6.2 installations?

Actions #11

Updated by Helmut Hummel over 8 years ago

Markus Klein wrote:

Can this "break" existing 6.2 installations?

no. The thing is, that in the PackageStates.php file the classes path is always "Classes" this is the case before and after the patch
The only difference is, that the PackageStates.php file is not rewritten any more if composer packages are used, which have a psr-0 autoload section defined (which triggers a cache rebuild, which is quite expensive)

6.2 installations without composer packages are not affected, neither before, nor after the patch

Actions #12

Updated by Markus Klein over 8 years ago

Then I think 6.2 should get that one too.

Actions #13

Updated by Alexander Opitz about 8 years ago

  • Status changed from Needs Feedback to New
  • Assignee set to Helmut Hummel

@Helmut Do you like to provide a patch?
As this issue is only open for 6.2 and composer I would also happy with closing this issue as unresolved for 6.2.

Actions #14

Updated by Riccardo De Contardi almost 7 years ago

  • Status changed from New to Closed
  • Assignee deleted (Helmut Hummel)

I close this as it affects only version 6.2.x, which is not supported anymore.

If you think that this is the wrong decision then please reopen it or open a new issue with a reference to this one. Thank you.

Actions

Also available in: Atom PDF