使用 PHP、HTML 和 CSS 的正确网站结构？
我知道这个问题可能被使用和滥用......但我不断看到相互矛盾的论点。那么，使用 php、html 和 css（+ 最少的 javascript）构建网站的最佳方法是什么？我听说有人将所有文件存储在根目录上方的隐藏目录中，包括，我听说有人使用包含类、函数等子目录的 include 文件夹。我听说有人在单独服务器上的单独目录，例如亚马逊...
那么构建网站的最佳方法到底是什么，以及我应该在每个文件夹中放置什么。
旁注：对于用户上传的照片，如果我要为每个用户分配默认照片，我会将默认照片放在哪里（在同一目录中？）。另外，我应该如何在数据库中表示（默认照片名称与 NULL），请记住，用户最多可以上传 1 张照片，并使用其用户 ID 设置
编辑
网站相当简单，没有什么奢侈的。截至目前，我有一个类文件夹、一个函数文件夹、一个表单文件夹、一个模板文件夹（带有 css）、一个包含配置文件的文件夹、一个上传文件夹以及一个包含字体和内容的验证码文件夹用于验证码图像。所有内容都位于公共可访问的文件夹中，但我正在运行检查以防止用户访问私人数据。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
其中 /app 位于 Web 根目录下方，即 /public_html
Where /app is below the web root, which is /public_html
最好的方式永远是最适合你（或我）的方式；并且完全取决于拥有/运营该网站的人的要求。
我建议将所有敏感信息和逻辑放在网络根目录之外，但这只是出于安全考虑。否则，只要一切都对你来说有意义就没关系。
如果您根据自己的要求更新问题，那么我们可以为您提供一些有用的答案。
Edited
响应以下更新：
我非常非常强烈地建议将那些您正在“检查以防止用户访问私人数据”的项目移到网络根目录之外。这至少有两个原因，但我最喜欢的是：
如果您不希望公众访问数据，请不要将其放在他们可以访问的地方。 （严重）解释克劳利：为什么要把受限制的信息放在人们可以访问的地方？
不过，在大多数情况下，我喜欢你的设计。如果它对你有用，那么我对你存储位置和控制访问的抱怨就无关紧要了。您的数据及其模型完全取决于您的品味和用例。如果它没有坏，就不要修理它。
但要尽可能做好它崩溃的准备，因为它很可能会崩溃：用户是无价的，但他们也是危险的。
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?
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:
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:
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?
一般来说，以下文件夹结构是非常有用的。当然，您可以简化它，例如，如果您不使用框架或不使用 MVC 模式。重要的是要有一个可公开访问的 web_root 。这意味着您的服务器指向该文件夹。例如，在 Apache httpd.conf 中，它将是
DocumentRoot。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.对我来说，重要的是系统和数据的分离。如果您有用户上传的照片，它们不希望与应用程序的所有静态图像位于同一图像文件夹下。否则，当您进行应用程序更新时，您将永远忙于提取用户图像。
相反，文件夹结构类似于：
然后您可以在
data上设置权限以允许网络服务器用户写入访问权限，并且在您需要时交换整个system目录升级应用程序。您可以使用 Alias（在 Apache 中）挂载可公开访问的运行时数据，因此您可以使用类似于“http://www.example.com/data/avatars/12345.gif”的 URL 来表示运行时数据，并使用“ http://www.example.com/img/default-avatar.gif' 用于静态图像。
（如果每个用户都有一个图像并且有一个数字用户 ID，我会使用它作为文件名，而不是将每个文件名存储在数据库中；那么您只需要一个布尔标志来表示“用户有图像” ，否则链接默认图像。您不想做的是允许用户自己提供文件名，因为这需要大量工作才能确保安全。）
最好？确实没有这样的事情。但这种方法在部署端给我带来的问题最少。
请小心允许用户上传图像。特别是由于 IE 愚蠢的内容类型嗅探，它可能是一个令人讨厌的安全漏洞：图像可以包含嵌入了 JavaScript 的 HTML，从而允许跨站点脚本攻击。这可以通过处理图像和/或从不同的主机名提供用户上传的文件来避免。
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:
Then you can set the perms on
datato allow the webserver user write access, and just swap out the wholesystemdirectory 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.