Штирлиц — Сеть печатных салонов в Перми

Весь комплекс печатных услуг в Перми. Общирная сеть печатных салонов в Перми. Цифровая печать, цветное и черно-белое копирование документов, сканирование документов, ризография в Перми

Структура сайта на php: Структура сайта. что, где и как должно работать? — Хабр Q&A

Содержание

Структура сайта. что, где и как должно работать? — Хабр Q&A

Добрый вечер! Помогите, пожалуйста, разобраться как павильно сделать структуру сайта. Не судите строго, я только недавно начала изучать и многого не знаю.
Сейчас он выглядит так(верстка будет дорабатываться), на данный момент он делает все то, что я хотел.

Можно посмотреть новости по категориям, прочитать полностью, зарегистрироваться и оставить комментарий, администратор может добавлять новости и категории которые сразу появятся на сайте. Но, происходит это с достаточно большой задержкой(как для такой верстки). Я понимаю, что это из за сплошного ХАОСА в файлах. Что у меня происходит можете лицезреть ниже. Это все файлы нужны для работы сайта в данном виде.

Макет содержит 3 страницы, 1 — это главная index.php, 2 — это новость полностью и 3 — это страница для админа с добавлением новостей и тп.

Работает это так. Есть некий index.php который с помощью require_once покдлючает header и тп.
Если с страници есть какойто запрос он отправляеться в соответсвующий файл в папке scripts где в свою очередь файл(скрипт) снова require_once файл класса и что то там делает, и возвращается обратно на страницу.
Пример «скрипта».

Вопрос состоит в том как правильно должна виглядеть структура сайта, что и !!!КАК!!! должно между собой работать?
Как пхп должен отображать(как я сейчас делаю на скрине ниже) html код, сколько php должен содержать html код?
Если использую php в html, то как лучше, подгружать файл с кодом php или писать непосредственно в html?
Как правильно загружать разные части сайта типу header или footer?
и т.д.
Читал, видел паттерн MVC, но на данный момент не особо разобрался в нем. И так же интересно есть ли какие-то гласные/негласные правила проектирования сайтов, другие варианты кроме CMS и MVC?
P.S. Если ваш аргумент за MVC, будьте так любезны, оставьте ссылку на хороший туториал о нем.(уже читал habrahabr.ru/post/150267 )
И еще 1 вопрос, данную часть кода я использую для проверки авторизации и соотвественно для вывода нужных блоков html. Находиться он в html-файле с версткой. Как правильней сделать такую проверку, что б от результата зависело отображение нужных блоков?
<?php if (isset($_SESSION['user_id'])) {
       echo  "<div class=exit>
                <form name=logout method=POST action=/php/scripts/destroy.php>
                    <button type=submit>Log out</button>
                </form>
            </div>";
            if ($_SESSION['role'] == 1) {
                echo "<button class=admin><a href=admin.php>Админка</a></button>";
            }
    } else {
       
             echo "<div class=vxod>
            <form name=authentication method=POST action=/php/scripts/authentication.php>
                <input type=text name=login placeholder=LOGIN>
                <input type=password name=password>
                <!--<p><input type=checkbox name=remember>Remember me</p>-->
                <input type=submit value=Войти>
            </form>
            </div>        
            <div class=reg>
            <button><a href=html/registration.html>Регистрация</a>
            </button></div>";
    }
?>

Извините за такое количество текста. И огромное спасибо тем, кто откликнется.

Сайт на PHP — это просто

Давайте обсудим самостоятельное создание сайта на PHP. Но прежде всего о том, что нам потребуется:

  • Некоторое представление о HTML (см. уроки html для начинающих)
  • Некоторое, хотя бы начальное понимание PHP
  • Интерпретатор PHP, установленный на локальный компьютер, или же хостинг с поддержкой PHP. Без этого пункта создание сайта php невозможно.

Какие основные отличия сайт на PHP от сайта на чистом HTML?

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

В качестве простого примера можно привести следующую ситуацию — нам потребовалось в шапке сайта исправить одно слово. Когда сайт основан исключительно на HTML, то для решения данной задачи придется исправить каждый файл сайта. Если сайт состоит всего из одной страницы, то это не вызывает особых затруднений, но если в составе сайта 100 html-страниц, то задача становится весьма трудоемкой и время затратной. А если таких страниц больше 1000? Если же сайт на PHP, и шапка реализована как подключаемый компонент, то потребуется сделать изменения только одного файла, и они автоматически отразятся на всех страницах сайта.

Типичная структура php сайта:

Теперь давайте рассмотрим код основного шаблона сайта на PHP. Следует обратить внимание, что файлы, содержащие php код должны иметь расширение .php. Это не обязательное требование, но будет лучше, если вы будете поступать именно так. Тогда меньше будет путаницы.

Код центрального файла index.php может иметь следующий вид:

<html>
<head>
   <title>Название страницы</title>
   <?php
      require_once $_SERVER['DOCUMENT_ROOT'].'/head.php';
   ?>
</head>

<body>
   <div>
      <?php
         require_once $_SERVER['DOCUMENT_ROOT'].'/top.php';
      ?>
   </div>
   <div>
      <div>
         <?php
            require_once $_SERVER['DOCUMENT_ROOT'].'/sidebar1.php';
         ?>
      </div>
      <div>
         ... Основная часть сайта...
      </div>
      <div>
         <?php
            require_once $_SERVER['DOCUMENT_ROOT'].'/sidebar2.php';
         ?>
      </div>
      <div>
         <?php
            require_once $_SERVER['DOCUMENT_ROOT'].'/footer.php';
         ?>
      </div>
   </div>
</body>
</html>

Как видно из примера, базовая страница состоит из ряда подключаемых файлов: head.php, top.php, sidebar1.php, sidebar2.php, footer.php. Подключение осуществляется при помощи специальной функции PHP:


require_once <полный путь/имя файла>

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

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

— WEB чайник

В предыдущей статье я описал свои изыскания по структуре сайта и описал некие этапы, которые я думаю все когда-нибудь проходили (у некоторых, правда был этап, который можно назвать «Создание сайтов на Joomla» или другой популярной CMS, который я проходил совсем недавно, и не как создатель сайтов – а как разработчик шаблонов, модулей и компонентов для Joomla, поскольку в этом была необходимость, но сейчас не об этом).

