Show Thread Enhancements - Limited Guest Viewing -- Motivate Guests to Register

With vBulletin, forum guests are able to view endless amounts of content without being directly asked or forced to register no matter how many times they come back. The purpose of the Limited Guest Viewing System is to drive in registrations [or membership upgrades] by limiting the number of threads guests [or certain membergroups] are able to view without interruption.

This plugin offers two options which can be used to drive in more registrations. The first option allows you to show a reminder message or advertisement after a guest has viewed a certain number of threads. The second option puts up a roadblock stopping guests from viewing threads altogether after reaching a certain number of views. Both options work together to encourage and ultimately force anonymous visitors to either register or login but can also be used separately based on your individual needs.

Install Instructions: Read the install file. Customize via admin settings & templates.

Customizing the content / messages: To customize which messages appear or what they say, go to vBulletin options, select the ?Limited Guest Viewing System? group and configure the options as desired. Each phase can be modified by adding translation text. Through the ACP you can enable or disable each option, specify the number of threads that can be viewed before the option is enabled and input any forums you wish to exclude from being blocked.

Search Engine Bots (Spiders): Anything that changes your forum viewing can impact how search engines treat it. The cookie approach used by this modification is bypassed by many bots and, since people can still view posts, cloaking should not apply. Users with IP logging may face more restrictions although a filtering system lets defined spiders pass. This plugin is intended to limit repetitive viewing and not restrict people from single views.

For a full explanation of the impact on bots read the install file before asking questions.

Usergroup Limitations:
Version 2.1 introduces basic usergroup limiting with the same rules & messages guests get. Based on demand this may be extended to a per-usergroup level restriction and messaging in the future.

Change Log:
- 7.21.2012 - Update to 2.1.0 which adds usergroup limiting, fixes mySQL 5.5 support, removes the need for template editing, cleans up install guide. Upgrading is optional.

Mod Philosophy -- Drive Your Own Success:
All of my mods are inspired by my work in the digital industry and are designed to drive registrations, interaction or other engagement activities the core platform does not address. Each is designed to fit a general need by providing a starting point but it's on you to decide how to make things work to their best possible outcome. Don't stay in the box.

[Ted S]

Originally Posted by BadgerDog

Combined with storing the IP log forever (if you wanted), this seems to be an obvious method of getting people who clear cookies (or have that browser option OFF) be forced to register to continue to view our site all, unless of course they change IP addresses.

The issue is less about your users and more about your server.

Far larger boards run this mod with IP logging on but also have large servers, or clusters in some cases, to support it.

Thus the question is really how much load you are already placing on your system and how much it adds too it.

[BadgerDog]

Originally Posted by Ted S

Thus the question is really how much load you are already placing on your system and how much it adds too it.

Thanks Ted ...

We're on a dedicated server...

According to the list that our host shows me, here's our configuration ...

Intel2.0 GHz 1333FSB - ClovertownXeon 5335 (Quad Core)
Intel2.0 GHz 1333FSB - ClovertownXeon 5335 (Quad Core)
Generic1024 MBDDR2 667 FB DIMM
Generic1024 MBDDR2 667 FB DIMM
Dell1066/1333FSB Dual XeonPowerEdge 1950/2950
Maxtor 250GB:SATA:7200RPM
MaxLine Plus II Dell9G Drive Controller - SAS/SATA
SAS 5/i Dell4 Drive MaxDrive Bay for 2950

Our home page is currently showing this as performance for 470 users online (55 members and 415 guests)....

Page generated in 2.12171 seconds with 30 queries [Server Load Averages (1:5:15) 0.16 : 0.29 : 0.36]

Does that help?

Regards,
Doug

[Ted S]

seconds with 30 queries

Yikes

Still... you've got pretty low load averages. Lots of room to grow.

[Server Load Averages (1:5:15) 0.16 : 0.29 : 0.36]

Run the option for a couple days and compare them against those benchmarks when you have similar traffic on. If you rise to more than 0.50 let me know.

[BadgerDog]

Originally Posted by Ted S

Yikes

Still... you've got pretty low load averages. Lots of room to grow.

Run the option for a couple days and compare them against those benchmarks when you have similar traffic on. If you rise to more than 0.50 let me know.

Thanks Ted.....

I assume you would NOT recommend the "Never" setting for the IP "Activity Log"?

I wonder whether using the IP activity log set at 7 days is more effective than the life of a "cookie" in which gets cleared first so an unregistered guest can start the cycle over again?

If I turn IP Logging ON, is the "cookie" method still active and used also?

By the way, great mod and has really helped in driving increased membership .. :up:

Regards,
Doug

[Ted S]

Originally Posted by BadgerDog

I assume you would NOT recommend the "Never" setting for the IP "Activity Log"?

Never is a long time and the table will grow so ya, I'd stay away from that. It's very easy to go from 7 days to 15 or 30 if you so wish.

If I turn IP Logging ON, is the "cookie" method still active and used also?

Yup yup. Cookie check comes first as there's no sense in a query if we're already going to say no.

[BadgerDog]

Originally Posted by Ted S

Never is a long time and the table will grow so ya, I'd stay away from that. It's very easy to go from 7 days to 15 or 30 if you so wish.



Yup yup. Cookie check comes first as there's no sense in a query if we're already going to say no.

Thanks.

I see e log clearing check box up to 7, so if I wanted 30 days before it clears, how do I set that?

Regards
Doug

[Ted S]

Open the file lgvdb.php and replace

$vbulletin->db->query_write("
  DELETE FROM " . TABLE_PREFIX . "lgv
  WHERE (lastactivity + (". $vbulletin->options['lgvcleardays'] ." * 86400)) < ". TIMENOW ."
 ");

With code

$vbulletin->db->query_write("
  DELETE FROM " . TABLE_PREFIX . "lgv
  WHERE (lastactivity + (30 * 86400)) < ". TIMENOW ."
 ");

[BadgerDog]

Originally Posted by Ted S

Open the file lgvdb.php and replace

$vbulletin->db->query_write("
  DELETE FROM " . TABLE_PREFIX . "lgv
  WHERE (lastactivity + (". $vbulletin->options['lgvcleardays'] ." * 86400)) < ". TIMENOW ."
 ");

With code

$vbulletin->db->query_write("
  DELETE FROM " . TABLE_PREFIX . "lgv
  WHERE (lastactivity + (30 * 86400)) < ". TIMENOW ."
 ");

Thanks Ted ... I did that ...

I just turned ON logging ...

I notice that the AdminCP options do not show 30 days, but still the "Never" to 3 day range ...

I left the "Never" checked, but I assume your code change above overrides that and the cron job will clear it out at 30 days now?

Appreciate your help ... :up:

Regards,
Doug

[Ted S]

Originally Posted by BadgerDog

Thanks Ted ... I did that ...

I just turned ON logging ...

I notice that the AdminCP options do not show 30 days, but still the "Never" to 3 day range ...

I left the "Never" checked, but I assume your code change above overrides that and the cron job will clear it out at 30 days now?

Appreciate your help ... :up:

Regards,
Doug

Turn it to one of the other options so it runs but you are correct, we manually overwrote the date so 30 won't show up.

[It's Damn Real!]

Fantastic mod. Works incredibly well for well-timed events. I run a hockey forum and utilize this on specific dates like the trade deadline, major trades, singings, etc. Works PERFECTLY.