Bug #101181


Installer shows a blank page.

Added by John Miller 6 months ago. Updated 18 days ago.

Should have
Install Tool
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


Installation page for TYPO3 12+ shows a blank page. It is still possible to setup TYPO3 using composer typo3 setup console command. However, navigating to the backend page also generates no assets. The /_assets folder is empty. I've followed the request process for the install page and seen that the links to the assets are generated in a \TYPO3\CMS\Core\Page\ImportMap class, but the assets themselves are not generated.

No errors are generated.


InstallPage.png (116 KB) InstallPage.png John Miller, 2023-06-27 15:53
Mklink.png (19.9 KB) Mklink.png Windows Cmd Mklink Screenshot John Miller, 2023-06-29 10:52
ComposerDebugging.png (109 KB) ComposerDebugging.png Composer debugging John Miller, 2023-06-29 11:27

Related issues 2 (0 open2 closed)

Related to TYPO3 Core - Bug #98434: Extension assets are not exported with Composer installers v4 on Windows platformResolved2022-09-26

Related to TYPO3 Core - Bug #98447: Wrong symlink name for extension assets with Composer installers v4 on WindowsResolved2022-09-27

Actions #1

Updated by Georg Ringer 6 months ago

  • Tracker changed from Epic to Bug
  • Status changed from New to Needs Feedback
  • TYPO3 Version set to 12

thanks for creating the issue.