Итак, в конце предыдущей статьи я описал возможность создания сайта на одной странице. Идея эта не нова, и конечно не я ее изобрел, но на ней основываются все современные сайты. Подумаем: что нужно, чтобы реализовать сайт на одной странице? Главное – как определить какую страницу подключать основному файлу. Для начала сама структура:

Итак, за все у нас будет отвечать файл index.php. Ссылки на разделы будут выглядеть следующим образом:
http://ваш_домен/index.php?razdel=раздел_1
http://ваш_домен/index.php?razdel=раздел_2
http://ваш_домен/index.php?razdel=раздел_3….
Удобство такой схемы заключается в том, что в страницах раздел_1.php, раздел_2.php и раздел_3.php не нужно думать о подключении конфигурационных файлов. Все их можно подключить в файле index.php. Также для последнего можно оставить настройку основных функций, таких как авторизация и прочее.
Соответственно в теле файла index.php разделы будут подключаться следующим образом:
include $_SERVER[‘DOCUMENT_ROOT’].’/includes/’.$_GET[‘razdel’];
Вот и все. Когда мы передаем на основную страницу сайта переменную $_GET[‘razdel’], она подключает нужную страницу, отвечающую за данный раздел сайта. Недостатком такого решения является то, что не совсем очевидно как сделать страницы с разной разметкой, но на самом деле эту проблему тоже можно решить, дальше я опишу как это сделать. На этом можно было бы остановиться, и делать сайты сколько угодно и какие угодно. Но, честно признаюсь, предметом для меня одно время была Joomla, и не зря. Ковыряясь в ее исходниках я открыл для себя довольно много нового и интересного. А почему тогда не делать сайты на Joomla, спросите вы. Ответ простой: вы когда-нибудь видели как работает интернет магазин на связке Joomla+virtuemart в котором около 300 категорий товаров и самих товаров несколько тысяч. Вот вот. А мое знакомство с Joomla началось именно с такого сайта, и главной задачей – было увеличение скорости работы. Для человека, который в веб-программировании «третий день как с пальмы слез» — такая задача – тихий ужас, по-началу я даже не знал с какой стороны подойти, но потом пошло-поехало, изменил тут, дописал там, и скорость загрузки страниц увеличилась в три раза.
Но что-то меня занесло. Вернемся к одностраничной структуре сайта. В продолжение темы можно сказать, что никто не заставляет вас запихивать всю логику в страницу index.php. В папку includes можно поместить файлы, отвечающие за вывод главного меню сайта, шапки footerа а других блоков. Здесь главное понять сам принцип организации такого сайта.
В следующей статье я опишу структуру сайта, которую я сейчас использую, и планирую практически не изменяя модернизировать, однако для ее понимания нужно иметь представление об использовании классов и объектов, хотя можно обойтись и без этого.

Структура файлов мастера создания сайта

Папка мастера создания сайта может содержать следующие файлы и папки:

  • Файл .description.php, содержащий название, описание, а также ряд других характеристик мастера. Этот файл должен всегда присутствовать в папке мастера.

  • Файл .sites.php, описывающий шаги Выбор типа сайта и Установка сайта. Тип сайта – сущность, которая может объединять группы шаблонов, шаблоны, сервисы. От выбора типа сайта может зависеть дальнейший выбор группы шаблонов, шаблонов сайта и сервисов. Этот файл может отсутствовать в папке мастера.

  • Файл .templates.php, описывающий шаги Выбор группы шаблонов, Выбор шаблона и Установка шаблона. В файле
    .templates.php     можно описать зависимости шаблона от типа сайта, определить группы шаблонов. Этот файл может отсутствовать в папке мастера.
  • Подпапка templates, содержащая шаблоны сайта. Если в этой папке есть шаблоны, то шаги Выбор шаблона и Установка шаблона добавятся в мастер автоматически. В файле .templates.php описываются шаблоны, находящиеся в подпапке templates. Эта директория может отсутствовать в папке мастера.
  • Файл .services.php, описывающий шаги Выбор сервисов и Установка сервисов. Этот файл может отсутствовать в папке мастера. Под сервисом понимается совокупность программных модулей (публичных файлов, компонентов, данных), направленных на реализацию конкретного функционала сайта. Примерами сервисов могут быть доска объявлений, фотогалерея, каталог ссылок, каталог товаров, новости, форум и т.п.
  • Подпапка lang, содержащая языковые сообщения (перевод) мастера. В этой папке находятся подпапки с именами, равными кодам языков. В этих подпапках находятся файлы языковых сообщений (переводов) мастера. Файл языковых сообщений для какого-либо файла мастера должен иметь такое же имя, как и файл мастера и находиться в той же иерархии относительно папки /lang/код_языка/, в которой файл располагается относительно папки мастера. Например, языковой файл с английскими фразами для файла /.sites.php требуется располагать по пути /lang/en/.sites.php. Подпапка lang может отсутствовать, если в мастере нет зависящих от языка фраз;
  • Файл license.php, определяющий шаг Лицензионное соглашение. Если в директории мастера создания сайта лежит файл license.php (например, /bitrix/wizards/my_company/demo/license.php), то после шага Приветствие автоматически добавится шаг Лицензионное соглашение. В этом шаге пользователю будет предложено согласиться с лицензионным соглашением, текст которого находится в файле license.php. Файл с текстом лицензионного соглашения может зависеть от языка интерфейса мастера. Для это сначала ищется файл license_идентификатор_текущего_языка.php и если такого файла нет, текст берется из файла license.php.
  • Любые другие папки и файлы с ресурсами, необходимыми мастеру. Все ресурсы мастера должны находиться в папке мастера.

© «Битрикс», 2001-2021, «1С-Битрикс», 2021

Наверх

Структура сайта: основные виды

Структура сайта — основа для выстраивания последовательности и формы отображения имеющихся данных на сайте. При правильной структуре сайта пользователям максимально удобно переходить от одной странички к другой и изучать необходимые для них сведения. Если вы еще не определились какую структуру выбрать для своего сайта — узнайте о разных видах структур сайта и выберите наиболее подходящую для вас.

Самым первым видом структуры сайта является линейный. Он называется так потому, что в нем вся информация представлена в линейном виде. Это как будто цепочка, где все элементы послушно следуют друг за другом. Здесь не может быть разделов, и пользователь не может перескакивать с одной страницы на другую в любой последовательности, он получает возможность лишь плавно переходить по заданной траектории, так, как будто он читает книгу. Данный вид структуры сайта отлично бы подошел для создания презентаций либо онлайн-книг, его очень просто реализовать. Навигация здесь также присутствует минимальная, на каждой странице нужно обозначить лишь три основные ссылки: на главную страницу, на предшествующую и последующую.

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

