VPester - Pester Lurkers to Register

[Lynx]

curiousadmin,

From what I've seen, plugin authors don't typically send out PM's for fixes - they'll typically post in their support thread so all users of the plugin know when a fix has been applied and released.

[Chris]

To my knowledge, this is a problem that is directly caused by a recent change (or at least a change I've never observed before) where Proboards will send out new key permissions that effectively disable key writes once it receives any AJAX request (such as switching between tabs, liking a post, clicking participated button, etc.). If that key write is done through AJAX and there exist a form on the page such as quick reply or WYSIWYG that is capable of transporting key data without the need for AJAX then that permission change gets sent out. I take the fact that the  observations I laid out above were not refuted or amended in anyway by Tim Camara as confirmation of the problem.

I'm seeing this problem affect other plugins as well (example: Plugin Error 32) which leads me to believe it was a fairly recent change, perhaps part of the batch of changes that saw the removal of pending member profiles which has also recently reared its head and was the only way people found out there was even a change made since there was not so much as a heads up in the Development Blog.

The problem Virgil faces has to do with using the form transport method to avoid the changed behavior but still maintain some sort of accurate timekeeping since the form transport method offers no callback for real-time value processing and the operation of the plugin heavily relies on timekeeping being fairly accurate so I do not envy him/her in the least since that is a slippery slope to climb, if anybody can do it however my bet is on Virgil Sovereign  

[Virgil Sovereign]

Maude Fealy , curiousadmin , and interested parties: I've updated to v1.1.4 in the library and below.

VPester 1.1.4.pbp (5.66 KB)

Try it out on your boards and, if you can, make sure the data it reports back to you is accurate after you post. (That is, please dump the data after you've posted a few times and verify that the plugin is accurately tracking when you've posted.)

Chris : I thank you once again for your analysis. I settled for just pushing out the on-submit data to localStorage and then writing to key on the subsequent page load. It's a hack, but it doesn't violate the ToS since the update still only ever occurs in response to the user submitting a new post.

I would have liked to use the set_on utility to help out PB but there are just too many hitches and headaches. I have no idea whether set_on can be safely used in response to the form submit event. If not, I don't know whether it's possible to issue multiple set_on calls at frequent intervals (in order to get an accurate timestamp) and be guaranteed to have both i) the key reflect the data in the last call (as opposed to, say, the first), and ii) only the data in the last call piggybacked onto the post submit, since the plugin could potentially wind up queuing hundreds of updates otherwise. I don't know whether set_on supports multiple hooks (e.g. 'thread_new post_new'). I don't know whether either of the two supported hooks will trigger if a post is simply being edited, which needs to happen for this plugin. I don't know what to pass as an argument to object_id (pb.data('user').id? undefined? null?) since it needs to be supplied in this case to pass in a third argument but private user keys don't have IDs insofar as I'm aware.

I'm also getting red flags with the value parameter in set_on being optional. If the function works the way I think it does, value should never be optional. The function call would be useless at best and an error at worst if the value was omitted, leading me to believe my understanding may be flawed.

At any rate, I'm sticking with the sure thing.

[Maude Fealy]

Jul 24, 2016 13:46:58 GMT -8 Virgil Sovereign said:

Maude Fealy , curiousadmin , and interested parties: I've updated to v1.1.4 in the library and below.



Try it out on your boards and, if you can, make sure the data it reports back to you is accurate after you post. (That is, please dump the data after you've posted a few times and verify that the plugin is accurately tracking when you've posted.)

Thanks for all your hard work Virgil Sovereign . And thank you as well Chris for your help in solving what I originally thought was a simple problem. I just installed the new version.

I think you're asking me to test the new plugin to see if it reacts correctly according to the settings I've entered. If that's correct, I can do that with no problem. I imported all my settings from the key on the previous version. I hope that's OK. I didn't want to have to recreate my exclusion list because last time I did that, it took over an hour.

[Virgil Sovereign]

Maude Fealy: Yes. Just let me know if there are any problems with the new version.

[curiousadmin]

Jul 24, 2016 13:46:58 GMT -8 Virgil Sovereign said:

Maude Fealy , curiousadmin , and interested parties: I've updated to v1.1.4 in the library and below.



Try it out on your boards and, if you can, make sure the data it reports back to you is accurate after you post. (That is, please dump the data after you've posted a few times and verify that the plugin is accurately tracking when you've posted.)

Chris : I thank you once again for your analysis. I settled for just pushing out the on-submit data to localStorage and then writing to key on the subsequent page load. It's a hack, but it doesn't violate the ToS since the update still only ever occurs in response to the user submitting a new post.

