Hello Community,
I want to bring this old thread to your attention again. I strongly suggest to get rid of this nonsense in one way or another. Note, that the $hint parameter of plugin_admin_common() is not used anymore since CMSimple_XH 1.6, and that editing of custom files in the back-end can be done easily done by other means at least since CMSimple_XH 1.6.
I see several possibilities:
- Don't use the global variables inside plugin_admin_common()
- Temporarily override the global variables according to the passed parameters during plugin_admin_common()
- Make the parameters optional
- Remove all parameters from the function signature
(1) is probably a bad idea, as plugin_admin_common() calls other functions/methods, which wouldn't cater to the given parameters. That's likely to cause a mess. (2) would solve this issue, but I have some doubts that it's really useful to pass custom parameters. Furthermore that would break plugins which pass wrong parameters inadvertently (it's all to easy to get the order of $admin and $action wrong, for example).
Actually, I tend to prefer (4), as that seems to result in the cleanest API. PHP is forgiving about passing additional parameters to a function, which could be used by func_get_args(), so there's no BC break. However, there is an
RFC draft about triggering a warning on superfluous arguments, which might be accepted sometime in the future (I don't think that'll make it in the near future, though). Therefore option (3) might be preferable.
If we choose option (3) or (4), we should consider whether superfluous arguments should be silently accepted, or whether they shall trigger a deprecated warning or maybe a notice or normal warning. The latter would be the cleaner solution, in my opinion, and could be easily accomplished (if (func_num_args() > 0) trigger_error(...);), but I'm afraid that many plugins won't be updated/fixed in this regard, so silently accepting the arguments might be the more practical option. Furthermore plugin_admin_common() may be superseded by another API in the future, so why bother plugin developers with two deprecations.
Opinions? Maybe there is an even better option (5)?