Cms на файлах без mysql: CMS без базы данных mysql

Начал знакомиться с чудесными миром CMS-ок без Mysql. Говоря…

?

(no subject)
frost_16
October 19th, 2011
Current Music:
Arida Vortex — Зеркала

Начал знакомиться с чудесными миром CMS-ок без Mysql. Говоря простыми словами — с сайтовыми движками, не требующими наличия баз данных, и хранящих всю информацию непосредственно в собственных файлах. Воистину, последние три года я забивал гвозди микроскопом 🙂 Joomla — это конечно круто и удобно, но иногда все-таки нужно решение попроще, когда нужен просто сайт-визитка на 1-2 страницы с минимумом текста и 1-10 картинками. Можно конечно не замарачиваться и сверстать все в блокноте, но сайт периодически требует обновления, а заказчики все чаще встречаются технологически-неподкованные. Для них зайти на сервер, открыть PHP-файл и отредактировать его — задача посложнее подъема на Эверест, причем даже при наличии подробнейшей инструкции. А если там стоит Joomla — они ее пугаются и вечно путаются в ее интерфейсе (хотя казалось бы — проще некуда). WordPress же использовать мне религия не позволяет 🙂 А такое простое решение как CMS без баз данных похоже очень удобно.

Плюсы очевидны:
1. Меньший размер дистрибутива — полмегабайта против 10-20 мегабайт у Joomla. Заливается на сайт и бэкапится за считанные минуты.
2. Простой бэкап, инсталляция и перенос на другой сервер. Тупо взять файлы движка-сайта и скопировать/закачать куда нужно.
3. Простота интерфейса. Админка такой CMS как правило элементарно-проста, там нет лишних функций, а настройки минимальны, плюс встроен визуальный html-редактор. Клиенту будет проще разобраться.
4. Простая внутренняя логика при работе с шаблоном дизайна сайта. Настолько просто что даже нет смысла делать его с нуля. Стандартная php-страничка и css-файл. Гораздо проще по своей структуре нежели у той же Joomla. Как будто сам писал 🙂 Никаких лишних непонятных функций, переменных и операторов — все просто и понятно, даже с первого взгляда на шаблон можно разобраться с полпинка что за что там отвечает.
5. Можно сэкономить и купить хостинг без поддержки баз данных. Или вообще найти бесплатный хостинг с PHP

Минусы очевидны не менее:
1. Отсутствие большого комьюнити и поддержки. Если заглючит намертво — скорее всего придется ломать голову самому.
2. Отсутствие большого числа всевозможных модулей, плагинов и прочих дополнений, адаптированных под эту конкретную CMS. Если нужно прикрутить к сайту, допустим, слайдшоу — нужно будет искать реализацию этого слайдшоу на PHP, XML, Flash и т.д. и прикручивать его на сайт самостоятельно. Несложно, но это лишняя морока.

До недавнего времени я юзал собственную сборку CMS Joomla с модифицированным под мои нужды шаблоном Jsn Epic Free — удобная связка, подходящая практические под любые задачи — от сайта-визитки на 1 страницу, до интернет-магазина на полтыщи десятков страниц. Главное — правильно настроить систему и вбить в файл шаблона нужные значения. Но теперь, я вижу, есть смысл добавить в свой «джентельменский набор» еще и дистрибутив, ну например Template CMS. Неплохое решение для небольших сайтов. Как раз сейчас разбираю его по кусочкам и впечатления самые положительные.

Tags: полезности, работа, сайт

Среда разработки для CMS в Docker

  • Конфигурации контейнеров

    • PHP-FPM
    • APACHE
    • MYSQL
    • phpMyAdmin
  • docker-compose
  • CMS в Docker
  • Итог

По работе потребовалось ставить на конвейер разработку модулей под разные CMS для команды разработчиков. Имея опыт работы с Docker, было решено конфигурировать среду разработки модуля для CMS в Docker.

