Duplicate module

You could mimic the same behavior using Rules, but I'm not aware of any other module that implements this simple functionality without any custom configuration.

So I'll guess that the answer is no :)

I've used http://drupal.org/project/cck_redirection for something like this before now.
Not to prevent access to hidden nodes, but to make placeholder nodes that do something else.

Based on #2 I guess that Field Redirection is a close call.

However, it seems that the only purpose of that module is to handle redirects. And since it's based on another field, you will have to add additional field modules that supports that formatter, actually add an extra field and configure it's display settings to make sure that the field actually does what it supposed to.

In my opinion, that is a bad approach since it overcomplicates things and requires more configuration from the user. And the redirect options isn't really a field that's displayed to the user, that's why it's better to add this as a setting to the content type/node.

I no longer find using CCK to add a field and set its display handler overcomplicated. :-B
When evaluating modules, I highly prefer modern ones that build upon the CCK-style field mechanism for data storage rather than the Drupal 4&5 style way of taking care of their own database tables (or even the Drupal 3 modules that used to alter core database tables to add their own stuff!!)

I don't know what method this module uses, but a module that uses or re-purposes CCK fields gets a lot of free wins, like views integration (for VBO or status reports) or permission control per field, or working with editable_fields, or data import/export, or availability to rules etc etc - so it's usually a sign of good future-proof design. It's worth giving this general approach a chance.

Anyway. As noted, the other ones don't seem to (yet) allow the exact behavior to be chosen by editors per-node, so that's a good feature from the module here.

I'm also of the opinion that it's almost always the best approach to build new features/modules using the Field API, default Rules, Views etc, since they integrate well with existing modules.

However, this module isn't about storing values that are interesting for a visitor. This is only about a small configuration per node. In my world, a field is something that's displayed, and will store information that's relevant for the visitor. Since this is used only by the back-end, I'm not planning on changing the approach.

However, a future integration with Rules and/or Views is possible, I just can't see any scenario where that's really needed.

This module seems to duplicate Internal Nodes.

Is there any other module that does something simular?

With "Page Manager" (from ctools) you could accomplish something like that, I think.

See for example:
https://www.lullabot.com/articles/module-monday-rabbit-hole#comment-9639

Probably yes, but we have Drupal 6 version! :)

Looks like mikeker has a match in #6.

This module could differentiate itself from the latter by also offering the functionality in this ticket: #1529130: Same functionality for taxonomy vocabs

Wowza. The UI is almost exactly the same!
Two differences (last item in UI):

1. Internal Nodes offers toggling "per node" functionality.
2. Rabbit Hole offers several options for 300 redirect codes.

This first one is a larger issue in my opinion though as it allows reducing data.
More about data bloat here: #1537646: Reduce/remove per-node data cruft

At this moment I'm working on #1529130: Same functionality for taxonomy vocabs which would make the two modules somewhat different. However, a merge is a good idea if the developer of Internal Nodes has a roadmap similar to mine.

An interesting idea would be to expand this functionality to cover entities in general. I'm not sure that there's a good use case for that though.

The module has just been updated to support taxonomy terms, and has been rebuilt to more easily support other entities in the future.

The maintainer for Internal Nodes has been contacted regarding a co-maintainership.

I'll be closing this issue, since the original question somewhat has been answered =). Feel free to open it again if anyone else has any thoughts.

Another module you could check is Node aspect pages. (A more generic "entityaspect" is in the pipeline)

A main difference is that nodeaspect/entityaspect has no UI, and you need a custom module to do anything with it.
Yet, it is quite a powerful beast.

I could imagine modules like "Rabbit hole" to use "entityaspect" as an API. If we want this, then let's open up a new issue.

There is also Restrict Node Page View.

I am the creator of Internal Nodes. We should figure out a method to merge all this functionality.

Also, just found http://drupal.org/project/page_manager_redirect which is same same, but different.

I'm not that keen to merge the two modules, since Rabbit Hole now provides this functionality for various entities.

And since I want to keep this module as simple as possible, the additional features that are provided by Internal Nodes, is not something that I'd like to integrate into Rabbit Hole.

.02: I hope you two can find a way to consolidate these two modules :)

Multiple modules that are almost exactly the same just confuse people who are new to Drupal. Plus, having two maintainers means more progress gets made on the project, and that there will be less work for both of you! (That's why we use Drupal, after all!)

+1 for collaboration. :)

As said in my previous comment, the modules aren't that similar anymore, because Rabbit Hole has the ability to cover any entity using submodules.

Therefore, I won't initiate a merge, and will continue to develop Rabbit Hole.

Duplicate modules are bad for the Drupal community. Would you please reconsider?

For me personally, the usefulness of Rabbit Hole providing this functionality to all entities rather than just nodes means it kind of kills Internal Nodes.

Just my thoughts.

I would accept a co-maintainer to speed up the maintenance etc, but I'm not keen to take the time to initiate a merge between the modules. I'd imagine that the code is a lot different since Rabbit Hole is built by a core module and sub modules.

Some of the functionality from Internal Nodes would be nice to have though, such as a an optional status message, which has been requested here as well.

But I'm afraid that a merge won't happen. I can't see how that would help the community. It would only mean that existing issues for Rabbit Hole would be postponed in order to complete the merge.

To echo jenlampton in #17, duplication is wasted effort and causes confusion. However a lot has changed with Rabbit Hole since my comment in #6. The structure of RH, with submodules extending the main API and coverage of entities, now makes it much more flexible. Internal Nodes does not allow you to have an internal taxonomy vocabulary, for example.

eosrei, would you be interested in co-maintaining Rabbit Hole, as ojohansson offered, to help bring some of the functionality of Internal Nodes -- such as to Rabbit Hole?

Internal Nodes definitely has the better module name. :) Perhaps relocating the project to "Internal Entities" to better describe what it does?

Just my $.02 worth... I only wish I'd found this module before I wrote a pile of custom code to do the same!

To echo jenlampton in #17, duplication is wasted effort and causes confusion. However a lot has changed with Rabbit Hole since my comment in #6. The structure of RH, with submodules extending the main API and coverage of entities, now makes it much more flexible. Internal Nodes does not allow you to have an internal taxonomy vocabulary, for example.

eosrei, would you be interested in co-maintaining Rabbit Hole, as ojohansson offered, to help bring some of the functionality of Internal Nodes -- such as to Rabbit Hole?

Internal Nodes definitely has the better module name. :) Perhaps relocating the project to "Internal Entities" to better describe what it does?

Just my $.02 worth... I only wish I'd found this module before I wrote a pile of custom code to do the same!

Regardless of what happens, my thanks to eosrei and ojohansson for your work.

I'm the author of https://drupal.org/project/denynodenidpath . My module is a lot more limited than this one. I'm thinking about writing an upgrade path to this module.

Would you be interested in adding the update patch if I supply it?

Absolutely!

Closing this since there has been no activity for a couple of years.