Allow multiple levels of premium content

This sounds like a reasonable enhancement.

This actually takes away flexibility. With the all-or-nothing flag method, you had the ability to add "access premium content" to any number of roles. With this approach, you can only permit one role to access each content type. There is also no upgrade path provided here.

It's also a little confusing to introduce partial functionality. You can make some distinctions (role) on a per-node basis, but the archiving stuff is only configurable globally.

A more appropriate strategy for what you propose is to create premium "profiles", each with their own entry in hook_perm. Then, iterate through these types to build the nodetype settings and node edit forms.

You could create a "super premium" profile that keeps things premium forever, and grant it to your "member" role. And a "semi-premium" profile that expires after 3 weeks and is available to both your "member" and "guest" roles. You get the picture...

I will take a look at this. Anyone else ?

I would like to test this patch. Has anyone else?

I haven't yet tested. I will this week.

Eaton, have you thought about adopting the module to update it to drupal 5 ?

If you are, I may be able to help you. The module would include your added functionalities, and one of my own :
the hability to show the teaser or no teaser at all for nodes that are restricted, and that would be configurable in the admin settings.

Hi Eaton,

I haven't tested the views. I applied the premium_0.patch and tested only that.

I think that this is an outstanding improvement to the premium module !

After a little tweaking I had it working.

Here are the problems I encountered :

- Uninstalling and reinstalling the module did not work for me (after the patching). The new patched premium.install just doesn't work. (I am using a MySQL database). So, reading from premium.install, I manually edited the premium table and created the new premium_level table in phpMyAdmin. I cannot tell you if premium.install works when you have not installed the premium module previously. (I just did not feel like dropping my premium table...).

- If the input format of your premium node is php, and you're using a teaser, the full restricted view shows the teaser in html format followed by the premium $message -- thing is I modified node.module to allow breaking a teaser out of a node of which the input format is php, because I figured that if you're knowledgable enough to use php, you're knowledgable enough to know where to put the break comment... my "limit" in word count for the teaser is infinite. I changed the theming function to show only the premium $message in "full" restricted view. So that's that. It's a dirty fix. I need to figure out why premium.module does not respect the input format for the teaser.

- I changed the block.png image output to <span class="premium">premium</span> in the same way that the "new" tag is outputed. It's preferable to use CSS to show an image here, if one wants to use an image. In the "links".

I love that we can have different "levels", so that by "role" we can have different access restrictions, and I love that we can use different input format for the premium message(s) (plural) !

Correction : I really applied premium_1.patch, and not premium_0.patch. Sorry about that typo.

I think that premium.install from the patched module needs to work in both situations :

- where someone already had the premium module installed (old version).
- when someone is a first-time user of the premium module.

When there's a change in the tables like that, the Drupaler can be told to uninstall and reinstall the module in admin/modules, but he shouldn't have to drop his premium table (lose that information) first.

Please, could anyone attach the already patched module?
(No I don´t know how to patch propery yet... and yes.. I´ve already readed the Handbooks...) my situation is kinda pathetic in this issue... but I would really appreciate if someone could do that for me... and for everyone out there that does not know how to apply a patch :-)

Thanks!

Rosamunda

Eaton,

The files that are attached to restricted nodes, restricted to user 'x', can still be downloaded by user 'x' if he/she links directly to said files.

The following code solves that 'problem', and is based on this : if ONE module returns "-1" for the hook_file_download function, the file's access is restricted. See file.inc line 595 (Drupal 4.7) for details.

I added this code to the patched premium.module. Let me know if you want me to create a new patch, with that modification. I tested it. It works really well.

// Added by chill
function premium_file_download($filename)  {
  $file = file_create_path($filename);
  $result = db_query("SELECT f.* FROM {files} f WHERE filepath = '%s'", $file);
  if ($file = db_fetch_object($result)) {
    $node = node_load($file->nid);
	$node->premium_access = true;
    global $user;
    if (!$node->premium) {
	  return;                  // not premium content
    }  
    $levels = _premium_levels();
    $level = $levels[$node->premium];
    if (!user_access(_premium_access_perm($level->name))) {
      return -1;             // user has privileges
    }
  }
}

The second comment should read : the user has no privileges.

Eaton, I get this error when trying to add a second level :

user warning: Duplicate entry '1' for key 1 query: INSERT INTO premium_level (plid, name, mode, time_count, time_unit, denied_message, denied_message_format) VALUES (1, 'private_stuff', '0', 0, '', 'Full text available to premium subscribers only', 1) in /.../includes/database.mysql.inc on line 121.

Then when I try again, that is, click add, fill out the form, and submit, I succeed in adding it.

I was able to reproduce this bug on 2 installations.

Hi:

