Please upgrade here. These earlier versions are no longer being updated and have security issues.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

[Solved] Is it possible to tell the Autoloader to ignore a folder?

businessdadbusinessdad Stealth contributor MVP
edited August 2012 in Vanilla 2.0 - 2.8

Hi all,
I'm working on my next plugin and, due to its use of 3rd party libraries, it contains a folder with about 65 files. This folder will never contain anything for Vanilla, but it seems scanned anyway by the Autoloader, which slows things down quite a bit. I was therefore wondering if there's a way to tell the AL to stay out of it.
Thanks in advance for the answers.

Comments

  • peregrineperegrine MVP
    edited August 2012

    @todd will surely give you the best answer.

    But I think a kluge would be

    if your plugin was called Sample and you put all the usual files in Sample
    and put all the 3rd party libraries in SampleAddition. As long as you called what you needed with the Sample plugin with paths to SampleAddition. I don't think main vanilla would pick it up in the autoloader (just a theory).

    I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.

  • Also... take a look at the location of the Markdown library files...

    I don't think you have that folder with 65 files in the right location :-)

    There was an error rendering this rich post.

  • businessdadbusinessdad Stealth contributor MVP

    @UnderDog Definitely not, I should probably put it into vendors folder. However, I found out that Autoloader is not "guilty", the slowness is somewhere else. Now I need to find a good profiling tool (xdebug doesn't seem to be keeping track of everything the call to some of my functions don't show up). Thanks for the answers so far. :)

  • businessdadbusinessdad Stealth contributor MVP

    Problem solved! I'm using a 3rd party library which provides its own Autoloader. The slowdown was due to the fact that, before the library's Autoloader kicked in, Vanilla's Autoloader wanted to do its job.

    It didn't matter if I put the library in vendors or inside the plugin, as the library itself relies on autoloading and this means "bothering" Vanilla. I found two solutions to this issue:

    1- Unregistering Vanilla Autoloader before calling Library's initialization routine and registering it again immediately after. This initialization occurs only once, and that's the only place where the Library needs to load its own files. Such initialization has nothing to do with Vanilla, it doesn't trigger any event and it's completely encapsulated. Therefore, the unregister/register approach is safe, although unorthodox.
    2- Modify the Library so that its Autoloader function would be prepended to the Autoloaders List and, therefore, would run before Vanilla's one. In case someone wonders if this solution would produce the original issue in reverse (i.e. any other plugin would now be slower because of the new Autoloader in the chain), there is no risk. Library's Autoloader doesn't do folder scans, buffering or anything, it simply keeps an array of Class => File name entries. Should it receive a request for a class it doesn't have, all it would cost in terms of execution would be an isset() against the array, which would be negligible.

    Personally, I'm using the second solution, simply because I don't like unregistering core stuff without being 100% sure that I'm able to register it back. It's true that an Exception would interrupt the execution anyway, but I find it a bit "dirtier". The only real risk, if we really want to look for one, is that someone implements a class with the exact same name of one registered by Library's Autoloader. However, I think this could be an issue even with Vanilla's Autoloader, as there is no absolute guarantee that a plugin won't implement a class whose name has already been used.

    I hope this can help other people in the future. :)

Sign In or Register to comment.