Title: mc001's Replies | WordPress.org --- # mc001 [ ](https://wordpress.org/support/users/mc001/) * [Profile](https://wordpress.org/support/users/mc001/) * [Topics Started](https://wordpress.org/support/users/mc001/topics/) * [Replies Created](https://wordpress.org/support/users/mc001/replies/) * [Reviews Written](https://wordpress.org/support/users/mc001/reviews/) * [Topics Replied To](https://wordpress.org/support/users/mc001/replied-to/) * [Engagements](https://wordpress.org/support/users/mc001/engagements/) * [Favorites](https://wordpress.org/support/users/mc001/favorites/) Search replies: ## Forum Replies Created Viewing 9 replies - 1 through 9 (of 9 total) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[The Events Calendar] Critical error after upgrading to latest version – how to roll back?](https://wordpress.org/support/topic/critical-error-after-upgrading-to-latest-version-how-to-roll-back/) * [mc001](https://wordpress.org/support/users/mc001/) * (@mc001) * [1 year, 4 months ago](https://wordpress.org/support/topic/critical-error-after-upgrading-to-latest-version-how-to-roll-back/#post-18393282) * Yep. Just move the 6.11.0 install from under the plugins directory, unzip the 6.10.3 distro in its place and activate it from the admin page. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[The Events Calendar] Critical error after upgrading to latest version – how to roll back?](https://wordpress.org/support/topic/critical-error-after-upgrading-to-latest-version-how-to-roll-back/) * [mc001](https://wordpress.org/support/users/mc001/) * (@mc001) * [1 year, 4 months ago](https://wordpress.org/support/topic/critical-error-after-upgrading-to-latest-version-how-to-roll-back/#post-18393037) * Download an older version from the bottom of the page here: * [https://wordpress.org/plugins/the-events-calendar/advanced/](https://wordpress.org/plugins/the-events-calendar/advanced/) * The latest version, 6.11.0, broke my site but rolling back to 6.10.3 fixed it. Make sure you then disable auto-updates for this plugin. * Forum: [Developing with WordPress](https://wordpress.org/support/forum/wp-advanced/) In reply to: [Running different versions of the same JS library](https://wordpress.org/support/topic/running-different-versions-of-the-same-js-library/) * Thread Starter [mc001](https://wordpress.org/support/users/mc001/) * (@mc001) * [1 year, 4 months ago](https://wordpress.org/support/topic/running-different-versions-of-the-same-js-library/#post-18391426) * In case anyone runs into the same issue, we’ve solved the problem by using something like: * ```wp-block-code function dte_selective_js_loading() { $allowed_pages = [ 'page1', 'page2' ] ; if ( is_page( $allowed_pages ) ) { wp_register_script('cri_DTE_1', '/path/to/datatables.min.js'), array('jquery'), '1.0.0', true); wp_enqueue_script('cri_DTE_1'); }}add_action( 'wp_enqueue_scripts', 'dte_selective_js_loading' ); ``` * That $allowed_pages is a list of slugs of pages where we want the newer JS library( that datatables.min.js being registered) to be used, with the older version being used elsewhere by default. So far it’s passed all our tests, and though we realise that this solution is not ideal since we have to keep that list up to date, we deem it a reasonable cost for the constraints placed on us. Furthermore, we expect to eventually replace the use of the older library, whence we would then be able to dispense with this approach anyway. - This reply was modified 1 year, 4 months ago by [mc001](https://wordpress.org/support/users/mc001/). * Forum: [Developing with WordPress](https://wordpress.org/support/forum/wp-advanced/) In reply to: [Running different versions of the same JS library](https://wordpress.org/support/topic/running-different-versions-of-the-same-js-library/) * Thread Starter [mc001](https://wordpress.org/support/users/mc001/) * (@mc001) * [1 year, 4 months ago](https://wordpress.org/support/topic/running-different-versions-of-the-same-js-library/#post-18381333) * Thanks for replying. I understand that you can’t help with specific plugins, but I was interested in the general problem of having to support two versions of the same JS library, immaterial of their origin. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Next Active Directory Integration] WP 6.1.1 problem](https://wordpress.org/support/topic/wp-6-1-1-problem/) * Thread Starter [mc001](https://wordpress.org/support/users/mc001/) * (@mc001) * [3 years, 8 months ago](https://wordpress.org/support/topic/wp-6-1-1-problem/#post-16235182) * 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. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Next Active Directory Integration] WP 6.1.1 problem](https://wordpress.org/support/topic/wp-6-1-1-problem/) * Thread Starter [mc001](https://wordpress.org/support/users/mc001/) * (@mc001) * [3 years, 8 months ago](https://wordpress.org/support/topic/wp-6-1-1-problem/#post-16233549) * 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 3 years, 8 months ago by [mc001](https://wordpress.org/support/users/mc001/). * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Next Active Directory Integration] WP 6.1.1 problem](https://wordpress.org/support/topic/wp-6-1-1-problem/) * Thread Starter [mc001](https://wordpress.org/support/users/mc001/) * (@mc001) * [3 years, 8 months ago](https://wordpress.org/support/topic/wp-6-1-1-problem/#post-16232156) * 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? * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Contact Form 7] Infinite loading (and workaround)](https://wordpress.org/support/topic/infinite-loading-and-workaround/) * Thread Starter [mc001](https://wordpress.org/support/users/mc001/) * (@mc001) * [5 years ago](https://wordpress.org/support/topic/infinite-loading-and-workaround/#post-14679572) * Hi [@codekraft](https://wordpress.org/support/users/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](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Contact Form 7] Infinite loading (and workaround)](https://wordpress.org/support/topic/infinite-loading-and-workaround/) * Thread Starter [mc001](https://wordpress.org/support/users/mc001/) * (@mc001) * [5 years ago](https://wordpress.org/support/topic/infinite-loading-and-workaround/#post-14676848) * Hi [@codekraft](https://wordpress.org/support/users/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 9 replies - 1 through 9 (of 9 total)