Physical Application Structure

[designermonkey]

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)

[designermonkey]

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:

1. Can Laravel run code like controllers, and models from different locations, like /symphony/app/models and /workspace/models?
2. Could we possibly have our admin separate from the /symphony api app in another root folder /admin for instance? Having it's own separate routes, models etc?

[brendo]

Related, symphonycms/symphony-2/issues/1477

[iwyg]

@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.

[iwyg]

@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.

[designermonkey]

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.

[iwyg]

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.

[DavidOliver]

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.

[michael-e]

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!

[ijy]

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.

[ijy]

@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.

[michael-e]

Agreed.

[DavidOliver]

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.

[iwyg]

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.

[designermonkey]

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.

[michael-e]

really seems to be a bit of a lousy argument.

??? No comment.

[bernardodiasc]

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.

[jonmifsud]

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?

[bernardodiasc]

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...

[designermonkey]

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).

[designermonkey]

Already working on it

Documentation in general I mean.

[iwyg]

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/

[iwyg]

@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?

[designermonkey]

@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.

[bpierre]

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 :-)

[designermonkey]

I have to say, I have thought this.

[DavidOliver]

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.

[iwyg]

that being said, the question is which ORM we are going to pick. Laravel's Eloquent? Doctrine?

[ijy]

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

[ijy]

Eloquent would get my vote. That's one of Laravel's strongest points and surely one of the best ORM's available.

[bpierre]

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?

[ijy]

I think Laravel is still only provisionally chosen as the framework to build with at this point and there are a lot of good options that there isn't so much a right and wrong but just best fit with all things considered. It's a valid suggestion and one which was also brought up in the original forum thread.

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.

If you look at it like that though then why move away from the current code base for a complete rewrite at all as it will still be a custom framework which needs developing, documenting, and promoting. The choice of a popular framework is to try and take that burden away so the core team can just focus on improving Symphony at it's core values. Sometimes a little opinion and a scaffold based on best practices can be a good thing when it's weighed up against what the business objectives of the system are and where the efforts need to be focused.

Would 'built on Laravel for easy extension with ready documentation' or 'built on another custom code base for you from scratch' be more of a draw for those looking for a CMS to work with?

[designermonkey]

I would like to continue this discussion on another thread.

We should keep this to the physical structure of the applications we are building, as it is important to consider.

[lewiswharf]

I'd like to point out that for obvious reasons the application directory shouldn't be located within the public web root.

I agree. Symphony Next needs to be forward thinking and best practices are certainly a good start. I believe security is still in its infancy when it comes to the web and I don't believe hanging on to outdated thinking is a good decision.

There's nothing wrong with having barriers to entry. The community as a whole should support the idea of Symphony Next appealing to smart designers & developers, as it has always done.

[jensscherbl]

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!

So we should drop XSLT as well and introduce a marketplace for ready made themes? ;) Sorry to bring this up again, but since when is Symphony targeted to starters?

[iwyg]

"starters" is a highly extendable expression :)

[jensscherbl]

I've got a default Laravel working with the following structure, and so would like to propose it as our structure:

@designermonkey What's the point in using manifest instead of /app/storage or workspace instead of public? I would say keep it simple and stick with the frameworks recommendations.

Besides, you already thought about file structure a while ago for 2.4. The old proposal looked pretty good to me, so if we really have to have our own structure, why changing this once again and not using this one?

[designermonkey]

The old proposal is basically the same as above? I don't see what the problem is??

[designermonkey]

The point is they are terminology for our existing app and heavily entrenched in how we work.

[iwyg]

So, you say having both workspace and manifest/ reflects symphony's identity? Like wordpress and wp-content or t3 and fileadmin?

[designermonkey]

Kind of yeah, we have the $workspace parameter.

We have a specific structure from a frontend perspective and I can imagine that if we went with another, we would end up saying things like 'it was in the workspace, sorry, public folder'.

