Как скрыть узлы, к которым нет прямого доступа от пользователей и поисковых систем?

Я обнаружил, что иногда у меня есть узел, который просто содержит контент, который будет отображаться где-то еще, но не должен просматриваться напрямую. То есть никто не должен когда-либо заходить в узел / 1234, но контент в узле 1234 должен отображаться где-то еще. Например, я создаю страницу с информацией о вкладках, используя представления. Итак, есть страницы «О себе», «О нас» и «О них». Все они отображаются на одной странице с вкладками с использованием представлений. Поэтому я не хочу, чтобы люди попадали прямо в узел «О нас», потому что тогда они не увидели бы вкладки для других страниц. В то же время я не хочу, чтобы Google давал людям прямую ссылку на этот узел, я хочу ограничить доступ, чтобы пользователи могли получать к нему доступ только через представление (т. Е. Вкладку).

Поэтому мне нужно ограничить доступ к узлу, удалить его из результатов поиска Drupal и убедиться, что Google его не обнаружит. Какие-либо предложения?

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

Модуль Rabbit Hole предоставляет эту функцию.

Rabbit Hole - это модуль, который добавляет возможность контролировать, что должно происходить, когда объект просматривается на его собственной странице.

Возможно, у вас есть тип контента, который никогда не должен отображаться на отдельной странице, например, тип контента изображения, который отображается в карусели. Кроличья нора может помешать этому узлу быть доступным на своей странице через узел / xxx.

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

Другое решение заключается в использовании hook_nodeapi('view')/ hook_node_view()реализации для выдачи drupal_goto()или drupal_access_denied()когда страница узла посещается неавторизованным пользователем. Помните, что hook_nodeapi()/ hook_node_view()используются во многих случаях, а не только при просмотре страницы узла.

hook_menu_alter()также может использоваться для изменения обратного вызова доступа к страницам узлов, чтобы запретить доступ к скрытым узлам.

Лучше всего, вероятно, не основывать фильтрацию на жестко закодированном идентификаторе узла, а использовать либо настраиваемое поле на узле (используя CCK / Field API или пользовательскую таблицу), либо список скрытых узлов, хранящихся в переменной .

Для Drupal 7 Rabbit Hole предоставляет эту функцию.

Rabbit Hole - это модуль, который добавляет возможность контролировать, что должно происходить, когда объект просматривается на его собственной странице.

Это работает путем предоставления нескольких опций для управления тем, что должно происходить, когда объект просматривается на его собственной странице. У вас есть возможность

1. Доставить доступ к запрещенной странице.

2. Доставить страницу не найдена.

3. Создать страницу перенаправления на любой путь или внешний URL-адрес.

4. Или просто отобразить сущность (обычное поведение).

Как :

Включить подмодуль узлов Rabbit Hole. Затем мы получим раздел конфигурации, связанный с каждой формой в Drupal CODE.

Решаемые. Сначала я попробовал ответить Пьера Байля, но если вы отмените публикацию узла, доступ к нему будет невозможен, и эти узлы станут бесполезными. В моем случае у меня есть родительские и дочерние узлы, только дочерние узлы (для целей администратора) должны быть скрытыми и НЕ индексироваться сканерами. То, что я сделал с помощью менеджера страниц, сделало переадресацию URL (скрывая эти узлы для всех пользователей, кроме администратора) с ответом http в соответствии с этим руководством http://www.wunderkraut.com/ 1, и узлы без индекса, обработанные сканерами, обрабатываются по Node безиндексный модуль . Это будет работать, даже если у вас нет отношений между узлами paret и child. Ссылка на учебник:

В Drupal 7 также должно быть возможно использовать hook_node_access () , это обычный хук в D7, который может быть реализован всеми модулями для всех типов узлов. Затем вы можете запретить доступ, если пользователь пытается просмотреть узел на своем собственном узле / nid.

Вам, вероятно, также необходимо реализовать hook_query_node_access_alter () и добавить туда проверку, чтобы скрыть узел в результатах поиска. Этого даже может быть достаточно, и вам не нужен hook_node_access (). И это может даже работать в D6, потому что вы также можете изменить запрос, но в D7 это намного проще из-за построителя запросов.

