symphonycms
Physical Application Structure
One of the great things about Symphony is the ease that comes with installation; A website owner can just drop the package into their root http folder and hit up /install in their browser and get on with it.
Laravel works slightly differently in that the root http folder is part of the package, and there are lots of files surrounding that folder. This will make it more difficult for a website owner to install the package, as they will have to allow for this structure. We already know that a large number of our community use shared style hosting, and we cannot afford to just assume that all of these users can manipulate their hosting environment to allow a package like Laravel to be installed. It's ok for us developers, but what about the non-developers?
We will have to make some modifications to allow our product to be used by the same current base of users which will mean that we can't just create packages called 'Symphony Whatever' and allow them to be installed on Laravel. We are building our unique product based on a framework, so our folder hierarchy will be unique to us too.
I really like our current folder hierarchy (at a base level, not inside the /symphony folder) and it has lent itself to our terminology also, which we should try and keep intact too. I would like to see us mimic that as closely as possible with the obvious requirements that using Composer adds.
I've got a default Laravel working with the following structure, and so would like to propose it as our structure:
/install (new folder to run installation commands)
/manifest (replaces laravel's /app/storage folder)
/cache
/config (new folder for our xml config)
/env-name (environment specific config)
/logs
/meta
/sessions
/views
/symphony (new sandbox folder)
/app
/commands
/config
/env-name (environment specific config)
/controllers
/database
/lang
/models
/start
/tests
/views
/bootstrap
/vendor
/workspace (replaces laravel's /public folder)
/packages
/.htaccess (moved from laravel's /public folder)
/index.php (moved from laravel's /public folder, paths are changed in file)
/server.php (moved from laravel's /public folder, paths are changed in file)
With thinking about separating concerns to keep the core api, backend and frontend as separate apps, I can envisage /install being a separate app also, but intrinsically linked to the core api.
As I don't have as much experience as some, I have some questions:
- Can Laravel run code like controllers, and models from different locations, like
/symphony/app/modelsand/workspace/models? - Could we possibly have our admin separate from the
/symphonyapi app in another root folder/adminfor instance? Having it's own separate routes, models etc?
@designermonkey have a look at the docs. Should explain a lot of Laravel's package handling and file structure.
Can Laravel run code like controllers, and models from different locations, like /symphony/app/models and /workspace/models
As long as they are registered on the autoloader you can run everything, e.g Route::controller('admin', 'Symphony\Admin\AdminController'); So theoretically it doesn't matter where Symphony\Admin\AdminController is located at.
@designermonkey I had a brief look at how laravel's path configuration works and luckily they're not hardcoded. Although I'd like to point out that for obvious reasons the application directory shouldn't be located within the public web root.
I'd like to point out that for obvious reasons the application directory shouldn't be located within the public web root.
Then we have a problem using Laravel for this project, as from experience, many web hosts won't allow deployment of files outside of a shared hosting environment's web root. This is why Symphony is currently the way it is.
This isn't laravel specific. If you wan't to, you can alter all system paths to your liking. It's more a security related issue to have executable code outside the webroot. I personally haven't had the bad luck to work on a shared host that doesn't allow you to configure the webroot location, but yes, this surely is a big concern.
More generally, I don't think that Symphony should feel the need to accommodate every hosting setup out there. Shared hosting, yes. Crappy/unduly restrictive shared hosting? I'd say not. Rather than spend time on stuff like this, we could point out to people that they need to move to a host that does allow for files outside of webroot/public_html.
However, I expect there are ways round it with Laravel 4 as there are with Laravel 3.
You don't see the real problem: Even if your shared host allows to set the web root to a subfolder and thus actually have files "above" the web root, most people simply won't get it. Do you remember when you started with your first CMS? When I installed my first "system", I just wanted to:
- put it "in there" (required FTP, which I considered some sort of secret knowledge…)
- call it in the browser
- dance like… well, you know.
If somebody would've said that I should put something outside of the web root, I would've given up, probably.
So think of starters!
Keeping the application folder outside of the webroot is best practice across the board with the majority of applications, frameworks, and even some CMS's. But it is just that—best practice rather than a requirement. I agree with David in that you can't cater for everyone but as long as it's the majority then it's acceptable. If hosting environments meet the PHP 5.4 requirement then chances are they're geared up enough to allow for items outside of the public_html/ directory.
I've worked with a few shared hosting environments and I've not come across an instance yet where I've not been able to place files and folders outside the public directory. Maybe it's better to go on the presumption it's possible for the time being but keep an open list of any hosting environments which crop up which don't provide that level of access and determine if it will actually be a problem or not. Don't forget that again we're looking forward with the likes of PaaS and cloud hosting are really setting the new direction. In a year's time or more the hosting landscape will have shifted again so it's worth noting where things are heading.
@michael-e Yes I guess it does depend on the target market considerations and keeping things simple. Does this have to be a requirement or can it not be kept as a best practice? I know in EE this is highly recommended as a best practice (as with all apps etc) but it's kept in the "Post Installation Best Practices" section after performing the install. I've seen quite a number of setups and the vast majority follow this practice and I've not heard anyone so far having problems either keeping it in the web root or moving it above web root for those that understand why and want a bit more security. That would certainly cover all bases.
I'd be happy if both bases were covered, but my opinion is that it shouldn't place extra burden on Symphony's developers and the project as a whole.
You don't see the real problem: [...] most people simply won't get it.
That's not a problem to solve by catering to bad practice. It's a problem to solve with good documentation and education.
I'm all with a "Easy First" approach but you have to draw the line somewhere, especially when it comes to security related decisions. I fully agree with @DavidOliver here. and I don't think that this is a real problem at all but a educational issue you have to get used to. Remember the first time you stuck with the W3c Boxmodel implementation? But you're still using CSS, don't you. And that's by far more complicated than having two separated directories :). Apart from that, having the obstacle of dealing with xslt as a starter,
most people simply won't get it.
really seems to be a bit of a lousy argument.
I already have this running with my adjusted layout, and I'm toying with a couple more ideas. I'm sorry to say that we need to cater for the easiest option, irrespective of whether it is industry best practice.
Without moving the discussion off topic, we have a great problem with community uptake of our product, and we have a great opportunity to break that cycle here, so lets not put any obstacles in our way from the offset. If it turns out we can get feedback on the use of our product, and our users have the opportunity more often than not to change the root, then we should re-address it then, as for now, I really think we should try the all in one folder approach that we currently have. As Ian states, we can opt to follow suit of EE and advise on how to adjust the structure after the fact.
Anyhoo, The main question here is to see how we separate the aspects of our app, the core, the admin, and the frontend.
Why this can not be optional?
Edit: I'm a bit delayed on this comment. Now that I read this:
As Ian states, we can opt to follow suit of EE and advise on how to adjust the structure after the fact.
I agree with John; it's got to be optional. Mind you I'd always go for the more secure option where possible; however simple install = potentially higher user base.
Just throwing this in; if one had to use this two-folder structure how would it impact users who are currently using git to deploy? Two separate git or would it also work with sub modules?
I like the idea of a "Security/Best Practices" article/documentation, as there are a lot more things that can be made in this way. Like file permissions, event filters, htaccess configurations, system folder placement, etc. But this is another subject...
how would it impact users who are currently using git to deploy?
Whatever we do, it would always be one package that we release.
I like the idea of a "Security/Best Practices" article/documentation
Already working on it ;o) (@designermonkey is a busy boy).
I still don't fully understand the the separated app directory != easy install thing, but that's more a personal problem I guess.
Keep in mind that with the one folder concept we have to shut down public access to all files and folders except of index.php and /workspace. Apart from that, I think having the choice to separate public directory would be a great benefit for more advanced setups. Maybe this will even work on the installation level, maybe something like this:
// pseudo code :)
detectLocation: no symphony directory here, must be one directory up;
configureAppPath: ../../symphony/app/
@designermonkey I was playing around with the directory structure you proposed. The only issue I encountered so far is the config path being hardcoded to the application path. If this is a big concern we might have to overload Illuminate\Foundation\Application::getConfigLoader() but that isn't a real problem.
I figure the next step is to replace laravel's configuration with the xml config. So, we maybe should discuss the structure of a config xsd schema first?
@iwyg I've jigged it around a little too myself. I'll fork the repo and get the code in there on my account and we can start to look at it.
This is all still high level stuff, and I still want us to focus on definition first, I've just been doing this while having some personal down time and a holiday.
I've got some ideas for a schema already, bearing in mind we will be loading only Symphony related config with xml, the app config will remain as such, but we will need to define the difference as well.
I don’t know if it has already been discussed, nor if this is the right place to post this, but did you consider to directly use components of Symfony (the PHP framework), instead of Laravel?
Symfony is decoupled in small (and very high-quality) components, and Laravel reuses a lot of them.
Maybe it would be a better solution, there is no imposed structure with these components, and Symphony Next would not be restricted by the requirements of an “end-user framework” like Laravel.
Plus, the Symphony CMS would be powered by the Symfony framework :-)
If Symphony CMS is not going to follow Laravel's conventions and file structure, perhaps Symfony is a better fit. And as has already been pointed out in other issues, Symfony can use XML for configuration already.
that being said, the question is which ORM we are going to pick. Laravel's Eloquent? Doctrine?
The two frameworks differ in which layer of the software cake they operate. Laravel is one level up providing the syntactic sugar to make things a little sweeter whilst Symfony provides a few of the ingredients. Symfony is more of a full-stack framework (modularised of course) whilst Laravel just aims to provide a little opinion and set some sensible defaults and provide some common utilities from the get go. It's designed to make things easier to work with on a daily basis in a similar way Rails did to Ruby. Laravel is popular and lowers the barrier to entry as a result of this and that is a big selling point if the aim is also to increase adoption whilst making it easier for the core developers to work with on a daily basis
Laravel is actually more on a level with something like Silex (also from SensioLabs) so that again could be another option as are other micro-frameworks like Slim and the Fat Free Framework. Generally though I think having Laravel in the mix is one of the key ingredients as it provides the glue and an easy interface to work with on a daily basis for the core team and for potentially interested newcomers. It handles things with elegance and style and riding on the back of the Laravel wave can only be a bonus with the likes of features, documentation and marketing (to an extent) all taken care of.
I think it was mentioned earlier in this thread or another but this is a good discussion on Laravel vs Symfony2 with Taylor summing up a few key benefactors nicely:
http://www.reddit.com/r/PHP/comments/1bdln1/symfony2_vs_laravel
Eloquent would get my vote. That's one of Laravel's strongest points and surely one of the best ORM's available.
I’ll try to clarify my point of view for completeness, hope that helps!
I think that Symphony CMS could provide its own structure (and opinion) on top of PHP / Symfony components, as Laravel and Silex does. I don’t see Symphony as a final application (which is, I think, the target of these frameworks), but more like a CMS / framework hybrid.
What Silex and Laravel are providing is mostly a glue between PHP components and a “way to do things”, which is handy for quickly building a website, but not so much for building a CMS / framework with a lot of special requirements. If we have to get around a lot of things because building an easy to install CMS (for example) is not targeted by the authors of the framework, maybe it is not the right tool for the job.
The good news is that with PSR-0 and Composer, almost every component used by Silex and Laravel can be used separately, without having to use the whole framework (but Laravel 4 is still in active development, and every module − including Eloquent − is physically in the same repository for the moment).
That being said, I really like Laravel, I just finished a project based on Laravel 4 (I chose it over… Symphony CMS!), and I find the framework clean, understandable and easy to use (reading the code helps a lot, the code has moved fast while I developed on top of it the last 4 months, and the documentation is a bit behind). I think Laravel 4 can technically be used for Symphony Next, but maybe not at its full potential because of the Symphony specificities: plugins, easy install, Symphony workspace, XSLT, updates without composer, etc.
PS: maybe another issue should be opened to discuss the pros and cons of each solution regarding the Symphony requirements?