VPester - Pester Lurkers to Register

[Maude Fealy]

May 27, 2016 20:24:29 GMT -8 Chris said:

Maude Fealy , if you are able to perform a set of steps in order to get the error yourself then posting those steps would be immensely helpful. The idea is to capture the specimen and get it to the lab so it can then be observed under a microscope to see what makes it tick, this of course means it has to show itself in order to be captured.

Chris , gimme a bit of time and I will see what I can do with a regular (non-staff) ID which I use for testing.

If I can't reproduce the error myself then I'll PM a couple of members who reported the error and ask them to do it for me.

I'll report back once this is done.

[Maude Fealy]

Virgil Sovereign & Chris ,

I spent part of the morning conducting tests with a regular (non-staff) ID.

For me, the error is intermittent. I got it once using the Quick Reply box, and once using the full reply box. In both cases, they occurred when I was using Firefox. I was not able to reproduce the error on Chrome. Those are the only browsers I use (on a desktop computer).

What happened in both cases is that I typed my reply, then hit "Create Post". In both cases, the error message (screen shot posted upthread) appeared briefly (maybe for a couple of seconds) before disappearing. Upon the error disappearing, the post posted normally without my having to do anything.

Is this of any help? If not, I can ask for more details from my members who reported the error.

Thanks for all your help!

[Chris]

I only tried it a few times so if it's intermittent then that may explain it not being triggered for me. It may also be some combination of codes particular to that forum that exacerbates the situation so in order to rule that out I may need to register an account on that forum rather than testing on a clean forum and see if I can get it triggered that way.

[Maude Fealy]

Chris ,I don't know if this will help, but here's a list of all the plugins that we have installed. Maybe there is a conflict between two or more of them?

• Disable editing after a set time
• Hide recent edits
• Simple image upload
• Auto embed image links
• Shoutbox links
• Mini profile for welcome PM
• Welcome header below ad
• IP Lookup
• Guest IP Lookup
• Different on/off icons for different boards
• Images in thread title
• Gif blocker
• Thread description
• Message alert (timed)
• Hot topics
• Post specific avatar
• Quote button in thread summary
• V Pester

I also made some template modifications. I could take screen grabs of my style sheet and PM them to you if you think that could be of any help. I'm not sure how many it would require to have the entire style sheet.

I'm not sure what else it could be... I've modified a few of the settings. Could that be a factor?

One thing that just occurred to me: could it be my settings of the pester plugin itself that could be the problem? I have a customized pester message for both lurkers and mutes. For lurkers, my settings are: 20 thread visits; one visit per thread; 96 hours between pesters; 8 maximum pesters. For mutes: 6 thread visits; many visits per thread; 24 hours between pesters and 999 maximum pesters (mutes are a very big problem on our forum!)

Thanks again for all your help! Love your Data avatar

We have a Guest Board if you'd like to try posting there as a guest. Maybe you won't need to sign up after all.

[Virgil Sovereign]

May 29, 2016 12:25:44 GMT -8 Maude Fealy said:

Chris ,I don't know if this will help, but here's a list of all the plugins that we have installed. Maybe there is a conflict between two or more of them?

• Disable editing after a set time
• Hide recent edits
• Simple image upload
• Auto embed image links
• Shoutbox links
• Mini profile for welcome PM
• Welcome header below ad
• IP Lookup
• Guest IP Lookup
• Different on/off icons for different boards
• Images in thread title
• Gif blocker
• Thread description
• Message alert (timed)
• Hot topics
• Post specific avatar
• Quote button in thread summary
• V Pester

I also made some template modifications. I could take screen grabs of my style sheet and PM them to you if you think that could be of any help. I'm not sure how many it would require to have the entire style sheet.

I'm not sure what else it could be... I've modified a few of the settings. Could that be a factor?

One thing that just occurred to me: could it be my settings of the pester plugin itself that could be the problem? I have a customized pester message for both lurkers and mutes. For lurkers, my settings are: 20 thread visits; one visit per thread; 96 hours between pesters; 8 maximum pesters. For mutes: 6 thread visits; many visits per thread; 24 hours between pesters and 999 maximum pesters (mutes are a very big problem on our forum!)