I would have liked to use the set_on utility to help out PB but there are just too many hitches and headaches. I have no idea whether set_on can be safely used in response to the form submit event. If not, I don't know whether it's possible to issue multiple set_on calls at frequent intervals (in order to get an accurate timestamp) and be guaranteed to have both i) the key reflect the data in the last call (as opposed to, say, the first), and ii) only the data in the last call piggybacked onto the post submit, since the plugin could potentially wind up queuing hundreds of updates otherwise. I don't know whether set_on supports multiple hooks (e.g. 'thread_new post_new'). I don't know whether either of the two supported hooks will trigger if a post is simply being edited, which needs to happen for this plugin. I don't know what to pass as an argument to object_id (pb.data('user').id? undefined? null?) since it needs to be supplied in this case to pass in a third argument but private user keys don't have IDs insofar as I'm aware.

I'm also getting red flags with the value parameter in set_on being optional. If the function works the way I think it does, value should never be optional. The function call would be useless at best and an error at worst if the value was omitted, leading me to believe my understanding may be flawed.

At any rate, I'm sticking with the sure thing.

Virgil Sovereign 

Thank you so much for this!  I actually don't know much about how importing settings from previous versions works, as I'm a fairly new admin.  Also you mention a 'switch' to localstorage, but for unregistered guests wasn't it a cookie instead? (sorry if I misunderstood.)

Anyway the technical details are less important, my basic question is: would users previous pester settings (such as number of times they've visited as an unregistered guest) be retained?  If not, since my forum is just starting out, with low visitor numbers that I occasionally drive visitors to, I don't want to reset the number of times they've visited yet because then I would lose all that very valuable information.  If you don't bring this across from the old version, then I'd prefer to wait a bit until I have more registered users to test.

Just to give you an indication, I have about 5,000 views from similar sources of traffic, and my analytics are...very spiky let's say  So far I have less than 10 registered users from the thousands of visitors across multiple articles I occasionally post.

So despite the fault, I actually still have it turned on and had just put a notification to ignore the error.  people who are actually posting are already 'in the fold' and also, they have been notified to ignore the error. 

so if you could let me know whether I can retain the number of visits of guests or not it would help me to decide whether to update now or a little later, and also how to import these settings.  Thanks so much!

[Virgil Sovereign]

Jul 29, 2016 2:22:38 GMT -8 curiousadmin said:

Jul 24, 2016 13:46:58 GMT -8 Virgil Sovereign said:

Maude Fealy , curiousadmin , and interested parties: I've updated to v1.1.4 in the library and below.



Try it out on your boards and, if you can, make sure the data it reports back to you is accurate after you post. (That is, please dump the data after you've posted a few times and verify that the plugin is accurately tracking when you've posted.)

Chris : I thank you once again for your analysis. I settled for just pushing out the on-submit data to localStorage and then writing to key on the subsequent page load. It's a hack, but it doesn't violate the ToS since the update still only ever occurs in response to the user submitting a new post.

I would have liked to use the set_on utility to help out PB but there are just too many hitches and headaches. I have no idea whether set_on can be safely used in response to the form submit event. If not, I don't know whether it's possible to issue multiple set_on calls at frequent intervals (in order to get an accurate timestamp) and be guaranteed to have both i) the key reflect the data in the last call (as opposed to, say, the first), and ii) only the data in the last call piggybacked onto the post submit, since the plugin could potentially wind up queuing hundreds of updates otherwise. I don't know whether set_on supports multiple hooks (e.g. 'thread_new post_new'). I don't know whether either of the two supported hooks will trigger if a post is simply being edited, which needs to happen for this plugin. I don't know what to pass as an argument to object_id (pb.data('user').id? undefined? null?) since it needs to be supplied in this case to pass in a third argument but private user keys don't have IDs insofar as I'm aware.

I'm also getting red flags with the value parameter in set_on being optional. If the function works the way I think it does, value should never be optional. The function call would be useless at best and an error at worst if the value was omitted, leading me to believe my understanding may be flawed.

At any rate, I'm sticking with the sure thing.

Virgil Sovereign  

Thank you so much for this!  I actually don't know much about how importing settings from previous versions works, as I'm a fairly new admin.  Also you mention a 'switch' to localstorage, but for unregistered guests wasn't it a cookie instead? (sorry if I misunderstood.)

