Hey Allie, et al,

A client of mine was looking for node by node role based access like control. Premium sounded at first like what we wanted; but, unless i am confused i think it only replaces $node->body with custom message. Not quite what we needed; but your module certainly provides the groundwork for what we are trying to put together. Here are a few "enhancements" i have either already done or will be doing in next couple days. Just wanted to see if any interest in any of them to be provided as patches for Premium.

Not exactly in priority order, but close:

- do actual node access control - i.e. non-premium can see teasers but not allowed access to full node [done]
- make this an admin configurable option [done]
- hide cck fields as well as body in both teaser and full node views [done]
- support multiple roles [likely next]
- support different mesage for each premium role [next next]
- select which cck fields to hide [right now i simply hard code which not to hide for my client's specific requirements - but making this configurable might be nice; just not sure he'll fund it]

I think we had a couple others.. but thats going to be a pretty good start for his project.

Any interest in patches for any of these?

Anyone have any interest in this as a new module if Allie doesn't want to patch Premium?

Members fund testing for the Drupal project. Drupal Association Learn more


liquidcms’s picture

Title: addig new features to Premium - any interest? » adding new features to Premium - any interest?
liquidcms’s picture


- do actual node access control - i.e. non-premium can see teasers but not allowed access to full node [done]
- make this an admin configurable option [done]
- hide cck fields as well as body in both teaser and full node views [done]
- support multiple roles [done]

- support different mesage for each premium role [next]
- select which cck fields to hide [right now i simply hard code which not to hide for my client's specific requirements - but making this configurable might be nice; just not sure he'll fund it] - likely easy enough to throw in; but wondering best place for UI

liquidcms’s picture

- do actual node access control - i.e. non-premium can see teasers but not allowed access to full node [done]
- make this an admin configurable option [done]
- hide cck fields as well as body in both teaser and full node views [done]
- support multiple roles [done]
- support different message for each premium role [done]

just debating now if i should do the bit to select fields to show??

will add patch for changes to this point in a a bit.

liquidcms’s picture

Title: adding new features to Premium - any interest? » full node access control, hide cck fields, multiple roles and msg per role
Status: Active » Needs review
7.48 KB

here ya go... pretty cool addition to this module i think and likely closes a few of the requests in the issue queue

liquidcms’s picture

also, correction to my original post which i stumbled upon while adding new features..

i said:

replaces $node->body with custom message

when in fact: it replaces $node->body with $node->teaser + custom message.

this functionality is untouched in my patch.

heyyo’s picture

I tried your patch, but it doesn't seem to work for me...
Before I applied the patch, the body of my nodes were only visible to premium. But now everything is visible to anyone.
I wanted to apply to patch to give access to full node only to premium members. I tried the option in the admin panel of premium:

Access Control:
Select this to prevent access to full node if user not in premium role

But it doesn't have any effect.

I tried to disabled the module, remove it and reinstall. I have the same behavior, premium doesn't have any action.

My full settings in premium admin panel:

Node Types :
x Besoin
x Offre

Access Control:
x Select this to prevent access to full node if user not in premium role

Mode :
x Premium items are permanently restricted
Protect archives only: Items switch to premium status after a specified period
Protect latest content only: Items switch to non-premium status after a specified period
Décompte :
Unit :

Bulk update premium status
x Update all existing nodes of the types selected above with the new premium settings.
Premium body text for role: utilisateur identifié :

Full text available to premium subscribers only belonging to the utilisateur identifié rôle
When a visitor doesn't have access to a premium item they will see this message instead of its full text

heyyo’s picture

I finally found my problem, i removed the status premium on all my nodes, and reset it.
Thanks for your work, works great.

Just maybe fix the uninstall process, because it doesn't remove everything form the module premium. uninstall/Reinstall should have fixe my bug...

heyyo’s picture

After playing with your patch, I think something is missing or maybe I don't understand how to deal with it.

On my website, I have users with special role to publish nodes of a special content type.

I enabled premium access to this content type (in premium admin menu or in the content type itself, seems to be the same). But as soon as users with this role create content, this content is not accessible at all, except for admin.
If the admin set the premium access to this role by editing the node, the premium access works correctly according to permissions.

