TINYIB_REQMOD seems to break post approval when set #219
After setting TINYIB_REQMOD to any value, the management panel claims that every post currently on the board is pending. Even if TINYIB_REQMOD is set to "files", text-only posts will also require approval. Despite this, posts are still visible on the board after a rebuild. When this bug is occuring, approval in any other circumstance doesn't work either. E.g., if a post is reported, that report can't be cleared, and the post remains hidden if TINYIB_AUTOHIDE is set.
It otherwise functions mostly-correctly for new posts. They're hidden until they're approved, after which they do appear on the board. Even still, they're eternally listed as pending in the management panel.
Unsetting TINYIB_REQMOD fixes all issues.
Thanks for reporting this. I am not able to reproduce this yet, at least using the sqlite3 dbmode. Which dbmode are you using? This setting should only be set to "", "files" or "all". In your testing, did you only use these values?
That's very strange. On further testing, I can reproduce this on a fresh upstream instance of TinyIB with a new database. I'm using SQLite3 as well, though I don't think this issue is database-specific, as I can also reproduce the same behavior with Flatfile. I can confirm that I'm only using the proper values for TINYIB_REQMOD: https://i.imgur.com/jASzVbH.png
I'm primarily confused by how approval seems to only work partially. If a post was hidden by the TINYIB_REQMOD rules and I approve it, it appears on the board as expected. At the same time, if I approve a post that was reported, it doesn't clear the reports. If I approve a post that wasn't reported, it doesn't prevent it from being reported in the future. In any scenario, it puts a proper entry in the modlog claiming the post was approved (at least with SQLite3. With Flatfile, it gives me offset notices and only puts a timestamp with the Unix epoch in the modlog, though I suspect that's a separate bug, as it continues to occur after disabling TINYIB_REQMOD).
Let me know if there's anything else I should test, or any other information I can supply. I'm happy to help.
Thanks, I've made the post approval process more consistent. Previously, posts could need to be approved twice before reports would no longer be accepted.
I will look into this further.
I'm suspecting that another minor issue I have is connected? Whenever I delete any post, I see this warning:
Warning: Trying to access array offset on value of type null in /var/www/html/tinyib/inc/html.php on line 827
I think this is dependent on the PHP version, which might be why you can't reproduce it if you're testing with PHP <=7.3. Looking this up, PHP 7.4 got more strict about it, and a few people reported this problem on other applications after updating: https://stackoverflow.com/questions/59336951/message-trying-to-access-array-offset-on-value-of-type-null
I apologize for the mistaken connection in the last post, I appreciate that the warning was fixed anyways though. I've looked into it more now.
I can confirm it's not related to the PHP version. I've tested with Debian 8 and PHP 5 now, and it's still fully reproducible there (my usual setup has been Debian 11).
I believe a more accurate description of the issue would be that the "Pending posts" category is just mirroring the content of the "Recent posts" category when TINYIB_REQMOD is set. Everything is fine in the database, posts appropriately have a moderated value of
2, and if I approve a post, it's always set to
2. The visibility of posts on the index is also correct relative to their value.
Nonetheless, the management panel shows both "Recent posts" and "Pending posts" categories. Both of these just contain the ten most recent posts, regardless of moderation status, as long as TINYIB_REQMOD is set to 'files' or 'all'. However, the usual distinct buttons are still generated on posts that are listed as supposedly pending ("Approve", "More Info", and "Delete"): https://files.catbox.moe/9cybjp.png
If it would help in debugging, I'd be happy to configure a TinyIB instance on a burner VPS and give you access, or upload the virtual disk of a VM I've reproduced this on.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?