I don't know about 'wisdom', but I can list some of the problems I encountered.
The plugin in question 'Recently Updated Threads' plugin, that tries to keep track of any new posts and/or threads that are created and list them separately on the page.
The major issue here are keeping track of the thread numbers as
Chris mentioned above, and this can be frustrated by several things...
Mobile devices
The way key data is managed
Rules on using keys
Browser settings
Even impatient members.
To name 5
The major issue is the fact that threads are assigned their numbers only as the thread is being created, so any plugin has to try and predict that number, threads are assigned numbers in ascending order, so the RUTS plugin attempts to count the threads as they are being created. Now onto the issues...
Mobile devices.Plugins do not work on mobile devices, so any threads created using them are not included in the plugin, so you will likely have holes in your data. BUT, that also screws up the thread count according to the plugin. If the plugin is on thread 100, but a member has created a thread using a mobile device since the key was last updated, the plugin will lose count, assigning the next thread 101 when it should be 102, for example. That means that any link using the key data will take you to the wrong thread.
This issue may be helped with PB V6, when plugins will run on mobile devices.
The way key data is managed.Data read from a key is accurate only at the time it was read, when the page was loaded. So..
Member A starts to create his thread.. The plugin assigns his thread number 101
Member B then starts creating their thread, as member A is still writing their post, the plugin also assigns Member B's thread number 101
Member B finishes and posts their thread (101).. All is good.
Member A then their posts their thread, 101, when it should now be 102. Also, when Member A updates the key, it will update according to how it was when it was last read, Member B would not have posted, and so Member B's thread is deleted from the key.
Which leads to the last 3 issues I mentioned.
Rules on using keys, browser settings and even impatient membersThe way I attempt to get over the previous issues is to check the number stored in the key with the current thread number after the page has loaded with the new thread. The rules state that keys can only be written to after a user interaction, so, although the thread numbers can be checked in the background, if incorrect, the key cannot legally be updated automatically, so a pop-up is created that the user has to click on to close, and in doing so updates the key with the correct thread number. Now, the plugin needs to know when to check thread numbers, so I do that using web storage, but, if your browser is configured to not use web storage, then that part of the plugin would fail.. Updating of the key will ONLY happen if the member sees and responds to the pop-up. If they ignore it, or navigate away before they have a chance to click on it, or for whatever other reason, they do not respond to the pop-up, the key data will be wrong, and so will the thread count according to the plugin. Now, all of this can still be upset by members clicking their pop-ups out of sequence for the same reasons mentioned in the previous issue.
There are other plugin associated problems too, but all this leads to one thing. I, myself, will probably not attempt another plugin like this unless we can get accurate 'real-time' key data and a way to get a thread number at the point of posting
