Project Directory Structures - Please pick holes

[eazyGen]

Hi guys.

 

I am new to PHP, but experienced in other languages. My thoughts today centre on project directory structures. Here is what I have for my current (testing and learning) project. I would be grateful for any constructive criticism.

 

I have a local container directory called "Development", which I periodically upload to the server. This can be thought of as root. Plus within that, I have a single PHP file (index.php) and I will, in time, move my .haccess  file there, plus I have the following directory structure:

 

Root

==>Controller

==>Data

==>Images

====>Decoration

====>Logos

======>Favicon

==>Includes

==>Javascript

==>UI

====>CSS

==>Work

 

As you can see I am trying out an MVC type approach to my test project. The directory purposes are:

 

Controller - Controller scripts

Data - Object Classes that wrap the database tables - I don't call this "Model" as I equate a model with a model and not a db table.

Images - Container for all images

    Decoration - Non essential decorative images (these could easily just be placed in the "Images" folder)

    Logos - Logos of varying size, branding etc (As above, could just be in "Images")

        Favicon - My Favicon (again could just be in "Images")

Includes - Self explanatory I feel

Javascript - Javascripts (I have not progressed much with JS so this is a place holder and subject to change as I learn)

UI - This is usually called "View" from what I can see, but I don't like "View" in this context because I relate "View" to SQL. Plus, this really does contain UI files.

    CSS - CSS

Work - This is just a dump of tests, mics files and anything else. It does not form part of the app.

 

So, apart from the fact that I should be calling MVC (Model, View, Controller) DUC (Data, UI, Controller - and some people will no doubt dislike this immensely) and I could combine the image folders - where would you say the weaknesses are with this approach?

 

The only other thing I guess would be to rename "Development" to the name of the project.

 

Many thanks for any response.

 

S

[trq]

The thing that stands out the most is that your client side stuff is mixed in with your server side stuff.

 

I would be inclined to make a new directory and place all your js, css and images within there own sub directories within that. Then, if your have sufficient privileges to do so your could (and should) also make this your servers document root for this site.

[eazyGen]

The thing that stands out the most is that your client side stuff is mixed in with your server side stuff.

 

I would be inclined to make a new directory and place all your js, css and images within there own sub directories within that. Then, if your have sufficient privileges to do so your could (and should) also make this your servers document root for this site.

"Document root" - are you referring to the DOM? If so, that is further down on my learning path - and so I can bear what you say in mind when I come to that - thanks. Until then I cannot really make any sensible comments.

 

The only other point is this - do you find my blatant disregard of the names of "Model" and "View" a problem? I tend to do things in my own way according to how I see things. That said, there is no point in altering this naming convention if it confuses the rest of the world.

 

Thanks for your thoughts.

 

S

[KevinM1]

He means make it your web root.  Aside from your index script, you don't need your PHP code in your web root in order for it to work.  In fact, it's more secure to keep your PHP somewhere above your web root in order to block all outside access to it.

 

And, yeah, all static content (read: non-PHP, non-db) should be in its own folder, with whatever folders you need for organization inside.

 

RE: naming conventions - conventions are conventions for a reason.  Do you anticipate confusion?  Are you aiming for your system architecture to be used by others?

[eazyGen]

He means make it your web root.  Aside from your index script, you don't need your PHP code in your web root in order for it to work.  In fact, it's more secure to keep your PHP somewhere above your web root in order to block all outside access to it.

 

I have this in place. In the root I have only index.php, .htaccess and then sub directories. I have an includes directory (I am going to change that to "requires") and in there I have the db connection data declared once, although I am not entirely sure how secure this really is.

 

And, yeah, all static content (read: non-PHP, non-db) should be in its own folder, with whatever folders you need for organization inside.

 

Is there any particular reason for this???

 

RE: naming conventions - conventions are conventions for a reason.  Do you anticipate confusion?  Are you aiming for your system architecture to be used by others?

 

I think I am trying to get a flavour of the php community and how it thinks. I have seen many a convention that is a very poor one. In fact, the joke was - "The good thing about standards is there are so many to choose from". But I will have to think on this some more. At this point I am building my views piece by piece.

 

Thanks for you comments.

 

S

[trq]

I think your still misunderstanding what the web root is.

 

My typical structure is (simplified) something like:

 

[pre]

project

  htdocs

    assets

      js

      css

      imgs

    .htaccess

    index.php

  lib

    MyFramework

[/pre]

 

Where the htdocs directory is configured to be my web servers document root. My framework would then sit within a lib directory completely outside of a position where it is at all accessible via the web. In fact my framework will most often sit in /usr/share/php or some other globally accesible location and I will just add it to my include_path in order to use it. Point being, your php code does not need to be within your web root (only the index.php file which bootstraps the application).

 

