Bug #101181
closedInstaller shows a blank page.
0%
Description
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.
Files
Updated by Georg Ringer over 1 year 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 over 1 year ago
- File Mklink.png Mklink.png added
- File ComposerDebugging.png ComposerDebugging.png added
Just finished analysis of the problem.
Synopsis
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]){
...
if(!$fileSystem->isSymlinkedDirectory($publicResourcesPath)){
$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);
chdir($cwd);
return $result;
...
There are two points to note from this snippet
- 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 likexdebug.scream=true
set to override the silence. Additionally, thesymlink
function has historically has had problems in Windows OS and a bug reported to PHP, filed in 2015 has the details (See https://bugs.php.net/bug.php?id=69473). 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'ssymlink
function uses themklink
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. - The method returns a bool value from the
symlink
function. This is useful in determining whether the operation went through successfully or not. In thePackageArtifactBuilder::publishResources
method, no checks are done to test the successfulness of creating the symbolic links.
Solution
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)
{
if(!Platform::isWindows()){
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);
$link=readlink($publicResourcesPath);
...
References
- https://github.com/composer/composer/blob/2b18799c4451a8362c9b7e51916a45ecd83d3637/src/Composer/Util/Filesystem.php#L712
- https://www.php.net/manual/en/language.operators.errorcontrol.php
- https://man7.org/linux/man-pages/man2/symlink.2.html
Updated by Kurt Gusbeth over 1 year ago
I have the same problem since TYPO3 12.4.0 and a solution is there:
https://review.typo3.org/c/Packages/TYPO3.CMS/+/75867
But this bug is still not fixed in TYPO3 12.4.3.
Updated by Christian Kuhn about 1 year ago
- Related to Bug #98434: Extension assets are not exported with Composer installers v4 on Windows platform added
Updated by Christian Kuhn about 1 year ago
- Related to Bug #98447: Wrong symlink name for extension assets with Composer installers v4 on Windows added
Updated by Christian Kuhn about 1 year ago
Patch for #98447 and #98434 has been merged with https://review.typo3.org/c/Packages/TYPO3.CMS/+/75867 meanwhile, and has been released with 12.4.6. Did this solve the issue?
Updated by Riccardo De Contardi about 1 year 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.