Anyway the technical details are less important, my basic question is: would users previous pester settings (such as number of times they've visited as an unregistered guest) be retained?  If not, since my forum is just starting out, with low visitor numbers that I occasionally drive visitors to, I don't want to reset the number of times they've visited yet because then I would lose all that very valuable information.  If you don't bring this across from the old version, then I'd prefer to wait a bit until I have more registered users to test.

Just to give you an indication, I have about 5,000 views from similar sources of traffic, and my analytics are...very spiky let's say  So far I have less than 10 registered users from the thousands of visitors across multiple articles I occasionally post.

So despite the fault, I actually still have it turned on and had just put a notification to ignore the error.  people who are actually posting are already 'in the fold' and also, they have been notified to ignore the error. 

so if you could let me know whether I can retain the number of visits of guests or not it would help me to decide whether to update now or a little later, and also how to import these settings.  Thanks so much!

Updating to the new version of the plugin from v1.1.0 or later should retain all of your settings.

Note that the plugin only uses keys for "mutes" on your forum (registered users that read the board but don't say anything). Keys can't be used for lurkers (unregistered users, or users that refuse to log in) since Proboards has no way of tracking them.

"localStorage" is a way of storing information about a website in a user's browser. This is the only way the plugin has to track the activity of lurkers. The problem with it is twofold. Firstly, the data is associated with a specific browser on a specific computer, hence if the user uses multiple browsers or multiple computers, the plugin has no way of "sharing" data between the various instances. Each instance will behave as though the activity on the other instances never happened. Secondly, localStorage data can be wiped out by certain types of cache wipes, and some people perform deep cache wipes quite frequently.

Generally speaking, there's no way to avoid these two problems. It's just the way the Internet and browsers are designed.

I mention this because it's important that admins understand that limitations of the plugin re lurkers.

[curiousadmin]

Jul 29, 2016 9:39:23 GMT -8 Virgil Sovereign said:

Jul 29, 2016 2:22:38 GMT -8 curiousadmin said:

Virgil Sovereign  

Thank you so much for this!  I actually don't know much about how importing settings from previous versions works, as I'm a fairly new admin.  Also you mention a 'switch' to localstorage, but for unregistered guests wasn't it a cookie instead? (sorry if I misunderstood.)

Anyway the technical details are less important, my basic question is: would users previous pester settings (such as number of times they've visited as an unregistered guest) be retained?  If not, since my forum is just starting out, with low visitor numbers that I occasionally drive visitors to, I don't want to reset the number of times they've visited yet because then I would lose all that very valuable information.  If you don't bring this across from the old version, then I'd prefer to wait a bit until I have more registered users to test.

Just to give you an indication, I have about 5,000 views from similar sources of traffic, and my analytics are...very spiky let's say  So far I have less than 10 registered users from the thousands of visitors across multiple articles I occasionally post.

So despite the fault, I actually still have it turned on and had just put a notification to ignore the error.  people who are actually posting are already 'in the fold' and also, they have been notified to ignore the error. 

so if you could let me know whether I can retain the number of visits of guests or not it would help me to decide whether to update now or a little later, and also how to import these settings.  Thanks so much!

Updating to the new version of the plugin from v1.1.0 or later should retain all of your settings.

Note that the plugin only uses keys for "mutes" on your forum (registered users that read the board but don't say anything). Keys can't be used for lurkers (unregistered users, or users that refuse to log in) since Proboards has no way of tracking them.

"localStorage" is a way of storing information about a website in a user's browser. This is the only way the plugin has to track the activity of lurkers. The problem with it is twofold. Firstly, the data is associated with a specific browser on a specific computer, hence if the user uses multiple browsers or multiple computers, the plugin has no way of "sharing" data between the various instances. Each instance will behave as though the activity on the other instances never happened. Secondly, localStorage data can be wiped out by certain types of cache wipes, and some people perform deep cache wipes quite frequently.

Generally speaking, there's no way to avoid these two problems. It's just the way the Internet and browsers are designed.

I mention this because it's important that admins understand that limitations of the plugin re lurkers.

Virgil Sovereign:

First of all, thank you so much for making this Plugin and keeping up the work it takes to maintain it.  Your work is truly appreciated!!!

I'd like to report two great things:

-  First, after extensive testing, I could no longer reproduce the 32 error.  Not by saving, editing, previewing, saving, switching lots and lots of times between BBCode and Preview mode, saving again, etc.  So I am happy to report  that the fix seems to be working completely!  I've removed the notification from our users to ignore it!!

- Secodnly, I've tested the Pester functionality with a guest user, and it seems to work as I expect!!

So, I am a happy camper! Thanks so much for everything you do.
? for me
green checkmark of appreciation! 

[Maude Fealy]

Jul 26, 2016 6:42:30 GMT -8 Virgil Sovereign said:

Maude Fealy : Yes. Just let me know if there are any problems with the new version.

Virgil Sovereign ,

I just tested the "Mute" portion of the plugin and the pester message popped up right on cue.

None of my members have reported any "Error 32" issues since I installed the new version. No news is good news, as they say, so I take that to mean that the problem has been fixed.

Thank you again for all your hard work. This is one of my favourite plugins