Но самым многофункциональным и развитым можно назвать древовидный вид структуры сайта. Это форма представления данных, выраженная в форме многоуровневой иерархии. То есть, вся структура может содержать большое количество разделов и подразделов, внутренних страниц любой вложенности и в произвольной последовательности. В таком формате можно выполнить совершенно любой веб-ресурс, причем вне зависимости от того, посвящен он одной тематике или сразу нескольким различным областям. Однако здесь следует быть осторожным, ведь вы можете запутать своих посетителей в лабиринте составных частей проекта. Чтобы этого не случилось, при выборе подобного вида структуры сайта следует хорошо позаботиться о подробной и удобной навигации, понятном интерфейсе.

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


Теги: структура сайта

Подход MVC для разработки сайтов на PHP

Когда мы разрабатываем сайт, то пишем HTML и PHP код в одном и том же файле, перемешивая эти языки между собой. Если проект маленький, то ничего страшного в этом нет. Но если проект начнет расти, то через некоторое время его станет достаточно тяжело поддерживать из-за смешения языков. Со временем проект будет становиться все больше и больше, код становиться все запутанней, и вам тяжело будет его поддерживать.

Для решения таких проблем был придуман специальный подход под названием MVC. Аббревиатура MVC расшифровывается следующим образом: M — модель (model), V — представление (view), С — контроллер (controller). При этом модель отвечает за получение данных, представление — за вывод этих данных на экран в нужном виде, а контроллер представляет собой связующее звено между моделью и представлением.

На основе MVC созданы все PHP фреймворки. Фреймворк представляет собой заготовку проекта, упрощающую разработку сайта PHP программистом, избавляя его от многих рутинных операций. Кроме того, фреймворк представляет собой набор правил, которым необходимо следовать при разработке. Следование этим правилам вносит четкую структуру в проект, обеспечивая легкую поддержку созданного кода, а также позволяя легко брать новых людей в проект. Одним из таких правил и является подход MVC.

Как работает MVC

Рассмотрим, как работает сайт на MVC. Все начинается с того, что пользователь вбивает адрес в адресную строку (чаще всего перейдя по ссылке). В этот момент контроллер разбирается, что именно хотел получить пользователь и просит модель дать соответствующие данные. Модель дает контроллеру данные. Контроллер получает эти данные и отправляет их в представление. Представление показывает данные в оформленном нужным образом виде.

При этом у нас получается разделение труда: контроллер не знает, как получить данные — он просто просит об этом модель, представление не знает, откуда приходят данные — оно просто их отображает.

Уверен, что пока это все звучит не понятно, поэтому специально для вас я сделал учебный мини фреймворк, использующий MVC подход. Для начала я научу вас пользоваться этим фреймворком, чтобы вы поняли, как именно следует разрабатывать на MVC. А затем вы сами, следуя моим указаниям, напишите такой же фреймворк на ООП.

Уставновка фреймворка

Для начала фреймворк необходимо скачать по следующей ссылке: скачать фреймворк. Распакуйте файлы фреймворка в какую-нибудь папку сервера, например, в framework.local. В PhpMyAdmin создайте базу данных для вашего фреймворка. Затем перейдите в файл /project/config/connection.php и настройте там подключение к базе данных. Для проверки работы перейдите по следующему адресу: http://framework.local/hello/. Там вы должны увидеть приветственное сообщение. Если вы его видите — значит все работает.

Структура папок

После распаковки фреймворка у вас будут две папки: папка core и папка project.

В папке core размещается написанное мною ядро нашего фреймворка. Под ядром понимается код, который обеспечивает функционал, которым вы будете пользоваться при разработке. При использовании фреймворка в эту папку заглядывать вам, как правило, не будет нужно. В папке project будут размещаться файлы вашего проекта: контроллеры, модели, представления, а также настройки фреймворка. Именно в этой папке и будет вестись вся работа по разработке сайта.

Структура сайта с блочной версткой

Как упоминалось ранее, все обращения к сайту по ссылкам указывают на файл index.php, который формирует web-страницу, содержимое которой зависит от переданных в запросе значений параметров GETи POST.Все остальные html-файлы не будут являться самостоятельными HTML-документами, а будут лишь фрагментами динамической страницы. В силу такой архитектуры заголовок html-документа будет присутствовать только в файле index.php, соответственно, подключение всех CSS-файлов и файлов JavaScriptнеобходимо выполнить в заголовке файла index.php. Структура файлов проекта может быть следующей (с учетом того, что описание каждого объекта представляет собой только один html-файл):

Лабораторное задание

Сайт, разработанный в предыдущих лабораторных работах и имеющий фреймовую организацию, преобразовать в сайт с блочной версткой. Для этого необходимо:

1) Разработать файл, определяющий блочную структуру страницы и управляющий загрузкой контента в блоки (см. пример).

2) Разработать новый или доработать имеющийся css-файл для определения взаимного расположения блоков согласно варианту задания. При этом следует сохранить ранее используемые стили для форматирования сайта (см. пример).

3) Исключить из всех остальных файлов заголовки документов <head>. Содержимое заголовков (CSS, HTML) перенести в файл index.php

4) Отредактировать PHP-файл с обработчиком html-формы, изменив значение атрибута actionтэга form и добавив в форму скрытый параметр (см. пример).

Лабораторная работа 7. Использование шаблонов в PHP

Принцип шаблонизации

В предыдущей лабораторной работе динамическая веб-страница (lab6.php)состояла из блоков <div>, в которые при помощи функцииincludeпроисходила вставка внешних файлов контента в зависимости от управляющих GET-параметров. Для простых веб-страниц такая реализация вполне походит, однако если страница имеет сложную разметку, большое количество динамического контента и развитый интерфейс, то разработка и отладка такой страницы сильно осложняется из-за плохой читаемости php-кода и разметки «вперемешку». В таких случаях можно вынести весть php-код в отдельный файл, а разметку превратить в т.н. «шаблон».

Принцип использования шаблонов заключается во включении в HTML-кодспециальных последовательностей символов, которые при помощи PHP-скрипта по определенным правилам заменяются содержимым (контентом) в процессе динамического формирования веб-страницы. Такие последовательности (будем называть их метками) не являются HTML-тэгами и определяются самим разработчиком. Преимущества использование шаблонов:

– отделение PHP от HTML, улучшение читаемости кода;

