In case others come across this, the answer was to literally rename the Vanilla 2 __autoload function to something else (like "vanillaAutoload"), then call this function AFTER it.
There are a couple of other places that call __autoload directly that will need to be changed as well, like class.controller.php -- I think there are 2-3 files that need the function name change.
I got difficulties to add a third party library which made use of spl_autoload_register to register its autoloader.
It's not very hard once we know the tricks to register the __autoload method on the __autoload stack (see http://www.php.net/manual/en/function.spl-autoload-register.php) but it won't be a solution if 2 enabled plugins do the same, so vanilla definitely need to register its autoloader with spl_autoload_register.
This has been changed in our unstable branch, so it will be getting released shortly. Actually, I put the following method in which I guess I should ask here if people know whether or not it will cause any problems (it doesn't seem to).
if (!function_exists('__autoload')) { function __autoload($ClassName) { trigger_error('__autoload() is deprecated. Use sp_autoload_call() instead.', E_USER_DEPRECATED); spl_autoload_call($ClassName); } }
Why not totally remove it ? the main change was to rename __autoload to for example vanillaAutoloader and call spl_autoload_register just after the function declaration as suggested by chriscoyier.
And one of his rule is that "Custom autoload functions should not have a failure consequence"
I think this his because a third party library could check also with function_exist if an autoload is already defined and add it to the stack if TRUE with spl_autoload_register('__autoload').
So imo it's better to remove the __autoload method if it's not needed anymore and "just let it crash" if another part of the code use it instead of spl_autoload_call
I want to stop with removing functions in case plugins call them. It's one of those things where it gets deprecated for a few versions and then removed once people have had time to remove it.
Comments
- Spam
- Abuse
0 · Insightful Awesome LOL ·spl_autoload_register('vanillaAutoload');
- Spam
- Abuse
0 · Insightful Awesome LOL ·@andyblackwell, @chriscoyier, are there any drawbacks to sp_autoload_register that you know of?
- Spam
- Abuse
0 · Insightful Awesome LOL ·- Spam
- Abuse
0 · Insightful Awesome LOL ·I got difficulties to add a third party library which made use of spl_autoload_register to register its autoloader.
It's not very hard once we know the tricks to register the __autoload method on the __autoload stack (see http://www.php.net/manual/en/function.spl-autoload-register.php) but it won't be a solution if 2 enabled plugins do the same, so vanilla definitely need to register its autoloader with spl_autoload_register.
- Spam
- Abuse
0 · Insightful Awesome LOL ·if (!function_exists('__autoload')) {function __autoload($ClassName) {
trigger_error('__autoload() is deprecated. Use sp_autoload_call() instead.', E_USER_DEPRECATED);
spl_autoload_call($ClassName);
}
}
- Spam
- Abuse
0 · Insightful Awesome LOL ·the main change was to rename __autoload to for example vanillaAutoloader and call spl_autoload_register just after the function declaration as suggested by chriscoyier.
While googling for my autoload problem with vanilla I found this :
http://aaronsaray.com/blog/2008/09/29/php-spl-autoload-3-simple-rules-you-must-follow/
And one of his rule is that "Custom autoload functions should not have a failure consequence"
I think this his because a third party library could check also with function_exist if an autoload is already defined and add it to the stack if TRUE with spl_autoload_register('__autoload').
So imo it's better to remove the __autoload method if it's not needed anymore and "just let it crash" if another part of the code use it instead of spl_autoload_call
- Spam
- Abuse
0 · Insightful Awesome LOL ·Our code doesn't call it anymore though.
- Spam
- Abuse
0 · Insightful Awesome LOL ·