I haven't tested this path because I'm using 5.x... I'll wait till there is a version for 5.x available.

If I understand this patch it gives you the option to mark your contents with various premium access levels and give a give permissions to each level in a per role basis.

I want to do a proposal:

Why don't we use the taxonomy module to label the contents and then give premium access to taxonomy terms?
For example:
- I want all contents marked with term private to be accessible to registered users
- and all nodes marked with term superprivate accessible s to users with role "employee"

I could then manage all contents with the taxonomy module (which offers a lot more possibilities of restricting who can edit terms and a lot more).

Then I can go to the premium setting page, which would present a terms vs. role table and mark the terms I want to give access under the roles who have access. If a term has no mark in any role it could be assumed to be public.
The premium content message text could be inserted in a text box near each term...

There would be only need to a term/role table in the database and the current premium table would become unnecessary.

I think this modification would add a lot more power to this module by integrating it with the taxonomy way of manage content.
This would simplify this module by removing the need to maintain each node premium level in the guy and in the database. This would be done by the taxonomy module.

With this modification it would be very easy to integrate premium content in existing sites without any modification to the nodes.
If you have 3 terms to mark news (Software news, Hardaware News, Internet News) and you want to restrict only Internet news to premium access you only have to go to premium access setting page and mark under the roles with access to the contents. No need to remark the nodes with a level of premium access.

If someone want to emulate the current premium module behavior it would be as easy as setting a new vocabulary called "Premium" with terms "yes" and "no". Then you can tell drupal in which content types you want this vocab to be present and that all. And if you want you can restrict what roles can set content to be premium or not via the taxonomy access module. This way you doesn't need to give administer nodes perms. to any user only for doing that.
As you can see: the same but with a lot more flexibility.

I don't know if I've explained my thoughts with enough clarity...
If you don't understand something please ask me. I'm very interested in this feature!

What do you think?

Javi.-

That's feasible. In the meantime, you can still tag these posts with 'private' and 'superprivate' (although the wording is off-puttish). That's what I do on my web site. I have a 'premium content' term.

Hi

Im trying to convert this to 5.1 but i have some problems. Has anybody converted it already?

Dirk

I changed the title back to "allow multiple levels of premium content", because "5.1 converting" is misleading.
I read the thread, because I thought the patches are for a 5.1 Version, but they aren't.

I'm interested in a 5.1-patch - I also can test it, but I can't help to convert.

Here's a patch that adds the ascribed features to the 5.x-1.x-dev branch of the code. Needs tested.

It's almost like a 2.0 version of this module to be honest. More features are planned as well.

Please note that this includes a schema update so make sure that you are logged into your site as UID 1 before installing this module and run update.php immediately after installing or you will get errors.

This patch works great. I'm considering taking over the maintainership of this module if no one protests... Anyone?

While I don't speak for the current maintainers of this module, I would like to see someone work on maintaining this module. I didn't have time to write any inline documentation for this patch while I was working on it, and there are quite a few more features to be added to it, (options for each level of content, such as teaser only, no teaser, drupal_is_denied(), or possibly even drupal_not_found().)

Honestly new features, and new maintainers should be discussed in another issue though... Perhaps start an issue here asking the maintainers for commit access to the project, and if they don't respond in a few weeks, post something to the webmasters queue here on drupal.org.

Rather than asserting that you're taking over the ownership of a module, why not try following up on other issues and/or contributing to the overall heath of the module? There's a handful of support issues, bugs and patches that need review/RTBC. I'd welcome a co-maintainer who takes an equal interest in those as they do in their own pet issue, and demonstrates good problem-solving, coding, etc. skills by "doing".

FWIW, I'm waiting on D6 for this feature. D5 is not really flexible enough to control how the node is rendered, and I don't want to make an invasive change like that until that's addressed.

Thanks!

I am sorry, I was not asserting anything, but by all appearances, this module is not maintained. No code changes the last 7 months. No stable relase.

If you want to maintain this module, that's fine by me. I have no specific need to have more demands on my spare time.

That's a fair point on the official release, but there aren't otherwise a lot of code changes because this is a very simple module. Again, I welcome support/feedback/followup on this or any other issue here. Like most module maintainers, I welcome co-maintainers, but that role is best filled by someone whose name pops up in more than one issue for the module.

What about removing from this module all the logic that determines what content is premium, and defering this to submodules through the hook_premium_access function? Users could then select how a content is made premium by installing only the needed submodules.

premium_multi_level could be one such submodule; premium_time would implement the current aging feature of premium; and I am currently working on something similar to what is described in comment 17, that could become the premium_taxonomy submodule (although I plan to use Drupal permission table to store terms vs role access permission).

@Allie

I agree with what you wrote in #24 and #26, but by that standard you should not even be co-maintainer of this module.