That's not to say you have to do it this way, and in fact most people don't or can't because they simply do not have the ability to do so because of there hosting.

[eazyGen]

Ahh. You are right. I misunderstood root.

 

I think I have it now.

 

And I think your example also explains the reason why you separate the client and server side functions. Presumably, this is because users will request client side files (js scripts etc) and they MUST have access, otherwise we all fall down?

 

I will need to have a re-think here.

 

One last thing. For the sake of security, ought I to put all my config data in a "config" directory and allow read only access to that directory? Or is there a better technique?

 

Thanks for your thoughts?

 

S

[trq]

One last thing. For the sake of security, ought I to put all my config data in a "config" directory and allow read only access to that directory? Or is there a better technique?

 

Any data outside of the web server root can not be accessed via the web. Hell, you can even place passwords etc etc inside a php script within the web root and they can't be read unless your script echoing the variables back to the client. This can fall over however if somehow your server becomes misconfigured and starts server php as plain text.

 

All files and directories only need to be read by the web server. Of course, you yourself may need write access to be able to edit the application though this should really be done on a separate dev server and then your application installed into production. Keep in mind that some directories may also need to be writable by the web server if you wish users to be able to upload files etc etc.

 

Most of what I'm covering here is probably a bit over the top for general web sites, and allot of hosts won't even grant you the ability to do allot of what I've mentioned, but I figure your asking the questions so.....

[eazyGen]

Most of what I'm covering here is probably a bit over the top for general web sites, and allot of hosts won't even grant you the ability to do allot of what I've mentioned, but I figure your asking the questions so.....

This is all good. What I have in mind is anything but a "general web site". However, I am a natural worrier and security plays on my mind. Are you able to point me at a good resource that covers the whole subject of security?

 

Many thanks,

 

S

[eazyGen]

I think your still misunderstanding what the web root is.

 

My typical structure is (simplified) something like:

 

[pre]

project

  htdocs

    assets

      js

      css

      imgs

    .htaccess

    index.php

  lib

    MyFramework

[/pre]

 

Where the htdocs directory is configured to be my web servers document root. My framework would then sit within a lib directory completely outside of a position where it is at all accessible via the web. In fact my framework will most often sit in /usr/share/php or some other globally accesible location and I will just add it to my include_path in order to use it. Point being, your php code does not need to be within your web root (only the index.php file which bootstraps the application).

 

That's not to say you have to do it this way, and in fact most people don't or can't because they simply do not have the ability to do so because of there hosting.

After having given this a little more thought I have some further questions – many thanks for any responses.

 

I can see that your client directories and files (plus the index.php, and the .htaccess) sit nicely under your root.

 

Lib contains everything else, which again seems nice.

 

However, the functions within your framework may use php to dish up html pages. In this case, would they not need reference images and js? If they do, what would you say is the best way to specify the path to these items?

 

In your example above, if you had a function called myfunction.php, which resided in your “MyFramework” directory, and it wanted to reference myimage.gif in your img directory, would you do something like this:

 

<img src="../imgs/myimage.gif" Title="myimage" alt="myimage" />

 

Also, you mention the include_path. I have looked around for this, but am not 100% with it yet. Here are my questions:

 

Is the purpose of include_path to store one or many paths?

Is it only there to support “includes” (or requires)?

Why would I use this if I can use relative paths in my code (re-use????)?

 

To what extent is any of this platform specific? If portions ARE platform specific, are there ways to alter it to run across platforms?

 

Thanks again,

 

S

[trq]

Images and Javascript need to be referenced relative to the url they are called from. These are not filesystem paths like what PHP uses, but urls.

 

Placing directories or files on your include_path means that you can access them without the complete path. eg; You may have a file at: /usr/share/php/foo.php Now, if /usr/share/php is on your include path you only ever need to use:

 

include 'foo.php';

 

to get this file. This makes things even easier when your using OOP and PHP's auto loading capabilities. See __autoload & spl_autoload.

[eazyGen]

Images and Javascript need to be referenced relative to the url they are called from. These are not filesystem paths like what PHP uses, but urls.

 

Placing directories or files on your include_path means that you can access them without the complete path. eg; You may have a file at: /usr/share/php/foo.php Now, if /usr/share/php is on your include path you only ever need to use:

 

include 'foo.php';

 

to get this file. This makes things even easier when your using OOP and PHP's auto loading capabilities. See __autoload & spl_autoload.

Thank you kindly sir.

 

I just wrapped __autoload into my app and it is working nicely.

 

I appreciate your thoughts and comments.

 

S