This was also brought up in the following topic, but there was no answer from IPS there and I do believe it is solvable:

In almost all places where Item::$containerNodeClass is used, there is an isset test before accessing it and graceful fallback when it's not present. However, that check is missing in a few places that affect following and tagging.

For followable:

• \IPS\core\Followed\Table:99 - this join should actually be within the preceding if statement (since I believe it only makes sense when permissions are used)
• core/front/table/tables/rows.phtml:104 - the if should also check that method_exists, as it the pattern everywhere else (but this isn't insurmountable because it will use the table desc if available)
• core/front/tables/manageFollowRow.phtml:43 - as above
• \IPS\Content\Search\Elastic\Query:467~487 - (what's going on with that code structure?) you should only honour $includeContainers if isset($class::$containerNodeClass)
• \IPS\Content\Search\Mysql\Query:416~436 - as above

for tags:

• \IPS\Content\Item:7684 - should also check isset($containerClass)
• \IPS\Content\Item:7727 - I think this should be a constant if containerClass is empty, but I'm not sure how it's used so I may be wrong here.

To my eye, all those changes should be feasible, and would make it much easier to avoid nasty hacks involving pseudo-nodes. nb. I searched for these occurences using intellij, so there may be places that I missed because the static analysis wasn't powerful enough.

I've added your suggestions to an internal development suggestions list for consideration in an upcoming release.

On 11/9/2020 at 3:12 PM, bfarber said:

I've added your suggestions to an internal development suggestions list for consideration in an upcoming release.

Another one I've just run into - \IPS\Content\Comment::contentImages calls $item->container() indiscriminately, which results in a bad method call exception. This can be triggered when viewing an activity stream RSS feed.