Version: 1.00, by Shadow
Developer Last Online: Nov 2023
Category: New Posting Features -
Version: 4.x.x
Rating:
Released: 06-04-2012
Last Update: Never
Installs: 23
Uses Plugins
Re-useable Code Translations
No support by the author.
Description:
This hack adds prevents Staff Members from posting in closed threads. When a thread is closed, administrators and moderators are still able to post in it. This basically prevents that. There is also an option to exclude selective users from this. I made this modification for a client and decided to put it up here for others to use if they need to.
Installation Instructions:
To install simply import the attached product-denied_reply.xml file. Then you're done.
Altering the Error Message:
It is possible to change the error message that is displayed to users when they are denied from replying in a closed thread. This can be done by going to Phrase Manager in the Admin CP and searching for the denied_reply_error phrase. Then add a translation for the language your forum is in and alter the message as required.
Changelog:
05/06/2012 - Version 1.00:
- Initial release.
Notes:
I'm always looking to improve my work for the people that enjoy using it. If you have any suggestions on how I can improve this hack then please leave a comment and I'll see what I'm able to do. Don't forget to 'Mark As Installed' if you've got it installed!
I have a testbed installation of vB 4.2.0 with absolutely no added products or modifications. It's hosted on an entirely different server that's running PHP 5.4.27 (as opposed to PHP 5.3.20 on my user-accessible installation of vB 4.2.0). I installed this 'Deny Reply for Staff' product for testing purposes on my testbed vB installation. It worked better in that it did not block staff members from posting or replying to unclosed threads. BUT, when the product is enabled, it throws the following error when attempting to post from the advanced editor:
Code:
Warning: Illegal string offset 'threadid' in [path]/newreply.php on line 519
Posting from the Quick Reply editor does NOT render this error when the product is enabled. And disabling the product eliminates this error during Advanced Reply posting.
The above behavior, coupled with the complete loss of our staff members' ability to post anywhere when the product is enabled on my user-accessible vB installation, leads me to believe that this product could use a bit more development in order to hopefully work out some of these apparent bugs. What's somewhat puzzling, though, is the fact that I'm the only one who has reported these problems. I'm unsure what the significance of that may be.