Show the node teasers even if the user doesn't have the permission to access the node

Bump!

I know its been over a year, but now how can I do this for version 6.x?

Basically, I need to display the teaser template: node--teaser.tpl.php

The only way I can display it is by giving everyone access. Although I could redirect non-subscribed users to drupal_goto('/user/login',NULL,NULL,301); I want to instead utalize LogintoBoggan and redirect a user right back to the node after they log in.

So the best solution is for Content Access to just let me show teasers to anonymous users, but the actual content is not shown..

I'd like this, too. Especially within the search results page, since we need to encourage potential members to sign up to get access to protected content.

Subscribing. We'd like to show the menu links and teasers for member only content, but present a login/signup screen when they click on them. Basically to show non-members what they are missing.

looking for same

The case of the node teasers shown in the front page could make sense. The problem is that Drupal doesn't have the concept of node teasers that don't allow the users to pass to the node page.
I mean that when the node teaser is shown, it is always possible to pass to the page that shows the complete node; in the case users don't have access to a specific node, they would get an access not permitted error, and this could confuse them.

I understand what you are asking for, but I am not sure it would be a good idea to implement it.

Well I got around this by creating a page in PHP format, doing a query on the node table, finding the exact nodes I wanted to use (the most recent 3 of a certain type) and then used node_load() to get the information I needed.

I am a Drupal developer, but sometimes even I need to do things the quick and dirty way :)

Can you post the quick and dirty code here as snippet ?

Found a similar thread, not sure which one is a duplicate
http://drupal.org/node/262766

Looking for this functionality as well.

What esend7881 describes in #6 is to completely bypass node access.

This is technically possible, but a module that does that is considered buggy in the Drupal universe, and it's unlikely that you can convince a node access module maintainer to put intentional bugs into his module.

Look at the Premium module.

We use the Premium module for this function. Works simply and well.

What you could do is use the CCK module to make your own content type. If you make a content-type with a Title, Summary and Body field, you emulate the standard page content-type closely enough. CCK forces you to set permissions for each field separately. Generally that's quite a drag (I tend to forget), but in your case that sounds like a solution.

Premium is still in development. It might help if it were stable.

I'm slightly bothered by the replies that Drupal doesn't do this, nodes are nodes. Clearly *users* want to do this.

I imagine I could make separate nodes with teaser text and my own more link to the main node... Might work for my small site until the premium node gets out of dev mode for drupal 6. Sigh.

I'm slightly bothered by the replies that Drupal doesn't do this, nodes are nodes. Clearly *users* want to do this.

Even more clearly, no one has wanted to do this badly enough to actually sit down and implement it (or to sponsor someone to do it, if you lack the technical ability).

You can sigh as much as you want, or you can help to get Premium into production. The latter is your way, carlwohlforth, of paying for the privilege of using Drupal and the resources of the Drupal community free of charge.

Thanks for the feedback, I get the message. Drupal is not free.

For now we uninstalled the module and removed content access permission for anonymous users. We get our teasers back on the front page for those anonymous users and they get an 'Access Denied' message and an opportunity to login when they click 'Read More'. For now we will do without allowing anonymous users to access our About Us page.

I get the message. Drupal is not free.

I think Drupal is free.
What salvis mean is that if you want something to be resolved, you should help too; if you think you need the Premium version, than you should test it, and report any problem you get.
That is true for any Drupal modules. There is not a test team behind them, and testing a module is done by the users who needs the module; the maintainers of a module can test it on their PCs, but they cannot test their module in all the existing platforms, and with all the existing browsers, and with all the database engines.

Thanks kiamlaluno. I thought salvis told me to fix it myself or hire someone to do so. Either of those actions involve cost.

I do test every module I install out of necessity. I report all issues I encounter. Often there is no reply. So I hack it or bag it. Trust me if I write any code worth sharing I will.

salvis was referring to what you wrote (Premium is still in development. It might help if it were stable); he replied saying that if you want to have the Premium version more stable, you should help to test the premium version.
His reply meant to say that you are using software released under GPL license, developed with the help of many users who are not paid for what they do; in such projects, if you want something done, you must participate more actively. I am not saying it is your case, but probably salvis had this feeling.

