Как установить второй wordpress
Размещение нескольких сайтов WordPress при помощи Multisite
Мультисайты в WordPress
В 2010 вышла версия 3.0 популярной платформы управления контентом WordPress, которая, помимо прочих улучшений, поставлялась с WordPress MU, включенным в основную конфигурацию. Благодаря этому изменению стало намного проще создавать несколько сайтов WordPress на одном сервере. Раньше каждый размещенный на сервере блог требовал отдельной установки WordPress; теперь же одну установку WordPress и одну базу данных можно использовать для создания неограниченного количества сайтов.
Требования
Для выполнения этого руководства нужно предварительно настроить сервер и создать пользователя с расширенными привилегиями. Чтобы узнать, как это делается, обратитесь к руководству по начальной настройке сервера.
Прежде чем приступить к работе с WordPress, необходимо установить группу программ LAMP. Все инструкции по установке Linux, Apache, MySQL и PHP можно найти в этой статье.
Кроме того, нужно также установить WordPress; инструкции по установке этой платформы можно найти в данном руководстве, но обратите внимание: нужно выполнить только первые 4 раздела, поскольку в этой статье будут внесены дополнительные изменении в конфигурационный файл WordPress.
1: Настройка WordPress
Установив WordPress, нужно отредактировать несколько конфигурационных файлов.
Для начала активируйте режим multisite; для этого откройте:
sudo nano /var/www/wp-config.php
Внесите следующую строку над строкой «/* That’s all, stop editing! Happy blogging. */»
/* Multisite */
define(‘WP_ALLOW_MULTISITE’, true);
Включите модуль Apache mod_rewrite:
sudo a2enmod rewrite
sudo nano /etc/apache2/sites-enabled/000-default
В следующем разделе замените значение строки AllowOverride на All:
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
Затем перезапустите веб-сервер:
sudo service apache2 restart
Выполнив все эти настройки, можете перейти к странице онлайн-установки WordPress. Для этого добавьте wp-admin/install.php к домену или IP-адресу сайта (например: example.com/wp-admin/install.php) и заполните короткую онлайн-форму.
2: Установка нескольких сайтов WordPress
Откройте панель инструментов WordPress и выберите раздел Tools.
Заполнив все необходимые поля, следуйте инструкциям следующей страницы:
sudo mkdir /var/www/wp-content/blogs.dir
sudo nano /var/www/wp-config.php
define(‘MULTISITE’, true);
define(‘SUBDOMAIN_INSTALL’, false);
$base = ‘/’;
define(‘DOMAIN_CURRENT_SITE’, ‘IP_АДРЕС‘);
define(‘PATH_CURRENT_SITE’, ‘/’);
define(‘SITE_ID_CURRENT_SITE’, 1);
define(‘BLOG_ID_CURRENT_SITE’, 1);
Внеся все необходимые изменения, снова войдите в WordPress.
3: Настройка нового сайта WordPress
Снова войдя на сайт, обратите внимание: в верхней панели вместо названия блога появился раздел My Sites.
Чтобы создать новый сайт, перейдите к этому разделу, нажмите Network Admin и выберите Sites в выпадающем меню.
Руководство по миграции WordPress-сайта
Каждый веб-разработчик регулярно сталкивается с задачей миграции. Сюда входят и развёртывание (deploy) локальной версии на удалённом сервере, и перенос работающего сайта с одного сервера на другой. Некоторые печатные издания для программистов называются «Cookbook» – что буквально значит «книга рецептов». Рецептов множество, какой из них лучший — дело вкуса. В этом материале автор расскажет о том, какую технологию переноса типичного сайта на WordPress он считает оптимальной, и почему.
Также данный материал подойдёт для тех, кто хочет узнать больше о резервном копировании сайта и последующем его восстановлении. Потому как по сути это два необходимых шага для осуществления миграции.
Резервное копирование данных
Иногда заботу о создании резервных копий проявляется хостинг-компания. Чаще всего это случается, когда вы пользуетесь услугой простого хостинга сайтов.
В чём главная цель разработчика при переносе сайта с одного сервера на другой? Ничего не потерять. То есть на новом месте сайт должен быть полностью идентичен тому же сайту на старом.
Перво-наперво, вы должны убедиться в том, что после создания резервной копии сайта на нём не будут производиться какие-либо изменения.
Самый простой путь — обратиться ко всем редакторам сайта с просьбой не вносить изменения в содержимое сайта на время переноса (допустим, на ближайшие полчаса). Если, например, вы ведёте блог на WordPress, то договариваться с кем-либо нет необходимости.
В случае, когда такой возможности нет, необходимо перевести сайт в режим обслуживания.
Режим обслуживания
Вы могли заметить, что когда WordPress обновляет плагины или ядро системы, посетители сайта видят вместо его содержимого белый фон и поверх большой заголовок «Сайт ненадолго закрыт на техническое обслуживание. Зайдите через минуту.».
Как принудительно перевести в него сайт?
Результат: 
В принципе, этого будет достаточно для того, чтобы никто (кроме администратора сервера) не смог пользоваться сайтом.
Также можно порекомендовать специальный плагин, которые можно использовать в тех же целях:
Теперь, когда мы точно знаем, что никакие данные в течение процесса миграции изменены не будут, можем приступать к создании резервной копии базы данных.
Резервная копия базы данных
Если у вас есть доступ к консоли сервера, и вы умеете пользоваться терминалом — это заметно ускорит работу.
Прежде всего потому, что создании резервной копии выполняется одной единственной командой:
По-хорошему будет заархивировать дамп базы на ходу:
Текстовые файлы, коим является дамп базы, архивируются наилучшим образом. Размер архива может быть значительно ниже размера дампа базы. Это важно при переносе, т.к. 100Мб перенести куда быстрее, чем 1Гб, например.
Некоторые хостинг-компании предоставляют возможность архивирования данных сайта через панель управления услугами:
После чего на почту приходит заархивированная копия базы данных и сайта.
Однако, далеко не каждый хостинг предоставляет подобные возможности клиентам, поэтому если данный вариант присутствует — удобнее всего пользоваться им.
Резервная копия файлов
Файловая система WordPress обычно выглядит следующим образом (без поддиректорий и их содержимого):
Прежде всего потому, что все остальные папки и файлы у различных установок WordPress (в случае использования последней версии системы) не отличаются друг от друга.
Важно: самый быстрый способ переноса файлов — создание архива, перенос архива и последующая разархивация на конечном сервере.
WordPress состоит из сотен файлов. В случае, когда вы продолжительное время ведёте сайт, к этому прибавляются ещё все загруженные вами изображения, плагины и темы.
Представьте себе перенос по FTP тысячи или даже нескольких тысяч маленьких файлов. Для переноса каждого из них требуется сначала установить, а потом разорвать соединение. В итоге процесс получается долгим и иногда случается что-либо потерять в пути. Тем более, когда файлы переносятся сначала на локальный компьютер, а потом уже — на новый удалённый сервер.
Используя для переноса архив, вы перемещаете всего 1 файл. Да, он много больше размером, но за счёт того, что требуется всего лишь одно соединение с сервером, перенос совершается быстрее. При текущих скоростях доступа к сети Интернет разница во времени может составлять десятки, сотни раз.
Настоятельно рекомендую для транспортировки большого скопления мелких файлов использовать архив в роли контейнера.
Восстановление данных
Итак, архив файлов сайта и дамп базы данных перенесены на новый сервер.
Воссоздание файловой структуры
Первым делом необходимо распаковать архив таким образом, чтобы полностью восстановить исходную структуру файлов и папок.
Чтобы восстановить исходную структуру и не напортачить с папками, необходимо руководствоваться следующим правилом:
Распаковывать архив необходимо там же, где он был создан.
Не забудьте удалить архив с файловой структурой сайта с сервера, чтобы его не могли скачать посторонние.
Воссоздание базы данных
Прежде чем восстанавливать базу данных, необходимо убедиться, что на новом сервере уже создана соответствующая новая база данных.
Используя эти данные мы должны импортировать наш дамп базы данных.
Опять-таки, сделать это мы можем теми же средствами.
В phpMyAdmin выбираем базу данных, вкладку «Импорт», выбираем файл дампа и отправляем форму запроса.
Не забудьте удалить дамп базы данных с сервера или перенести его в безопасное место, в случае, если он там был.
Настройка файла конфигурации
Теперь необходимо открыть в редакторе файл wp-config.php и установить соответствующие настройки для соединения с новой базой данных:
Остаётся только проверить работоспособность сайта!
Заключение
Надеюсь, что данное руководство пригодится тем, кто ещё только озаботился вопросом миграции WordPress-сайта и ищет ответов на вопросы.
Вероятно, более опытные веб-разработчики захотят поделиться с коллегами собственными наработками по теме.
Что же, для этого и созданы комментарии. Поэтому любые советы, дополнения и просто обмен опытом категорически приветствуются.
P.S. Важное дополнение в комментарии от nik_vr:
При переносе с localhost’а на реальный сервер нельзя забывать про адрес сайта. Смена домена с одновременным переносом по вашей инструкции сделает сайт абсолютно неработоспособным. По-этому в инструкцию стоит добавить ещё один шаг (актуальный при смене домена, в т.ч. — при переносе с локального сервера на боевой). Для примера будем считать, что сайд переносится с домена mysite.local на домен mysite.ru.
В сохранённом дампе базы данных WordPress ищем все вхождения mysite.local и заменяем на mysite.ru. Можно это сделать в любом нормальном текстовом редакторе (например, Notepad++). После замены аккуратно сохраняем БД, не забывая о кодировке (в случае с более или менее современными версиями WordPress нужна кодировка UTF-8 без BOM).
После импорта базы данных можно выполнить следующую MySQL-команду:
Ке?блог
Блог о интересном
Многосайтовость на wordpress
Нашел в интернете очень полезную статью о том как сделать на одном движке от wordpress несколько сайтов, при этом использовав 1 базу данных.
Это полезно, если у хостера имеются определенные ограничения на количество БД.
есть экономное решение – использовать одну установленную систему WordPress. Первый случай может пригодиться, когда
у вас есть несколько блогов на хостинге и вы просто добавляете новые проекты, то есть не требуется обновление старых, доработка плагинов и т.п. Они как работали, так и продолжают работать. Второй вариант лучше использовать, если вы изначально планируете создавать сетку блогов или просто несколько простых проектов. Ведь часто кроме ограничения на количество БД у хостеров есть лимиты на занимаемое дисковое пространство – смысл тратить его на одни и те же файлы, плагины.
Кроме того, вы получите хорошую
экономию по времени – обновлять плагины можно будет в одном месте, хотя
не уверен насчет дальнейшей их активации по отдельности. На самом деле
процесс достаточно прост. Используется трюк, как и в прошлой статье,
поэтому можете ее прочитать для общего развития.
Первым делом необходимо настроить домены блогов
дабы они ссылались в один и тот же каталог. Внимание, я рассказываю как
все работает у моего хостера, поэтому не могу на 100% гарантировать
такой же алгоритм у вас. Если возникнут вопросы, проще всего обратиться
в их службу поддержки (собственно, я так и поступал). Так вот,
допустим, есть 3 сайта – site1.ru, site2.ru, site3.ru. При создании их
на хостинге, скорее всего, для каждого будет выделена отдельная папка
на FTP. Суть метода – направить все домены в одну (главную директорию).
Для этого используются алиасы. В админке hqhost, например это выглядит приблизительно так:
Для каждого сайта (домена) редактируем
алиасы – для второстепенных (site2.ru, site3.ru) убираем и добавляем их
к основному (site1.ru). Пожалуй, повторюсь, если вы мало что поняли в
моих словах – лучше обратиться в тех. поддержку хостера, там должны
помочь
Итак, в результате этой процедуры
каждый сайт будет «смотреть» в одну директорию – главного блога. Именно
туда мы заливаем все исходники WordPress, плагины, шаблоны. После этого
= ‘wp_’; Она задает префикс для таблиц блога, нужно сделать так, чтобы
генерировались разные префиксы в зависимости от домена. Для этого
В итоге вместо wp_ получим префикс site1ru_, site2ru_ и т.п. Можете в последней строке добавить любые символы, например:
Теперь каждый раз, когда вы будете
заходить по тому или иному домену, вы будете видеть тот сайт (блог),
который ему соответствует. Поскольку все настройки системы хранятся в
БД, то настраивать каждый проект придется по отдельности. Это же
касается шаблонов – загружаете все в одну папку, а для блогов выбираете
для каждого сайта они должны быть разные. Для решения этой проблемы
создается несколько файлов с идентичными названиями (структурой)
robots-site1.ru.txt, robots-site2.ru.txt и sitemap-site1.ru.xml,
Теперь при заходе с разных URL адресов будут выбираться нужные файлы.
Еще автор советует для загрузки
изображений создавать разные папки в uploads, которые потому указывать
в настройках блога. Также он замечает, что в процессе работы возникают
нерешенные проблемы с некоторыми плагинами: watermark, md5,
дополнительное кеширование. В принципе, в 95% случаев, думаю, без них
можно обойтись, поэтому данный момент не столь критичен. Если
создавать, например, простые сателлиты, то хватит и стандартного набора
Вот, кстати, нашел в сети еще один вариант
реализации нескольких сайтов на одном движке wordpress. Там подход
несколько иной, позволяющий для каждого сайта использовать отдельный
конфиг файл. А это значит, что теоретически можно под одной админкой
объединить даже сайты с разных баз данных.
Также в процессе поиска решения наткнулся на статью с официального сайта, где собраны различные реализации для нескольких проектов – от блогохостингов до целых блого-ферм.
Как установить wordpress на двух серверах
Установка WordPress на двух серверах — балансировка нагрузки
Я должен установить WordPress (один блог, один домен, например, mycompany.com/blog) на двух серверах, совместно использующих одну базу данных на другом сервере, эти два сервера находятся за балансировщиком нагрузки, а база данных будет на другом сервере. Мы планируем этот путь из-за большого трафика.
Я сделал отдельные установки WordPress на одном сервере, на Windows 2003, 2008 с IIS6, 7 и т. Д.
Я просто исследую, как бы я это реализовал.
Каковы были бы шаги для достижения этой цели, и после поиска я увидел несколько сообщений, касающихся каталога wp-content / uploads, которые будут синхронизироваться через равные промежутки времени?
Ваша помощь высоко ценится Спасибо за чтение
а) у нас есть два веб-сервера, подключенных к кластеру san; б) создан каталог блогов в сан; в) сопоставлен этот каталог блогов как виртуальный каталог на обоих веб-серверах; каталоги одинаковы для обоих серверов — например, www.abc.com) e) База данных для этого блога расположена на двух MySQL Boxs
поскольку WordPress сидит в сети, поэтому нет конфликтов с загрузками или чем-то подобным, URL-адрес блога — www.abc.com/blog, и вот как он настроен на обоих сайтах.
Надеюсь, что это помогает кому-то!
Если эти каталоги должны быть идентичными, не могли бы вы разместить их на другом сервере и смонтировать их удаленно через NFS?
Существует так много способов улучшить производительность WordPress, которые не требуют второго сервера и балансировки нагрузки. В двух словах: «кешировать все».
Включить кеш запросов mysql. Вы можете легко достичь 65% или> коэффициентов попадания в кэш с очень небольшим значением mem (зависит от сайта, но не слишком высоко).
WordPress — это тяжелый «читаемый» сайт (против записи), большинство запросов ограничено несколькими сотнями страниц (постами в блоге). Вы можете увеличить количество запросов в секунду в 10 раз, предоставляя статические версии своих самых популярных сообщений. Лучший плагин для этого: wp-super-cache. Я не уверен, что этот конкретный плагин совместим с 2k3, но общая идея автоматического создания статических версий ваших страниц и их периодического обновления для добавления новых комментариев, изменений и т. Д. Будет для вас лучшим выбором.
Я действительно сомневаюсь, что ваш сайт будет использовать достаточно трафика, чтобы потребовать два сервера веб-приложений, если реализованы вышеперечисленные общие усовершенствования (описанные выше могут легко справиться с эффектом слешдот). Однако два веб-сервера добавили бы уровень отказоустойчивости. Поскольку производительность может быть достигнута с одним веб-сервером, отказоустойчивость может быть достигнута с помощью активной / пассивной настройки. Это было бы проще и не требовало обмена информацией о сеансе.
Мультисайтовость в WordPress. Часть 1 — Что, зачем и как? Установка в 2 шага. Особенности.
Да, знаю, что в общем-то эта тема в интернете не была обделена вниманием, но я всё же возьмусь за неё, кроме того, ниже вы найдёте видео по установке WotdPress Multisite.
Вообще сначала я планировал только один пост, но в процессе написания я понял, что поста должно быть два, и в данный момент решено — всего будет три части про WordPress Multisite. Ссылка на вторую часть.
Для кого эта серия статей?
WordPress Multisite (мультисайтовость) — это возможность движка WordPress, появившаяся в 3.0 версии, которая позволяет создавать и использовать неограниченное количество сайтов на одном и том же движке. И «неограниченное» нужно понимать именно буквально, потому что существуют сайты, у которых в сети Multisite Network миллионы (!! самому трудно поверить) подсайтов.
Из особенностей можно отметить следующее:
Когда нужно использовать и когда не нужно?
А вот тут я вас разочарую — я считаю, что каждый сам может решить, нужно ли ему использовать мультисайтовость для решения конкретно своих задач, важно лишь хорошо понимать особенности, которые я перечислил выше.
Например я использую WordPress Multisite при создании мультиязычных сайтов. Иногда компании просят английскую версию, и нет ничего проще, чем добавить её на поддиректорию /en при помощи создания сети.
Обозначу здесь лишь один важный момент, связанный с переводом интерфейса тем — на мой взгляд здесь проще всего на русском сайте включить в Настройки > Общие русский язык, а на английском — английский. И потом просто-напросто локализовать свою тему. Просто, как два пальца об асфальт!
Как установить в 2 простых шага? + видео
Шаг 1. Подготовка.
Тут, если вы реализуете мультисайтовость на уже существующем сайте, обычно рекомендуется сделать полную резервную копию и отключить все плагины — понятное дело, что это не обязательно, однако поможет вам избежать возникновения проблем.
Также на первом шаге я предлагаю вам решить, хотите ли вы использовать поддиректории или поддомены (прилинковка целых доменов тоже возможна, но считается следующем этапом, когда сеть уже установлена).
Также будет не лишним упомянуть, что WordPress уже должен быть установлен.
Шаг 2. Установка сети
На этом шаге тоже ничего сложного нет, если хотите, можете посмотреть видео, либо почитать текстовое описание.
Итак, тут вам понадобится открыть файл wp-config.php и добавить перед строчками «/* That’s all, stop editing!… (Это всё, дальше не редактируем)» следующее:
После сохранения переходим в админку сайта и видим новый пункт в меню Инструменты > Установка сети.
Хочу обратить ваше внимание на то, что на этом же самом шаге WordPress предлагает выбрать либо режим поддоменов, либо режим подкаталогов. А так как я установил WordPress уже в подкаталог, то выбора мне не предлагают.
Смело жмём кнопку «Установить» и в случае с выбором поддиректорий получаем следующее:
Выполняем указанные инструкции и после того, как вы сохранили изменения в файлах, на этом же экране кликаем внизу на ссылку «Войти». Авторизуемся, и в результате у нас в левом верхнем углу появляется выпадающее меню Мои сайты.
Администрированию сети WordPress Multisite будет целиком и полностью посвящена вторая часть поста, которая выйдет через неделю.
Какие фактические отличия от обычного сайта на WordPress?
И для того, чтобы вы стали настоящим мастером по мультисайтовости, я залезу под капот (но не слишком глубоко) и покажу вам, чем отличается мультисайт от обычной установки WordPress.
Какие отличия в админке?
Вот так выглядит консоль управления сетью и доступ к ней имеется только у суперадминистраторов (это же вы!).
Как видите, всё очень похоже на стандартную консоль WordPress, нет только пунктов управления контентом, зато появился пункт меню «Сайты».
Также некоторые плагины будут добавлять свои настройки именно сюда, но большинство — непосредственно в админки подсайтов сети.
И, как я уже говорил, про администрирования я напишу отдельный пост на следующей неделе.
Какие отличия в файлах?
Чтобы было более наглядно, вот как это выглядит:
Какие отличия в базе данных?
В базе данных тоже нет ничего замысловатого:
Это была обзорная вступительная статья по WordPress Multisite, вторая часть уже есть, вот ссылка, скоро будет и третья.
Sysadminium
Устанавливать WordPress будем на Devuan 3 beowulf, а в качестве web-сервера используем nginx. Про Devuan я уже писал, если вкратце это урезанный Debian без systemd, с низким потреблением ресурсов.
Подготовка веб сервера
Все действия я буду выполнять от имени root, а утилиту sudo использовать не буду.
Я покажу как установить WordPress на свой сервер, чтобы потренироваться в создании сайтов на этом движке. Я создам 2 экземпляра WordPress. На одном сервере, например можно изучать создание Интернет Магазина, а на втором создание Личного Блога. По аналогии вы можете создать третий и четвертый экземпляр.
WordPress для своей работы требует:
Устанавливаю веб сервер nginx и подготавливаю две папочки в которые положим два экземпляра WordPress:
Устанавливаю php. Для nginx потребуется php-fpm, для базы данных php-mysql, также потребуются дополнительные модули для работы WordPress:
Перезапустим процесс php-fpm:
Подготавливаю конфигурацию для веб сервера. Нужно создать два конфига на каждый сайт. Первый конфиг:
Выше в конфигах я указываю что оба сайта работают на 80 порте, указываю корень для каждого сайта (/var/www/wp1 и /var/www/wp2), название каждого сайта (wp1.ru и wp2.ru), первая индексная страница это index.php.
Включаю данные конфигурации и выключаю дефолтную конфигурацию, проверяю все ли я сделал правильно и перезапускаю веб-сервер:
Устанавливаю сервер баз данных mariadb,повышаю его безопасность и создаю две базы, для первого и второго экземпляра WordPress:
Скачивание и установка WordPress
Устанавливаю утилиту curl и с её помощью скачиваю последнюю версию WordPress. Далее распаковываю скачанный архив:
Из файла образца настроек WordPress (wp-config-sample.php) с помощью копирования делаю файл настроек WordPress (wp-config.php):
Кидаю подготовленный экземпляр WordPress в подготовленные для сайтов каталоги и указываю в качестве владельцев папочек пользователя www-data:
Получаю ключи WordPress для первой установки, эти ключи нужно будет прописать в конфигурационный файл первого экземпляра WordPress:
Настраиваю первый экземпляр WordPress:
Выше, в конфиге, я указал имя базы данных, логин и пароль для подключения к ней, а также дополнительную опцию «define(‘FS_METHOD’, ‘direct’);» для доступа к файловой системе (это необходимо для закачки обновлений WordPress). Чуть ниже нужно заменить блок ключей полученных ранее.
Получаю ключи для второго WordPress:
Настраиваю второй экземпляр WordPress:
Перезагружаю последний раз веб сервер:
Добавляю на свой компьютер в файл hosts две записи, которые будут указывать на один сервер:
Таким образом мой компьютер будет искать сайты wp1.ru и wp2.ru на моем сервер, а не в интернете. 192.168.10.92 это ip-адрес моего сервера.
Дальше открываю сайт wp1.ru в браузере и донастраиваю WordPress из веб-интерфейса. И тоже самое проделываю с сайтом wp2.ru.
В веб интерфейсе вам нужно будет указать язык сайта, имя сайта, логин/пароль админки, ваш email, после чего можно будет зайти в админку и начать настраивать сайт.