We use and love the sites concept in gravcms.
To reuse specific pages, themes, plugins we use symlinks which works quite well in linux but not in windows (which is the preferred OS when developing).
Are there any gravcms internal equivalent mechanisms to achieve the same? I tried with redirect: '/some/custom/route' but this screws up my navigation and search.
Any ideas how to get symlinks behavior done with gravcms features?
@hi-ko, Have you considered Windows Subsystem for Linux?
I run Apache in Linux and create symlinks in Linux. All code/sites is/are stored on Windows filesystem.
├── add-ons
│ ├── plugins
│ └── themes
├── grav-admin <-- Grav 1.7.latest
├── site-base <-- All site-* are symlinked to grav-admin +
│ plugins/themes are symlinked to /add-ons
├── site-blog
├── site-dev
├── site-modular
└── ...
To create a symlinked site, you could use the sandbox command: bin/grav sandbox -s ../site-test
Not sure if it fits your needs, but it does fit mine… 
@pamtbaau, thanks for you hints. yes - I already tried to convince the developer(s) to use WSL but they prefer to use their default setup / development environment and don’t have good linux knowlege. Unfortunately there is no easy way to ship a working WSL installation like a VM image or a container which may be updated/replaced coexist easily. Additionally there is no support to edit files from Windows in latest WSL release (even in 1.0 there are caching issues). So I guess if we go with linux on development then we run a container and use vs code remote explorer which may have the best experience for a windows users running any command transparently on linux.
I thought there is maybe a feature/trick which also works in windows and linux the same way.
The sandbox command is a nice feature but we have another use case. We create symlinks by hand to use the same pages like imprint, privacy policy or specific blog pages in different, independant websites which share some plugins, themes but not all.
Anyway - all good. We will stay with the symlinks.
Unfortunately there is no easy way to ship a working WSL installation like a VM image or a container which may be updated/replaced coexist easily.
True, but all I do is scp a zipped /user folder to the remote host and unzip.
Additionally there is no support to edit files from Windows in latest WSL release (even in 1.0 there are caching issues).
Using then new WSL 2.0 you can use any editor (vs code for me) to edit files on the Linux filesystem using \\wsl$\Ubuntu-20.04\home\<user> and anywhere else on the Linux filesystem if allowed.
The sandbox command is a nice feature but we have another use case.
I also have my own bash script to symlink-ify a site.
Using Microsoft Terminal, one can setup nice bash and Powershell terminals in split windows.
Any way… just my 2 cents 
I use symlinks all the time on Windows, across development environments and setups. What in particular is not working with your symlinks?
There was a recent discussion on this, one of many on how to effectively manage distinctly related but not necessarily hierarchical sites and multisites. I wrote down a few words on it.
@GeorgesPapas has been experimenting with it recently too. In short, create a structure that lets you minimize the amount of things you need to replicate - and the amount of times you need to symlink. Every common piece or component should be at your fingertips, and minimal enough to be passed into any system.