Hi Christopher,
Sorry for the late response, but this issue was much harder to trace than I thought. First, thank you very much for the proper details, they helped me a lot. I will try to explain what I have found.
First I’ve turned on all error reporting to see if there are any error messages generated, but unfortunately nothing showed up. I went line to line to on ajax search pro code first to see at which line the error stops.
Surprisingly disabling the inclusion of the wp_filesystem (via including the wp-admin/includes/file.php) got rid off the error, but it did not make any sense, as it’s a very common practice, in fact it’s used by most of the plugins out there. At this point I knew this is going to take a couple of hours to investigate.
Then I proceeded to look for similar inclusions in the extra product options plugin in file woocommerce-tm-extra-product-options1\include\class-tm-extra-product-options.php. Turns out they do this as well, but another surprise: this was not the source of the conflict, no matter if I disabled the inclusions, the error remained.
Then I started looking for places where the file system is used and stumbled upon woocommerce-tm-extra-product-options1\include\class-tm-epo-helper-base.php file, where after several tries I’ve managed to pinpoint that the call of the
wp_check_filetype()function caused the issue. But again, it didn’t make any sense, as this is a core function, and it should work. I’ve traced the source of this core function and these calls all failed down the line:
get_allowed_mime_types()which uses:
current_user_can()which uses:
wp_get_current_user().. and BINGO, this function was not defined!
I stopped at this point investigating any further, but a possible explanation of the problem is: There is a file system function executed within the extra product options plugin, which does not do anything, unless the file system is initialized. By default at that point of execution it is not defined, so it was not executed when loading the admin screen. However in ajax search pro the file system gets initialized, as it is used to check the directories and files for consistency upon loading if needed. So at this point the previously not executed part of the product options plugin gets executed, as the file system check returns true, but it ultimately fails, as it turns out that the wp_check_filetype() function is bound to wp_get_current_user() function, which is not yet defined – the reason might be that this snippet is used too early in the wordpress loading process.
Anyways, I have solved the problem by changing line 732 of wp-content\plugins\woocommerce-tm-extra-product-options1\include\class-tm-epo-helper-base.php file from this:
if( $this->init_filesystem() ){to:
if( $this->init_filesystem() && function_exists('wp_get_current_user') ){Which I believe solved the problem. Please note that this change is in the product options plugin, so I’m not sure if this is okay or not. I highly recommend asking for advice from it’s author. I’m not sure if there is anything I can do to ajax search pro to prevent this problem in future versions, because I cannot disable the file system loader, because then it won’t be able to check and create the neccessary directories/files.
Best,Ernest Marcinko
If you like my products, don't forget to rate them on codecanyon :)
