it-swarm.com.ru

Стратегия мини-сайта

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

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

Но каждое местоположение имеет любое количество клиентов и хочет, чтобы у каждого клиента был свой "мини-сайт" в сети. По сути, новый сайт WordPress, но размещенный под сайтом местоположения, URL-адресом и списком администраторов.

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

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

Установка нескольких сетей

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

Это наполовину сработало. Вы могли бы создавать сайты просто отлично, но без более глубокого контроля над сервером (мой клиент попросил установить плагин, что-то, что они могли бы сбросить на сервер без необходимости предоставления мне доступа по SSH), было трудно заставить работать маршрутизацию в Apache. Некоторые из новых мини-сайтов будут загружены, другие - 404, другие перенаправят обратно на родительский сайт.

Другой проблемой было управление. Хотя вы можете создать столько мини-сайтов, сколько захотите (и можете проверить через phpMyAdmin, что они существуют), мне было трудно зачитать список доступных сайтов.

Другой проблемой было управление базой данных. Каждый раз, когда вы создаете новый сайт, вы создаете более 10 новых таблиц в базе данных. Если на сайте будет только 1 или 2 сообщения/страницы, это излишне.

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

Мой новый подход заключается в настройке клиентов в качестве пользовательского типа сообщения. Затем пользователи родительского сайта могут писать новые сообщения и проверять поле в мета-поле, чтобы связать контент с клиентом (используя схему отношений пост-к-посту).

Когда вы посещаете страницу для пользовательского типа сообщения, WordPress переопределяет отображение и представляет пользовательскую тему (мод P2), отображающую сообщения, связанные с пользовательским типом сообщения.

Здесь не так много проблем с масштабируемостью, просто в управлении контентом. Я не совсем нашел способ разрешить фильтрацию контента от одного клиента к другому (помните, что контент связан с CPT на основе мета-поля, поэтому, если я не создаю другой экран управления почтой, трудно просмотреть все) сообщения для клиента-х ").

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

6
EAMann

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

Требования:

сеть wp, где каждый дочерний сайт имеет много пользователей (клиентов). Каждый клиент хочет иметь одну страницу, которую он может редактировать и контролировать. (Только на одной странице? Нет сообщений?)

поэтому их URL-адрес что-то вроде:

network.com/minisite/clients/clientx (подпапка)

или же

minisite.network.com/clients/clientx (поддомен)

Как сделать:

Используйте плагин для членов/ролей, такой как бесплатный плагин Justin Tadlocks для создания настраиваемой роли клиента с возможностью редактировать страницу, но не создавать посты и т.д. (Или с помощью php)

При регистрации клиента добавьте действие в 'user_register':

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

Добавить действия/фильтры (возможно, посмотреть в коде wp, чтобы найти лучшие хуки)

  1. удалить add_new из меню (Google WordPress удалить меню - я сделал, просто не могу вспомнить, какое действие)
  2. проверьте, если 1 страница уже создана, не позволяйте больше (в случае, если они находят способ даже с меню (WP, я не думаю, что имеет возможность создания страницы, отличную от edit-page, но она может появиться, см. http: //core.trac.wordpress.org/ticket/16714
  3. убедитесь, что каждый может видеть только свои страницы из списка страниц редактирования

Возможно (если будет стандартный шаблон для клиентских страниц):

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

Мой интерес:

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

Я думаю, что описанный выше подход сделает его довольно чистым и простым (всегда хорошая идея).

0
anmari