It has been a while since I looked at Premium and I don't know in what state it currently is. I do know that sighing will not advance it, though.

Maybe it just needs some more testing and positive feedback to convince the maintainer that it's ready for release. Maybe there's essential functionality still missing, or there are unresolved bugs. In that case, whoever has a need for it should develop patches or possibly offer some financial incentive for the maintainers or someone else to work on it. (If you look through the Premium issues queue you'll find that at some point I beat up the maintainer because that's what I felt was needed...) It depends on where a contrib stands and what is holding it up. You have to find out yourself what is needed.

Drupal is developed and maintained by volunteers. Some of us have paid jobs that allow them to devote a portion of their work hours to community work, others are enlightened freelancers who realize that they can do better work for their clients if they work with the community, still others may help just for the fun of it, etc. The common pattern is that whatever you contribute, you get back much more, but if you don't contribute anything, you shouldn't expect to get anything either.

Drupal as it is is free and everyone is welcome to use it. Obviously, at this point, the thought might already occur to you that you want to give something back, but at the latest when you need more than what is here (support, functionality, fixes, whatever), then you're expected to contribute in some way to make it happen. Nothing gets done unless someone's need for it is big enough to make it happen. Premium in its current state probably works well enough for those who are using it; if you need a release version of it, then find out what's needed to get there and do whatever it takes!

It's unfortunate if you don't get any reply. Just keep in mind that whoever might reply is taking time that they might otherwise spend with their family and friends. And they may be up to their neck in other tasks. Or they may have lost interest in the given module but they haven't felt enough pressure to look for someone else to take it over. There's the IRC channel where you can voice such issues, if really necessary. Above all, be positive, patient, and persistent. And make your posts so that they're worth replying to.

Jumping in...

No argument with the "give to get" notion that drives community software.

But there's a different elephant in the room too -- what is Drupal's place in the marketplace of content management/presentation software (CMS)? Aside from the "let's all help each other" aspect, Drupal has to compete in the big world of CMS, or it risks losing whatever momentum it has, in favor of "better" choices. Drupal could become a dead-end, as have earlier "hot" CMS platforms that had their brief day in the sun but died because they didn't "keep up".

If Drupal lacks a capability that seems basic to CMS, then in the marketplace Drupal (not a module, but Drupal itself) seems to be inadequate, insufficient, immature, unworthy. If it fails to provide key baseline functionality, instead of being on the short list of CMS to consider, Drupal can easily slide to the long list of losers.

Per this discussion, it seems that the vast, vast majority of public sites that offer "premium" content -- newspapers, magazines, professional sites, etc -- offer content in two modes: public teasers, and private/sign-in-based full content. How else would such sites show what they have and motivate visitors to join/buy/etc?

If Drupal does not -- and cannot -- do this out-of-the-box, or via a stable add-on, then Drupal is simply not useful for such sites. Sure, they can help close the gap as suggested in this thread. But why would they make a business decision to hack/develop/fund a capability for Drupal rather than choose another CMS product that already has it?

The parallel universe of Drupal-improved-for-cash (Dries company, etc) make the situation worse. That's a different Drupal, and its existence "proves" that the free, open Drupal is not for serious use.

Faced with all the evidence that free Drupal is weak (just search these forums for discussions about shortcomings ranging from premium content to comments spam to the unusual forum style to views/SQL limitations, etc) it's easy to determine that a really good Drupal system requires paying consultants/developers. Fine. Except that any business would first ask, "what else can I get for my money?" There are plenty of other CMS options where Drupal can lose by comparison.

If the explanation is that Drupal is not architected to do what is desired, such as to separately control access to node teaser and body, that just adds evidence that it is a weak, poorly-conceived platform -- even if not true, where's proof? It doesn't matter that Drupal developers are unpaid, have limited time, etc. That's an insider explanation, not a market justification, for Drupal's state of affairs. If your car doesn't run reliably, will you stop complaining if told the mechanic didn't have time to hook up all the sparkplugs?

