Некоторые основные вопросы о структуре веб-сайта

Если это очень простой проект, который вы выполняете и не сотрудничаете с другими разработчиками во время работы над ним сейчас или в будущем, тогда вы можете просто сделать то, что вы уже знаете в PHP, даже процедурный, например, в такой спешке, чтобы закончить его, и у вас нет времени на дополнительное техническое чтение о ООП и каркасах.

Использование коммутатора, предложенного в вашем примере, является самым простым способом разбить файлы, чтобы сделать верхний и нижний колонтитулы и другие общие части повторно используемыми. Но если у вас есть больше времени, узнайте, как использовать шаблоны или еще лучше использовать шаблон MVC, если вы знакомы с ним, поэтому он экономит ваше время при тестировании, отладке, и это упрощает поиск кодов/файлов, потому что все сгруппированы вместе.

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

Структуры PHP обычно объектно-ориентированы и следуют шаблону MVC (Model-View-Controller), просто фреймворк Google и выбирают тот, который вам нравится, и вы больше не вернетесь к старому PHP,

надеюсь, это поможет,

вот некоторые приятные рамки:

http://phpframeworks.com/

счастливое кодирование :)

Все html файлы начинаются с синтаксиса, который вы сказали, и да, register, ask_question, search_question и login all нуждаются в своих отдельных файлах html/php, если вы не собираете их вместе.

Если это помогает, тег для ссылки: [a href "//link name"]//текст для ссылки [/a] теги (<>) заменяются скобками ([])

Я не знаю, насколько вам комфортно с PHP, но не стесняйтесь использовать эту очень простую фреймворк PHP, которую я написал некоторое время назад (хотя я бы настоятельно рекомендовал вам изучить структуру, такую как Laravel).

Причина, по которой я настаивал на надежной структуре, заключается в том, что она была построена и протестирована многими инженерами, поэтому почему мы должны изобретать колесо для создания новой структуры для каждого проекта, чтобы предоставить нам самый простой скелет выражение? Это только замедляет вас.

Если вы решите взглянуть на мою основную фреймворк PHP, основным файлом, которым вы должны быть заняты, является index.php это "пространство движка" для фреймворка и обрабатывает все входящие запросы, а именно этот фрагмент ниже:

require_once(VIEW_PATH . "components/header.php");

if(isset($_GET['page'])) {
    $view = $_GET['page'];
    if(file_exists(VIEW_PATH.$view.".php")) {
        require_once(VIEW_PATH.$view.".php");
    } else {
        header("Status: 404 Not Found");
        header('HTTP/1.0 404 Not Found');
        require_once(CORE_PATH . "http_responses/404.php");
    }
} else {
    // This should only happen when a bogus URL is requested
    require_once(VIEW_PATH."home.php");
}
require_once(VIEW_PATH . "components/footer.php");

Проверяет наличие или отсутствие страницы на сервере, и если она показывает ее пользователю, в противном случае будет представлена страница 404. Обратите внимание, как использование PHP файлов включает функции, мы можем заставить PHP показать верхний и нижний колонтитулы на каждой странице, чтобы уменьшить размер файла (поскольку весь html для файла заголовка теперь инкапсулирован внутри header.php). Это более эффективная реализация для оператора switch, так как вы можете продолжать масштабировать свой проект, и до тех пор, пока вы поместите файл в папку представлений, php найдет его (поэтому вам никогда не придется возвращаться к index.php для добавления другого файла к оператору переключения).

Вы также заметите, что был реализован другой файл hierachy. Хотя у вас нет существенных проблем, вам следует рассмотреть права доступа к папкам, и наличие всего в одном корневом каталоге может вызвать проблемы в будущем. В моих рамках я создал public папку, которая может быть доступна никем, и app папка, которая имеет более строгие разрешения на доступ только приложение (кроме чтения доступа, который каждый может выполнять).

Чтобы ответить на вопрос 3), я бы не включил все ваши функции в один файл, из-за чего все становится бесполезным и сложным в будущем. Как правило, лучше создавать структуру данных для моделирования вашего приложения, например, вы могли бы иметь класс Post для моделирования нового сообщения, которое будет сохранено в базе данных, функции внутри класса Post будут обрабатывать операции CRUD для этого объекта ( создавать, читать, обновлять, удалять). В случае с каркасом, который я предоставил, вы можете увидеть папку под названием модели в /app/core/models. Там вы увидите класс Database.php, который является оболочкой для маршрутизации всех транзакций через базу данных, что означает, что вы производите меньше кода каждый раз, когда хотите выполнить запрос.

Если вы решите использовать мою фреймворк и вам нужна помощь, начните, пожалуйста, свяжитесь со мной или войдите в частный чат.