Просто установите этот узел как «неопубликованный», затем в представлении добавьте фильтр «опубликованный узел: нет».

Как следует из заметки, хорошей практикой является создание пользовательского типа контента для этих «призрачных» узлов и указание pathauto давать им конкретные URL-адреса (я использую /dev/null/[title-raw];): даже если узел не опубликован, у него будет свой собственный псевдоним URL, так что в вашем примере, если вы создадите сначала призрачный узел «о нас», а затем просмотрите страницу «о нас», второй URL-адрес будет example.com/about-us-0becose example.com/about-usвзят из призрачного (однако вы можете установить пути вручную)

Вы можете использовать любой вид системы доступа к узлам и использовать views3. Там вы не можете отключить перезапись sql в настройках запроса, поэтому вы можете отключить систему доступа к узлам в этом представлении.

Вы можете сделать с помощью модулей правил.
+ Создать новое правило с событием «Контент просматривается».
+ Добавьте пару условий, например: у пользователя есть роль (и): анонимный, у пути есть псевдоним URL: узел / xyz (это узел, который вы хотите ограничить для анонимного пользователя). Не забудьте добавить «и» или «или» условие, если это необходимо.
+ Создать действие для перенаправления на другую страницу или сделать что-то еще. Это пример кода, который я экспортировал для вас

{ "rules_limit_viewing_some_nodes" : {
  "LABEL" : "Limit viewing some nodes",
  "PLUGIN" : "reaction rule",
  "REQUIRES" : [ "rules", "path" ],
  "ON" : [ "node_view" ],
  "IF" : [
     { "user_has_role" : {
       "account" : [ "site:current-user" ],
       "roles" : { "value" : { "1" : "1" } }
      }
     },
     { "AND" : [] },
     { "path_has_alias" : { "source" : "node\/28" } }
   ],
   "DO" : [ { "redirect" : { "url" : "error" } } ]
 }
}

Я думаю, что самый простой способ выполнить то, что вы хотите, это использовать менеджер страниц (Ctools), он действительно прост в использовании, все, что вам нужно сделать, это указать, какой узел перенаправить куда (в данном случае, с одного узла на другой)

Модуль Content Access идеально подойдет для ваших требований.

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

Он также имеет хорошую документацию, чтобы помочь вам начать.

Если «включено содержание» узлы должны оставаться недоступными, затем заблокируйте / узел / * на веб - сервер «местоположение = / узел / *» уровень . По умолчанию запрещен доступ ко всем / узлам. По умолчанию разрешен доступ к узлам, которые получили автоматический путь path, например / pages.

(Базовый пароль .htaccess для подкаталогов - это также неплохой способ блокировки случайной индексации поиска внешними сканерами.)

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

Это то, для чего нужны узлы.

Важна ли для вас конфиденциальность вашего «включенного контента»? Если так, то ...

1. Все, что имеет URL-адрес, в конечном итоге будет поражено Google.

   Потому что поисковые системы не полагаются только на пауков. Они также оценивают отзывы браузера и т. Д. Никакой модуль robot.txt или pathauto, globalredirect, rabbithole не поможет вам спать спокойно. Если к узлу можно получить доступ, он будет проиндексирован. Возможно вашим собственным браузером / аддонами.

2. Пересмотреть, должен ли «контент, который должен быть включен» действительно быть узлом , если никто не должен обращаться к нему как к странице ?

   Если ваш «включенный контент» будет храниться внутри мини-панели / block / snippet / bean / ..., то вы рискуете его когда-либо перечислить, или он появится как страница с автоматическим URL, который вы не знаю , о , пока. (обзорные страницы таксономии, поиск, просмотры ...)

Модуль « Ограничить просмотр страницы узла » делает именно то, что вам нужно.

Из описания модуля:

Вы когда-нибудь использовали тип узла слайд-шоу, который нужно опубликовать, но не хотите, чтобы узел был доступен сам по себе, используя путь узла / XXX? Этот модуль для вас!

С помощью этого модуля вы можете ограничить доступ к fullрежиму просмотра узла , поэтому вы не можете получить доступ к узлу node/XXX.