Thanks again for all your help! Love your Data avatar

We have a Guest Board if you'd like to try posting there as a guest. Maybe you won't need to sign up after all.

Quite often when problems show up intermittently, it's because of a race condition between two events. I'm wondering if it's possibly the form submit causing the listener for the key write callback to instantly abort with "failed" status, causing the message box to show up just before the next page loads.

If that's the case, then the problem can be fixed by deferring the key write to when the next page loads.

I don't have it in me tonight to make the fix, but it's simple enough that I can get it out tomorrow night or Tuesday.

[Chris]

Virgil Sovereign , thanks to a member's post on the forum I was able to consistently reproduce the error message by flipping between bbcode and preview and adding text on each. The key as you can see is properly initialized with both read and write permissions being set to true for the "vpester_data" key for my numeric user_id of 789 proboards.plugin.keys.init_permissions(["pb_gifblocker_key",{789:[1,1]}],["vpester_data",{789:[1,1]}],["thread_description_key",{3981:[1,0]}]);

Between the initial page load however and the time the form gets submitted that permission has somehow been changed to [1,0] thus producing the error on key set. Logic woulds therefore dictate that some code is directly manipulating the permissions data but have yet to identify which. I'll pick this up later after I take care of some IRL stuff...

EDIT:

---

I've identified the source of the permission change between page load and page submit and it is Proboards itself. Each time an ajax call is executed it returns with updated data for the plugins and switching between tabs does indeed generate ajax calls which carries new plugin permissions effectively disabling write for all keys as far as I can tell. I'll venture this is an effort to get plugin authors to use the set_on call whenever it is available in lieu of the set call. You'll need to convert to the set_on call which doesn't really shoot off an ajax but instead piggybacks on the form data thus being the preferred and least resource-wasting method to set a key.

I also notice that the plugin will sometimes shoot off an ajax on page load which is frowned upon and may in fact be responsible for the permissions lockdown in cases where the user may not have even switched between WYSIWYG tabs, so converting to the set_on method on pages where that is available will certainly cut down on those unnecessary calls by combining multiple calls into a single payload.

[Maude Fealy]

Thanks so much for all your help Chris ! I thought that this would be a simple problem to fix. Shows how much I know! LOL!

You rock!

[Virgil Sovereign]

May 29, 2016 17:54:31 GMT -8 Chris said:

Virgil Sovereign , thanks to a member's post on the forum I was able to consistently replicate the error message by flipping between bbcode and preview and adding text on each. The key as you can see is properly initialized with both read and write permissions being set to true for the "vpester_data" key for my numeric user_id of 789 proboards.plugin.keys.init_permissions(["pb_gifblocker_key",{789:[1,1]}],["vpester_data",{789:[1,1]}],["thread_description_key",{3981:[1,0]}]);

Between the initial page load however and the time the form gets submitted that permission has somehow been changed to [1,0] thus producing the error on key set. Logic woulds therefore dictate that some code is directly manipulating the permissions data but have yet to identify which. I'll pick this up later after I take care of some IRL stuff...

EDIT:

---

I've identified the source of the permission change between page load and page submit and it is Proboards itself. Each time an ajax call is executed it returns with updated data for the plugins and switching between tabs does indeed generate ajax calls which carries new plugin permissions effectively disabling write for all keys as far as I can tell. I'll venture this is an effort to get plugin authors to use the set_on call whenever it is available in lieu of the set call. You'll need to convert to the set_on call which doesn't really shoot off an ajax but instead piggybacks on the form data thus being the preferred and least resource-wasting method to set a key.

I also notice that the plugin will sometimes shoot off an ajax on page load which is frowned upon, so converting to the set_on method on pages where that is available will certainly cut down on those unnecessary calls by combining multiple calls into a single payload.

I wasn't even aware of the set_on method, so I'll definitely convert to that.

Many thanks for your exhaustive analysis.