При наличии достаточного пространства на диске, организованная среда на docker контейнерах имеет ряд преимуществ:

  • разработчикам не нужно самостоятельно настраивать рабочую среду, а это влечет следующее:
    • быстрый вход в разработку
    • на машинах разработчиков нет лишнего, кроме docker-engine и docker-compose
  • из developer среды можно на этапе разработки сделать задел для организации:
    • среды для CI/CD
    • production среды

В данной статье развернем среду разработки в Docker для произвольной CMS на php с использованием Apache2, PHP-FPM, MySQL (5. 7/8), phpMyAdmin. В конце подведем итог.

Когда-то мы уже пробовали развернуть локальный LAMP, теперь развернем его в Docker.

Файловая структура:

  • .docker — директория с конфигами для организации среды разработки

    • mysql
    • php
    • webserver (не apache чтобы в дальнейшем можно было заменить на любой другой web сервер)
  • cms — директория с исходниками CMS
  • src — директория с исходниками плагина (если нужно)

Каждый компонент среды будет помещен в отдельный контейнер — микросервисная архитектура.

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

#Конфигурации контейнеров

Сначала сконфигурируем каждый сервис/контейнер по отдельности, а потом запишем это в docker-compose. yml.

Возможно, проще для понимания будет параллельно поглядывать на docker-compose.yml.

#PHP-FPM

Нужна отладка и тесты на phpunit, значит нужен xdebug и composer.

Создаем файл .docker/php/Dockerfile и записываем в него конфигурацию образа на основе официального образа docker php:

FROM php:7.3-fpm
RUN apt update && apt install -y libzip-dev zip mc nano
# установка модулей php из репозитория ОС
RUN docker-php-ext-install pdo_mysql zip
# установка модулей php из репозитория pecl
RUN pecl install xdebug && docker-php-ext-enable xdebug
# установка composer
RUN cd ~ \
    && curl -sS https://getcomposer.org/installer -o composer-setup.php \
    && php composer-setup.php --install-dir=/usr/local/bin --filename=composer
# запуск PHP-FPM
CMD ["php-fpm"]

Внутрь каждого контейнера предназначенного для разработки, я устанавливаю mc (консольный файловый менеджер) и nano (консольный текстовый редактор), чтобы работать внутри контейнера с удобным для меня ПО.

