Posted by acstewart on January 17, 2009 at 12:35am
| Project: | Premium |
| Version: | master |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | Login Redirect |
Issue Summary
In addition to showing a message, it'd be useful if an admin could specify that the user go to a login / register page in order to access the content.
Comments
#1
Attaching a patch for this one. Would love to see this make it in.
The patch is against the 6.x version of the module, and adds a "Redirect Url" to the premium settings page. If set, it will call drupal_set_message() with the premium message.
It also adds a hook_premium_message($premium_message, $node) so that other modules can override the specified message with more specific messaging.
For example, an audio module could display a "Log in or register to play this song!" message on the login page.
Feedback welcome!
#2
#3
sorry, wrong thread...
#4
Has this patch gotten reviewed or incorporated yet?
#5
Would you be willing to make a similar patch for 5.x?? That would be amazing!
#6
This works great... a big improvement if your content type has lots of cck fields...
Only problem is that if a view is displayed and in the listing there is a teaser that is premium content you are automatically redirected to the login screen.
The workaround I found for this was to use views with fields rather than nodes... this works fine and only when a premium article title is clicked on are you redirected to the correct screen...
#7
Actually I digress... this is now driving me crazy... although the workaround works.... every time a search is done and premium content is found in the teasers on the site, visitors are sent to the register/login page.
Can someone please help me with what code in the module (or this patch) I would need to change to make the redirection only occur when the full node is viewed. All teasers should be displayed.
Thanks in advance.
#8
Another plea for help, I really need to remove the functionality that causes the redirect on teasers... its also destroying my rss feeds...
Any ideas anyone .... getting deperate....
Thanks
Gregg
#9
Is there anyone out there out there out there?
#10
The patch works but defeats the purpose of Premium. With the Patch the user never sees the teaser. They are auto redirected right away. I would like to see the page load with the teaser text and a link to login in the premium message. However, the link to login should appended the desired page in the url query string so that, once login is successful, the user is taken directly where they were originally trying to go. Much like
403 redirect:
http://drupal.org/project/r4032login
This can be done manually with a link to the user/login but then the user wont be redirected to the original page. Does anyone know the php code to make a link redirect to login and then once logged in go back to the page that sent them to the login?
#11
I've got something similar happening on my end (using 6.x-1.0-alpha1). In admin/settings/premium, I've entered the following PHP code as the 'Premium body text':
<?phpdrupal_goto('access-denied');
?>
Now what that does is redirect when a user tries to view a full page node. Probably not what everyone is after, but anonymous users can now see page titles and node teasers (currently working on the "Search Results" page) without the need for patching.
You could get a little more tricky I suppose, redirecting certain user roles to different places, but this is all I need for now!
#12
@spgd01
I use this:
Please <a href="/user/login?<?php print drupal_get_destination(); ?>">login</a> to view the full text.Work great to redirect to the full node view.
#13
This patch breaks drupal's ability to send indexed content to apache solr.
Basically, the patch is saying, "Every time an anonymous user views a premium node, redirect them to a user-defined page giving them more information about why they should sign up." This is done in hook_nodeapi where
$op = 'view'. So far so good.However, this assumed that
$op = 'view'is only ever called when a user needs to view a node - a reasonable assumption, but not in solr's case. Somewhere along the line, apachesolr.module needs to index nodes, and it does so when called by cron. Specifically, cron calls search_cron() which doesmodule_invoke($module, 'update_index');which then calls apachesolr_search_update_index() in apachesolr_search.moduleAt some point (I haven't tracked exactly where), apachesolr.module calls node_view() - I guess so it knows how a full node is rendered, so that it can send it to solr. This then loads up the code in the patch, which redirects the user to the redirect url, which means solr can not index content.
To replicate this bug, install the apachesolr module and run cron.php in your browser - you should find yourself sent to the redirect url (and see that the number of indexed items in solr doesn't increase).
[Update: this behaviour is also described http://api.drupal.org/api/drupal/developer--hooks--core.php/function/hoo... ]
#14
Patch attached - it makes sure that the redirect doesn't happen during a cron run.
#15
I am not convinced this approach is the right way to go. I think we should instead have a submodule (premium_access) that uses Drupal’s standard node access framework to make access control on premium content. There's plenty of modules that provides the ability to show login on access denied pages.
This would be a lot cleaner and not give us trouble with cron, etc.