1 декабря 2016 в 18:57
Всем привет
Есть ли у кого удачный опыт настройки мультисайта D8 (или хотя бы 7) на nginx+php-fpm?
D8 мультисайтинг nginx
Главные вкладки
1 декабря 2016 в 18:57
Комментарии
да.
что конкретно у вас не получается?
cd /YOUR/DRUPAL/ROOT
drush site-install --db-url=sqlite://sites/site1.local/files/.ht.sqlite --site-name="site1.local" --sites-subdir="site1.local"
drush site-install --db-url=sqlite://sites/site2.local/files/.ht.sqlite --site-name="site2.local" --sites-subdir="site2.local"
drush -l http://site1.local upwd admin --password=12345
drush -l http://site2.local upwd admin --password=12345
server {
server_name site1.local site2.local;
root /PATH/TO/DRUPAL/ROOT;
...
127.0.0.1 site1.local
127.0.0.1 site2.local
Пиар своих блогов
«что конкретно у вас не получается?»
на апаче работает, а тут
«Запрашиваемая страница не найдена. »
xd.home/ms
делаю так
'www.xd.home.ms' => 'ms',
);
ссылка ms -> корень
на тлито написано в разделе Веб-Серверне увидел различий, ткните
# try_files $uri @rewrite; # For Drupal <= 6
try_files $uri /index.php?$query_string; # For Drupal >= 7
}
location @rewrite {
rewrite ^/(.*)$ /index.php?q=$1;
}
# Don't allow direct access to PHP files in the vendor directory.
location ~ /vendor/.*\.php$ {
deny all;
return 404;
}
# In Drupal 8, we must also match new paths where the '.php' appears in
# the middle, such as update.php/selection. The rule we use is strict,
# and only allows this pattern with the update.php front controller.
# This allows legacy path aliases in the form of
# blog/index.php/legacy-path to continue to route to Drupal nodes. If
# you do not have any paths like that, then you might prefer to use a
# laxer rule, such as:
# location ~ \.php(/|$) {
# The laxer rule will continue to work if Drupal uses this new URL
# pattern with front controllers other than update.php in a future
# release.
location ~ '\.php$|^/update.php' {
fastcgi_split_path_info ^(.+?\.php)(|/.*)$;
# Security note: If you're running a version of PHP older than the
# latest 5.3, you should have "cgi.fix_pathinfo = 0;" in php.ini.
# See http://serverfault.com/q/627903/94922 for details.
include fastcgi_params;
# Block httpoxy attacks. See https://httpoxy.org/.
fastcgi_param HTTP_PROXY "";
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_intercept_errors on;
# PHP 5 socket location.
#fastcgi_pass unix:/var/run/php5-fpm.sock;
# PHP 7 socket location.
fastcgi_pass localhost:9004;
}
я ж привел простое рабочее решение.
или конфиг nginx нужен полностью?
он стандартный - только в имени сервера - их два.
это ж на разных доменах, а я бы хотел в папке домена
хочу базу на отдельном сайте сделать (на всякий случай) но что бы выглядело все как один сайт
Непонятно, что имеется ввиду
это обычный мультисайтинг: одно ядро и много отдельных сайтов в /sites
(в примере: site1.local, site2.local)
структура следующая:
├── autoload.php
├── composer.json
├── composer.lock
├── core
├── example.gitignore
├── index.php
├── LICENSE.txt
├── modules
├── profiles
├── README.txt
├── robots.txt
├── sites
│ ├── default
│ ├── development.services.yml
│ ├── example.settings.local.php
│ ├── example.sites.php
│ ├── README.txt
│ ├── site1.local
│ ├── site2.local
│ └── sites.php
├── themes
├── update.php
├── vendor
└── web.config
Уточните, что конкретно интересует.
вот
https://www.drupal.org/docs/7/multisite-drupal/multi-site-in-subdirectories
И?
When you are attempting to get Drupal multi-site working using subdirectory URLs rather than subdomain or different domain URLs, you may encounter problems. You'll start out by making a directory such as sites/example.com.site1, and putting a settings.php file there. If this works for you, great! But it probably will not, until you create a symbolic link for each site.
so, its work for me!
solution above)
Попробуйте своими словами более подробно объяснить,
у меня такое ощущение, что вы несколько запутались с целью и методом.
идея такая (не знаю насколько правильная):
разнести сайт и crm (обзовем так) на разные сайты.
Зачем? Ну в crm тяжелые запросы к базе, я предполагаю что одновременная работа будет притормаживать сайт(не уверен).
Можно разделить так:
site.ru
crm.ru
но это не удобно
лучше так
site.ru
site.ru/crm
то есть будет 1 сайт с двумя независимыми базами.
под апачем работает без проблем
p.s. Опять же гибкая работа с базой, можно разнести на разные диски или даже на разные серверы...
ага)
это больше к multiple database,
или - общие таблицы,
можно на поддомен вынести.
но, для анонимов то все кешируется, а в crm - авторизованные
я думаю - решать проблемы по мере появления нужно
так это ключевой вопрос, его надо решить перед тем как делать, потом уже не переделаешь
«но, для анонимов то все кешируется, а в crm - авторизованные»
на сайте будет форум, и еще типа тикет системы, так что тоже авторизованные будут
да, и магазин ишшо
ну в текущей базе 4000 записей, по 20 полей, + еще зависимые таблицы
выборки сложные....
зачем делать халтуру, если ее можно легко избежать?
если контент особо не пересекается - выноси пользователей в общую таблицу (для разных сайтов),
а все эти crm, форумы и магазины - на поддомены.
а там уже как желаешь - хоть в мультисайтинг, а базы на отдельные серв.
site.domain
crm.site.domain
store.site.domain
forum.site.domain
имхо.
а почему предпочтительно поддомены а не поддиректории?
если в будущем захочешь разнести по серверам или даже другим программным стекам - проблем будет меньше.
эдакие "толстые" микросервисы, пардон за каламбур))
так маршрутизация читабельней и логичней - имхо
А в плане сео, если например яндекс их будет воспринимать как разные сайты? Можно конечно склеить, но как то терзают смутные сомнения...
А третий уровень вы прямо в зоне домена прописываете?
в плане seo:
опять таки - имхо
человеко-читаемая логичная маршрутизация с неглубокой вложенностью (rest будет плюсом)
четкая семантика
разметка, структурирование данных
так, если вы используете разметку одной организации на всех сайтах,
то пауки определят где у организации магазин, где основной, где форум и тд.
я не вижу тут проблем.
так-же плюс - указание и открытие полной информации в настройках домена.
(для whois)
про третий уровень - не понял))
поддомены - это все кроме корневого)))
разные регистраторы - разные интерфейсы, своего dns у меня нет(bind не насилую)),
т.е., везде, это просто новая "А" запись.
может будет полезным:
https://developers.google.com/schemas/
https://developers.google.com/search/docs/guides/intro-structured-data
ya понимает json-ld
ну третий уровень это stor.site.ru
второй site.ru
а первый .ru, вроде так ранжируется
Да я как раз про "А"
Там все прописано?
типа
site 111.111.111.111
stor.site 111.111.111.111
типа * - ето все, а остальное поддомены и адреса