– использование нескольких представлений для одного кода.

Для того, чтобы отличать файл шаблона от обычного html-документа, ему дают другое расширение, например *.tpl, хотя это не принципиально. Простейший шаблон может выглядеть так:

По сравнению с файлом из предыдущей лабораторной работы он имеет более простую структура за счет того, что фрагменты php-кода в нем заменены на метки {objects} и {content}. Код обработчика такого шаблона (файл lab7.php)может выглядеть так:

Принцип работы этого обработчика заключается в следующем:

— содержимое шаблона загружается в переменную $tmp;

— в зависимости от значений GET-параметров переменным $objectи $contentприсваивается содержимое файлов, которое необходимо вывести в левом и правом блоке страницы соответственно;

— при помощи функции str_replace()в переменной $tmp (шаблоне) происходит замена меток на содержимое выбранных файлов;

— при помощи функции echoготовая страница отправляется в браузер.

Данный принцип продемонстрирован на следующем рисунке:

Данная реализация работы с шаблоном очень проста, однако обладает существенным недостатком: если во внешних файлах, содержащих контент страницы (objects1.php, object1-2.phpи др.) будет содержаться php-код, то он не будет исполнен, т.к. функция file_get_contents() не обеспечивает его исполнение, а просто загружает файл в переменную в виде текста в неизменном виде. Исполнение php-кода во внешних файлах можно обеспечить использованием функции include() (см. лабораторную работу №6), но и здесь есть особенность: html-содержимое внешних файлов, а также результат php-операторов вывода в этом случае будет отправлена в браузер. Но в соответствии с принципом обработки шаблона это содержимое должно быть вставлено в шаблон, и только потом, в виде готовой страницы, должно быть отправлено клиенту. Преодолеть данное противоречие можно при помощи механизма кэширования при обработке php-сценария, который перенаправляет вывод, предназначаемы клиенту в специальную функцию, осуществляющую накопление результатов вывода в памяти для последующего использования.

При использовании кэширования php-сценарий registration_form.php запускается при помощи функции include(), причем перед этим необходимо выполнить функцию ob_start() и указать в качестве параметра имя функции, которая будет принимать результат выполнения сценария и помещать в переменную. В следующем примере эта функция называется load_content(). После выполнения функции include() кэширование отключается при помощи ob_end_flush().

Лабораторное задание

Разделить содержимое главной страницы сайта на два файла – шаблон (*.tpl) и код (*.php).Обеспечить корректное выполнение PHP-сценария по обработке формы при помощи механизма кэширования.

Справочники и руководства

http://www.cyberforum.ru/php-beginners/thread153221.html

http://phpfaq.ru/tpl

http://webew.ru/articles/3609.webew

Пример базового шаблона PHP для файловой структуры с примером кода | Стив Сохкот

Шаблон кода для каждой страницы будет выглядеть так:

Вы увидите , очень , первое (опять же, на каждой странице), это то, что я включаю файл конфигурации. Я поставил перед именем файла префикс «a_», чтобы оно отображалось первым в алфавитном порядке при сортировке по имени файла.

Файл конфигурации:

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

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

Содержимое, импортированное в тег HEAD:

Это позволяет каждой странице иметь свой собственный уникальный заголовок (как определено в файле конфигурации).

На странице «index» (также определяемой одной из переменных в файле конфигурации) я показываю теги META. На не домашних страницах я этого не показываю.

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

Остальные включаемые файлы предназначены для оформления и содержания. В этом примере я разбил его на три части:

1) Верхняя часть дизайна:

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

2) Навигация:

Код PHP динамически включает дополнительный класс для каждой ссылки, так что в зависимости от того, на какой странице вы находитесь, эта ссылка будет выделена (указывая, что она «активна»).

Обновление: было несколько комментариев о том, что эта часть не работает. Попробуйте напечатать $ _SERVER [«SCRIPT_NAME»] , чтобы увидеть каталог, в котором вы находитесь. В моем примере я создал каталог с именем «php-template» (и вы, вероятно, не используете тот же самый!).

3) Нижний колонтитул:

Там есть код для динамического отображения текущего года (так что вам не придется вручную менять его каждый год!).

Я предпочитаю иметь свои включаемые файлы с расширением .php . Я знаю, что некоторые люди предпочитают использовать такие расширения, как .html или .inc (чтобы обозначить его как «включенный» файл), но так:

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

Надеюсь, с этого вы начнете.Скорее всего, у вас будут варианты кода из моего примера.

Одним из изменений может быть DIV с идентификатором «main-content». Потенциально вы можете:

  • Поместите открывающий тег DIV в design-top.php
  • Создайте дополнительный файл с именем design-bottom.php , который имеет закрывающий тег DIV (который был открыт в другом файле).

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

Как выбрать структуру каталогов проекта PHP?

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

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

PHP-приложения и фреймворки с открытым исходным кодом имеют собственные способы структурирования. каталоги и файлы. Если вы используете фреймворк или CMS, у вас уже есть определена структура каталогов. См. Ссылки внизу для некоторых распространенных программ с открытым исходным кодом. Примеры.

Сложность и характер проекта влияют на требуемые каталоги. Например, веб-приложение будет иметь дополнительный общедоступный каталог по сравнению с приложение командной строки.

Структурируйте свой проект так, как вы считаете его наиболее логичным и полезным.

Пример структуры каталогов

Давайте посмотрим на следующий пример.

  корневой проект /
  .git / # Конфигурация Git и исходный каталог
  assets / # Не скомпилированный / необработанный CSS, LESS, Sass, JavaScript, изображения
  bin / # Скрипты командной строки
  config / # Конфигурация приложения
  node_modules / # Node.js модули для управления интерфейсом
  public / # Общедоступные файлы по адресу http: // example.com /
      index.php # Основная точка входа - фронт-контроллер
      ...
  src / # файлы исходного кода PHP
      Контроллер / # Контроллеры
      ...
  templates / # Файлы шаблонов
  tests / # Модульные и функциональные тесты
  translations / # файлов переводов
      en_US.yaml
  var / # Временные файлы приложения
      cache / # Файлы кеша
      log / # Файлы журнала для конкретного приложения
  vendor / # сторонние пакеты и компоненты с Composer
  .gitignore # Игнорируемые файлы и каталоги в Git (node_modules, var, vendor ...)
  composer.json # Файл зависимостей композитора
  phpunit.xml.dist # файл конфигурации PHPUnit

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

Общий справочник

