Directory structure conventions - PHPSettling for the "quick and dirty" solution often costs far more time than it saves. This is as true of PHP coding practices as anything else. In this first article in the series, you will learn practices that will save you time and headaches in the long run, and help you write better PHP code.
print this article SEARCH DEV SHED |
Directory structure and filesystem naming conventions are something that rarely receive enough attention in PHP applications. It is common practice to simply begin work and save all project files to a publicly accessible Web directory, despite the fact that many PHP files, especially configuration files and files uploaded through the application itself, never need to be directly accessed via the Web. It is also common to see files of all types – configuration files, function libraries, class files, logs, and so forth all mixed in the main application directory or all stuffed into one subdirectory. In addition to this, files of all kinds tend to have haphazard names that often do not adequately convey the purpose of the file – a problem that is compounded when the files do not live in a directory that conveys the general purpose of a group of files. As a project grows, something seemingly insignificant like a bit of filesystem disorganization can become a maintenance nightmare. It is important to organize your project files, period. Directories should have names that are meaningful and should be in the appropriate location. The image below is an example of what a basic PHP Web application directory structure should look like. Images used in this article will be captured in Windows but do not rely on any operating system specific features or system directories. In this example, “public_html” is the Web accessible directory and “webapp” is our project directory. On Red Hat this might be “/home/webapp/”. The “public_html” directory (the default name for the web directory in Red Hat) will contain files a user would directly access in a Web browser, such as “index.php”. In this directory you would organize your css files, javascript files, and images into the appropriate directories. These files must be in the Web accessible directory since browsers need access to them. The parent directory, “webapp”, is where all files that do not need to be accessed by a Web browser will reside. The “classes” directory will be used to store class files, the “config” directory will store configuration files, “lib” will store files containing function libraries, “logs” will contain our applications custom log files, and “templates” will be the directory where we store our HTML template files. The names of these directories are clear and meaningful and reside in the proper locations. In a product intended for repeat use, files outside of the public Web directory would be stored in a centralized location on the server and accessed by project scripts at that location either directly or by creating symbolic links (shortcuts in Windows) to those directories. There are some simple security considerations when planning your Web applications directory structure, one of which we addressed above – keeping files out of the Web accessible directory if they aren’t accessed via the Web. Other simple considerations include preventing directory listings, blocking hotlinking, and password protecting areas that require a login through .htaccess files (or IIS Virtual Directory configuration). Authentication through .htaccess files uses basic HTTP authentication and is only one possible method of requiring authentication on a directory.
blog comments powered by Disqus |
/ 106 
PHP Closures as View Helpers: Lazy-Loading File Data
