Hey all, As part of the composer stuff I've been playing around with restructuring the directory layout of a SilverStripe application, both in the way the entire application and also individual modules are structured. None of these changes I'm suggesting will be required for things to work - you can still structure things however you want (within reason). However, this will be the default installed setup, and how the docs suggest things. In short, this will be the recommended/standard application layout. Application /application /src Application.php Page.php modules.yml _config.php /public assets index.php .htaccess /themes /vendor
/composer.json
There are now the following directories in the root of your app: "application", "public", "themes" and "vendor". The application folder contains all your custom application code, and replaces the mysite folder. Each application has a subclass of the SilverStripe application class, which registers the modules it uses. There are a number of ways to register modules - you can register them in PHP, from a YAML file, or by scanning a directory. The default setup loads them from a YAML file, and this file is automatically updated when you install a module using composer. The public folder is the webroot of your application. An important thing to note is that now your application code no longer lives in the webroot, meaning it is no longer directly accessible from the web. To make sure that any public URL referenced assets from your application (eg images, css, js) are still available, SilverStripe will automatically create the appropriate symlinks (or copies on windows systems) to make sure these are available from the public folder. The way this works is that each module can define a `getAssetDirs` method, which returns a set of directory names to copy across (if they exist). By default it copies the css, javascript, images and thirdparty dirs. If you want other directories to be copied across you will be required to define these explicitly. The themes directory still has the same function as previously, however themes are not be auto-discovered - I will probably change this behaviour. The vendor directory holds all of your composer-installed dependencies. This includes the framework, any modules and themes, as well as thirdparty dependencies. Modules The main change here is renaming the `code` folder to the `src` folder, which I think is a more sensible name. Also, I'm going to say in the docs that it's suggested to use PSR-0 style autoloading. Thoughts?
Andrew Short.
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
SilverStripe will automatically create the appropriate symlinks (or copies on windows systems) to make sure these are available from the public folder.
The public folder is the webroot of your application. An important thing to note is that now your application code no longer lives in the webroot, meaning it is no longer directly accessible from the web.
Personally I don't use the themes folder at all, I rather keep everything (php, js, css, templates respectively) under 1 folder ('app') in my case (shorter than application).For me it's one less top level directory and keeps everything 'together' but I understand if making SS fit everyones idea is impractical.. we still need to use themes for things like subsites and mobile module.
SilverStripe will automatically create the appropriate symlinks (or copies on windows systems) to make sure these are available from the public folder.
When does it create the symlinks?
The public folder is the webroot of your application. An important thing to note is that now your application code no longer lives in the webroot, meaning it is no longer directly accessible from the web.
Will an .htaccess be needed in the topmost root? In that case for those users that typically setup WAMP/MAMP and just download SilverStripe to a folder as well as most shared hosts where you have very little if any control on the webroot path.
Andrew, this is looking great, thanks so much for seeing this through!And for being so thorough on the docs: https://github.com/ajshort/sapphire/commit/a4d0aee836237c99fa602e7f5d4080b65279375aAre you planning to update the "install from source" docs as well?I guess both "phing update_modules" and "git clone" variations would be deprecated now.Is there any reason we need to keep them around?
I guess an upgrade guide should have a "migrate to new app structure"section, right? A few "mv" commands, which strings to searchfor in your own code (e.g. hardcoded /assets paths).
Have you tested the setup in a subfolder, e.g. http://localhost/silverstripe-composer-demo?The Request->extractBaseUrl() doesn't seem to work for me,which means the <base> tag is pointing to http://localhost/silverstripe-composer-demorather than http://localhost/silverstripe-composer-demo/public.
I agree with Will, "app" is shorter than "application", and has the same semantic value.It means a mismatch between the folder ("app") and the main class in there ("Application"), but I think that's acceptable.Andrew, I know its configurable, but what do you think, worth changing the default?
When I do "composer.phar install" on your demo project,it loads everything fine, but barfs on wrong DB credentialson the post-composer scripts. But I can't really run the SS installerbefore I have loaded the dependencies. Bug, or did I overlook something? :)