Clearly, Drupal has some appeal (we're here, after all) but, trying to be objective, an observer might wonder, how can something as basic as separating teaser from node not have been improved in version 6 when it was a common desire in version 4? There's a Http header reset problem thread that has been going in circles for more than a year, a Drupal 5 problem that still exists in Drupal 6.15, the solution being to hack code to block the error message -- not cure the problem. And why is essential cron so unreliable? The list of such "quirks" is rather long, as is the number of contributed modules that are actually attempts to "fix" Drupal -- not indicators of a strong core.

Pretend you must sell someone on Drupal, and your customer has full access to the discussions (and frustrations expressed) on this site, AND full access to learn about any/all other CMS options. What's your pitch? Will you make the sale?

Shooting the messenger doesn't change the facts, but fire away!

Subscribed.

Merry Christmas folks! or Happy Holidays if that suits better.

hawkdrupal expressed some thoughts I have but haven't expressed. Thank you all for a stimulating discussion.

Since I am new to Drupal I will spend some time looking into how Drupal development, testing and support are organized. I will also try to pick up some history. If I can make improvements I will attempt to do so.

Thank you for your well-thought out comments, hawkdrupal!

I can't address them all, but here are some:

"Drupal-improved-for-cash (Dries company, etc)" is available for free, too, AFAIK. Dries is determined to feed any Acquia improvements back into the community, because he has realized that open-source Drupal can grow Drupal's market share much faster than Acquia Drupal can.

If you see "evidence that free Drupal is weak", then please hammer away at the weak spots in whatever way is needed (see above). As far as Premium is concerned, maybe the maintainers just need a gentle nudge...

OTOH, if this really is such an important use case, then it's hard to believe that we don't cover it adequately. Sites who are trying to make money by withholding content are unlikely to get preferred treatment when they ask for free support in an open source community. What we've been saying in the technical part of this thread is that the node access system is all or nothing, i.e. it cannot and should not be bent into offering teasers and withholding full text. I'm not aware of alternatives to Premium, but I haven't really researched the subject.

A pretty strong selling point for Drupal is that if you ever encounter a problem, you can do something about it, and you even have a chance to get your fix into the next version. It's an uphill battle, unfortunately, but it is possible.

@carlwohlforth: I'm glad we (I) haven't scared you off — welcome to the community!

*@carlwohlforth: I'm glad we (I) haven't scared you off — welcome to the community!*

Thanks! That is nice of you to say and I honestly appreciate it.

*What we've been saying in the technical part of this thread is that the node access system is all or nothing, i.e. it cannot and should not be bent into offering teasers and withholding full text.*

But offering teasers and withholding full text is exactly what happens if in the administer/user management/permissions form you check the node module 'access content' authorized users box but not the anonymous users box. Anonymous users see teasers but get the access denied message if they try to access the body. If the user logs in he can see the full content. I just wanted to continue that behavior but wanted to grant anonymous access to an 'About Us' page and couldn't figure out how to do that.

At least that is what happens to me. (DietInn.com)

Turns out the easiest solution for my particular situation is to add about us information to the contact us page which can be accessed by anonymous users.

WHAT??? Anonymous users see teasers even when they don't have the access content permission?

That is not 'normal' behavior. What have you set for Default Front Page on admin/settings/site-information? When I have this set to 'node' and I remove the access content permission from the anonymous user role, and I log out, then I get an 'Access Denied' message on the front page (where teasers would be displayed).

You must be using some contrib module that makes those teasers available (an alternative to Premium?), but Drupal core is not supposed to work that way!

Default front page: frontpage

I'm using Drupal 6.13, Acquia Marina theme, login toboggan, pathauto, admin menu, advanced forums and many, many more. The behavior I see now is the behavior I've seen ever since I started working on permissions and access control which was after installing several modules. I haven't knowingly installed anything to produce this behavior because it has worked as expected for me.

I guess I should do a fresh install somewhere else to see how that goes...

My site: Diet Inn

"frontpage" is not part of Drupal core. Look through your source code to find the module that defines the menu menu item with that path.

Got it. That took a while, I was basically rebuilding my website from scratch...

Anyway I installed a bunch of modules before I figured out what causes the behavior I have. I can try tomorrow to reduce it to just the two I think are involved: views and nodequeue.

I add pages with teasers to a nodequeue I created so I could order them. Then I edited an existing view named 'frontpage' to use the nodequeue I created. Then I edited admin/site/info to Default front page: frontpage.

Now anonymous users see teasers at the home of my website and when I click 'read more' they are asked to log in.

test site

Then I edited an existing view named 'frontpage' to use the nodequeue I created.

The module that creates views is Views. The view frontpage doesn't allow the anonymous users to see the front page, if they don't have access to the content, anyway.

Indeed, I had an idea in the back of my head that Views allowed bypassing node access (or in this case even the missing access content permission), but I wasn't able to find the setting that would do this. You can define the visibility of the view itself, but in my test this didn't make nodes (or parts of nodes) visible if they weren't visible otherwise...

Maybe Nodequeue does this for Views?

Behavior confirmed with only Drupal, Views and NodeQueue, see simplest test case linked below. Actually I like it this way and will probably add my blog entries to a nodequeue so I can get teasers of them in a front page block for my anonymous visitors. :)

