Не используйте WordPress MultiSite

Изменить: это май 2015 года, и этот пост по- прежнему актуален.

Я говорил об этом на WordCamp SF 2013. Проверьте мой слайды или смотреть видео ,

Я люблю MultiSite. Я думаю, что это здорово и очень полезно, когда вы хотите создать сеть сайтов. Но все больше и больше я вижу людей, которые делают вещи, когда я просто наклоняю голову и удивляюсь, почему они используют MultiSite для этого конкретного варианта использования. Люди, кажется, думают, что просто потому, что они могут использовать MultiSite, они должны его использовать, а это просто не тот случай!

MultiSite, как по намерению, так и по эффекту, работает лучше всего, когда вы думаете, что у вас есть собственная версия WordPress.com. У вас есть сеть сайтов, которые отключены друг от друга в отношении данных, но имеют общую доступную базу пользователей. Это означает, что единственной «информацией», которая передается между двумя сайтами, является ваш идентификатор пользователя, и даже тогда, если вам явно не предоставлен доступ к сайту, вы являетесь не чем иным, как подписчиком. Это значит, что вы можете читать сайт и комментировать. (Вы можете получить придирчивость здесь и указать, что на сайте можно сделать гораздо больше, чем подписчик, но вы понимаете суть.) Это означает, что, хотя Есть много совершенно веских причин для наличия MultiSite, он никогда не будет идеальным решением для всех людей.

Одна из лучших альтернатив MultiSite - это пользовательские типы сообщений. Они позволяют вам добавлять «подпапки» на ваш сайт и форматировать их по своему усмотрению. Однако существует недостаток, заключающийся в том, что вы не можете использовать YYYY / MM / DD в своих постоянных ссылках на них ( Отто о пользовательских типах постов - список рассылки wp-testers ) Однако я хотел бы знать, почему люди используют это в любом случае в эти дни? Единственная причина, по которой я использую YYYY в своих URL-адресах, заключается в том, что я считаю, что есть дата полезности этих сообщений, и если вы вернетесь через пять лет, вы должны знать, сколько лет информации.

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

Вот несколько примеров сайтов, которые не следует создавать как мультисайты:

Чтобы классифицировать сообщения

Это от моей девушки, Andrea , который напомнил мне о человеке, с которым мы столкнулись, который хотел иметь один сайт для публикации, и каждый пост будет переходить на специальный сайт в зависимости от категории. В WordPress это уже встроено! Это называется, получить это, «категории». Теперь рассматриваемый пользователь сказал, что не хочет категории, потому что ваш URL отображается как / category / pemalink, а это не его желание. Поэтому я предложил пользовательские типы сообщений. / posttype / name был намного лучше, и он мог добавлять теги как хотел.

Когда ваш сайт однороден

Вы хотите, чтобы вся ваша сеть выглядела и чувствовала себя на 100% одинаково? Не используйте MultiSite. Если все дочерние сайты будут одинаковыми, за исключением контента, но весь контент написан одинаково, вам не нужен MultiSite. Репликация темы и настроек на каждом дочернем сайте - это боль, и вы можете добиться того же результата с помощью категорий, тегов и CPT. Вы даже можете использовать плагин членства, чтобы контролировать, кто видит и имеет доступ к каждому CPT! ( Роль Скоупер утверждает, что делает это, на самом деле.)

Теперь кто-то укажет, что этот сайт не проходит эту проверку! Если вы заметили, три (четыре вида) сайта выглядят очень похоже. Та же общая схема, те же ссылки и боковые панели, но разные заголовки. Этот сайт мог быть сделан как категории и CPT, и не нуждался в мультисайте, пока я не зашел на детские сайты, такие как сайт для моей бабушки. Но. Когда я построил это, я решил разместить свои технические посты на их собственной странице, чтобы отделить письмо. Это отдельные сайты. То, что я пишу здесь, сильно отличается от моего блога, и это важно для меня. Сайт выглядит так же, как один: внешний вид разделяет нас (и у меня есть план для фотоблога).

За одну особенную вещь

Я виновен в этом. У меня был сайт, который был блогом, и я хотел создать раздел «видео». Итак, я сделал MultiSite! Мальчик был таким тупым. Две административные области, два раздела для макета, и я хотел, чтобы сайт по-прежнему выглядел как «сам». Позже я уловил подсказку и преобразовал все это в пользовательские типы постов! Гораздо проще в обслуживании! Теперь у меня есть меньший, более быстрый сайт.

Пользователи не должны знать друг о друге (отдельные пользовательские базы данных AKA)

