Structuring a Large PHP Project [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

PHP is a largely flexible la开发者_开发问答nguage, I could do this anyhow and anywhere. However, what would you consider to be best practices for structuring large projects?

I have built a bespoke CMS for a client, but as it was my first venture into a large project its a bit of a mess. There's files everywhere, with a very bad folder structure.

A friend suggested that the only files that should sit in the root directory of the website are the "page" files - i.e. the files that actually have HTML in them and that you should have separate folders for each of the different elements, which can then be easily pulled into different pages with includes. Would everybody recommend this route or is it governed entirely by personal preference?

---

If starting a new project, consider using a Framework, or taking a look at how they do it.

Frameworks usually either dictate, or suggest, a directory structure.

Even if you don't end up using one: The way they structure their projects usually comes from tons and tons of experience.

I personally like the Zend Framework way of structuring, and its Autoloader, best. But there are several options and philosophies out there.

Framework questions:

• What PHP Framework to choose

• Best PHP framework for an experienced PHP developer?

• More Framework questions....

Generally related:

• In a PHP project, how do you organize and access your helper objects?

• How to use PHP for large projects?

---

I would recommend having only one file in root folder, being index.php, and make this file include everything else that's needed based on requests received. If you do OOP, it's usually convienient to put your classes into folder structure that mimics your namespacing (whether simulated in PHP <5.3 or actual in 5.3+). This allows for easy autoloading of classes.

---

I'd say it doesnt matter too much how you layout your application folderwise. Having files is a necessity and it has some impact on the application. Address that impact. It's not how you layout your folders, it's why. Find some ideas below.

For security, you should put only those scripts into the webroot that are actually supposed to be directly servable to the world.

Also, if you have files created during runtime, make sure those dont get overwritten when you deploy/update your application to your server. Whether you address that in your deployment routine or by the folder layout is up to you.

For performance, take into account that including files/code that are/is not needed for a particular request will unneccessarily slow down your app. So does having many include_paths to search in. Make sure PHP can find the files it needs fast.

For maintainability, use common sense. There is no rule that you have to have one file per class. There is also no rule that you have to follow PEAR file layout. PEAR is a widespread convention and a reasonable one, but throw your files into a single folder if it makes sense for this particular application.

IMO, an application is not the files, it's the code within. It's much more important to have your code well organized than your files. Having a messy file layout is much less an issue than having a messy architecture.

---

Personally I use the way you described in last paragraph, and find it useful, clean & fast to execure. Be sure to move all common stuff in common libs/files, in no way should you copy/paste.

Another (common) way of structuring is when you use some frameworks, which usually enforce some specific project structure.