Drupal Views NodeQueue only

@carlwohlforth - this is a very good "tip"/"snippet of action"/whatever - thanks to you, for this will save many hours of fiddling for those who want this behavior. May be we can note down the version numbers so that we may keep on using them or refer to those when needed.
Your test server shows this behavior superbly and the server is very very fast ( is it ded? and hosted where?)

A very helpful and very working solution provided by you - if you do get some spare time do consider writing a bookpage on this.

Very nice — so we do have at least one working solution without node access and Premium!

Let's leave this thread active here under Content Access, even though the solution does not involve CA. People may well come here looking for a solution.

A handbook page would be great, too, as kaakuu suggested. I'd suggest adding it as a child to http://drupal.org/handbook/site-recipes and adding a link to the new page at the bottom of http://drupal.org/node/206719 or maybe even to http://drupal.org/node/257 ('Working with premium content').

Other good places for links: http://drupal.org/node/306808 and http://drupal.org/node/206766.

My solution was even simpler, using only Contemplate. :)

In node body I check for user role, and if not the desired role, then show them the teaser. Voila.

No premium, no ACLs nothing. What a relief :)

@giorgio79: Ah, great, more options to document on the new handbook page!

* In node body I check for user role, and if not the desired role, then show them the teaser. Voila. *

Pretty easy if you know php and are willing to add it to every node. Works great when only protecting a few nodes! I will certainly add that suggestion to the handbook page I'm volunteering to write.

Actually I was not trying to solve this problem, I was trying to put my front page items in a particular order. So for me I needed nodequeue anyway.

Thanks for the pointers salvis. I'll see if I can add a handbook page, I haven't done that before. It will take me at least a day or three due to other pressures.

@kaakuu, thanks for the kind words. I'd send you a private message regarding web hosting but haven't figured out how to do that. I did add an affiliate link to my host on my test site.

http://drupal.org/project/pcapbt seems to be yet another approach (although it's only for D5 and doesn't seem to offer free teasers yet), and its front page lists a few more.

@carlwohlforth: You don't need to write a comprehensive study or survey (unless you want to). It'd be nice if you could start a list of the various solutions and describe at least yours in some more details (how to set it up and what its advantages / side-benefits are). If you provide some good structure, then others will be able to fill in any missing pieces as well as more solutions. Many documentation pages are works in progress with contributions by multiple people — the most important part is to get started with some good structure.

Thanks in advance!

OK I've added my first recipe: Show node teasers even when the user doesn't have node access permission http://drupal.org/node/677644

carlwohlforth #38

That's a very excellent write-up. You are a documentation genius :)
Thanks - it will help many of us.

Hi Everyone, well I have one question for any of you who can (PLEASE DO) surprise me with a way of doing this:
I need the content to be searchable. I have a tons of private article I sell, but I need people to be able to find them. Any thoughts? I haven't been able to do it!

