mc001
Forum Replies Created
-
Forum: Plugins
In reply to: [Next Active Directory Integration] WP 6.1.1 problemFor 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.
Forum: Plugins
In reply to: [Next Active Directory Integration] WP 6.1.1 problemOK, 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.
Forum: Plugins
In reply to: [Next Active Directory Integration] WP 6.1.1 problemHi,
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?
Forum: Plugins
In reply to: [Contact Form 7] Infinite loading (and workaround)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.
Forum: Plugins
In reply to: [Contact Form 7] Infinite loading (and workaround)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.