How to enable that setting automatically ?

liquidcms’s picture

not sure why we can set premium for node type in 2 different places (i'd get rid of the one on premium config form) - but i did verify they are at least the same variable.

and, yes, i can confirm there seems to be a bug as you say. this was my test, just to confirm

- peter is in role assoc
- role assoc has access to premium content set (i think all this does is enable ability on admin form to have custom message and has it show as a selectable role under publishing options for node)
- peter adds a node
- after node submit i am not allowed access to node (actually i don't have full node restrict set so i just see message as opposed to no access at all)
- as peter i edit and re-submit (no impact)
- admin edits node and simply re-submits (here i could see default under publishing options set as )
- peter now has access

further to this i can see that in the premium table the role id for a newly "peter submitted" node is 1 (anonymous) (which sounds right; but isnt working as we'd expect), and after admin resubmitts (still with access set as ) the entry in the premium table is removed (i.e. unrestricted access).

won't get to this today - but likely have it sorted out this weekend.

liquidcms’s picture

580 bytes

ok, i see the issue - Alie was supporting the idea of a default setting for the node and i don't carry that on with the multiple role option.

the attached patch seems to fix this but isn't quite the right way to do it; i'll look at the right way later this weekend.

heyyo’s picture

This patch works for me.
Thanks a lot. I will wait for your other way to fix this issue.

To answer to your question regarding admin section to choose which cck fields to hide, I think it would be a really good idea. For the moment I don't use cck on my website, but I'm sure I will need this in the futur, or on other project.

But first your patch has to be commited !!!

liquidcms’s picture

i think support for this module has been dropped as i have had no response from maintainer about my patch. So not sure how likely getting patch committed will be.

cyrildruesne’s picture

When I try to patch with premium-new_features1.patch, I have this message, with no more details :

"patch unexpectedly ends in middle of line
patch: **** malformed patch at line 204: "

Any idea ?

Cyril Druesne.

liquidcms’s picture

sorry.. no idea.. patch works for myself and others. took a quick look at line 204 and it looks fine.

drupizzle’s picture

I got the error for line 204 as well. Using cygwin to apply the patch. Please advise

liquidcms’s picture

14 KB

does this help?

no longer here 690904’s picture

First of all many thanks for the additional features! Especially the hiding of the CCK fields is really usefull.
One question came up, when I tried out yout patch:
Everytime I change something in the 'premium' settings, all of my nodes switch back to in the new listbox on the node editing site. So basically even if I set the premium status for all nodes in the premium settings and also the content type settings, all my exisiting nodes just switch back to being not restricted and I would have to set them all manually again. Maybe this has something todo with the new feature for multiple roles. Or do I just miss something here and have wrong configuration?

hawkdrupal’s picture

TO: liquidcms

Your mods are a HUGE improvement in Drupal. There are many, MANY postings wishing for the capabilities you have implemented. For a debatable social reason ("content should be free", "premium content" is a capitalist notion) as argued in other threads, Drupal has not provided a way to do what many sites need: present teasers to all while controlling full text access via roles -- exactly what you've done. You are closing this massive hole that has caused Drupal to compare poorly to more well-rounded content management systems.

Your module should become a separate project, not tied to Premium, which seems to be abandoned (no finished Drupal 6 version after all this time). Spinning off has been the origin of many excellent modules over the years, based on earlier incomplete/abandoned works.

As a separate module you can tweak, enhance and evolve without any regard to the state or fate or the Premium module.

I should mention that your "Premium Content" module seems to work to control access, but in my tests (Drupal 6.15) the custom message never appears -- an anonymous user just sees "Access Denied". I'm using the fully patched version you provided in premium.zip. I'm using it with a custom node Article (as in, magazine article), which is based on Story but with some added CCK fields.

hawkdrupal’s picture

Another wish is the ability to bulk update the value of "Access restricted to premium role" in selected nodes.

Drupal has several ways to apply bulk updates, in the basic Content system, via module Views Bulk operations, and using other add-ons.

But none of them can "see" "Access restricted to premium role". It's not a value that can be shown in a view, for instance, which is a key way to monitor and administer content.

So updating the access value is a painful 1-node-at-a-time process.

Perhaps there's a simple way to make the value of "Access restricted to premium role" visible as a normal field so the various tools and other modules can work with it?

liquidcms’s picture

thanks for the compliments and suggestions regarding my additions. The changes came about from a client's request to do what he thought the Premium module sounded like it already did. For the most part the changes were trivial (which is why i questioned if this was maybe never the intent of this module as it seems to have 95% of the code but just stopped short of being significantly more useful, imho).

That all being said, even though the creating an action (and therefore usable in VBO) wouldn't be too difficult; i don't have a whole lot of time to devote to this (i.e. i don't typically work for free, and the client that requested this does not have a need for this at this time).

re #18, yes, perhaps split to a new project would make more sense as it does seem as though Allie has dropped support for this module - but again, that would be effort on my part which i can't spare at the moment (difficult concept for some people as it is open source s/w; they figure you should just fix things for free as well.. lol)

re: #17, yup, would bet for sure this has something to do with the multiple roles feature i added - but again no time to work on this - but if it works as you suggest i am sure client i originally did this work for will get after me to fix it fairly soon.

hawkdrupal’s picture

I've narrowed-down the problem reported in #18.

I said that when the user is not in the specified Premium role, the custom message never appears, just Drupal's default "Access Denied".

Actually the custom message does appear if I let Drupal show a simple list of nodes, such as by taxonomy category. (The nodes are all are to set to content type Article, but in the list of nodes Drupal comes up with a different node layout of just Title and Body). In the list I see the custom message just below the teaser.

But clicking into the node, the custom message vanishes, the entire body vanishes, and the page says "Access Denied" instead.

And in a view that lists nodes, which seems to cause Drupal to use the custom content type specified for the nodes, the custom message is not in the view. Again, opening the node shows no content at all, just "Access Denied".

My custom content type "Article" is the default Story with some extra fields. There's no diddling with Drupal's Body (Node form) field.

So, while Premium+mods does seem to control whether the full text is shown in a list, even with a custom node content type, in a view it does not add the custom message below the teaser, in place of the hidden rest-of-body. And in the full node, however accessed, the abbreviated body and custom message do not appear at all.

liquidcms’s picture

Not entirely sure i know what the issue is you are reporting; but this is what my client's site has for using this module (and my mods):

This is a screen of a portion of a view which lists content on the site: http://screencast.com/t/MzFkZjIzNT

The middle teaser shows the custom message which is shown to users not in the specific role. NOTE: the Notes (CCK) field is also showing because i hard coded that field to be allowed to show (one of the features i wanted to make configurable for this module but haven't gotten around to).

Also, this is a View but it is a teaser view, if you make a fields view this module will have no control over what is shown.

Clicking on the node title for the middle teaser takes us to this: http://screencast.com/t/MDViYmU5Yj which is now the full node view to users not in the premium role.

If you are getting access denied instead of the message in full node view it is because you have enabled the admin config which i added for this module which provides full access control for the node (i.e. gives Access Denied rather than showing anything).

Is any of this what you are testing?

Aleksic’s picture

It`s possible to add option dependent of where is node so if in fornt page for example "don`t show premium message" {i will like this:))} and also option, if someone like me use Views to generete content in one page two columns, also don`t show premium message. To be clear I will like if premium message can be ONLY publish in node view.
Example: www.example.com/node/1 HAVE message:) if node/1 in frontpage message is hide or not publish if node in another area like www.example.com/taxonomy/term/5 not publish.....
Thanks :)

spgd01’s picture

I haven't tested all the feature you implemented but so far this works great. Almost everything I was looking for from premium. Thank you so much. I second everything hawkdrupal said. This could be a great module on its own and much needed in drupal. The only thing I would like to see added would be a link in the premium message to "login to read more" with a redirect that will come back to the node once logged in. I know others would love this as well. I will try to use Login Destination (http://drupal.org/project/login_destination) to do that or perhaps including a login form in the premium message and see if that works.

by the way #22 did answer the same problem I had in #21. That was a duh!

Keep up the great work!

Aleksic’s picture

Also can you add suport for translation node. This is useful for multilingual site. If you select content type page is premium and if node in English, after you want translate to German, German node is not premium so you must add manual. That is ok if you only alone drive site, but if you have translations team, than you must give them access. Maybe is simple to implement few more code.

liquidcms’s picture

#23, #24, #25 should likely all be separate issues raised on the Premium module.

personally i have no need for any of these features so i won't be adding them (unless someone is paying for this work) - but also isn't my project.

Aleksic’s picture

@liquidcms I didn`t ask you! Project is not yours some you say, so let maintainer decide what will like to add. That`s all. Ah, yes.. and be sure that I didn`t pay you, if I need to pay someone that will be maintainer of this project.
Thank you for your opinion!

heyyo’s picture

This thread is from liquidcms...and also this great patch. Thanks liquidcms !
This project was a "dead" project from a long time til recently...

rfay’s picture


rfay’s picture

@liquidcms, with a huge patch like this you're asking for commit rights :-). Why not just ask to be added as a co-maintainer? Seems like you've put enough effort and brainpower into it that that would be a good path forward.

liquidcms’s picture

@heyyo, thanks for stickin' up for me.. lol.. for some people (myself included on many occasions) typing is easier than reading. :)

@rfay, Allie and I have discussed plan forward for this module and whether any of my updates are worthy of committing - I think she is looking at doing an updated release of this module. We may have discussed me being added to commit list but don't recall. Not sure i want to be. I have numerous projects of my own here and trouble enough keeping those up to date. And as i mentioned to Aleksic (although he missed the point) - i only added these features as they were funded by my client.

pianomansam’s picture

I like this module a lot, and like what you've added to it, liquidcms. I ended up not using the access control side of your patch, but I wanted to report some funny issues I encountered. When access control was enabled, I tried saving a node as premium but the content remained visible. I opened up my database and was surprised when the premium table was still empty. So I opened the module and began troubleshooting how it wrote to the database. It appears that "_premium_set_premium" is being ran more than once during a save. The first time, it deletes the node record in the premium table and properly inserts the new one. But for some reason it seems that this function is ran again, this time with no $premium variable. And when $premium is not set, the insert routine is not ran. This results it node settings never being saved. When I disabled access control within this module, it saved the settings properly. As I am not using access control, I won't be troubleshooting this any further, but wanted to pass this along. Thanks!

vood002’s picture

subscribing...seems close to what i need, but not quite there yet---maybe someone else will take the reigns at some point.

chrisbuck’s picture

subscribing as well. If I could just get the node to save as premium content, that would be perfect. I'll fiddle around with the SQL data tables for now (mainly because I know nothing about coding), but a small fix for comment #17 would be great. Thanks liquid for your efforts so far.

petey318’s picture

subscribing - I am trying to get my additional CCK fields (media files etc) to NOT display either unless the viewer has the premium role, liquidcms's patch seems like the way to go, so I'll try and test it...

EDIT: all works exactly as expected. thank you so much for submitting this patch; I would recommend having this committed.

prabhakarsun’s picture

Thanks liquidcms...

liquidcms’s picture

just finished up with my largest client and have time on my hands for a bit... should anyone that was looking for mods, fixes, improvements to this module be interested in funding me to do so.

yes, blatantly advertising.. :)

rfay’s picture

@liquidcms... I don't have any work for you but hope you get some out of this.

PLEASE request commit privileges and clean this up a bit while you're waiting for the offers to roll in. You may have to contact Allie more than one way. Or go through the "abandoned module" procedure and take it over.

Allie Micka’s picture

Has anyone ever considered contacting a module's maintainer with requests and funding opportunities? It's easy to dish out all kinds of judgment. Meanwhile the prevailing attitude continues to be "I can get paid to write patches, but only if module maintainers will work on my behalf for free." This is completely unsustainable.

@liquidcms, this is not directed at you, by the way.

rfay’s picture

@Allie, you've not been very active in the issue queue. I didn't even think you hung around here. Through entire issues you didn't check in. There have been no commits for more than a year.

I certainly didn't want to annoy you. It's obvious that you're really busy.

And I certainly am glad you're around.

But I would have asked for help from liquidcms (if I needed it) based on recent work on this module. #39 was actually your first check-in on this very important issue, and you weren't even checking in on the issue. From Nov 25th to now, nothing. I think I only follow one other issue, my own, #700084: premium_access should not be cached in $node. Global $user can change behind the scenes, which has been in "needs review" for 23 weeks with no maintainer check-in. So I was assuming you were too busy to give this module any attention.

liquidcms’s picture

Wasn't looking to ruffle any feathers here... but this is the open source way and many people don't get that. It is Allie's module and i would suggest she should get first crack at any paid efforts to improve this module. My improvements were done only because a client of mine needed these features and he suggested a good idea to start with this module as it was pretty close to what we were looking for. He allowed me to provide these mods back to the community.

My only point was i rarely work for free and this is what i do (module design, module modification, etc).

I am not all that interested in becoming a co-maintainer of this module (assuming Allie was interested in adding me) as that would most likely mean working for free to some extent (see point above.. :) - yes, i know it is selfish of me to want to pay for my mortgage, car, beer, etc). If i really wanted to do that i could always "steal" her code completely (but give her credit of course) and make a Premium Plus project (but again, unless a clinet of mine saw a benefit to that; not likely going to happen).

all that being said, if Allie were to add me.. i would certainly commit the code already provided here if she is too busy to do it.

petey318’s picture

I've tested liquidcms' patch, and it seems to work fine, except... it is messing with block visibility settings somehow.

The use-case: I want to have a block, visible ONLY to anonymous users.

When configuring a block, if I select only "anonymous user" in the role specific visibility settings area, the block is displayed to anonymous AND authenticated users.

I was expecting that if the "anonymous user" is the only box checked, (and that "authenticated user" and all other role boxes are left unchecked) then this block should only be visible to anonymous users and NOT shown to logged-in (ie authenticated) users.

This only occurs using liquidcms' patch, the problem is not seen when using the "official" Premium module.

I am not sure whether this is a huge problem to fix or not, however this would need to be resolved before this patch could be rolled into the formal release. (?)

liquidcms’s picture

4.47 KB

ok, yes i can confirm this is a bug and it is loosely based around the bad attempt to fix the default setting issue in #10.

the attached patch adds a new feature of allowing admin to set a default premium role on a per type basis; which then removes whatever i was trying to do with the patch in #10.

i am a bit concerned though as it was pretty late when i wrote this last night and the patch changes a fair bit of code. i tested in a few test cases but not sure i got them all - if anyone can test it out more and let me know that would be very cool.

there is certainly some code left over that is likely wrong or at least not required - for instance i don't think i am really using the premium admin setting of setting node types that use premium - as far as i can tell i have removed the checks for this. seems redundant to have this and my "Select premium role per type" selector as it defaults to "no role selected" which seems as though it would be the same thing. if anyone knows why we need to still set node types using premium; please let me know.

fyi, this patch is against the module which has the other patches above.. hmm.. maybe i should spawn a new project??

philpro’s picture

I cannot seem to successfully apply the patch given here. I'm not sure exactly what version I'm supposed to patch and which patches to include. I've applied the patch with a few hunks failing, the resulting module doesn't throw any errors, but won't save my settings.

@liquidcms can you zip up your latest edition of the module and paste it here?

morgannewspaper’s picture

This is probably a dumb question, but can you tell me the steps to install this patch?

rfay’s picture

@morgannewspaper, http://drupal.org/patch.

People will help you in IRC as well. http://drupal.org/irc.

prabhakarsun’s picture

How can I *show* certain fields?

NathanM’s picture

Subscribing. Will try the patch soon.

mikl’s picture

Status: Needs review » Patch (to be ported)

The functionality of the changes in #44 are also present in my multilevel branch, which I'd very much like more testers on. Please see http://drupal.org/node/51483#comment-4165850 for details :)