Just catching up, thanks. I use a few of their smaller add-ons so will look to see if there is a workaround or disable. Always a bit of risk of unfortunate circumstances or lack of bandwidth for maintenance with third-party developers.According to the overview it has not been updated.
@Ozzy47 and @Painbaker have been MIA for a while. Many of us are waiting for a multitude of their add-ons to be updated before we go to XF 2.3x.
![[XB] Approval Queue Improvements](/community/data/resource_icons/8/8089.jpg?1786999901){kind=icon}
[XB] Approval Queue Improvements [Paid] 2.1.5 Patch Level 1
- Thread starter Painbaker
- Start date
Painbaker updated [XB] Approval Queue Improvements with a new update entry:
2.1.3 Patch Level 1
Read the rest of this update entry...
2.1.3 Patch Level 1
Read the rest of this update entry...
When processing approval queue items via the background job XF:ApprovalQueueProcess, a hard delete action can trigger an exception in XenForo's moderator logging system.
The job is executed using XF::asVisitor(), which causes the moderation actor to match the current visitor. During moderator log creation, XenForo attempts to store the actor's IP address:
$log->ip_address = Ip::stringToBinary(\XF::app()->request()->getIp());
However, when the approval queue is processed from the CLI (xf:run-jobs), there is no HTTP request and therefore no valid client IP address. getIp() returns an empty string.
As a result, XenForo calls:
Ip::stringToBinary('')
which throws:
InvalidArgumentException: Invalid string IP
Stack trace:
XF\Util\Ip::stringToBinary('')
XF\ModeratorLog\AbstractHandler->setupLogEntityActor()
XF\ModeratorLog\AbstractHandler->log()
XF\Logger->logModeratorAction()
XF\Entity\Post->_postDelete()
...
XF\Job\ApprovalQueueProcess
The hard delete itself succeeds, but moderator log creation fails because XenForo assumes that a valid request IP is always available.
The issue appears to be that moderator logging does not handle CLI execution correctly when request()->getIp() returns an empty value.
The job is executed using XF::asVisitor(), which causes the moderation actor to match the current visitor. During moderator log creation, XenForo attempts to store the actor's IP address:
$log->ip_address = Ip::stringToBinary(\XF::app()->request()->getIp());
However, when the approval queue is processed from the CLI (xf:run-jobs), there is no HTTP request and therefore no valid client IP address. getIp() returns an empty string.
As a result, XenForo calls:
Ip::stringToBinary('')
which throws:
InvalidArgumentException: Invalid string IP
Stack trace:
XF\Util\Ip::stringToBinary('')
XF\ModeratorLog\AbstractHandler->setupLogEntityActor()
XF\ModeratorLog\AbstractHandler->log()
XF\Logger->logModeratorAction()
XF\Entity\Post->_postDelete()
...
XF\Job\ApprovalQueueProcess
The hard delete itself succeeds, but moderator log creation fails because XenForo assumes that a valid request IP is always available.
The issue appears to be that moderator logging does not handle CLI execution correctly when request()->getIp() returns an empty value.
Painbaker updated [XB] Approval Queue Improvements with a new update entry:
2.1.5
Read the rest of this update entry...
2.1.5
Read the rest of this update entry...
Bug: approval-queue delete with reason >100 chars throws and leaves items stuck in the queue
Hi,
[XB] Approval Queue Improvements 2.1.3 Patch Level 3 on XenForo 2.2.11.
When a moderator deletes content from the approval queue with a reason longer than 100 characters, the action fails with "Please enter a value using 100 characters or fewer" and the item stays in the approval queue. The same failure then repeats on every job retry and blocks other queued actions in the same run, so moderators see batches where only some approvals/deletions register.
Stack trace (from the XF:ApprovalQueueProcess job):
#0 src/addons/PB/ApprovalQueueImprovements/XF/ApprovalQueue/Thread.php(67): XF\Mvc\Entity\Entity->save()
#1 src/addons/PB/ModerationNotifier/XF/ApprovalQueue/Thread.php(41): PB\ApprovalQueueImprovements\XF\ApprovalQueue\Thread->actionDelete(...)
#2 src/XF/ApprovalQueue/AbstractHandler.php(122): ...->performAction('delete', ...)
#3 src/XF/Job/ApprovalQueueProcess.php(67)
Cause: in Thread.php (lines 63-67) and Post.php (lines 61-64) the raw moderator reason is assigned to $deletionLog->delete_reason and saved. XF\Entity\DeletionLog defines delete_reason as STR maxLength 100, so a longer reason throws on save. Because parent::actionDelete() runs first, the content IS deleted, but the exception prevents the queue record from being removed.
Suggested fix (what I applied locally):
$deletionLog->delete_reason = utf8_substr($reason, 0, 100);
(same in Post.php) — or raise/validate the limit before save.
Thanks.
Hi,
[XB] Approval Queue Improvements 2.1.3 Patch Level 3 on XenForo 2.2.11.
When a moderator deletes content from the approval queue with a reason longer than 100 characters, the action fails with "Please enter a value using 100 characters or fewer" and the item stays in the approval queue. The same failure then repeats on every job retry and blocks other queued actions in the same run, so moderators see batches where only some approvals/deletions register.
Stack trace (from the XF:ApprovalQueueProcess job):
#0 src/addons/PB/ApprovalQueueImprovements/XF/ApprovalQueue/Thread.php(67): XF\Mvc\Entity\Entity->save()
#1 src/addons/PB/ModerationNotifier/XF/ApprovalQueue/Thread.php(41): PB\ApprovalQueueImprovements\XF\ApprovalQueue\Thread->actionDelete(...)
#2 src/XF/ApprovalQueue/AbstractHandler.php(122): ...->performAction('delete', ...)
#3 src/XF/Job/ApprovalQueueProcess.php(67)
Cause: in Thread.php (lines 63-67) and Post.php (lines 61-64) the raw moderator reason is assigned to $deletionLog->delete_reason and saved. XF\Entity\DeletionLog defines delete_reason as STR maxLength 100, so a longer reason throws on save. Because parent::actionDelete() runs first, the content IS deleted, but the exception prevents the queue record from being removed.
Suggested fix (what I applied locally):
$deletionLog->delete_reason = utf8_substr($reason, 0, 100);
(same in Post.php) — or raise/validate the limit before save.
Thanks.
Painbaker updated [XB] Approval Queue Improvements with a new update entry:
2.1.5 Patch Level 1
Read the rest of this update entry...
2.1.5 Patch Level 1
Read the rest of this update entry...
Thanks for the report.
Should have been fixed in the latest patch.