Plugin Conflict

This topic contains 2 replies, has 2 voices, and was last updated by Christopher McCowen Christopher McCowen 7 years, 3 months ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #11394

    Hello,

    I’m currently having a plugin conflict that results in a 500 server error. I’m not sure how to resolve the problem. After disabled each plugin and enabling each plugin individually, I found Ajax Search conflicts with “WooCommerce TM Extra Product Options.” I plugin we rely heavily on.

    Any assistance would be greatly appreciated

    #11434
    Ernest Marcinko
    Ernest Marcinko
    Keymaster

    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 :)


    #11435

    Impressive! That is going well above any expected support and greatly appreciated. (and well explained) We also had a really difficult time trying to figure out what an earth was causing the conflict as we couldn’t find any direct error messages.

    I don’t see this being an issue moving forward though it will probably become overwritten during updates. I’m going to pass this along to the author to get their feedback and see if we can’t resolve this through the product options.

    Again, thank you so much for your amazing support. (and of course I’ll be sure to issue out a 5 star rating) It’s much appreciated!!

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.