Conversation
supportPlugin: WooCommerce Tax (formerly WooCommerce Shipping & Tax) File: classes/class-wc-connect-taxjar-integration.php Environment: WordPress 6.x, WooCommerce 9.x, PHP 8.4, MariaDB 10.11, Cloudways The _log() method (line 443) writes to the WordPress debug.log unconditionally. There are approximately 25 log calls throughout the TaxJar integration class that fire on every tax calculation, including routine messages like “:::: TaxJar Plugin requested ::::” (line 1538), “:::: TaxJar API called ::::” (line 1579), full API request/response body dumps, and tax rate lookup details. The debug toggle in WooCommerce Tax settings does not gate these calls. The _log() method on line 443 passes every message straight through to $this->logger->log() with no conditional check. This floods debug.log on active WooCommerce stores and makes it difficult to identify actual errors during server troubleshooting. Requested fix: Add a conditional check in _log() that respects the existing debug setting so informational logging only fires when explicitly enabled. Error-level logging via _error() should remain always-on since those messages (missing countries, bad zip formats, failed API responses) are genuinely useful.
Hi @twigandolive , Thanks so much for taking the time to flag this and for sharing a potential fix. I know how frustrating unexpected logging behavior can be, especially when it fills up your debug file for no good reason. I went ahead and tested this on my side as well, and I was able to reproduce the exact issue you’re seeing. Here’s a quick screen capture showing the behavior on a clean setup: https://share.zight.com/JruRb5pY . It does appear to be a bug in the current implementation. I’m checking in with the team to get full confirmation, and once the issue is officially logged, I’ll circle back here with an update so you’re kept in the loop. Hang in there, and thanks again for bringing this to our attention.
Hi again @twigandolive , Thanks for being so patient. We’ve reported the issue internal so someone from the tax team will take a look. We don’t have an ETA on when the fix will be released. For now, I’d say ignore it in the logs as it doesn’t affect the functionality of the extension, otherwise rollback to the previous version and see if that does the trick (temporarily). I hope that helps. Let us know if you need anything else. This reply was modified 2 months, 1 week ago by Frank Remmy (woo-hc) .
Hi @twigandolive , Thanks so much for taking the time to flag this and for sharing a potential fix. I know how frustrating unexpected logging behavior can be, especially when it fills up your debug file for no good reason. I went ahead and tested this on my side as well, and I was able to reproduce the exact issue you’re seeing. Here’s a quick screen capture showing the behavior on a clean setup: https://share.zight.com/JruRb5pY . It does appear to be a bug in the current implementation. I’m checking in with the team to get full confirmation, and once the issue is officially logged, I’ll circle back here with an update so you’re kept in the loop. Hang in there, and thanks again for bringing this to our attention.
Hi again @twigandolive , Thanks for being so patient. We’ve reported the issue internal so someone from the tax team will take a look. We don’t have an ETA on when the fix will be released. For now, I’d say ignore it in the logs as it doesn’t affect the functionality of the extension, otherwise rollback to the previous version and see if that does the trick (temporarily). I hope that helps. Let us know if you need anything else. This reply was modified 2 months, 1 week ago by Frank Remmy (woo-hc) .