ETA: One last issue. I'm currently setting the key using $([form]).bind( 'submit', ... ), but this seems like it might run into timing issues with Proboards resolving .set_on calls. I'm not seeing anything in the API for "safely" front-running Proboards on form submit. I'd prefer to do it in response to this event in order to get an accurate timestamp, but only if I'm not shooting myself in the foot.

If I invoke .set_on on page load, I'll get an inaccurate timestamp (which isn't the end of the world in this case, but still), and I'm reluctant to .set_on a 5-second interval on the off-chance that Proboards queues the operations rather than just dispatching the latest one. I'm also not intuiting when Proboards is flipping the write status on the keys. If it's in response to something other than the form submit, then presumably any call to .set is at risk of failing with write permission errors. And if it is in response to the form submit, I don't understand why the PB code doesn't just silently convert any .set call that comes in after the bell to a .set_on.

Any thoughts?

One other thing that comes to mind is that Proboards might want to ditch .set_on for something like

key.on('new_post').set( ... )

The reason being that all of the atomic updates (push, increment, etc.) are presumably going to run into this same problem, and rather than having _on versions of every method, it seems like it would be more elegant to call a delegate with an identical interface, e.g.

key.on('new_post').increment()

as opposed to

key.increment()

[Chris]

May 31, 2016 0:58:13 GMT -8 Virgil Sovereign said:

I wasn't even aware of the set_on method, so I'll definitely convert to that.

Many thanks for your exhaustive analysis.

ETA: One last issue. I'm currently setting the key using $([form]).bind( 'submit', ... ), but this seems like it might run into timing issues with Proboards resolving .set_on calls. I'm not seeing anything in the API for "safely" front-running Proboards on form submit. I'd prefer to do it in response to this event in order to get an accurate timestamp, but only if I'm not shooting myself in the foot.

If I invoke .set_on on page load, I'll get an inaccurate timestamp (which isn't the end of the world in this case, but still), and I'm reluctant to .set_on a 5-second interval on the off-chance that Proboards queues the operations rather than just dispatching the latest one. I'm also not intuiting when Proboards is flipping the write status on the keys. If it's in response to something other than the form submit, then presumably any call to .set is at risk of failing with write permission errors. And if it is in response to the form submit, I don't understand why the PB code doesn't just silently convert any .set call that comes in after the bell to a .set_on.

Any thoughts?

One other thing that comes to mind is that Proboards might want to ditch .set_on for something like

key.on('new_post').set( ... )

The reason being that all of the atomic updates (push, increment, etc.) are presumably going to run into this same problem, and rather than having _on versions of every method, it seems like it would be more elegant to call a delegate with an identical interface, e.g.

key.on('new_post').increment()

as opposed to

key.increment()

I'm always happy to assist a fellow coder Virgil Sovereign

What I am seeing is that once an ajax call is sent off the backend apparently checks if there is a set_on available for that page and sends back updated permissions via the _add_data method that then disables the write for any key that could conceivably use the set_on. The actual write permission for these keys on the server end is still enabled but I am seeing this as some sort of fudge to get the client-side javascript code responsible for sending off the key update to abort the operation in an effort  to nudge authors toward the set_on method.  
You could fudge the fudge by saving the permissions on page load and restoring them prior to making your call since the permissions appears to have gone unmolested on the server side (where it counts) given that set_on still works. I would however advise against this approach since it would go against the spirit of what Proboards is trying to achieve here and instead try to work within the imposed constraints.
Your timestamps are still being saved via localStorage if I am not mistaken so make that the primary source and update the key with the locally stored timestamp whenever the opportunity arises. I realize this negates that device-independent data that a key provides but if it is updated frequently (within coding guidelines) that might not even matter. You could also use the proboards.data('proboards.post') after submission to grab the timestamp of the post since that would conceivably be more accurate than relying on local device time.

The concerns you've brought up regarding the API itself are unfortunately not new and the proposed fix has yet to be implemented

Mar 10, 2014 8:09:51 GMT -8 Tim Camara said:

Wormopolis is correct, we don't assign the ID until the thread/post/etc. is created.  I'm assuming you're trying to use the not-yet-created ID as part of a key rather than by itself, so I see how using set_on may not be a viable option.  I went ahead and added a task to our system to look into various ways of incorporating better functionality into the set_on hooks, to provide greater flexibility in these situations.