Внутрь контейнера с PHP будем прокидывать следущие файлы:

  • .docker/php/php.ini (документация про файл конфигурации php и про директивы php.ini:
[PHP]
user_ini.filename = "php.ini"
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
log_errors = On
error_log = /var/www/html/php_errors.log
  • .docker/php/xdebug.ini (документация xdebug по настройкам):
xdebug.remote_handler = dbgp
xdebug.log=/var/www/html/xdebug.log
xdebug.client_host = 172.18.0.1
xdebug.client_port = 9003
xdebug.mode=coverage,debug
xdebug.start_with_request = yes
  • .docker/php/entrypoint.sh:
#!/bin/bash
# устанавливаем нужные библиотеки, если надо
composer install
# запускаем вечный цикл, чтобы контейнер не упал
while true; do sleep 10; done;

.docker/php/entrypoint.sh будет запускаться каждый раз при старте контейнера!

#APACHE

За основу возьмем официальный Docker образ Apache2 от Canonical (Ubuntu) и внутри образа установим модуль для работы веб-сервера по FastCGI. Запишем все это в конфиг образа .docker/webserver/Dockerfile:

FROM ubuntu/apache2:latest
RUN apt update && apt install -y libapache2-mod-fcgid nano mc

Запускать веб-сервер будем в отдельном скрипте .docker/webserver/entrypoint.sh, имхо удобнее, там несколько команд на запуск:

#!/bin/bash
# включаем нужные модули
a2enmod proxy
a2enmod proxy_fcgi
a2enmod rewrite
# тестируем конфиги
apachectl configtest
# запускаем демона apache2
service apache2 start
# стартуем вечный цикл
while true; do sleep 10; done;

Сделаем конфиг .docker/webserver/host.conf для нашего виртуального хоста:

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html
    <FilesMatch \.php$>
        # по дефолту PHP-FPM работает на 9000 порту
        # имя хоста php берем из имени сервиса,
        # которое присвоили контейнеру с php в docker-compose-dev.yml
        SetHandler "proxy:fcgi://php:9000"
    </FilesMatch>
    ErrorLog /var/www/html/error. log
    CustomLog /var/www/html/access.log combined
</VirtualHost>

Теперь нам необходим сам конфиг .docker/webserver/apache2.conf. Оригинальный конфиг apache2 в контейнере можно просмотреть так:

# запускаем контейнер в фоне
$ docker run -d ubuntu/apache2
# смотрим список запущенных контейнеров
$ docker ps
CONTAINER ID   IMAGE            COMMAND                CREATED          STATUS          PORTS     NAMES
2464a3b528d2   ubuntu/apache2   "apache2-foreground"   25 seconds ago   Up 23 seconds   80/tcp    heuristic_lederberg
# заходим в терминал в контейнере
$ docker exec -it 2464a3b528d2 /bin/bash
# просматрвиаем файл конфига
$ cat /etc/apache2/apache2.conf
# здесь будет вывод файла конфига
# закрываем сессию терминала в контейнере (выходим из контейнера)
$ exit
# останавливаем контейнер
$ docker stop 2464a3b528d2

Копируем то что в файле конфига, и заменяем некоторые настройки на это:

# ip адрес сервера
ServerName 172.18.0.1
# разрешение на децентрализованную конфигурацию (. htaccess) в диреткории /var/www/
<Directory /var/www/>
	Options Indexes FollowSymLinks
	AllowOverride All
	Require all granted
</Directory>
# название файла с децентрализованным конфигом
AccessFileName .htaccess

IP адрес директивы ServerName должен совпадать с IP адресом подсети создаваемой для композиции контейнеров в docket-compose.yml.

#MYSQL

В простом варианте достаточно взять Docker образ MySQL и заюзать переменные из раздела Environment Variables типа MYSQL_ROOT_PASSWORD, MYSQL_USER и MYSQL_PASSWORD.

Однако, у меня это не заработало в момент когда появилась вторая композиция контейнеров, то есть была одна запущенная композиция контейнеров с MySQL и все работало, но при попытке поднять вторую композицию контейнеров с использованием MySQL начались проблемы, что-то вроде такого:

Lost connection to MySQL server at 'reading initial communication packet', system error: 104
# или
Can't open and lock privilege tables: Table 'mysql. user' doesn't exist
# или
Can't open the mysql.plugin table. Please run mysql_upgrade to create it

И да, я не пытался поднять второй инстанс одной и той же композиции контейнеров, нет.

Все сводилось к тому, что сервис MySQL не мог инициализироваться.

В одном случае могла успешно работать композиция контейнеров 1, но не работала 2-ая композиция, но после docker system prune -a, магичеким образом переставала работаться 1-ая композиция, а 2-ая работала.

Решение: провести инициализацию самостоятельно при первом запуске сервиса.

Для этого нужно 2 файла.

.docker/mysql/entrypoint.sh:

#!/bin/bash
# инициализировать mysql без root пароля
# в первый запуск сработает, во второй нет, потому что хранилище уже инициализировано
mysqld --initialize-insecure
# запустить демона mysql в фоне
mysqld --user=root --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci --default-authentication-plugin=mysql_native_password --daemonize
# зайти в mysql от root но без пароля и передать на выполнение содержимое файла
# в первый запуск сработает, во второй не сможет зайти без пароля
mysql -u root < /usr/bin/init. sql
# запустить вечный цикл
while true; do sleep 10; done;

.docker/mysql/init.sql для MySQL 5.7:

ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'root';
GRANT ALL ON *.* to 'root'@'%' IDENTIFIED BY 'root';
FLUSH PRIVILEGES;
CREATE DATABASE IF NOT EXISTS db_name;
USE db_name;

.docker/mysql/init.sql для MySQL 8.0:

CREATE USER 'root'@'%' IDENTIFIED WITH mysql_native_password  BY 'root';
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%';
FLUSH PRIVILEGES;
CREATE DATABASE IF NOT EXISTS db_name;
USE db_name;

'root'@'%' позволяет указать что root пользователь может заходить с любого хоста. localhost будет доступен только в контейнере с MySQL, но к сервису MySQL в композиции контейнеров, будут обращаться другие контейнеры не по localhost, а по имени сервиса MySQL, например 'root'@'mysql'.

#phpMyAdmin

А здесь ничего дополнительно конфигурировать не будем, просто возьмем Docker образ phpMyAdmin, прокинем порт контейнера на хост машину, и укажем доступы к сервису mysql прямо в docker-compose. yml, и все будет работать 🙂

#docker-compose

Сделаем docker-compose.yml (документация):

version: '3.0'
services:
  mysql:
    image: mysql:5.7
    container_name: cms-mysql-dev
    restart: unless-stopped
    volumes:
      # хранилище mysql прокинем на хост машину
      - ./docker-data/mysql/data:/var/lib/mysql
      - ./.docker/mysql/init.sql:/usr/bin/init.sql
      - ./.docker/mysql/entrypoint.sh:/usr/bin/entrypoint.sh
    command: /bin/bash -c "/usr/bin/entrypoint.sh"
    networks:
      - app-network
    
  php:
    build:
      context: ./.docker/php
    container_name: cms-php-dev
    restart: unless-stopped
    depends_on: 
      - mysql
    volumes:
      # монтируем файлы cms (и плагина) внутрь контейнера
    networks:
      - app-network
      
  webserver:
    build:
      context: ./.docker/webserver
    container_name: cms-webserver-dev
    restart: unless-stopped
    depends_on: 
      - php
    ports:
      - "5011:80"
    volumes:
      - . /.docker/webserver/host.conf:/etc/apache2/sites-available/000-default.conf
      - ./.docker/webserver/apache2.conf:/etc/apache2/apache2.conf
      - ./.docker/webserver/entrypoint.sh:/usr/bin/entrypoint.sh
    command: /bin/bash -c "/usr/bin/entrypoint.sh"
    networks:
      - app-network
      
  pma:
    image: phpmyadmin/phpmyadmin:latest
    container_name: cms-pma-dev
    restart: unless-stopped
    depends_on: 
      - mysql
    ports:
      - "5012:80"
    networks:
      - app-network
networks:
  app-network:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 172.18.0.1/24

В терминал введем команду:

$ docker-compose up --build

И наш пустой web-сервер заработает, можно проверить по адресу localhost:5011.

Настало время разобраться как же сюда впихнуть CMS …

#CMS в Docker

Чтобы CMS заработала в Docker ее надо прокинуть/смонтировать — снаружи внутрь, и тогда можно будет редактировать файлы на хост машине, а изменения будут вступать в силу сразу при сохранении файлов на диск.

В случае когда работа осуществляется с целым инстансом CMS и этот ##инстанс CMS является продуктом##, то на этом развертывание среды заканчивается — монтируем CMS, запукаем docker-compose, заходим на localhost:5011 и производим установку CMS.

Если в качестве продукта выступает ##плагин##/##модуль##/##дополнение## для CMS, тогда, кроме прокидывания CMS нужно настроить прокидывание файлов модуля — сначала монтируются файлы CMS, затем файлы модуля.

Если говорить про плагины для WordPress, 1С-Битрикс, Shop-Script и прочие CMS где плагин располагается в отдельной директории, то достаточно прокинуть только эту директорию.

Например, в корне есть такие директории:

  • shop-script — исходники CMS
  • src — исходники плагина

Тогда монтирование CMS и исходников будет выглядеть так:

volumes:
  - . /shop-script/:/var/www/html/
  - ./src/:/var/www/html/wa-apps/shop/plugins/mymodule/

А если файлы плагина внедряются смешиваясь с основными файлами CMS, как например сделано в OpenCart, то прокидывать файлы плагина надо по отдельности каждый.

Например, в корне есть такие диреткории:

  • opencart — исходники CMS
  • src — исходники плагина

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

volumes:
  - ./opencart/:/var/www/html/
  - ./src/:/var/www/html/

Получим такую ошибку:

ERROR: Duplicate mount points: [/home/byurrer/modules/opencart3.0/opencart:/var/www/html:rw, /home/byurrer/modules/opencart3.0/src:/var/www/html:rw]

А вот так, многословно но работает:

volumes:
  - ./opencart/:/var/www/html/
  - ./src/admin/controller/extension/module/mymodule.php:/var/www/html/admin/controller/extension/module/mymodule.php
  - ./src/catalog/controller/extension/module/mymodule. php:/var/www/html/catalog/controller/extension/module/mymodule.php
  - ./src/admin/language/ru-ru/extension/module/mymodule.php:/var/www/html/admin/language/ru-ru/extension/module/mymodule.php

#Итог

В итоге мы получаем среду для работы с CMS в Docker контейнерах, организованных при помощи композиции контейнеров. При этом работа с CMS может осуществляться в двух вариантах:

  • продукт сайт
  • продукт плагин

По адресу localhost:5011 будет доступен сайт на CMS, а по адресу localhost:5012 будет доступен phpMyAdmin.

php — CMS: хранить пользовательские страницы в виде файлов или в базе данных MySQL?

спросил

Изменено
8 лет, 11 месяцев назад

Просмотрено
4к раз

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

Весь контент представляет собой HTML-код, по крайней мере, на данный момент.

Я не могу решить, что делать, поскольку запись файлов с помощью php кажется угрозой безопасности, а извлечение содержимого файла из MySQL при каждой загрузке страницы кажется неправильным (и может быть проблемой производительности?).

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

Я был бы очень признателен за любую помощь в том, что делать правильно, или, по крайней мере, что бы вы сделали.

  • php
  • система управления контентом

1

Лучше хранить содержимое в базе данных. Обратите внимание, что вы сохраняете контент, а не всю HTML-страницу (в противном случае вы не создаете систему управления контентом).

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

Вполне нормально выполнять запрос к базе данных при каждом просмотре страницы; действительно, для веб-приложений типично выполнять от 5 до 30 запросов к базе данных при каждом просмотре страницы, и я предполагаю, что stackoverflow.com, вероятно, вписывается в этот диапазон.

MySQL достаточно быстр.

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя электронную почту и пароль

Опубликовать как гость

Электронная почта

Обязательно, но не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Транспорты — База знаний Cascade CMS

Обзор

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

Транспорт файловой системы

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

Примечание . Транспорты файловой системы применимы только к локальным средам.

Для создания транспорта файловой системы:

  1. Перейти к Управление сайтом > Транспорт .
  2. Перейдите к контейнеру, в котором будет храниться новый транспорт, или создайте новый контейнер, используя Добавить > Контейнер .
  3. Щелкните Добавить > Транспорт .
  4. Выберите Файловая система и нажмите Выберите .
  5. В поле Name введите имя вашего транспорта.
  6. В поле Parent Container выберите контейнер для транспорта, если это необходимо.
  7. В поле Server Directory введите путь к каталогу. Этот путь будет предваряться необязательным неабсолютным путем к каталогу назначения при определении полного опубликованного пути объекта. Этот комбинированный путь затем добавляется к путям ресурсов при публикации. Например, если у транспорта есть каталог сервера «/www/publish root», у пункта назначения, использующего транспорт, есть каталог «mysite», а публикуемый ресурс имеет системный путь «/content/my press release»; затем ресурс будет опубликован в каталоге «/www/publish root/mysite/content» в файловой системе. Если, однако, используемый Destination содержит абсолютный путь, то поле Server Directory в Transport будет игнорироваться.
  8. Нажмите Отправить .
Права доступа к файловой системе и разрешения

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

Сопоставленные сетевые расположения

Возможна публикация на подключенный сетевой диск с использованием транспорта файловой системы. Каталог, используемый в качестве точки монтирования для подключенного к сети диска, следует рассматривать как любой другой каталог в файловой системе. Обратите внимание, однако, что, поскольку Cascade CMS рассматривает диск как каталог; механизм совместного использования диска (NFS, FTP и т. д.) не может управляться Cascade CMS. Альтернативой может быть установка сервера FTP/FTPS/SFTP и соответствующего транспорта FTP/FTPS/SFTP, которым можно управлять из Cascade CMS.

Транспорт FTP/FTPS/SFTP

FTP/FTPS/SFTP Передает содержимое на удаленный сервер по протоколам FTP, FTPS (FTP через SSL/TLS) или SFTP (Secure FTP). Учетная запись, указанная в параметрах транспорта, должна иметь соответствующие привилегии на удаленном сервере для перемещения по структуре папок, записи и создания, чтобы гарантировать, что операции публикации не вызовут ошибок.

Чтобы создать транспорт FTP/FTPS/SFTP:

  1. Перейдите к  Управление сайтом  >  Транспорты .
  2. Перейдите к контейнеру, в котором будет храниться новый транспорт, или создайте новый контейнер, используя Добавить  >  Контейнер .
  3. Нажмите  Добавить  >  Транспорт .
  4. Выберите FTP/FTPS/SFTP  и нажмите  Выберите .
  5. В поле Имя введите имя вашего транспорта.
  6. В поле Parent Container  при необходимости выберите контейнер для транспорта.
  7. В разделе Настройки транспорта настройте следующие поля:
    • Имя сервера — Имя хоста сервера, к которому будет подключаться Cascade.
    • Порт сервера — порт, через который Cascade будет обмениваться данными с сервером FTP/FTPS/SFTP. Обратите внимание, что порт по умолчанию для каждого выбранного ниже протокола выбран заранее.
    • Каталог сервера — необязательный путь к каталогу, который добавляется к неабсолютному пути к каталогу назначения при определении полного опубликованного пути актива. Этот комбинированный путь затем добавляется к путям ресурсов при публикации. Например, если у транспорта есть каталог сервера «/www/publish root», у пункта назначения, использующего транспорт, есть каталог «mysite», а публикуемый ресурс имеет системный путь «/content/my press release»; затем ресурс будет опубликован в каталоге «/www/publish root/mysite/content» на сервере FTP/FTPS/SFTP. Если, однако, используемый Destination содержит абсолютный путь, то поле Server Directory в Transport будет игнорироваться.
  8. В разделе Протокол выберите один из следующих вариантов:
    • FTP — с опцией Использовать пассивный FTP (PASV) .
    • FTPS — FTP через SSL/TLS.
    • SFTP — Безопасный FTP.
  9. В разделе Настройки аутентификации настройте следующие поля:
    • Имя пользователя — имя пользователя, используемое при аутентификации на сервере FTP/FTPS/SFTP.
    • Тип аутентификации
      • Пароль — пароль, который будет использоваться в сочетании с именем пользователя для аутентификации на сервере FTP/FTPS/SFTP.
      • SSH-ключ — позволяет загрузить файл закрытого ключа и дополнительную фразу-пароль закрытого ключа для аутентификации на SFTP-сервере.
  10. Нажмите  Отправить .

Публикация базы данных

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

Чтобы создать транспорт базы данных:

  1. Перейдите к  Управление сайтом  >  Транспорты .
  2. Перейдите к контейнеру, в котором будет храниться новый транспорт, или создайте новый контейнер, используя Добавить  >  Контейнер .
  3. Нажмите  Добавить  >  Транспорт .
  4. Выберите База данных и нажмите Выберите .
  5. В поле Имя введите имя вашего транспорта.
  6. В поле Parent Container  при необходимости выберите контейнер для транспорта.
  7. В разделе Настройки транспорта базы данных настройте следующие поля:
    • Идентификатор сайта — Идентификатор, который прикрепляется к каждому элементу, опубликованному с использованием этого транспорта, который используется для различения публикаций из разных транспортных баз данных.
    • Имя сервера — имя хоста сервера, к которому будет подключаться Cascade.
    • Порт сервера — порт, через который Cascade будет взаимодействовать с MySQL.
    • Имя базы данных — Имя базы данных, в которую будут вставлены данные.
    • Имя пользователя — Имя пользователя, используемое при аутентификации в MySQL.
    • Пароль — Пароль, который будет использоваться в сочетании с именем пользователя для аутентификации в MySQL.
  8. Нажмите Отправить .
Требования к публикации баз данных
  • Для публикации базы данных требуется MySQL 5+.
  • Набор символов по умолчанию во внешней базе данных и во всех ее таблицах и текстовых столбцах должен быть установлен на utf8, , а параметры сортировки должны быть utf8_unicode_ci .

Примечание . SSL в настоящее время не поддерживается для транспорта баз данных. Поскольку MySQL 8 по умолчанию использует SSL для подключений, если вы используете MySQL 8 в своей целевой базе данных, вам может потребоваться добавить ssl=0 в файл конфигурации целевой базы данных и перезапустить его, чтобы полностью отключить SSL.

Типы публикуемого контента
  • Файлы. Опубликованные файлы включают имя, местоположение, путь и метаданные связанного актива в CMS; опубликованная версия, однако, не включает байтовое содержимое файла.
  • Папки — опубликованные папки включают имя, расположение, путь и метаданные связанного актива в CMS; они служат контейнерами для коллекций других файлов, страниц и папок.
  • Страницы — опубликованные страницы включают имя, местоположение, путь и метаданные связанного актива в CMS; также включает отображаемый контент региона ПО УМОЛЧАНИЮ (т. е. контент, специфичный для страницы, с любыми примененными преобразованиями региона по умолчанию). Работает как со структурированными данными, так и со страницами WYSIWYG.
Внешняя база данных

Публикация базы данных создает записи во внешней базе данных, содержащей пять таблиц: файл, папка, страница, метаданные и метаданные_настраиваемые. Таблицы файлов, папок и страниц содержат записи, сопоставленные с соответствующими активами, управляемыми в Cascade. Таблицы metadata и custom_metadata содержат связанные и динамические метаданные для ресурсов страниц, файлов и папок, представленных в таблицах файлов, папок и страниц. Несколько замечаний по некоторым из вышеперечисленных полей:

  • account_id — всегда должно быть 1
  • site_id — произвольное значение, отражающее конкретный сайт, которому принадлежит запись, и устанавливается на транспорте
  • folder_id — соответствует cms_id папки, а не ее id полю в удаленной базе данных

Схему базы данных по умолчанию для публикации базы данных можно загрузить здесь.

Идентификаторы сайтов

Как упоминалось выше, идентификатор сайта — это произвольное число, установленное в транспортной базе данных для отражения «сайта», которому принадлежит запись. Идентификатор сайта должен быть уникальным для каждой из нескольких транспортных баз данных, использующих одну и ту же внешнюю базу данных MySQL, чтобы эффективно различать содержимое.

Устранение неполадок транспорта базы данных

Если Cascade не может опубликоваться во внешней базе данных, убедитесь, что соблюдаются следующие рекомендации:

  • Имя сервера и порт указаны правильно (обычно 3306 для MySQL).
  • Брандмауэр не блокирует доступ к вышеуказанному порту.
  • Хост, который пытается подключиться, предоставил доступ пользователю транспорта базы данных.
  • Параметр bind-address в конфигурации MySQL не установлен на localhost или петлевой адрес.

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

Прочие примечания

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

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

Например, папка, содержащая две страницы:

  • Папка
    • Страница 1
    • Страница 2

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

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

 Если пользователь имел дело с сайтом с идентификатором = 5 и учетной записью с идентификатором = 1 и хотел получить родительскую папку файла с именем «koko. png» во внешней базе данных, запись файла появится во внешней базе данных. база данных так:

Образец записи базы данных для ‘koko.png’

идентификатор

аккаунт_идентификатор

site_id

cms_id

идентификатор_папки

метаданные_id

название

путь

9

1

5

92436e0a7f00010100b2eca959237ccd

92436dc67f00010100b2eca953a7298f

10

Коко. png

сайт5/images/koko.pn

Запись желаемой папки будет выглядеть так:

Пример записи базы данных для родительской папки ‘koko.png’

идентификатор

аккаунт_идентификатор

site_id

cms_id

идентификатор_папки

метаданные_id

название

путь

3

1

5

92434dc67f00010100b2eca953a7298f

9a436dc67f00010100b2eca234526666

10

изображений

сайт5/изображение

Чтобы выбрать эту запись, правильный запрос будет:

ВЫБЕРИТЕ * ИЗ папки, ГДЕ cms_id='92436dc67f00010100b2eca953a7298f' AND site_id=5 AND account_id=1;

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

Транспорт Amazon S3

Amazon Simple Storage Service (S3) можно использовать для размещения статических ресурсов, таких как изображения, PDF-файлы, CSS или JS. Вы также можете публиковать и размещать целые сайты, включая содержимое страниц, на S3 и обслуживать их через личный домен в CloudFront.

Для публикации с помощью S3 Transport вам потребуется ключ доступа, который позволяет программе, скрипту или разработчику получить полный программный доступ к ресурсам в вашей учетной записи. Образец политики S3 JSON с минимальными необходимыми привилегиями можно найти ниже (замените BucketName с названием вашей корзины):

Клиенты каскадного облака 

 {
    «Версия»: «2012-10-17»,
    "Заявление": [
        {
            «Эффект»: «Разрешить»,
            "Действие": [
                "s3:УдалитьОбъект",
                "s3:ПолучитьОбъект",
                "s3:ПоместитьОбъект",
                "s3:ПутОбжектАкл",
                "s3:ЛистБакет"
            ],
            "Ресурс": [
                "arn:aws:s3:::bucketName/*",
                "arn:aws:s3:::bucketName"
            ]
        }
    ]
}

Локальные клиенты 

 {
    «Версия»: «2012-10-17»,
    "Заявление": [
        {
            «Эффект»: «Разрешить»,
            "Действие": [
                "s3:СписокВсеМоиВедра"
            ],
            "Ресурс": [
                "арн:aws:s3:::*"
            ]
        },
        {
            «Эффект»: «Разрешить»,
            "Действие": [
                "s3:УдалитьОбъект",
                "s3:ПолучитьОбъект",
                "s3:ПоместитьОбъект",
                "s3:путобжектакл"
            ],
            "Ресурс": [
                "arn:aws:s3:::bucketName/*"
            ]
        }
    ]
}

Для локальных клиентов: на вкладке «Разрешения» для корзины S3 должен быть отключен параметр Блокировать новые общедоступные списки управления доступом и загружать общедоступные объекты . Если этот параметр не отключен, вы можете столкнуться с ошибками Access Denied при попытке публикации в корзину S3. Другие причины этой ошибки и шаги по их устранению можно найти на странице устранения неполадок Amazon S3.

Для создания транспорта Amazon S3:

  1. Перейдите к  Управление сайтом  >  Транспорты .
  2. Перейдите к контейнеру, в котором будет храниться новый транспорт, или создайте новый контейнер, используя Добавить  >  Контейнер .
  3. Нажмите  Добавить  >  Транспорт .
  4. Выберите Amazon S3 и нажмите Выберите .
  5. В поле Имя введите имя вашего транспорта.
  6. В родительском контейнере  , при необходимости выберите контейнер для транспорта.
  7. В разделе Настройки транспорта Amazon S3 настройте следующие поля:
    • Идентификатор ключа доступа пользователя AWS
    • Секретный ключ пользователя AWS
    • Имя корзины S3 — имя корзины S3, к которой указанный выше пользователь с ключом доступа AWS имеет доступ для записи.
    • Базовый путь — необязательно, активы будут опубликованы в этой папке в вашей корзине S3.
  8. Нажмите  Отправить .
Соединение

Чтобы убедиться, что ссылки на ресурсы, опубликованные в S3, либо сами по себе, либо как часть раздачи CloudFront, из ресурсов, которые там не опубликованы, являются действительными, обязательно используйте URL-адрес корзины S3 (включая базовый путь) или CloudFront. URL-адрес раздачи (включая базовый путь) в качестве URL-адреса сайта или URL-адреса веб-сайта назначения.

Рекомендуется управлять опубликованными ресурсами S3 на отдельном сайте, чтобы система могла легко определить, какой URL использовать при создании ссылок.

Тестирование транспортного соединения

Утилита тестирования транспорта позволяет пользователям тестировать подключение к транспорту, не запуская публикацию.