Print module conflicts with Premium module & possible bug in Premium module for Count options

2rod - November 20, 2008 - 22:17
Project:Premium
Version:5.x-1.0
Component:Code
Category:support request
Priority:normal
Assigned:Unassigned
Status:active
Description

I'm having a couple issues with the Premium module. I hope it's ok to combine them here.

Anyhow, I'm on the most current version of the Premium module (5.x-1.0) running on Drupal 5.10.

I'm trying to restrict access to certain node types after 24 hours, when they will only be accessible to a member role.

Here are the problems I've encountered trying to make this happen:

1) When I first installed the module and viewed the module configuration settings, I noticed that the minimum Count option available was "2". But I needed to set that to 1 Day. I checked the module and found where the options for this drop down are set in premium_settings() function:

$options = (range(1, 15));

The displayed values in the Count drop down are 1 less than the actual option value; e.g., selecting "2" in the dropdown will pass a value of "1". So if I select 2 Days, as the time frame, does that mean that premium content will be restricted after 24 or 48 hours? In any case, I took the display value literally, so I went ahead and changed the range in the code above to start at "0", which meant that the display value was the same as the option value.

However, after saving the settings and running a Bulk update, some of the current day's node types were protected while others weren't. The story node in particular is where it was failing. The creation timestamp and the start ts in the premium table were set to be the same for some reason. Is this due to the change I made to the code? If so, then wouldn't this have applied to all node types in the same way?

I am using the CCK module, and I recall seeing posts about a potential conflict. But those were dated last year I believe and they have been resolved.

I plan to swap the code back to its original state to see if that works out better, but thought I'd throw this out there in case that line of code actually needed to be corrected.

Also, why would the story node types be restricted immediately, while other custom node types worked fine?

2) I'm also using the Print module to create printer-friendly versions of nodes. Apparently, you can view the full body of restricted nodes when choosing to view the printer-friendly version. Has anyone else experienced this issue with this or other print modules? Does anyone know of an existing or potential fix?

Any help or suggestions would be appreciated.

#1

jerdavis - January 13, 2009 - 18:41

Reydor,

Thanks for the information. The correction of the start of range() looks to be correct. I'm making that change in the code and it should appear in a new development build soon.

The issue you're seeing where some types were protected but not others is now corrected as well. Please see #346571 for more info.

I'll need to look into the print module issue a bit, I don't have that setup in my test environment and my time I'm able to devote to this right now is limited. If you could help troubleshoot this further, it'd be greatly appreciated. Try setting the weight of the premium module in the system table in relation to the print module and see how this affects things.

Thanks again!

Jer

#2

2rod - March 12, 2009 - 19:50

Jer...

Thanks for your reply. I haven't been on for quite some time, so I apologize for the delay.

I'm glad to hear that these issues have been addressed. I ended up keeping the start of range() at 0. Then we use another custom module to help handle content types. I had to explicitly provide the content types in our custom module to restrict access to them.

I'll play around with the premium dev build when I have some time.

As for the the 2nd issue with the print module, I will take your suggestion to change the weight of each module to see what impact this has. We ended up just allowing our premium members the ability to print.

Thanks again for your help.

2rod (formerly known as reydor)

#3

Chill35 - April 4, 2009 - 16:45

We ended up just allowing our premium members the ability to print.

I did the same thing on my website. Note that you don't need a special print module to experience the 'problem', you can replicate it by enabling the book module. The book module adds a printer-friendly link to book pages. When a node is restricted, its whole content is still viewable if one goes to the the printer-friendly page for it at http://EXAMPLE.COM/book/export/html/NID.

jerdavis, thanks for taking the time to care for this module. It's one of my favorites!

#4

alexkb - June 12, 2009 - 06:11

I also have a particular need to ensure that the print feature didn't print premium content. We have both premium and non-premium content that we want to allow for printing, so simply restricting the authenticated/paying user group to print wasn't an option.

I haven't done much drupal programming like this before, so please advise if what I've done is the wrong way, but I've made the following changes to make the above possible:

1. Added a new print_invoke_printapi() function to check for hooks in print.pages.inc.
2. Added a call to the hook checker in _print_generate_node()/
3. Created a hook in premium to manipulate the node body when premium is set.

I've attached two patches. Please let me know if the changes are ok, and/or if it should be implemented differently. Thanks!

AttachmentSize
premium.module.txt 517 bytes
print.pages_.inc_.txt 895 bytes
 
 

Drupal is a registered trademark of Dries Buytaert.