Веб-приложениям требуется общедоступный каталог. В приведенном выше примере используется имя общественный . Вы можете легко использовать pub , web , public_html или любое другое имя.

Этот каталог будет доступен для внешнего мира при использовании веб-сервера. По соображениям безопасности вы должны поместить только минимальный набор файлов, необходимых для ваше приложение для работы. Сюда входит один передний контроллер, например, индекс.php и статические файлы внешнего интерфейса (CSS, JavaScript, изображения…).

Конфигурация

Если у вас несколько файлов конфигурации, рекомендуется поместить файлы конфигурации в отдельном каталоге. Несколько примеров: config или и т. Д. или app / config … Избегайте размещения файлов конфигурации в общедоступный каталог.

Композитор

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

Специальный файл по умолчанию composer.json расположен в верхнем корневом каталоге проект. В этом файле вся конфигурация и зависимости Composer указаны определенный.

Composer создает каталог vendor в корневом каталоге проекта, который содержит сторонние зависимости (библиотеки, компоненты, плагины…).

Файлы исходного кода PHP

Когда речь идет о PHP-классах многих проектов, добавьте их в каталог с именем src или приложение .

Приведенный выше пример включает все файлы PHP в каталоге src . К ним в основном относятся классы. Композитор также включает в себя очень интересную функцию — автозагрузку PSR-4. Добавление частей autoload и autoload-dev в файл composer.json приведет к автозагрузить для вас все классы:

  {
    "автозагрузка": {
        "пср-4": {
            "Приложение \\": "src /"
        }
    },
    "autoload-dev": {
        "пср-4": {
            "Приложение \\ Тесты \\": "тесты /"
        }
    }
}

В современных приложениях PHP структурирование файлов PHP в каталоге src является частью объектно-ориентированного программирования и шаблонов проектирования.Представлено каждое пространство имен с подкаталогом в каталоге src .

Например:

  корневой проект /
  ...
  src /
      Контроллер / # Классы для управления запросами и ответами путем отображения
                  # шаблоны с логикой из сервисов и / или данными из БД
      Model / # Классы для хранения значений из базы данных
      Utils / # Application Services - бизнес-логика
      ...
  ...

Следуйте принципам шаблонов проектирования ООП при добавлении классов в пространства имен.

Тесты

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

Передняя часть

В зависимости от сложности проекта хорошей практикой является разделение внешнего интерфейса файлы (CSS, Sass, LESS, JavaScript, изображения…) и внутренние файлы PHP (исходный код PHP код, шаблоны, конфигурация приложения, модульные тесты…) на два отдельных репозитории.

В приведенном выше примере каталог node_modules является стандартным каталогом (аналогичный to Composer поставщик ), управляемый Node.js tooling system — npm или yarn.

Вместо разделения проекта на два репозитория используется каталог assets используется для хранения одного или нескольких некомпилированных необработанных изображений из JavaScript, CSS, SaSS, LESS, изображений и аналогичные файлы ресурсов, которые компилируются и обрабатываются в общедоступном каталоге .

Если вам не понадобится более сложная и сложная обработка внешнего интерфейса, вы можете поместите эти веб-ресурсы непосредственно в общедоступный каталог .

Как изменить каталог поставщика Composer по умолчанию?

По умолчанию Composer создает каталог vendor .Смена названия не распространенный подход, потому что это стандартное имя, используемое в экосистеме PHP. Однако переименование может быть выполнено путем установки специальной переменной окружения. COMPOSER_VENDOR_DIR :

  COMPOSER_VENDOR_DIR = lib composer требует phpunit / phpunit

или вручную добавив конфигурацию vendor-dir в composer.json :

  {
    ...
    "config": {
        "vendor-dir": "lib"
    }
    ...
}

Как настроить структуру каталогов при использовании виртуального хостинга?

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

Всегда избегайте размещения чего-либо, кроме общедоступных файлов приложения, в корневой каталог документов, например public_html , htdocs или аналогичный.

Некоторые панели управления могут позволить вам определить корень документа, отличный от по умолчанию:

  public_html / # Корневой каталог документов панели управления по умолчанию
  your-project / # Ваш проект с желаемой структурой каталогов
    ...
    config /
    ...
    public / # Установить этот каталог как новый корень документа
    src /
    ...

См. Также

Структура каталогов

— Laravel — PHP-фреймворк для веб-мастеров

Введение

Стандартная структура приложения Laravel предназначена для обеспечения отличной отправной точки как для больших, так и для малых приложений. Но вы можете организовать свое приложение так, как вам нравится. Laravel практически не накладывает ограничений на расположение любого данного класса — до тех пор, пока Composer может автоматически загружать класс.

Корневой каталог

Каталог приложений

Каталог app содержит основной код вашего приложения.Вскоре мы рассмотрим этот каталог более подробно; однако почти все классы в вашем приложении будут в этом каталоге.

Каталог начальной загрузки

Каталог bootstrap содержит файл app.php , который загружает фреймворк. В этом каталоге также находится каталог кэша , который содержит файлы, сгенерированные каркасом для оптимизации производительности, такие как файлы кэша маршрутов и служб. Обычно вам не нужно изменять какие-либо файлы в этом каталоге.

Каталог конфигурации

Каталог config , как следует из названия, содержит все файлы конфигурации вашего приложения. Это отличная идея — прочитать все эти файлы и ознакомиться со всеми доступными вам вариантами.

Каталог базы данных

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

Общедоступный каталог

Общий каталог содержит файл index.php , который является точкой входа для всех запросов, поступающих в ваше приложение, и настраивает автозагрузку. В этом каталоге также хранятся ваши активы, такие как изображения, JavaScript и CSS.

Справочник ресурсов

Каталог ресурсов содержит ваши представления, а также необработанные, нескомпилированные ресурсы, такие как CSS или JavaScript. В этом каталоге также находятся все ваши языковые файлы.

Каталог маршрутов

Каталог routes содержит все определения маршрутов для вашего приложения. По умолчанию в Laravel включены несколько файлов маршрутов: web.php , api.php , console.php и channels.php .

Файл web.php содержит маршруты, которые RouteServiceProvider помещает в группу промежуточного программного обеспечения web , которая обеспечивает состояние сеанса, защиту CSRF и шифрование файлов cookie.Если ваше приложение не предлагает RESTful API без сохранения состояния, то, скорее всего, все ваши маршруты будут определены в файле web.php .