You have an RTBC'd #234433: Updated for D6 patch in your issues queue for 5 weeks, but you haven't made any commit since 11 months. Asking people to work on your module and at the same time blocking commits will not advance your module nor find you any co-maintainers...

And if it's "a very simple module", then what has kept you from creating an official release? Fact is that you've never touched the D5 version, except for committing the D5 port that others have prepared in #109742: Will this module be updated for drupal 5.0?. That was the only D5 thread where you've even participated, except for this one, where you're stone-walling.

So, if you have only a tiny bit of interest left for this module, then look for a new maintainer and pass it on, please.

Please pass it on, Allie.

I'd really like to maintain that module. I sent you an e-mail way back about this, last year.

I really hate to add to the tangent this has gotten on by posting something else off topic, but this really needs to get back on track.

Allie has stated that as maintainer she believes that the multi-tier support is best left for D6. If you would like to provide suggestions or opinions on that, or if you have other things to contribute to the actual root topic of this thread, than please do so. If all you're here to do is critique how the module has been maintained, then please take it to email. Let's try to keep things civil and on-topic.

I'm waiting on D6 for this feature. D5 is not really flexible enough to control how the node is rendered, and I don't want to make an invasive change like that until that's addressed.

This is not an invasive change, at least by my own standards. I have applied these changes to my own version of the module ages ago, before I upgraded my site to Drupal 6. Would you elaborate on D5 not being "really flexible enough to control how the node is rendered"?

What made you change your mind after August 21, 2007 ? You said in issue #109742 that "For 5.x, I'm hoping to merge Eaton's changes with other feature requests."

I understand your frustrations, but the tone you are taking seriously disinclines me from making your requests a priority among a long list of responsibilities. Meanwhile, there's a full page of open issues with little or no followup. Some are dupes, many are support, and others are features that might pertain to this thread here.

It makes little or no sense to add functionality or upgrades while other aspects are considered broken, so now the tasks for feature improvements are preceded by the workload of sorting out the rest of the issue queue. That's a big time investment. Meanwhile, the only traffic here is whining and berating, which diminishes my interest in spending free time. Thus, I'm left with client time. As far as the clients using this are concerned, this works just fine as-is, and additional changes are un-funded and represent a liability.

I am not interested in making significant UI or structural changes unless I'm convinced they'll make sense in the long haul. I would prefer to have premium's functionality in conjunction with the ability to show/hide fields, ( see also http://drupal.org/node/250569 ) and/or participate in the node_access system. I feel that D6 is a better place to make those changes. There are other features here that would not be addressed by committing the patch wholesale, so I want to give this an appropriate amount of time and consideration. See above about prioritizing time and consideration.

I know this post has been abandoned for a while, but I gotta ask: Has anyone made any progress on this feature on the most recent versions of this module?

I got to this thread a little late in the game, and the patches on this page no longer apply to the most recent 5.x version of the module. Could anyone do me a kindness and post a patched version of the module with the "hack"...?

I would really like to see a D6 version of this patch. Can anyone assist?

Would be hugely grateful.

this was never got imlemented in D5 nor D6?
I seconded robobeau

TQ

It looks like two and a half years since the last patch related post. Did this ever materialize into a D6 version? It sounds very close to what I need.

I have created a multilevel branch of the Premium module in my sandbox copy of this module.

I have implemented an upgrade path from the 6.x-1.0-alpha1 release of this module to the new multilevel data structure and packaged an unofficial release here: https://github.com/mikl/drupal-premium/zipball/6.x-1.0-alpha2-unofficial – please test it out if you can spare the time.

I hope that the powers that be will let me help maintain this module. It could certainly do with some TLC.

@mikl: I encourage you to follow the procedure on http://drupal.org/node/251466.

It's obvious that this module has not had any love from a maintainer since D4.7 (see #28).

Premium is in sore need of a maintainer.

with Premium being a default module in OpenPublish, I wonder why Phase II has not taken over as a maintainer?

#38, #39: Problem is, the current “maintainers” are not willing to give up their ownership of the module, so this is moving nowhere – see #1119168: Premium has been forked. for details.

Just an update as to whats going on with my multilevel branch at http://drupal.org/sandbox/mikl/1078824:

I think the multilevel stuff is at release quality now. I have recently implemented CTools exportables, so you can make a Premium level a part of your Features-module (or just a part of your own code). The levels are identified by machine names, so you can build modules on top of Premium. I have a use case for this that I hope I'll be able to share with you as well.

As can be seen in #1119168: Premium has been forked., I have made a fork of the Premium module, that amongst other changes has support for multiple levels of premium content. So unless you really are into nostalgia, you should probably go use Premium Content module instead :)