[App scanner, 4.7.3B3] Don't log when extending non-IPS classes

[Martin A.]

Getting lots of logs for classes I have that extends global classes, such as \Exception, \DateTime, etc.

You would have seen this yourself if you hadn't excluded your own code from being scanned 🙂

The class \Braintree\Transaction\AddressDetails extends \Braintree\Transaction\Instance, but the parent class couldn't be loaded.

The class \IPS\core\api\GraphQL\Types\ProfileFieldGroupType extends \IPS\core\api\GraphQL\Types\ObjectType, but the parent class couldn't be loaded.

A class in an app extends the class \IPS\Node\Api\GraphQL\ObjectType for which no file /home/sites/dev/www/473b3/system/Node/Api/GraphQL/ObjectType/ObjectType.php exists! The method scanner skipped comparing that file to any of its subclasses

The class \IPS\nexus\Hosting\Exception extends \RuntimeException, but the parent class couldn't be loaded.

The class \IPS\nexus\CommissionRule\Iterator extends \FilterIterator, but the parent class couldn't be loaded.

The class \Symfony\Component\Finder\Iterator\SizeRangeFilterIterator extends \FilterIterator, but the parent class couldn't be loaded.

The class \Laminas\EventManager\Exception\DomainException extends \DomainException, but the parent class couldn't be loaded.

The class \PHPMailer\PHPMailer\Exception extends \Exception, but the parent class couldn't be loaded.

 

And it doesn't understand imports.

The class \IPS\toolbox\Slasher extends \IPS\toolbox\Singleton, but the parent class couldn't be loaded.

The class \IPS\toolbox\modules\admin\build\build extends \IPS\toolbox\modules\admin\build\Controller, but the parent class couldn't be loaded.

use IPS\Dispatcher\Controller;
<...>
class _build extends Controller
{

 

Would also be nice if there was a way to trigger the full compatibility scan without having to create an issue in a hook in order to see what's wrong. Two of my apps were disabled in this update, but the block on the support page said everything was fine. After creating an issue with a hook it would tell me the arguments for getItemsWithPermissions was incorrect in the full scan popup.

The system log fills up with ~15 pages of the above log entries whenever I hit the support page. Going through all that in order to see what could have triggered the scanner is not gonna happen.

[SoftwareFactory]

Bump. These are serious issues that are triggering lots of useless logs for many websites. While in theory I could stop using aliases (but this is not a viable solution to this problem), there is no way I can stop using classes like \RuntimeException.

[Stuart Silvester]

We've disabled logging in the compatibility scanner in 4.7.4 (it's now a debug log instead of a normal log)

[Martin A.]

Still makes the scanner worthless if we have to browse through 10+ pages of non-issues to find an actual issue.

Should also note that it scans disabled apps too, so I can't just disable Dev Toolbox to get rid of most of these log entries.