Moving the front end into a `/web` subfolder

[leofeyer]

Since the idea keeps popping up on a regular basis, let's discuss how it could be accomplished.

New file structure

assets               <-- will be symlinked or copied to /web
files
  images             <-- will be symlinked or copied to /web
  docs
    .protected       <-- do not symlink or copy to /web
    .syncignore      <-- ignore in the DB assisted file system
system
  modules
    core
      assets         <-- will be symlinked or copied to /web
templates
vendor
web
  assets
  contao
  files
  share
  system
    cron
    modules

Maintenance job "deploy assets"

• Will set up the symlinks or shadow copies
• Operation mode (symlink or copy) configurable in the back end settings

Possible issues

If a new folder is uploaded via FTP, it will not instantly be available via HTTP, because the symlink has not yet been set up. However, since we need to synchronize the DBAFS anyway, it could perhaps be added there.

Advantages

We could stop using .htaccess files, which means we would be compatible with Nginx and other web server alternatives out of the box.

[leofeyer]

We'd definitely have to discuss whether we can make symlinks a system requirement, so we don't have to fiddle with shadow copies. The latter would add a lot of overhead.

[fjacobi]

If we're already talking about completely restructuring the folder structure, couldn't we do a split from installation to core files at the same time?

I like T3 in that aspect, that one can run several websites with the same core files. Makes updating a lot easier aswell.

[dominikzogg]

Sounds good to me, but I am not sure if choosing another document root is an option on 0815 hosts.

[tristanlins]

@dominikzogg all shared hosts I know allow to change the document root of the domain to a sub-directory, so it should no problem ;-)

I realy like the idea, according to the files, maybe it is better to use two user file directories. /files (or /protected) contains protected user files, that are not for direct public access and passed through a php script. /web/files contains public user files, that can be accessed directly.

A sync may make some problems:

1. if you have a lot of (big) files, a sync may extremely slow.
2. if you have a lot of big files, a shadow copy sync may blasting your space.
3. symlinks requires the FollowSymlinks option on Apache (afaik nginx does not check for symlinks), I'm not sure, but in the past this option was not available on all shared hosts.

[Toflar]

We should certainly drop share because this is in fact just a special route and doesn't need to be a folder at all :)

[leofeyer]

@tristanlins That's why I would prefer making symlinks a system requirement.

@Toflar The share/ directory also holds the XML files, so they don't pollute the root directory.

[Toflar]

And why are they not dumped to assets? :)

[leofeyer]

Yes, they really should be!

[fabil]

I also think this is a good idea, but I believe that a new problem will occur.

If your Contao installation is located in /website and you would duplicate this folder to /website-testing for testing purposes, all the symlinks in /website-testing are still showing to the folder /website.

Actually, we would create a new point of failure.

[dominikzogg]

Relative symlinks are no problem Am 28.05.2014 22:01 schrieb "Fabian Laule" notifications@github.com:

I also think this is a good idea, but I believe that a new problem will occur.

If your Contao installation is located in /website and you would duplicate this folder to /website-testing for testing purposes, all the symlinks in /website-testing are still showing to the folder /website.

Actually, we would create a new point of failure.

— Reply to this email directly or view it on GitHubhttps://github.com/contao/core/issues/7042#issuecomment-44456884 .

[fabil]

@dominikzogg Oh, you're right. So everything is fine :-)

[leofeyer]

Implemented in contao/contao@1b88af3f43e888489709eb437b5bf1043efb826c then.

[tristanlins]

@leofeyer I think you mean https://github.com/contao/contao/commit/138d46a540451c8251dae950b3d2f4aaa3938b9b ?

[leofeyer]

You are right, it is actually both :)

contao/contao@138d46a is the one with the changes in the distribution repo and contao/contao@1b88af3 contains the composer.lock file needed to install the vendor libraries.