The result of the COMPOSER create-project command is a new directory containing an image of the Silverstripe CMS. In this collection of directories there are 19 defined as symbolic links (symlink). I am working in a Windows 11 world, and this is the first time of stumbled across this ‘feature’. These symlink objects point to a file in a different location within the project. One consequence of this behaviour is that it is not possible to rename the project directory, or copy, or move it. I ask myself: how am I to develop in one location and ‘deliver’ the website to a different (live) location ? Or a more relevant question would be, for me, how to create a project without usage of this symlink complication ?
Why not? All links should be relative, not absolute.
Please remember I am in a Windows world. I rename the project directory name.I traverse the directory structure to the directory public\_resources\themes\simple\ and I see the four symlink directories. When I attempt to open any of these I get Windows errors access denied etc. The project is now non functional. This behaviour/symptom has ben reported on this forum already. For me this is a deal breaker.
Once you have moved / updated the project directory, have you tried running composer vendor-expose? The links should get updated and should work as expected.
Are you going to deploy the website to production in windows, or will the production environment be linux?
If the production environment will be linux, I recommend you do your local development in a linux environment (e.g. use DDEV which uses docker to give you a flexible linux development environment even if your host machine is using windows).
If your production environment will be windows, then you may need to find a way to resolve this problem.
Which specific directories or files are being symlinked? If it’s the contents of public/_recources/, you can change the strategy for grabbing those files from symlink to copy - see silverstripe/vendor-plugin - customising behaviour
Apologies for the delay i responding, but here are the results of a sequence of tests I have competed.
Rename website directory
Rename directory D:\Websites\ssexampler → D:\Websites\ssexamplerr
Referencing the directory D:\Websites\ssexamplerr\public_resources\themes\simple\css fails
Define a new virtual directory and opening the website fails
Running the command composer vendor-expose fails
If I delete the directories and D:\Websites\ssexamplerr\public_resources \themes and D:\Websites\ssexamplerr\public_resources \vendor then run the command composer vendor-expose I have success
D:\Websites\ssexamplerr>composer vendor-expose
Deprecation Notice: Using ${var} in strings is deprecated, use {$var} instead in phar://C:/ProgramData/ComposerSetup/bin/composer.phar/vendor/symfony/console/Command/DumpCompletionCommand.php:48
Deprecation Notice: Using ${var} in strings is deprecated, use {$var} instead in phar://C:/ProgramData/ComposerSetup/bin/composer.phar/vendor/symfony/console/Command/DumpCompletionCommand.php:56
Deprecation Notice: Using ${var} in strings is deprecated, use {$var} instead in phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/Autoload/AutoloadGenerator.php:881
Deprecation Notice: Using ${var} in strings is deprecated, use {$var} instead in phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/Autoload/AutoloadGenerator.php:886
Exposing web directories for silverstripe-vendormodule silverstripe/admin with method auto:
- client/dist
- client/lang
- thirdparty
Exposing web directories for silverstripe-vendormodule silverstripe/asset-admin with method auto:
- client/dist
- client/lang
Exposing web directories for silverstripe-vendormodule silverstripe/campaign-admin with method auto:
- client/dist
- client/lang
Exposing web directories for silverstripe-vendormodule silverstripe/cms with method auto:
- client/dist
- client/lang
Exposing web directories for silverstripe-vendormodule silverstripe/framework with method auto:
- client/images
- client/styles
Exposing web directories for silverstripe-vendormodule silverstripe/login-forms with method auto:
- client/dist
Exposing web directories for silverstripe-vendormodule silverstripe/reports with method auto:
- javascript
Exposing web directories for silverstripe-vendormodule silverstripe/session-manager with method auto:
- client/dist
Exposing web directories for silverstripe-vendormodule silverstripe/versioned-admin with method auto:
- client/dist
Exposing web directories for silverstripe-theme silverstripe-themes/simple with method auto:
- css
- images
- javascript
- webfonts
All modules updated!
D:\Websites\ssexamplerr>
The website is now functional and correct.
Copy website directory
After the copy the synlink directories exist as standard directories but are empty.
Website opens but all ‘formatting’ is missing (no css files etc.)
Running the command composer vendor-expose completes without error and the website opens with all formatting active.
In conclusion it is possible to ‘move/copy’ the physical website files and with usage of the composer vendor-expose command the ‘new’ site can be ‘fixed’. My objective is to have a windows build/test cpnfiguration and a Linux live configuration.
I do not use windows, but in the past I read somewhere that on that OS all symlinks are always relative, hence my previous answer. The only exception to that is when you explicitly specify the driver letter.
Seeing you are using D: everywhere, maybe that is the problem.
In Windows a ‘symlink’ is implemented with an object name JUNCTION in place of the standard object DIR. This object poits to the target directory using an explicit directory location, not a relative address:
27/03/2025 13:05 .
27/03/2025 13:05 …
27/03/2025 13:05 css [D:\Websites\ssexample\themes\simple\css]
27/03/2025 13:05 images [D:\Websites\ssexample\themes\simple\images]
27/03/2025 13:05 javascript [D:\Websites\ssexample\themes\simple\javascript]
27/03/2025 13:05 webfonts [D:\Websites\ssexample\themes\simple\webfonts]
Consequently, when I rename the website root directory the JUNCTION objects reference a non-existent location.