Also bear in mind, if we use a public folder, all of the admin assets wild need to either be in there too, or provided by a php script as they wouldn't be see able from outside the docroot.

The thing we are changing is the underlying framework, not how the app is seen as a package IMO, but this is all just my opinion, if @allen or @brendo make an executive decision I will of course shut up. We can't please everyone's opinion.

I do fully understand the security concerns, it's something I do day to day as a manager, I just see it as a barrier here on uptake.

[lewiswharf]

So, you say having both workspace and manifest/ reflects symphony's identity? Like wordpress and wp-content or t3 and fileadmin?

Kind of yeah, we have the $workspace parameter.

I see. This is not true for me. XSLT, Fields, Sections, Events, and Data sources define Symphony for me.

[designermonkey]

It might not be true for many seasoned Symphony developers, but as the community lead, I have to take into account how all of the community would see a change like this; Developers, Designers, Authors etc.

Symphony's learning curve is difficult at best, and yes we are changing the underlying framework, but on the surface we should remember that not everyone can pick up changes that easily. Keeping to our existing front facing structure should be a thing we consider very seriously.

[jonmifsud]

I second what Mark said; for me its the XSLT, Fields, Sections, Events, and Data sources.

workspace is just the place where I put all the stuff; yes would be nice to keep the {$workspace} variable not to break the XSLT templates we did but if this had to change its no big deal to change it.

how the folder is named doesn't make a big difference to the Symphony Ideals.

On 10 May 2013 14:58, Mark Lewis notifications@github.com wrote:

So, you say having both workspace and manifest/ reflects symphony's identity? Like wordpress and wp-content or t3 and fileadmin?

Kind of yeah, we have the $workspace parameter.

I see. This is not true for me. XSLT, Fields, Sections, Events, and Data sources define Symphony for me.

— Reply to this email directly or view it on GitHubhttps://github.com/symphonycms/symphony-next/issues/9#issuecomment-17718598 .

[ijy]

I agree. I'm sure it'll be made very clear that Symphony Next is a complete deviation from Symphony 2 from the ground up so I'm sure a few small name changes to directories and variables here and there will be understood. Try to keep to previous convention where possible but not if it's too the detriment of Symphony Next in having to jump through hoops to make things line up or go against current best practices.

[brendo]

I've installed Laravel 4 briefly to have a look around and after a little bit of a looksie, I'm thinking/hoping that Next would just be another package (lives in /vendor) and it uses Laravel conventions as much as possible (ie. use app/config instead of our manifest/config.php file, use app/storage/(logs|cache|meta) instead of manifest/logs//manifest/cache/, manifest/tmp/)

I agree with the others, I don't see Symphony as being defined by the current naming conventions. Just the concepts that are shown through the UI.

Using app/config and individual files per 'group' is pretty much what we did with S3, so that change isn't too drastic.

There's a couple of folders I haven't quite figured out yet, but I'm sure I'll learn more as I keep picking through it.

[brendo]

Oh ignore part of me, I went and installed Laravel, not just Laravel Framework. Doh!

[designermonkey]

This is the laravel that everyone is talking about: https://github.com/laravel/laravel/tree/develop

[brendo]

Not quite, we'd use the Laravel Framework IMO.

[designermonkey]

Which would mean building our own application structure around it, which would make me a happy boy.

The 'Laravel' application I linked to, which everyone is meaning in these threads, includes this framework and all of the Symfony packages too that it needs. What I am talking about is to have our own application structure using these tools.

I based my layout (and I'm still playing) on using the 'Laravel' application but modified.

[brendo]

I based my layout (and I'm still playing) on using the 'Laravel' application but modified.

I think we're probably better off just using the actual framework. It'll give us a little more freedom and will save us having to 'hack' the Laravel defaults for our purposes. We'll build Next using the Laravel Framework, not the actual Laravel end product.

Is that what you imagined too @iwyg @nils-werner?