Файл api.php содержит маршруты, которые RouteServiceProvider помещает в группу промежуточного программного обеспечения api . Эти маршруты предназначены для того, чтобы не иметь состояния, поэтому запросы, поступающие в приложение через эти маршруты, предназначены для аутентификации с помощью токенов и не будут иметь доступа к состоянию сеанса.

В файле console.php вы можете определить все консольные команды на основе закрытия. Каждое замыкание привязано к экземпляру команды, что обеспечивает простой подход к взаимодействию с методами ввода-вывода каждой команды. Несмотря на то, что этот файл не определяет маршруты HTTP, он определяет точки входа (маршруты) в ваше приложение на основе консоли.

В файле channels.php вы можете зарегистрировать все каналы вещания событий, которые поддерживает ваше приложение.

Каталог хранилища

Хранилище . Каталог содержит ваши журналы, скомпилированные шаблоны Blade, сеансы на основе файлов, кеши файлов и другие файлы, сгенерированные фреймворком. Этот каталог разделен на приложение , framework и журналы каталогов. Каталог app может использоваться для хранения любых файлов, созданных вашим приложением. Каталог framework используется для хранения файлов и кэшей, сгенерированных платформой.Наконец, каталог logs содержит файлы журналов вашего приложения.

Каталог storage / app / public может использоваться для хранения файлов, созданных пользователями, таких как аватары профиля, которые должны быть общедоступными. Вы должны создать символическую ссылку в public / storage , которая указывает на этот каталог. Вы можете создать ссылку, используя Artisan-команду php artisan storage: link .

Справочник тестов

Каталог tests содержит ваши автоматизированные тесты.Примеры модульных тестов и функциональных тестов PHPUnit предоставляются по умолчанию. Каждый тестовый класс должен иметь суффикс Test . Вы можете запускать свои тесты с помощью команд phpunit или php vendor / bin / phpunit . Или, если вы хотите более подробное и красивое представление результатов ваших тестов, вы можете запустить их, используя команду Artisan php artisan test .

Справочник поставщиков

Каталог vendor содержит ваши зависимости Composer.

Каталог приложений

Большая часть вашего приложения размещается в каталоге app . По умолчанию этот каталог находится в пространстве имен под App и автоматически загружается Composer с использованием стандарта автозагрузки PSR-4.

Каталог app содержит множество дополнительных каталогов, таких как Console , Http и Providers . Думайте о каталогах Console и Http как о предоставлении API в ядре вашего приложения.Протокол HTTP и интерфейс командной строки являются механизмами взаимодействия с вашим приложением, но на самом деле не содержат логики приложения. Другими словами, это два способа подачи команд вашему приложению. Каталог Console содержит все ваши Artisan-команды, а каталог Http содержит ваши контроллеры, промежуточное ПО и запросы.

Множество других каталогов будет создано внутри каталога app , поскольку вы используете Artisan-команды make для создания классов.Так, например, каталог app / Jobs не будет существовать, пока вы не выполните Artisan-команду make: job для создания класса задания.

{tip} Многие классы в каталоге app могут быть сгенерированы Artisan с помощью команд. Чтобы просмотреть доступные команды, запустите команду php artisan list make в своем терминале.

Справочник вещания

Каталог Broadcasting содержит все классы широковещательных каналов для вашего приложения.Эти классы создаются с помощью команды make: channel . Этот каталог не существует по умолчанию, но будет создан для вас, когда вы создадите свой первый канал. Чтобы узнать больше о каналах, ознакомьтесь с документацией по трансляции событий.

Справочник консоли

Каталог Console содержит все настраиваемые Artisan-команды для вашего приложения. Эти команды могут быть сгенерированы с помощью команды make: command . В этом каталоге также находится ядро ​​вашей консоли, в котором регистрируются ваши пользовательские команды Artisan и определяются ваши запланированные задачи.

Справочник событий

Этот каталог не существует по умолчанию, но будет создан для вас командами Artisan event: generate и make: event. В каталоге Events находятся классы событий. События могут использоваться для предупреждения других частей вашего приложения о том, что произошло определенное действие, обеспечивая большую гибкость и развязку.

Справочник исключений

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

Каталог Http

Каталог Http содержит ваши контроллеры, промежуточное ПО и запросы форм. Практически вся логика обработки запросов, поступающих в ваше приложение, будет размещена в этом каталоге.

Справочник вакансий

Этот каталог не существует по умолчанию, но будет создан для вас, если вы выполните Artisan-команду make: job .В каталоге Jobs хранятся задания в очереди для вашего приложения. Задания могут быть поставлены в очередь вашим приложением или выполняться синхронно в рамках текущего жизненного цикла запроса. Задания, которые выполняются синхронно во время текущего запроса, иногда называют «командами», поскольку они являются реализацией шаблона команд.

Справочник слушателей

Этот каталог не существует по умолчанию, но будет создан для вас, если вы выполните Artisan-команды event: generate или make: listener .Каталог Listeners содержит классы, которые обрабатывают ваши события. Слушатели событий получают экземпляр события и выполняют логику в ответ на запускаемое событие. Например, событие UserRegistered может обрабатываться приемником SendWelcomeEmail .

Почтовый каталог

Этот каталог не существует по умолчанию, но будет создан для вас, если вы выполните Artisan-команду make: mail . Каталог Mail содержит все ваши классы, которые представляют электронные письма, отправленные вашим приложением.Почтовые объекты позволяют инкапсулировать всю логику создания электронной почты в одном простом классе, который может быть отправлен с помощью метода Mail :: send .

Каталог моделей

Каталог Models содержит все классы вашей модели Eloquent. Eloquent ORM, включенный в Laravel, предоставляет красивую и простую реализацию ActiveRecord для работы с вашей базой данных. Каждая таблица базы данных имеет соответствующую «Модель», которая используется для взаимодействия с этой таблицей.Модели позволяют запрашивать данные в таблицах, а также вставлять новые записи в таблицу.

Каталог уведомлений

Этот каталог не существует по умолчанию, но будет создан для вас, если вы выполните Artisan-команду make: notification . Каталог Notifications содержит все «транзакционные» уведомления, которые отправляет ваше приложение, например простые уведомления о событиях, которые происходят в вашем приложении. Функция уведомлений Laravel абстрагируется от отправки уведомлений через различные драйверы, такие как электронная почта, Slack, SMS или хранящиеся в базе данных.

Справочник политик

Этот каталог не существует по умолчанию, но будет создан для вас, если вы выполните Artisan-команду make: policy . Каталог Policies содержит классы политик авторизации для вашего приложения. Политики используются, чтобы определить, может ли пользователь выполнить определенное действие с ресурсом.