Эндрю Норкросс указал на это. Если вам нужно, чтобы пользователи были на разных сайтах, но не знали, что они в сети, не используйте MultiSite! Теперь, да, есть способы обойти это, однако для любой крупной компании это кошмар для аудита и риск для безопасности, о котором вы должны знать перед началом работы.

Кертисс Гримала указывает на то, что если вам нужны полностью отдельные пользовательские базы данных, это веский аргумент против MultiSite. Будь то для безопасности или просто для неясности, если пользователи должны быть разделены, не делайте этого. Есть обходные пути, но вы потратите на это больше времени, чем на обновление своих сайтов.

Хостинг небольших клиентских сайтов

Я не принимаю сайт моего отца, Woody.com , хотя я поддерживаю это. Зачем? Потому что, как

Кристиан Антох сказал, что ему просто нужна отдельная установка WP. Будет ли мне проще найти одно место, чтобы обновить его? И да и нет. Он маленький, ему не нужно много, и теперь он владеет своим доменом, сайтом и своей электронной почтой - все в одном месте. Это стоит ему 7 долларов в месяц плюс количество еды, которое он покупает мне, когда мы вместе в городе, и он мастер своего дела. Это здорово для него, потому что, если он уволит меня, у него все еще есть. Кроме того, если он делает что-то странное, что увеличивает его трафик на 500% (как в прошлом месяце), это не влияет на остальные мои сайты. Фактор это в ваш бюджет. Сделайте так, чтобы ваш клиент владел своими данными.

Пользователи должны вставлять JS в сообщения

Это не ошибка, люди. Только Super Admin при установке MultiSite имеет право включать в посты iframes, javascript и другие данные, не относящиеся к oEmbed! Вы не хотите их! Если вы работаете с MultiSite, вы - большая собака, и вы несете ответственность за то, чтобы ограничить их действия вещами, которые не сразят всех, потому что они не понимают, что такое небезопасный взлом iframe. Да, есть плагин, который позволит вам это разрешить. Нет, я не скажу вам, что это мы, потому что, если вы не используете 100% блокировку, вы одобряете пользователей, которых вы знаете и которым доверяете свой автомобиль, сайт, вы не хотите открывать эту дверь.

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

Пользователи должны установить темы / плагины

Кертисс снова напомнил мне, что MultiSite не позволяет вашим пользователям устанавливать темы и плагины так, как они хотят. Вы можете, используя умные темы, которые сохраняют настройки для каждого сайта (например, TwentyEleven), и плагины, которые позволяют настроить CSS (например, WordPress.com Пользовательский CSS ) дайте им больше настроек, но вы не можете дать им доступ к установке плагинов и тем. Зачем? Потому что эти вещи будут доступны всем во всей сети. (Существуют плагины для более детального управления плагинами, позволяющие только некоторым сайтам использовать определенные плагины, но опять же, это не то, что каждый в вашей сети должен иметь доступ для этого. .) Помните, мы делимся здесь!

Тот же пост, каждый сайт

Я продолжаю сталкиваться с этим. «Я хочу, чтобы одна и та же запись была отправлена ​​на каждый сайт в моей сети!» Я понимаю, почему люди делают это, я просто думаю, что они делают это неправильно. Дело не только в том, что MultiSite предназначен для отдельных (или отдельных) сайтов, а в том, что вы разбавляете свой контент. Чем больше разных мест кто-то может посетить, чтобы получить информацию, которую вы предоставляете, тем меньше влияние вы оказываете, потому что вы дали им слишком много вариантов. Решения. Сделай один. Кроме того, как напомнил мне Андреа, спамеры делают идентичный контент в нескольких местах. Google понизит рейтинг вашего сайта, если вы сделаете это (это не влияет на категории, теги и архивы из-за использования канонических ссылок).

Теперь один пользователь сказал, что ему нужно сделать это как бизнес-решение, потому что каждый из его (сопоставленных) доменов был отдельным брендом. Но отдельные бренды поделились данными. Так что ... на самом деле они не отдельные, а дети. Мне? Я хотел бы, чтобы все связывало общие данные с главным брендом. McDonalds может создать суб-бренд happymeal.com (они это сделали!) И создать отдельный сайт, но если вы нажмете на ссылку «Конфиденциальность», вы вернетесь на macdonalds.com! Зачем? Потому что родительский бренд - это то, где этот материал принадлежит.

BuddyPress Разделение

Это снова приходит от Андреа. Если вам нужно иметь полностью отдельные установки BuddyPress, используйте отдельные установки полностью. Просто ... знаешь, ты можешь сделать это другими способами, но это того не стоит.

Что-то еще?

Этот список можно продолжать и продолжать, поэтому прыгните и расскажите мне свои причины, почему вы никогда не используете MultiSite!

Похожие

Комментарии