(Also, if you have any ideas on implementation, leave 'em here for consideration, currently I'm thinking passing in an anonymous function and a key to a set_on call)

This bold idea would have addressed the issue but unfortunately it has never made it into any release that I know about.
To answer your question all calls to set_on are simply added on to the form data via $('input[name="_plugin_keys"]')  with each key having its own array of requested updates within that field so are indeed queued.

Since I am a consumer of the API just as you are any changes to interface would need to be addressed by a member of the development team(Tim Camara , Vinh , Zachary Guerrero , jruckle , Matej , et al.) or by someone with a foot in multiple camps (Brian , Ulises , David Clark )

[Tim Camara]

Well, there won't be any API changes made before the launch of V6. Beyond that, the API sections of V6 are still in flux, so it's possible this could be addressed at that time.

[Chris]

Thanks for the reply Tim, I know you are extremely busy at the moment

[Maude Fealy]

One of my members just reported seeing the error message again. He didn't specify if this was recent, but I assume that it was.

Just thought I'd let you guys know. I've been following this thread (or pretending to, since a lot of it is like trying to read Chinese upside down for me!) so I know that you're working on it. Your efforts are appreciated

[Virgil Sovereign]

Jun 1, 2016 11:43:06 GMT -8 Maude Fealy said:

One of my members just reported seeing the error message again. He didn't specify if this was recent, but I assume that it was.

Just thought I'd let you guys know. I've been following this thread (or pretending to, since a lot of it is like trying to read Chinese upside down for me!) so I know that you're working on it. Your efforts are appreciated

Sorry, busy week, no work today, and busy upcoming few days. The problem will be a bit trickier than I initially assessed, hence give me until Wednesday. Until then, tell your members it's a feature, not a bug.

[Maude Fealy]

Jun 4, 2016 4:41:39 GMT -8 Virgil Sovereign said:

Sorry, busy week, no work today, and busy upcoming few days. The problem will be a bit trickier than I initially assessed, hence give me until Wednesday. Until then, tell your members it's a feature, not a bug.

No worries Virgil Sovereign . I'm keeping my members updated and they know that fixing the problem is turning out to be more complicated than anticipated. Since the bug isn't preventing them from posting, they just make do and they're proving good humoured about it.

They will be happy to know that it's now a "feature"

Thanks for all your help!

[curiousadmin]

Jun 4, 2016 6:22:43 GMT -8 Maude Fealy said:

Jun 4, 2016 4:41:39 GMT -8 Virgil Sovereign said:

Sorry, busy week, no work today, and busy upcoming few days. The problem will be a bit trickier than I initially assessed, hence give me until Wednesday. Until then, tell your members it's a feature, not a bug.

No worries Virgil Sovereign . I'm keeping my members updated and they know that fixing the problem is turning out to be more complicated than anticipated. Since the bug isn't preventing them from posting, they just make do and they're proving good humoured about it.

They will be happy to know that it's now a "feature"

Thanks for all your help!

I also experience this (today) under Firefox as a regular user I use to post.  My personal habits include switching between bbcode and normal preview, because I always switch to bbcade and copy it to a local text file before submitting, since I don't trust browsers or servers.  I've disabled the plugin until this is fixed and would greatly appreciate if you would kindly PM me once you've identified the issue.

This happened to me consistently, including on edits, not only posts.  I use the following plugins:

Awards system
Mini-Profile for Welcome PM
Quote Selections
Karma System
Disable editing after a set time
First Time

Again, I'd appreciate a PM once you have figured this out.  BTW shall I include here the text of the error?  (It's not user facing).  I mean so that other admins could google it.  Right now if you google the error code and the name of this plugin, you get a support thread advising to disable it.  I didn't actually get this thread when I googled, I had to skim through all nine pages to realize that this is something that was known and being discussed, since the error number is only in the screenshot, not written in text.  I can include the text here for anyone else googling.

And to any users here: this is a known issue that does not effect saving posts, just a brief part of submission that disappears automatically within a second or two.