is this an empty installation or an update? if it is an update, disable the used extensions and please recheck. I guess there could be some if(!TYPO3_mode, die() code involved

Updated by John Miller 6 months ago

Just finished analysis of the problem.

The problem is located in the \TYPO3\CMS\Core\Composer\PackageArtifactBuilder::publishResources method. This method is called when the PackageArtifact in vandor/typo3 folder is being created via a composer process when autoload is being dumped. Its purpose is to create symbolic links for all Resources/Public folders of all loaded extensions in the home/_assets directory, to be commonly accessed from there.

[snippet from the publishResources method - problem area]

$fileSystem=new Filesystem();
foreach($installedTypo3Packages as [$composerPackage, $path, $extensionKey]){
        $fileSystem->relativeSymlink($fileSystemResourcesPath, $publicResourcesPath);

The function uses composer's Filesystem class and calls its relativeSymlink method to create the symbolic links. relativeSymlink method does an efficient job of creating a relative link to the _assets directory, but, unfortunately for Windows users, uses PHP's symlink function to carry out the task.

[snippet from the relativeSymlink method inside Filesystem class]

$result=@symlink($relativePath, $link);
return $result;

There are two points to note from this snippet
  1. The symlink function has Error Control Operator attached to it. This will ensures that you'll never see the error generated under Windows OS, which is 'symlink(): No such file or directory', unless you have a setting like xdebug.scream=true set to override the silence. Additionally, the symlink function has historically has had problems in Windows OS and a bug reported to PHP, filed in 2015 has the details (See Moreover, unlike in Unix OS, Windows treats file symbolic links ( SYMLINK , referring to a file) differently from folder symbolic links ( SYMLINKD , referring to a folder). In Windows, problems compound if one lacks the necessary authorization to create such links. PHP's symlink function uses the mklink program in windows to create the symbolic link. This program requires administrator right to use and creates one of two symbolic link flavors depending on configuration; the soft link (known in Windows as, symbolic link), and a hard link which Unix users call, a junction. The hard and soft links are created exactly the same with one minor difference: The hard link will be referred to as if it were the reference itself, while as the soft link will be treated as a shortcut. The default is the soft link.
  2. The method returns a bool value from the symlink function. This is useful in determining whether the operation went through successfully or not. In the PackageArtifactBuilder::publishResources method, no checks are done to test the successfulness of creating the symbolic links.


The composer Filesystem class has a method specifically for Windows users called junction.

[snippet from the junction method inside Filesystem class]

public function junction(string $target, string $junction)
        throw new LogicException(sprintf('Function %s is not available on non-Windows platform', __CLASS__));

It works in exactly the same way as the relativeSymlink method. It creates symbolic links in Windows systems. Better yet, the links it creates are hard. A slight modification to the publishResources method as follows would be sufficient to solve this problem for windows users for now. Better method are highly encouraged.

$fileSystemResourcesPath=$fileSystem->normalizePath($path) . '/Resources/Public';#/Somebody forgot to normalize path here. In Windows, md5 will come out wrong because in Windows, package paths come with the back slash (not forward slash).
if (!$fileSystem->isSymlinkedDirectory($publicResourcesPath)) {
    if(!$fileSystem->relativeSymlink($fileSystemResourcesPath, $publicResourcesPath) && !$fileSystem->isJunction($publicResourcesPath)){
        $fileSystem->junction($fileSystemResourcesPath, $publicResourcesPath);

Because $fileSystem->relativeSymlink return a boolean value, It can be used to form an if block to check whether the symbolic link was created. If not, the junction method can be tried.

It should also be mentioned that this technique of creating symbolic links (at this point in time when loading the packages) is grossly inefficient and perhaps this method will be move to another location where it can be called only when needed package assets are called. I call these kinds of procedures, 'lazy-man's techniques' as they absolve the creators of the responsibility of coming up with suitable methods that increase efficiencies. Some of the symbolic links that are loaded at this time will never be used (since they don't contain any assets or, depending on CMS use, that their assets may never be called) but will fill up disk space anyway and consume processing time.

Must I also say, that a Windows tester team ought to be assigned from existing contributors (most preferably from among young or promising contributors handling little tasks) to put any new release of TYPO3 to a continuous Windows testing programme checklist.

Steps to reproduce
Setup TYPO3 in a Windows machine. I gather most of TYPO3 contributors use Phpstorm as their IDE of choice. Its what I use. Have a PHP Script set by going to the Run menu and opening the Edit Configurations... dialog. Depending your project setup, I have mine set as shown below in the composer debugging screenshot. Be sure to have xdebug activated and xdebug.mode set to debug . If not, you can set those variable in the Environment variables: section as shown in the screenshot. Make sure to also have the ones set in my screenshot in yours or Composer will not allow you to debug it. The Custom working directory: should be the directory containing your composer.json for the project (not public directory). Under Configuration section , File is your Compose.phar or executable. Composer.phar is preferred since xdebug can step into it. Argument is the composer command you want to execute. You could also execute any TYPO3 command from here as well. Apply and OK the script and run it. Have a breakpoint set at the $fileSystem->relativeSymlink($fileSystemResourcesPath, $publicResourcesPath) line then step into it. Be sure to read the errors thrown into the error handler as you are directed there, at the symlink function.

Lastly, check to see whether the symbolic link was created using the PHP function readlink. However, if using xdebug's step debugging, it may not be necessary as the error will show prior to reaching this point.


        $fileSystem->junction($fileSystemResourcesPath, $publicResourcesPath);

Actions #3

Updated by Kurt Gusbeth 5 months ago

I have the same problem since TYPO3 12.4.0 and a solution is there:
But this bug is still not fixed in TYPO3 12.4.3.

Actions #4

Updated by Christian Kuhn 2 months ago

  • Related to Bug #98434: Extension assets are not exported with Composer installers v4 on Windows platform added
Actions #5

Updated by Christian Kuhn 2 months ago

  • Related to Bug #98447: Wrong symlink name for extension assets with Composer installers v4 on Windows added
Actions #6

Updated by Christian Kuhn 2 months ago

Patch for #98447 and #98434 has been merged with meanwhile, and has been released with 12.4.6. Did this solve the issue?

Actions #7

Updated by John Miller 19 days ago

Yes, it solved the issue.

Actions #8

Updated by Riccardo De Contardi 18 days ago

  • Status changed from Needs Feedback to Closed
  • Target version deleted (next-patchlevel)

@John Miller thank you for your feedback and sorry for the late reply.

I close this issue as solved then. If you think that this is the wrong decision or experience the issue again please reopen it or open a new issue with a reference to this one.

Thank you.


Also available in: Atom PDF