Forum Replies Created

Viewing 5 replies - 1 through 5 (of 5 total)
  • Thread Starter mc001

    (@mc001)

    For completeness, and in case anyone stumbles on this thread while experiencing the same issue, I was able to get rid of the cron errors by directly editing the “cron” value in the “wp_options” MySQL table and resetting it to the previous value prior to upgrading WP to 6.1.1. This got rid of most of the user defined cron jobs, but none of the core ones, and the former were simple to add back in. The point is that NADI is now happily sync’ing AD -> WP. My suspicion is that the database entry got corrupted during the WP upgrade, but I have no definitive proof.

    Thread Starter mc001

    (@mc001)

    OK, I’ve installed the test version from github. At first it failed to load as the vendor subdirectory was mostly empty and missing required files such as autoload.php. Once I copied that directory (and only that directory) from the previous version (2.3.5) then it loaded fine. I should add that I kept the new adLDAP directory in vendor, otherwise the required changes wouldn’t have been picked up. So far I haven’t seen the ldap_get_entries error being reported, just the cron job ones, which looks increasingly like a problem in WP core.

    • This reply was modified 2 years ago by mc001.
    Thread Starter mc001

    (@mc001)

    Hi,
    Thanks for replying so promptly. Yes, another NADI related error has shown up, namely:

    PHP Fatal error: Uncaught TypeError: ldap_get_entries(): Argument #2 ($result) must be of type LDAP\Result, bool given in /var/www/html/wp-content/plugins/next-active-directory-integration/vendor/adLDAP/adLDAP.php:1048

    Looking at where the error takes place, it’s at:


    // Non-Paged version
    $sr=ldap_search($this->_conn,$this->_base_dn,$filter,$fields);
    $entries = ldap_get_entries($this->_conn, $sr);

    According to the PHP manual pages, in 8.1 ldap_get_entries now expects an LDAP\Result instance as second argument; previously, a resource was expected. However, ldap_search only returns an LDAP\Result if it succeeds, whereas it will return False (boolean) on failure. This is probably the bool alluded to in the error message. Hence, I think the plugin needs to handle such a case more gracefully by checking $sr before passing it to ldap_get_entries. Would you agree?

    Thread Starter mc001

    (@mc001)

    Hi @codekraft. Yep, we whitelisted CF7 in the “Disable REST API” settings and it all burst into life, without requiring the hack I mentioned in my initial post. Thanks again for putting us on the right trail.

    Thread Starter mc001

    (@mc001)

    Hi @codekraft. Thanks for your comments. We do run “Disable REST API” plugin, so it gives us a lead what we need to reconfigure to get it to work.

Viewing 5 replies - 1 through 5 (of 5 total)