Thanks for all the help you gave already!

Hi PPL

I have yet another oslution to the problem

I called it PHP SOLUTION 2 in this book http://drupal.org/node/677644

Nice. Please do mention that the bodies will be indexed ('update index') but not shown ('view').

What do they look like in the search results ('search result')?

subscribe

@salvis

I'll update the book with the Index information.

Abou the Search results:
By default it show a small snippet of where the keyword you searched for was found. Anywhere in the Body. This can be changed using template_preprocess_search_result() and search-result.tpl.php.

Check the book for more info (http://drupal.org/node/677644)

Federico

@jm.federico: Thanks! Please add that to the documentation, too. It's important to realize that Search may be another consideration in this picture.

If you can see a snippet with some text before and some after what you found, a determined snooper can recover the entire message by searching repeatedly...

Salvis,

The Premium module bypasses node access.

Hmm, it has been quite a while since I looked at Premium and I don't remember exactly how it works.

Generally, no module should bypass node access, but if a module allows the administrator to give access on a node by node basis, this could be acceptable, if it's declared openly. In D7, there are new hooks to allow any module to provide access to any node within the node access framework, but bypassing the node access table.

Ideally, Premium should offer both ways, as does Views. If Premium's behavior causes you problems, then by all means open a bug report against it.

I should clarify. Basically it bypasses node access by providing its own access check, like PHP Solution #2 at http://drupal.org/node/677644. If the role has no access to the content type (like via this Content Access module), it doesn't work, so in that way it doesn't bypass security (i.e., provide access to something restricted). One has to set the content type to viewable by the "non-privileged" role then Premium takes over.

very interesting discussion everybody ! Thank you !

I seek another kind of solution -
We have a certain content type that the site owner doesn't want to display in full nodes and/or teasers, but would like to display the full body and other cck-fields using Views (without linking back to nodes, of course).

Example: say you have a catalog of elements (one element per node) while grouping a few elements together (in a view), makes them usable and it makes no sense to display separate elements.
Moreover, an element may participate in more than one group.

The views are built and function properly, but when we added "Content Access" to deny access to nodes of that content type, they disappeared from the views.

Any idea to solve this? Nodequeue is not a good solution here. It will be too cumbersome to add each and every element to many different queues, while regular Views-filtering works perfectly for us.

Cheers !!

Maruan, is this only for certain users or for everybody? In the latter case, CCK itself has a solution. On the content type edit page there are tabs for both editing and displaying fields. The display tab will let you switch off fields from being displayed in the full node.

Can I suggest the use of cck redirection? Do not deny access to the node, instead redirect users to a view or something.

http://drupal.org/project/cck_redirection

thanks guys !

@brankoc -
Those fields are everything. There is nothing else within the nodes. Thanks for the idea. Haven't thought about it. I'm afraid, however, that it'll solve one issue and create another one - leaving many searchable accessible meaningless (titles only) nodes.

@jm.federico -
Thanks. I didn't know of this module. It could be perfect if I could automate it. I need it to be simpler for the site-owner. They (a married couple) don't even understand how it works. They fill in the data, along with filtering information (serial numbers, locations, codes, etc.) and everything falls into place. Having them use another field to redirect the node's visitor to a final view's page is impossible. Moreover, a node may appear in different views - which one of them to redirect to? If we try to solve the last by redirect all nodes to homepage, I think it'll be an SEO disaster, won't it?

Thanks again for sharing your ideas. I'm sure we're getting closer.

@maruan

Please open a new issue, I'll help you there, we are hijacking this one which has a different purpose.

@everyone else

I'm marking this as closed as it is not an issue for this module anymore.

For the late comers if you didn't read the whole thing, go to http://drupal.org/node/677644.
There are some solutions and tips on how to accomplish it.

Just checking out the issue queue for this module, and this caught my eye. You can implement this functionality in D7 using my module Internal Nodes. Set the nodes you don't want accessible to be internal(301/302/404), and create a view to display the teasers.