Справочник поставщиков

Каталог Providers содержит всех поставщиков услуг для вашего приложения.Поставщики услуг загружают ваше приложение, привязывая службы к контейнеру служб, регистрируя события или выполняя любые другие задачи для подготовки вашего приложения к входящим запросам.

В новом приложении Laravel этот каталог уже будет содержать несколько провайдеров. При необходимости вы можете добавлять своих собственных провайдеров в этот каталог.

Справочник правил

Этот каталог не существует по умолчанию, но будет создан для вас, если вы выполните Artisan-команду make: rule .Каталог Rules содержит настраиваемые объекты правил проверки для вашего приложения. Правила используются для инкапсуляции сложной логики проверки в простой объект. Для получения дополнительной информации ознакомьтесь с документацией по валидации.

О структурировании PHP-проектов - Никола Поша

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

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

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

Структура каталогов

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

  bin / # исполняемые файлы командной строки
config / # файлы конфигурации
общедоступные / # файлы веб-сервера, ресурсы
ресурсы / # другие файлы ресурсов
src / # Исходный код PHP
шаблоны / # файлы просмотра и макета
тесты / # тестовый код

Это в значительной степени стандартно для приложений, но также и для библиотек, тогда как в их случае вряд ли можно найти каталоги public / или templates / .Кроме того, библиотеки обычно имеют следующие типы файлов: docs / , CHANGELOG , LICENSE , README . Конечно, они могут быть и в приложениях.

Я считаю эту структуру каталогов независимым от фреймворка , и на его основе мне удалось успешно построить различные проекты, в которых использовались разные фреймворки, такие как Zend Expressive, Slim и Laravel.

Недавно я узнал, что существует инициатива PHP-PDS, которая предлагает стандарт для структуры каталогов пакетов PHP.Я решительно поддерживаю такие попытки по тем же причинам, по которым я восхищаюсь работой и усилиями PHP-FIG. Я был рад видеть, что используемые мной соглашения об именах полностью соответствуют предложенному стандарту.

Исходный код PHP

Что касается представленной структуры каталогов, у вас может возникнуть вопрос: «А как насчет каталога app /?», И мой ответ на это: нет каталога app / , и не должно быть . Все, кроме src / , вносит ненужный уровень сложности.

Теперь, когда у нас есть автозагрузчик PSR-4 и Composer, все, что вам нужно сделать, это использовать пространства имен . Так, например, вместо app / controllers / у вас будет src / Controller / . Благодаря этому структура каталогов становится простой и однозначной. То же самое и с автозагрузкой, поскольку нет необходимости в каком-либо настраиваемом механизме автозагрузки или фреймворке. Единственная директива для composer.json выполняет всю работу:

  {
    "автозагрузка": {
        "пср-4": {
            "MyApp \\": "src /",
        }
    }
}

Теперь, когда мы развенчали все мифы о том, где должны располагаться исходные коды PHP, давайте рассмотрим варианты их организации внутри каталога src / , потому что именно там и находится сок.

Группировка по архетипу

Распространенная тенденция - организовывать вещи по их архетипам, например:

  src /
    Контроллер /
    Сущность/
    Репозиторий /
    Обслуживание/

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

Группировка по признаку

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

Если мы возьмем простой веб-сайт электронной коммерции в качестве примера, вот как все должно быть организовано в соответствии с этим подходом:

  src /
    Корзина /
        Корзина.php
        CartRepository.php
        CartRepositoryFactory.php
        CartService.php
        CartServiceFactory.php
    Товар/
        Product.php
        ProductCategory.php
        ProductRepository.php
        ProductRepositoryFactory.php
        ProductService.php
        ProductServiceFactory.php
    Пользователь/
        User.php
        UserRepository.php
        UserRepositoryFactory.php
        UserService.php
        UserServiceFactory.php

Я не особо вдавался в подробности реальных классов, интерфейсов и т. Д., потому что я хотел сосредоточиться на группировке вещей.

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

  src /
    Пользователь/
        HTTP /
            UserController.php
        CLI /
            CreateUserCommand.php
        User.php
        UserRepository.php
        UserRepositoryFactory.php
        UserService.php
        UserServiceFactory.php
Отдельный домен и универсальный код

Существует большая вероятность, что помимо кода, специфичного для домена, потребуется создать некоторый общий, многоразовый, подобный фреймворку код внутри каталога src / , например, пользовательский обработчик журнала (хотя, скорее всего, он уже есть в Monolog) , облегчение кеширования, фильтры и т. д.Этот материал не является логикой вашей предметной области, он не специфичен для вашего приложения и, вероятно, может повторно использоваться между проектами. Более того, он должен быть не частью вашего приложения, а скорее в отдельной библиотеке и в отдельном репозитории.

Я видел решение, в котором весь универсальный код помещен в отдельное пространство имен, например MyApp \ Framework или MyApp \ Common :

  src /
    Корзина /
    Фреймворк/
        Регистратор /
        Кэш /
    Товар/
    Пользователь/

Это совершенно нормально, но я вижу в этом подходе недостаток, который связан не с тем, как он влияет на приложение, содержащее этот универсальный код, а с самим кодом.Помните, что в идеале этот код должен находиться в отдельном репозитории, и усилия по его перемещению также потребуют избавления от этой дополнительной «Framework» или «Common» части пространства имен, что, в свою очередь, требует не только изменения всех определений классов. , но и обычаи.

По этой причине я выбираю совершенно другой подход, в то время как сам код домена изолирован в отдельном пространстве имен. Что важно в этом подходе, так это то, что вы разумно выбираете имя для пространства имен верхнего уровня. MyApp , наверное, не лучший выбор с точки зрения извлечения универсального кода в отдельный репозиторий.При разработке пространства имен верхнего уровня не выходите за рамки проекта, над которым вы работаете. Как правило, это должно быть название вашей компании, бренда или, в конечном итоге, ваше собственное имя. Что касается части пространства имен кода домена, она обычно должна описывать то, что делает приложение, например, Eshop , но я предпочитаю использовать для этих целей общее слово - Domain :

  src /
    Кэш /
    Домен/
        Корзина /
        Товар/
        Пользователь/
    Регистратор /

В результате вы получите такие пространства имен, как Company \ Cache и Company \ Domain \ User .Теперь, когда вы решите извлечь это облегчение кэша в отдельную многократно используемую библиотеку, никаких изменений в отношении его пространства имен не требуется.

