Структура сайта. Весь сайт на одной странице

Уважаемые посетители сайта, задающие вопросы вроде «А как прикрутить вашу корзину к сайту?» и т.п. Я не делаю готовых решений, я описываю логику реализации, для каждого отдельного сайта нужно будет дописывать те или иные вещи в любом случае, поэтому если вам очень нужно что-либо прикрутить или приделать, я оказываю платные и бесплатные услуги по консультированию и доработке сайтов. Пишите в форму обратной связи вверху страницы, отвечу всем.


В предыдущей статье я описал свои изыскания по структуре сайта и описал некие этапы, которые я думаю все когда-нибудь проходили (у некоторых, правда был этап, который можно назвать «Создание сайтов на 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а а других блоков. Здесь главное понять сам принцип организации такого сайта.
В следующей статье я опишу структуру сайта, которую я сейчас использую, и планирую практически не изменяя модернизировать, однако для ее понимания нужно иметь представление об использовании классов и объектов, хотя можно обойтись и без этого.



— WEB чайник

Уважаемые посетители сайта, задающие вопросы вроде «А как прикрутить вашу корзину к сайту?» и т.п. Я не делаю готовых решений, я описываю логику реализации, для каждого отдельного сайта нужно будет дописывать те или иные вещи в любом случае, поэтому если вам очень нужно что-либо прикрутить или приделать, я оказываю платные и бесплатные услуги по консультированию и доработке сайтов.

Пишите в форму обратной связи вверху страницы, отвечу всем.


Структура сайта – проблема, которая всегда волновала меня больше всего, не скажу что и сейчас я уже решил для себя все трудности. «Совершенства нельзя достичь, но к нему нужно стремиться». И вот решил в нескольких статьях описать путь от самого начала моей веб-жизни, до сегодняшнего момента. Постараюсь описать, что я умею и чему хотелось бы научиться.
Сначала немного истории. Как выглядел мой первый сайт я помню очень хорошо. Делал его в Macromedia Dreamweaver (которым иногда пользуюсь до сих пор, чтобы быстро перевести текст из ворда в html и отредактировать). Структура этого сайта была не то чтоб неудобной для работы, а ужасно неудобной. Все страницы были отдельными файлами с html-разметкой. Т.е. чтобы поправить один пункт меню, или еще какую мелочь, которая была на всех страницах – приходилось их все редактировать. Ну и естественно отсюда следовало то, что иногда я забывал отредактировать какую-либо страницу, получались на разных страницах разные ссылки и т.

д. В общем – с сайтом было невозможно работать (представьте себе каталог на чистом html…). На тот момент я вообще не был знаком с PHP.
Прошло не очень много времени до того момента, когда я понял, что PHP все-таки придется осваивать (по образованию я физик-теоретик). Нашел книгу, по-моему, Дронов что-то вроде Сайт на PHP+MySQL, в которой неплохо были изложены возможности именно Dreamweaver для создания динамического сайта на основе взаимодействия PHP+MySQL. Довольно доступно описывались возможности пакета Dreamweaver для того, чтобы выбрать записи из базы данных, вывести их на страницу и т.д. Установил Denwer и начал работать. Но понимания самого процесса выборки данных и вывода их на страницу не было. Довольно долго я работал именно с Dreamweaver, переделал на нем первый сайт, добавил к нему базу данных, даже простенькую админку сделал. Стало значительно проще. Но вопросы все равно оставались. Забыл сказать, что походу этого познакомился с инструкцией include, и начал подключать одинаковые части страниц.
Но структура сайта все равно оставляла желать лучшего. На картинке приведу пример того сайта:

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

Можно видеть, что в общем разницы между первой и второй структурами сайта нет. Однако, со времени первой я научился сам писать запросы к базе данных, выводить их результаты на странице и еще много чего. Но чего-то все равно не хватало. Примерно через полтора или два года (пока защищал диплом и все такое) до меня все-таки дошло, что структуру можно еще более упростить, подключая не на каждой странице шапку, боковое меню и так называемый footer,а сделать одну страницу index.php, которая будет содержать в себе весь дизайн, а в теле ее будет подключаться уже нужный раздел, но об этом в следующей статье, т.к. реализация такого подхода порождает довольно много проблем.



Как выбрать структуру каталогов проекта 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/ # Файлы шаблонов
  тесты/ # Модульные и функциональные тесты
  translations/ # Файлы перевода
      en_US.yaml
  var/ # Временные файлы приложения
      cache/ # Файлы кеша
      log/ # Файлы журнала приложения
  поставщик/# сторонние пакеты и компоненты с Composer
  .gitignore # Игнорируемые файлы и каталоги в Git (node_modules, var, vendor...)
  composer.json # файл зависимостей Composer
  phpunit.xml.dist # Файл конфигурации PHPUnit

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

Общий каталог

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

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

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

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

Composer

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

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

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

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

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

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

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

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

Например:

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

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

Испытания

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

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

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

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

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

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

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

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

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

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

 {
    ...
    "конфигурация": {
        "вендор-дир": "библиотека"
    }
    ...
}

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

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

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

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

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

См. также

  • Глава «Конфигурация» — подробнее о PHP подходы к настройке приложений.
  • Структура CakePHP
  • Структура Laravel
  • Структура Symfony
  • Каркас приложения Zend Framework

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

Редактирование проблемы в GitHubLog

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

Местоположение корневого каталога

Корневой каталог компонента соответствует имени компонента и содержит все его подкаталоги и файлы. В зависимости от того, как вы установили Magento, вы можете поместить корневой каталог вашего компонента в одно из двух мест:

  • <директория установки Magento>/app : это рекомендуемое расположение для разработки компонента. Вы можете настроить эту среду, клонировав репозиторий Magento 2 GitHub.

    • Для модулей используйте приложение /код .
    • Для оформления витрины магазина используйте app/design/frontend .
    • Для тем администратора используйте app/design/adminhtml .
    • Для языковых пакетов используйте app/i18n .

  • <Каталог установки Magento>/vendor : Вы найдете это место для установок, которые используют composer create-project для установки метапакета Magento 2 (который загружает код CE или EE).

    Magento устанавливает сторонние компоненты в каталог <директория установки Magento>/vendor . Но мы рекомендуем добавлять ваши компоненты в каталог <директория установки Magento>/app/code . Если вы добавите свой компонент в каталог <каталог установки Magento>/vendor , Git проигнорирует его, поскольку Magento добавит каталог поставщика в файл <каталог установки Magento>/. gitignore .

Структура файла модуля

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

Общие каталоги

Ниже приведены некоторые общие каталоги модулей:

  • Блок : содержит классы представления PHP как часть вертикальной реализации логики модуля Model View Controller (MVC).
  • Контроллер : содержит классы контроллера PHP как часть вертикальной реализации модульной логики MVC.
  • и т. д. : содержит файлы конфигурации; в частности, module.xml , который обязателен.
  • Модель : содержит классы модели PHP как часть вертикальной реализации модульной логики MVC.
  • Настройка : содержит классы для структуры базы данных модуля и настройки данных, которые вызываются при установке или обновлении.
  • ViewModel : содержит классы моделей PHP как часть реализации модели-представления-представления (MVVM). Это позволяет разработчикам выгружать функции и бизнес-логику из блочных классов в отдельные классы, которые легче поддерживать, тестировать и повторно использовать.

Дополнительные каталоги

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

  • Api : содержит все классы PHP, открытые для API.
  • Консоль : содержит команды CLI. Дополнительные сведения см. в разделе Добавление команд CLI.
  • Cron : содержит определения заданий cron.
  • CustomerData : содержит файлы разделов.
  • Helper : содержит агрегированные функции.
  • i18n : содержит файлы локализации.
  • Observer : содержит файлы для выполнения команд слушателя.
  • Плагин : содержит все необходимые плагины.
  • UI : содержит файлы генерации данных.
  • представление : содержит файлы представлений, включая файлы статического представления, шаблоны дизайна, шаблоны электронной почты и файлы макета.

Структура файла темы

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

 
 ├── composer.json
├── и т. д.
│   └── view.xml
├── i18n
│   └── en_US.csv
├── LICENSE_AFL.txt
├── ЛИЦЕНЗИЯ.txt
├── СМИ
│   └── превью.jpg
├── Registration.php
└── сеть
    ├── CSS
    │   ├── электронная почта.без
    │   ├── print.less
    │   ├── источник
    │   │   ├── _actions-toolbar.less
    │   │   ├── _breadcrumbs.less
    │   │   ├── _buttons.less
    │   │   ├── компоненты
    │   │   │   └── _modals_extend.less
    │   │   ├── _icons.less
    │   │   ├── _layout.less
    │   │   ├── _theme.less
    │   │   ├── _tooltips.less
    │   │   ├── _typography.less
    │   │   └── _variables.less
    │   ├── _styles.less
    │   ├── стили-l. less
    │   └── стили-m.less
    ├── изображения
    │   └── logo.svg
    └── js
        ├── navigation-menu.js
        └── theme.js
Скопировано в буфер обмена 
 
 
 1├── composer.json 
 
 2├── etc 
 
 3│   └── view.xml 
 
 4├── i18n 
 
 5│   └── en_US.csv 
 
 6├── LICENSE_AFL.txt 
 
 7├── LICENSE.txt 
 
 8├── media 
 
 9│   └── preview.jpg 
 
 10├── Registration.php 
 
 11└── веб-сайт 
 
 12 ├─ ─ css 
 
 13 │   ├── email.less 
 
 14 │   ├── print.less 
 
 15 │   ├── источник 
 
 16 │   │   ├── _actions-toolbar.less 
 
 17 │   │   ├── _breadcrumbs.less 
 
 18 │   │   ├── _buttons.less 
 
 19 │   │   ├ ── компоненты 
 
 20 │   │   │   └── _modals_extend.less 
 
 21 │   │   ├─ ─ _icons.less 
 
 22 │   │   ├── _layout.less 
 
 23 │   │   ├── _theme.less 
 
 24 │   │   ├── _tooltips.less 
 
 25 │   │   ├── _typography.less 
 
 26 │   │   └── _variables.less 
 
 27 │   ├── _styles. less 
 
 28 │   ├── без стилей 
 
 29 │   └── без стилей 
 
 30 ├── изображений 
 
 31 │   └ ── logo.svg 
 
 32 └── js 
 
 33 ├── navigation-menu.js 
 
 34 └── theme.js

Общие каталоги

Типичные каталоги тем:

  • 900 23 и т. д. : содержит файлы конфигурации, такие как view.xml файл, который содержит конфигурации изображений для всех изображений и эскизов.

  • i18n : Переводные словари, если таковые имеются.

  • media : Сюда можно поместить изображения предварительного просмотра темы (снимок экрана вашей темы).

  • web : Дополнительный каталог, который содержит статические файлы, организованные в следующие подкаталоги:

    • css/source : Содержит меньше файлов конфигурации темы, которые вызывают миксины для глобальных элементов из пользовательского интерфейса библиотека и файл theme. less , который переопределяет значения переменных по умолчанию.
    • css/source/lib : Содержит файлы представлений, которые переопределяют файлы библиотеки пользовательского интерфейса, хранящиеся в lib/web/css/source/lib .
    • шрифты : Папка для размещения различных шрифтов для вашей темы.
    • изображения : Папка статических изображений.
    • js : Папка для ваших файлов JavaScript.

Подробнее о структуре папок темы см. в разделе Структура темы.

Структура файла языкового пакета

Типичная структура каталогов для трех языковых пакетов следующая:

 ├── de_DE
│ ├── composer.json
│ ├── язык.xml
│ ├── LICENSE_AFL.txt
│ ├── ЛИЦЕНЗИЯ.txt
│ └── Registration.php
├── en_RU
│ ├── composer.json
│ ├── язык.xml
│ ├── LICENSE_AFL.txt
│ ├── ЛИЦЕНЗИЯ.txt
│ └── Registration.php
├── pt_BR
│ ├── composer.json
│ ├── язык.xml
│ ├── LICENSE_AFL.txt
│ ├── ЛИЦЕНЗИЯ.
No related posts.