Proper site structure using PHP, HTML, and CSS?

Question

I know this questions probably been used and abused.... but i keep seeing conflicting arguments. So, what is the BEST way to structure a site using php, html, and css (+ minimum javascript). I've heard of people storing all of their files in a hidden directory above the root and including, I've heard of people using an include folder with subdirectories such as classes, functions, etc. I heard of people having an uploads folder in a separate directory on a separate server all together, like amazon...

So what exactly is the BEST way to structure a website, and what should I place in each folder.

side note: for user uploaded photos, if i were to assign a default photo for each user, where would I place the default photo (in the same directory?). Also, how should I represent that in the database (default photo name vs. NULL) keep in mind at the time, users can upload a maximum of 1 photo, and its set using their user id

EDIT

The site is fairly simple, nothing extravagant. As of now, I have a folder of classes, a folder of functions, a folder of forms, a folder of templates (with css), an includes folder with a configuration file, an uploads folder, and a captcha folder with fonts and stuff for captcha images. Everything is in public accessible folders, but I am running checks to prevent users from accessing private data.

Answer 1

The best way is only ever the best way for you (or me); and depends entirely on the requirements of the person who owns/runs the site.

I'd suggest that placing all sensitive information and logic outside of the web-root, but that's only because of security. Otherwise, it doesn't matter so long as it makes sense to you where everything is.

If you update your question with your requirements, then we can give you some useful answers.

---

Edited

In response to the following update:

The site is fairly simple, nothing extravagant. As of now, I have a folder of classes, a folder of functions, a folder of forms, a folder of templates (with css), an includes folder with a configuration file, an uploads folder, and a captcha folder with fonts and stuff for captcha images. Everything is in public accessible folders, but I am running checks to prevent users from accessing private data.

I'd -very, very strongly- suggest moving those items for which you're "checking to prevent users accessing private data" outside of the web-root. This is for -at least- two reasons, but my favourites are:

1. Why make work if you don't have to? (Work smart, not hard)
2. Your code, and mine¹, sucks, and has bugs; why expose yourself (and your users) to unnecessary risks?

If you don't want the public to access data don't put it somewhere they can access. To (severely) paraphrase Crowley: why put restricted information where people can get to it?

For the most part, I like your design, though. And if it works for you then my whining about where you store, and control access to, is irrelevant. Your data and its model is entirely down to your tastes and use-case. If it ain't broke, don't fix it.

But be as prepared as possible for it to break, because it -very probably- will: users are invaluable, but they're a hazard too.

---

1: I would've linked to further articles here, but I wasn't sure about nesting html in SO answers. And I didn't want to mess with the formatting/markdown too much. But you get the point, we make crappy software with bugs, so any checks are likely to be fragile. So why put yourself through that?

Answer 2

/site
    /app
    /public_html
        index.php
        /js
        /css
        /images

Where /app is below the web root, which is /public_html

Answer 3

For me, the important thing is to separate system and data. If you have user-uploaded photos, they don't want to be under the same images folder as all your application's static images. Otherwise, you'll forever be mucking around extracting the user images when you do an app update.

Instead, a folder structure something like:

appname
    system
        htdocs         (the web root)
            imgs
            scripts
            styles
        includes       (app code kept outside the root)
        files          (any other random resources the app needs)
    data
        public
            avatars
        private        (runtime data that shouldn't be visible to webserver)

Then you can set the perms on data to allow the webserver user write access, and just swap out the whole system directory when you're upgrading the app.

You'd mount the publically-accessible runtime data using an Alias (in Apache), so you'd have URLs like ‘http​://www.example.com/data/avatars/12345.gif’ for the runtime data and ‘http:​//www.example.com/img/default-avatar.gif’ for the static images.

(If each user has one image and there is a numeric user ID to go on, I'd use that for a filename rather than storing each filename in the database; then you'd only need a boolean flag for ‘user has image’, and otherwise link the default image. What you don't want to do is allow the user to supply a filename themselves, as this needs an awful lot of work to make it safe.)

Best? No such thing really. But this kind of approach causes me least problems at the deployment end.

Be careful allowing users to upload images. In particular thanks to IE's inane Content-Type sniffing, it can be a nasty security hole: images can have HTML with JavaScript embedded in them, allowing cross-site-scripting attacks. This can be avoided by processing the image and/or serving user-uploaded files from a different hostname.

Answer 4

In general the following folder structure is a very usefull one. You can of course simplify it, for example if you're not working with a framework or if you're not using the MVC pattern. Important is just to have a web_root which is publicly accessible. Meaning that your server points to that folder. For example in Apache httpd.conf it would be the DocumentRoot.

/application
    /config
        application.ini
    /controllers  
    /views  
    /models
    bootstrap.php
/var  
    /log  
/tests  
    /controllers  
    /views  
    /models  
/libraries  
    /mylib  
    /myframework  
/web_root  
    /media  
    /js  
    /css  
    index.php  
    .htaccess