Заключительные мысли

Код местоположения должен быть интуитивно понятным и быстрым. Соответствующее структурирование приложения экономит массу времени и усилий разработчиков.

Суммируем:

  • Не позволяйте фреймворку диктовать структуру каталогов
  • Хранить все источники PHP в каталоге src /
  • Группировка по признаку, а не по архетипу
  • Не смешивайте домен и код общего назначения

Как поддерживать основные проекты PHP? | by Shuvojit Sarkar

Уже почти 2018 год, и большинство современных веб-сайтов, написанных на PHP, написаны на какой-то платформе MVC или MVT, наиболее известными из которых являются Laravel и CodeIgniter, Laravel - мой личный фаворит.

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

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

Сначала будет структура папок, я бы рекомендовал разбить ваш проект на 4 папки.

. 
 ├── assets / 
 ├── helpers / 
 ├── views / 
 ├── process / 
 ├── .htaccess 
 └── index.php
  • assets: Эта папка будет содержать все файлы ресурсов , изображения, таблицы стилей и файлы JavaScript, и если вы хотите использовать даже жесткое ядро, создайте отдельные каталоги для каждого типа файлов, что я лично делаю.
  • просмотров: Эта папка будет содержать все файлы php, которые будут действовать как «представления», что в основном означает, что это файлы, отображающие какую-либо форму или веб-страницу.
  • процесс: эта папка будет содержать все процессы, что в основном означает все файлы, кроме обработки отправки форм и других форм процессов. Ограничьте эти файлы трехэтапным процессом: ввод> процесс> перенаправление.
  • помощники: Эта папка будет содержать определенные функции, которые будут использовать все файлы, самый большой пример - подключение к базе данных. Вы когда-нибудь писали mysqli_connect () поверх каждого файла в большом проекте, а затем приходилось менять пароль в 20 разных файлах? У меня есть.

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

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

Итак, предположим, что мы создаем блог, а веб-страница имеет верхний колонтитул, нижний колонтитул, боковую панель и основную часть.

Очевидно, что есть три части веб-сайта, которые будут присутствовать на каждой странице в верхнем, нижнем колонтитуле и боковой панели.Итак, что мы можем легко сделать, так это создать отдельные файлы для каждого из разделов и включить их с помощью функции include () .

После воссоздания структуры папок она будет выглядеть примерно так.

. 
 ├── assets 
 ├── помощники 
 ├── process 
 ├── views 
 │ └── sub-views 
 │ ├── footer.php 
 │ ├── header.php 
 │ └── sidebar .php 
 ├── .htaccess 
 └── index.php
И для использования подвидов в индексе .php или любой другой файл, мы напишем что-то вроде этого.

Теперь у нас возникнут некоторые проблемы с этим кодом, если у нас есть файл в каталоге представлений. Потому что относительная ссылка на каталог вложенных представлений не будет работать. Что мы можем сделать в качестве дешевого взлома, так это просто изменить путь включения с views / sub-views / footer.php на sub-views / footer.php .

Но мы не хотим получать больше технических специалистов, поэтому мы постараемся автоматизировать весь процесс. Введите помощников .

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

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

Мы используем __DIR__ для получения текущего каталога, который будет каталогом помощников, теперь первое, что мы делаем, это ../ , который меняет каталог на корень проекта, затем мы переходим к представлениям / sub-views / , а затем добавьте имя файла.

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

Выглядит чище, чем раньше, правда? Обратите внимание на include_once вверху страницы, мы включаем вспомогательный файл, чтобы мы могли использовать функции, которые мы написали в файле.

Наиболее часто используемый вспомогательный файл - это место, где мы подключаемся к базе данных, что необходимо каждому динамическому веб-сайту. Давайте создадим conn.php в каталоге помощников.

. 
 ├── assets 
 ├── helpers 
 │ ├── conn.php 
 │ └── helper.php 
 ├── process 
 ├── views 
 │ └── sub-views 
 │ ├── footer .php 
 │ ├── header.php 
 │ └── sidebar.php 
 ├── .htaccess 
 └── index.php
Содержимое conn.php будет выглядеть примерно так.

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

Одна вещь, которую я заметил, это то, что новички полностью игнорируют обработку ошибок, самая важная часть написания core php - это обработка всех ошибок.

Всегда ожидайте, что что-то пойдет не так, будьте готовы к каждой ошибке!

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

   'helper / helper.php'; 
   'helper / conn.php';

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

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

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

. 
 ├── активы 
 ├── помощники 
 │ ├── conn.php 
 │ ├── помощник.php 
 │ └── init.php 
 ├── process 
 ├── views 
 │ └── sub-views 
 │ ├── footer.php 
 │ ├── header.php 
 │ └── sidebar. php 
 ├── .htaccess 
 └── index.php
init.php должен выглядеть примерно так.

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

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

Если вам понравился этот пост, нажмите 👏 ниже для поддержки.

PHP против HTML: что нужно знать в 2020 году

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

Когда вы впервые занимаетесь веб-дизайном или разработкой веб-сайтов, вы можете быть ошеломлены различными языками и подходами к разработке, с которыми вы столкнетесь.PHP и HTML, например, кажутся повсюду, и люди, которые работают с одним из них, часто работают и с другим. Знание как PHP, так и HTML является практически обязательным требованием для веб-разработчиков всех мастей. Понимание того, что они из себя представляют и что они делают, чтобы современный веб-мир вращался без проблем, поможет вам внести свой вклад в диалог PHP и HTML-кода.

Наша статья за спиной. С нашей помощью вы получите важную статистику по обоим этим важным веб-инструментам и узнаете больше о том, как разработчики и дизайнеры используют их для создания веб-сайтов.Вы узнаете, как HTML создает структуру Интернета и как PHP работает в этой структуре, чтобы устанавливать соединения и выполнять всевозможные операции. Мы также покажем вам, чем похожи PHP и HTML, а также когда использовать каждый из них в вашей работе по веб-разработке.

Что такое HTML?

HTML похож на Matrix, но менее зеленый и менее запутанный.

Даже люди с минимальными знаниями о том, как работают веб-страницы, слышали об HTML. Большинство людей не удивятся, узнав, что HTML - популярное средство создания веб-страниц.Но что именно представляет собой таинственная вещь, называемая HTML, и с помощью какой магии она создает ваши страницы с фан-артом, сообщения в блогах и бизнес-сайты?

Найдите свой учебный лагерь Match