My use case is both complicated and not terribly relevant so feel free to skip this paragraph. I'm trying to implement a way for end users to customize media sites on top of what
my add-on does without too much extra configuration on their part, and one of the way I envisaged was to use the media site's name in the callback. There are 68 media sites in my add-on and I didn't want to create 68 methods ahead of time, most of which would never actually be run and all of which would only serve as a redirector to the real method. So I thought I'd cut the middle man and implement the "real" method as
__callStatic() and let PHP's magic do its thing. Unfortunately for me, XenForo had other plans.
But that's a terrible use case. The reason I reported this behaviour as a bug is because even though the callback is valid, XenForo rejects it. It broke my expectation that a valid callback would be accepted, and I think it would deserve to be changed. However, as far as I'm concerned, magic callbacks are not a priority because I don't actually
want to use them...
...which brings me back to my use case and the feature request I didn't have time to file earlier. I thought I'd file it separately but since I'm already discussing it here it is. The admin panel describes the signature of the "Embed HTML Callback" as the following:
Code:
public static function myCallback($mediaKey, array $site)
I had expected that
$site would contain more information about the media site but all it contains is the HTML code and the callback itself. If you want to fix
my use case then please add the media site's id (
media_site_id) to
$site so that the callback knows which site called it.