Правильная структура сайта с использованием PHP, HTML и CSS?

Question

Я знаю, что эти вопросы, вероятно, использовались и злоупотребляли .... но я продолжаю видеть противоречивые аргументы. Итак, какой ЛУЧШИЙ способ структурировать сайт, используя php, html и css (+ минимальный javascript). Я слышал о людях, которые хранят все свои файлы в скрытом каталоге над корневым каталогом, в том числе слышал о людях, использующих папку include с такими подкаталогами, как классы, функции и т. Д. Я слышал о людях, у которых есть папка для загрузки в отдельный каталог на отдельном сервере все вместе, как amazon ...

Итак, что именно ЛУЧШИЙ способ структурировать веб-сайт, и что я должен поместить в каждую папку.

примечание: для загруженных пользователем фотографий, если бы я назначил фотографию по умолчанию для каждого пользователя, где бы я разместил фотографию по умолчанию (в том же каталоге?). Кроме того, как я должен представлять, что в базе данных (имя фотографии по умолчанию против NULL) следует помнить, что в то время пользователи могут загрузить максимум 1 фотографию, и ее можно установить, используя свой идентификатор пользователя

EDIT

Сайт довольно прост, ничего экстравагантного. На данный момент у меня есть папка классов, папка функций, папка форм, папка шаблонов (с css), папка включений с файлом конфигурации, папка для выгрузки и папка капчи с шрифтами и прочим. для изображений с картинки. Все находится в общедоступных папках, но я запускаю проверки, чтобы запретить пользователям доступ к частным данным.

Answer 1

В общем, следующая структура папок очень полезна. Вы, конечно, можете упростить его, например, если вы не работаете с фреймворком или не используете шаблон MVC. Важно просто иметь web_root, который общедоступен. Это означает, что ваш сервер указывает на эту папку. Например, в Apache httpd.conf это будет 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  

Answer 2

Для меня важно разделить систему и данные. Если у вас есть загруженные пользователем фотографии, они не хотят находиться в той же папке изображений, что и все статические изображения вашего приложения. В противном случае вы навсегда извлечете уроки из извлечения пользовательских изображений при обновлении приложения.

Вместо этого структура папок выглядит примерно так:

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)

Затем вы можете установить разрешения на data, чтобы разрешить пользователю записи веб-сервера доступ для записи, и просто поменять весь каталог system при обновлении приложения.

Вы бы смонтировали общедоступные данные времени выполнения с помощью псевдонима (в Apache), чтобы у вас были URL-адреса, такие как «http: //www.example.com/data/avatars/12345.gif» для данные времени выполнения и 'http: //www.example.com/img/default-avatar.gif' для статических изображений.

(Если у каждого пользователя есть одно изображение и существует числовой идентификатор пользователя, я бы использовал его для имени файла, а не для хранения каждого имени файла в базе данных; тогда вам нужен только логический флаг для 'user has image ', и в противном случае создайте ссылку на изображение по умолчанию. Вы не хотите, чтобы пользователь сам предоставил имя файла, так как для обеспечения его безопасности требуется очень много работы.)

Лучший? Нет такого на самом деле. Но такой подход вызывает меньше всего проблем в конце развертывания.

Будьте внимательны, позволяя пользователям загружать изображения. В частности, благодаря тщательному анализу содержимого типов в IE это может стать неприятной угрозой безопасности: в изображения может быть встроен HTML-код с JavaScript, что позволяет выполнять атаки с использованием межсайтовых сценариев. Этого можно избежать, обрабатывая изображение и / или обслуживая загруженные пользователем файлы с другого имени хоста.

Answer 3

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

Где / app находится ниже корня сети, что / public_html

Answer 4

Лучший способ - только лучший для вас (или меня); и полностью зависит от требований человека, который владеет / управляет сайтом.

Я бы предложил размещать всю конфиденциальную информацию и логику за пределами веб-корня, но это только из-за безопасности. В противном случае, это не имеет значения, если для вас имеет смысл, где все.

Если вы обновите свой вопрос в соответствии с вашими требованиями, то мы можем дать вам несколько полезных ответов.

<ч /> 1008 * Отредактировано *

В ответ на следующее обновление:

Сайт довольно прост, ничего экстравагантно. На данный момент у меня есть папка классов, папка функции, папка форм, папка шаблонов (с CSS), включает в себя папка с файлом конфигурации, папка загрузки и папка с картинкой со шрифтами и прочее для капчи изображений. Все на публике доступные папки, но я бегу проверяет, чтобы запретить пользователям доступ личные данные.

Я бы очень, очень настоятельно рекомендовал переместить те элементы, для которых вы «проверяете, чтобы пользователи не имели доступа к личным данным», за пределы корневого веб-узла. По крайней мере, по двум причинам, но мои любимые:

1. Зачем делать работу, если не нужно? (Работай умно, а не усердно)
2. Ваш код , и мой ¹ , отстой и содержит ошибки; зачем подвергать себя (и своих пользователей) ненужным рискам?

Если вы не хотите, чтобы публика получала доступ к данным не кладите их куда-либо, они могут получить доступ к . Перефразировать (строго) Кроули : зачем размещать ограниченную информацию там, где люди могут получить к ней доступ?

По большей части мне нравится ваш дизайн. И если это работает для вас, то мое нытье о том, где вы храните и контролируете доступ, не имеет значения. Ваши данные и их модель полностью зависят от ваших вкусов и вариантов использования. Если это не сломано, не исправляйте это.

Но будьте как можно более подготовлены к тому, чтобы он сломался, потому что он - очень вероятно, будет: пользователи бесценны, но они тоже опасны.

<ч /> 1: я бы связался с другими статьями здесь, но я не был уверен насчет вложения html в SO ответы. И я не хотел слишком много возиться с форматированием / уценкой. Но вы понимаете, мы делаем дрянное программное обеспечение с ошибками, поэтому любые проверки могут быть хрупкими. Так зачем себя переживать?