Refactor site structure to reflect real website

Archives Feature Requests
1

Hi,

this is actually suggestion for planned Yii 2.0, but i could not find any separate forum for that.

In Yii 2.0, generated webapp (via CLI) should better reflect real-world organization of directories with regard to writing permissions and private versus public access.

This is most suitable structure and I use it almost without change in every project:




[private, read-only]

/app/             ... Yii application

/framework/       ... Yii framework

...


[private, writable]

/writable/        ... all writable private contents

/writable/cache/

/writable/log/

/writable/temp/

...


[public, read-only]

/public/  

/public/css/ 

/public/js/ 

/public/images/ 

/public/themes/ 

...


[public, writable]

/public/assets/     ... framework assets

/public/temp/       ... e.g. uploaded images

...

in short:




/app

/framework

/writable

/public

Current structure of CLI generated webapp is not quite well thought through, actually I must always

spend some time to move directory to provide more secure and easier maintainable structure:-)

Main problem is the [protected] folder containing writable and read-only contents, which is insecure and harder to maintain.

What do you guys think - would this structure be better or not?

Cheers

Lubos

2

Why writing to protected is insecure? Only log and temp/cache files are there. I mean if it’s moved to private area.

3

Hi,

writing to /protected in not insecure, if one knows how to set correct access permission (linux).

However, I find unfortunate that the /protected directory is placed inside of the PUBLIC area (along with /assets/).

In real world, web hostings usually provide structure like this:




/mydomain/

/mydomain/public/

which is correct.

Under /mydomain/ I would place /mydomain/protected and under /mydomain/public/ I would place /mydomain/public/assets/:




/mydomain/protected/      (or more suitable would be /mydomain/application/)

/mydomain/public/assets/

Yii webapp should reflect these real-world needs, which most of time need to distinguish between:




/private-read-only

/private-writable

/public-read-only

/public-writable

In such a case it is very transparent to maintain correct access permissions across the application, e.g. one could recursively set with a single shell command all /public-read-only not to be writable.

Unfortunatelly, Yii mixes up the above into following structure:




/public-or-private-read-only (depending on access permissions for each directpry, applies to all /* directories)

/public-or-private-writable (depending on access permissions, this applies to /protected/runtime)

Such a structure is not really practical coz:

  • one must set access permissions individually for each directory (so easy to make a mistake!)

  • one must move up and down directories when starting new project to make it more secure - at least in my experience:-(

Regarding the /writable, it may contain many other subdirectories, like /document_archive/, /sqlite_data/, /log/ etc. so it is perfect candidate for a single shell command e.g. [#chmod -R 0777 writable].

Cheers.

Lubos

4

777??

You really don’t need that for assets or protected/runtime - if it’s writable for the server/php, then that should be enough.

777 is just wide-open…

5

I have no problems with the current structure but I do always configure the assetsPath and runtimePath to be outside the web root if possible. It just makes it easy to replace the logic without affecting the logs/cache etc.

6

assets outside of webroot? How it’s being served then?

lubosdz

I think it’s a good idea to move protected outside of webroot and rename it to something like app so name will match what’s inside. Also path alias can be renamed to app.

7

I should point out that this structure has benefits too.

Right now I have a project with many sites, admin panels and other stuff, that just looks like this:

yii/

project1/

project2/

project3/

project4/

They all use "yii/" as the source for the framework itself.

So it should be done in a maner that regards such scenario of shared Yii source between bunch of projects and not to put the path for the framework inside the project itself by default like mentioned above.

8

An Apache Alias deals with that. It just depends on the access level you have on your box at the end of the day.

9

Well, you can generate a webapp just like you want to. :)

[list=1][]Copy yii/framework/cli/views/webapp to yii/framework/cli/views/betterapp.[]Copy yii/framework/cli/commands/WebAppCommand.php to yii/framework/cli/commands/BetterAppCommand.php.[]Edit BetterAppCommand.php to suit your needs - like swapping webapp with betterapp, etc.[]Restructure the contents of yii/framework/cli/views/betterapp to your liking.[*]Run yiic betterapp /var/www/betterapp_test[/list]Then you don’t have to redo the same things every time you create a webapp. ;)

10

You could extend this to:




yii/

  trunk/

  tags/

    1.1.5/

    1.1.6/

    1.1.7/

    1.1.8/

project1/

project2/

project3/

project4/

This way, you can upgrade your projects to newer versions of yii one by one, reducing the danger that an update breaks anything. Going one step further, I liked to have no relative pathes at all. Only “$yii = ‘yii/tags/1.1.8’;”, because I’ll care for myself, that the yii folder is in PHP’s include path.

But I think more important than having code generated that fulfills everyone’s wishes is to generate code that works out of the box. And once it’s coming to this, the current approach is okay. Regardless where you placed the framework, after you have generated you application stub, it’ll work. And this is most important to newcomers.

Maybe it’d be better to provide some sort of config/ template that more experienced users could tweak to get the stub generated the way they like it?

//EDIT:

It’s official: I’m typing way too slow… :(

11

Samdark

Hi, that would be cool. Also renaming to "app" would be great!

Of course, 0777 was just example, normally 0744 should suffice or so, depending on particular needs.

Say_Ten

Why should apache handle static contents…?? It’s just performance not wise.

jacmoe

Well, I am using Yii since it saves my time. I dont want to develop modules for my own perhaps one-time usage since I must focus on applications. My point here was, that generic CLI generated web application should enforce good and more secure habits with better thought-through structure.

Cheers.

lubos

12

I think you misunderstood what I wrote.

You are not supposed to go through those steps more than once.

Then every time you need a type of your app, generate one - just the way you want it.

Can’t get more time saving than that.

It’s just a matter of doing a yiic betterapp where_to_put_it

I have several, including some which I have added and configured several oft-used components/extensions.

It really saves time.

Personally, I don’t fancy your proposal.

I would definitely be doing a custom app template for my own use if that goes into Yii… ;)