The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.I have a Drupal system that handles multiple magazines, some with overlapping content, so Domain Access is starting to be a huge help.
But... DA control is only at the node level -- show it, or not. So I'm having to build all kinds of semi-duplicate views and steer users to the appropriate view/page based on current role -- very kludgy.
The need is to show only the node/article title (and related such as header/deckhead and blurb/summary/teaser) to a non-subscriber. But to a subscriber (signed-in and assigned to a role that represents having a subscription to the publication, further controlled by Ubercart), the complete article is visible. I've found many, many requests for this type of functionality, but no practical solution.
The kludge, still be devised, is to show the title/teaser of every appropriate article/node to everyone on the publication's main page. On this view there are no links to the underlying nodes. A separate view/page is available to subscribers (having correct role) and it shows the title/teaser but this time with live links. The idea is that non-subscribers (don't have correct role) don't get links because they can't access the nodes anyway (avoid a blank/error page). But it's tricky to get the dual views working/maintained for many publications, and to assure that visitors are looking at the right view. It's frustrating for a sign-in subscriber to be viewing the non-subscriber list of articles and not be able to click anything.
What would be a giant leap forward is to meet this Drupal need (I see many requests for this functinality) via Domain Access. Extend it to control not just whether a node is accessible, but WHICH piece of a node's content to display -- the teaser, or the body -- based on the Domain AND the user's role.
See the Premium content module for a promising but abandoned attempt at this. This module was too crude, a simple node on/off switch, so couldn't handle multiple roles/publications/situations. But the basic idea is good.
The needed functionality is this: The node can always be displayed, typically title (and some extra fields typical of a magazine such as header, deckhead, byline, blurb/summary). But only a signed-in user WITH a proper role can see the complete node fields/body. All other users see the title, etc so they can know what the article is about, but instead of the body they see a message stating that a subscription/membership/authorization or whatever is required (configurable wording).
Again, the Premium module has roughly the right outcome but insufficient control. Domain Access would be perfect if it gained a sub-module that controlled the node at the content level.
Comments
Comment #1
hawkdrupal commentedSorry about some typos in original message, wish it could be edited.
But I forgot to mention another major -- HUGE -- benefit of being able to control what a node displays, not just whether it is visible or hidden.
The benefit is SEARCH ENGINES.
If a node is 100% hidden, viewable only by signed-in users, then it is hidden from search engines. Therefore the node can't be indexed.
However, what if a node is 90% hidden from non-subscriber/role/member visitors, but 10% is visible to everyone. The 10% visible part would be (in magazine terms) the header/section, title, deck, byline and blurb/summary/teaser. If these are well-worded, there is plenty for a search engine to index and later searchers to find. Thus new users be be drawn to the site/publication and motivated by the visible, interesting 10% of each node's content to sign-up/subscriber/whatever.
There is no way to do this otherwise, except by tricks such as allowing known search bots to see nodes that are otherwise hidden, but this violates Google and other search engine policies so is risky -- very risky given how difficult it is to get unblocked. AND it's trivial for many users to visit a site while masquerading as a search engine, or to send their own spider doing the same, so the content isn't really locked up at all.
The safest way to control content access is internally via Drupal roles (and/or Domain Access, though it should ideally be tied to roles), but for any site that is for public consumption, this requires content-level control, not just node-level on/off.
Am I overstating my case?
Comment #2
agentrickardNow is not the time for new features.
We have been in RC for months, now.
Now is the time to fix this list --> #512770: Stable release tasks for 6.x.2.0
I appreciate that you are new to the module and very excited, but there is a history here, and many features may already be available. Did you try CCK's field access settings? (In D5 that may be a separate module.)
Even so, what you describe can be done with an extension module, and the core module has enough code in it that makes it difficult to maintain. The D5 branch especially is feature-frozen. And the D6 branch will be shortly.
Comment #3
hawkdrupal commentedWell, thanks for listening.
We're not moving to Drupal 6 because it's way too much work for too little benefit on the business side, which overrides contemplation of the technical improvements. And there are many modules/capabilities in Drupal 5 that aren't ported to Drupal 6 and probably won't be.
This "frozen at a version" situation is very common in application platforms, where once a certain level of features and stability is reached, it becomes "good enough". Check the history of FoxPro or Lotus Notes or Microsoft Access or Visual Basic or many other appdev platforms to see that they peaked mid-life -- often at version 5.
I'm hoping that Drupal 7 is somehow worth a rebuild, but the key will be sufficient modules/functionality or there will be no chance for mass upgrading.
I think it's worthwhile to keep suggesting features/enhancements because from a business perspective better capabilities drives things, not technical evolution. Just reality...
Maybe Domain Access isn't the place for my suggestion, though intra-content access control needs to be directly tied to something similar, somehow. Sorry to bother you.
Comment #4
agentrickardIt's not a bother, it's just a little frustrating because I have limited resources. Feature freeze is the only way to cope.
What you propose is possible, and the CCK and DA APIs make it achievable in D5, but you'd have to find someone else to code it as a standalone module.
DA itself has enough features that it can be very daunting to maintain, and even harder to explain to new users.
Comment #5
smscotten commentedThis would be a great feature. REALLY great. Personally I don't care about the 5.x branch, but this is the reason I investigated Domain Access in the first place.
I'm willing to write code, but this is a sort of complex set of modules. Anyone want to tell me where to get started with it?
Comment #6
agentrickardYou would need to investigate hook_domainrecords() or hook_domaingrants() -- probably the latter -- to adjust how permissions are handled, and then use hook_nodeapi() to appropriately truncate the node output.
Comment #7
smscotten commentedThanks!
I'm having second thoughts about this now. There may be a simpler, already built way to (mostly) get what I want.
Using Domain Source, if I select one domain to "publish to" but choose "send to all affiliates", the teasers will show up on all domains but all those teasers will link to the source domain.
There are two things that make this existing solution fall short of what the OP asked for. First, that the pages themselves will appear on all the domains if you browse to their URL directly. There is already a feature request in the queue for Domain Redirect, so I won't concern myself with that here.
Also, this doesn't give fine-grained control over users and roles' access to different nodes on different domains. The OP's use-case might necessitate control over access by role AND domain, but I'm happy with control over access by domain and access by role being separate.
There are other approaches for showing teasers while hiding the actual node: http://drupal.org/node/677644 . The OP from this thread said that the Premium module didn't meet his needs, but the Views-based solution listed there sounds much more powerful.
I'm setting the status to "postponed" which is what it was before I jumped in.
Comment #8
agentrickard