latti
Forum Replies Created
-
Thank you very much, I’ve made all the changes you requested and released the new version 3.2.22 . If you notice anything missing, please let me know here. In the meantime, you need to download and install the new version from the plugin’s wp.org page because the update notification will appear after 24 hours.
Thank you very much, I’ve made all the changes you requested and released the new version 3.2.22 . If you notice anything missing, please let me know here. In the meantime, you need to download and install the new version from the plugin’s wp.org page because the update notification will appear after 24 hours.
Thank you very much, I’ve made all the changes you requested and released the new version 3.2.21 . If you notice anything missing, please let me know here. In the meantime, you need to download and install the new version from the plugin’s wp.org page because the update notification will appear after 24 hours.
By the way, if you like the plugin, leaving a review would also be a huge help to me 🙏
Thank you very much, I’ve made all the changes you requested and released the new version 3.2.21 . If you notice anything missing, please let me know here. In the meantime, you need to download and install the new version from the plugin’s wp.org page because the update notification will appear after 24 hours.
Thank you very much 🙏
Thank you very much 🙏
Thank you very much, I’ve made all the changes you requested and released the new version 3.2.19 . If you notice anything missing, please let me know here. In the meantime, you need to download and install the new version from the plugin’s wp.org page because the update notification will appear after 24 hours.
By the way, if you like the plugin, leaving a review would also be a huge help to me 🙏
You were right, thanks for the detailed report. As of 3.2.19 there’s a switch to disable tracking entirely (WooCommerce → Settings → BrikPanel → Analytics), and 3.2.19 merges all tracking calls into a single request per page view and removes the per-navigation exit call, cutting tracking requests by roughly two thirds.
Hi,
Thank you for this. It is easily one of the most useful reviews we have received, and all of it is now shipped in 3.2.19. If you notice anything missing, please let me know here. In the meantime, you need to download and install the new version from the plugin’s wp.org page because the update notification will appear after 24 hours.
1. COGS source. We went one step further than the filter: WooCommerce’s native
_cogs_total_valueis now the source of truth for every cost read in BrikPanel (dashboard profit, product list, Quick Edit, Sheets). Anything your landed-cost pipeline writes there is picked up as is, including direct database updates, so there is no second key to keep in sync anymore. Old BrikPanel-only values are migrated over automatically, and the variation “additive” flag is honoured. Theapply_filters( 'brikpanel_product_cogs', $cost, $product_id, $variation_id )hook you suggested was also added, with that exact signature, for stores that keep cost elsewhere.2. Tracking switch. Added under WooCommerce → Settings → BrikPanel → Analytics: one checkbox turns all front-end tracking off (zero scripts, zero requests), and the AJAX endpoints refuse pings too, so pages still cached with the old JS stop hitting admin-ajax. The live ping interval is also configurable now (10 to 300 seconds).
3. WCML. Supported in this release. WCML does not snapshot a per-order rate, so BrikPanel snapshots the conversion onto the order at purchase time, which captures the day-of-sale rate going forward. Saving WCML’s settings re-converts your existing foreign-currency orders in the background.
brikpanel_order_base_factoris now documented in the FAQ as well.4. Multisite. The
Network: trueheader is gone; you can activate per subsite. Existing network activations are untouched.5. IP hashing. You were right, the code did not match the readme. It is now a truncated salted SHA-256 (HMAC with a per-site key), so the documentation claim finally holds.
6. Live visitor data. A new “Customer details in Live view” toggle keeps live tracking fully anonymous when off (nothing personal is cached at all), the unused user id field was removed, and the readme now states what is cached and for how long (a short-lived cache of about two minutes, never the database).
Thanks again, and the offer to test is very welcome. If anything in 3.2.19 does not behave as described above, we would genuinely like to hear it.
By the way, if you like the plugin, leaving a review would also be a huge help to me 🙏- This reply was modified 3 weeks, 4 days ago by latti.
Thank you so much, I’m glad the problem is solved.
By the way, if you like the plugin, leaving a review would also be a huge help to me 🙏
That log line cracked it, thank you!
Your setup was fine. The bug was on my side: WooCommerce loads its email system lazily, only when one of its own native status emails fires (processing, completed, etc.). A change into a custom status never triggers that, and on a lean setup like yours nothing else loads it either, so my plugin failed silently before ever reaching the mail system. That’s why your SMTP log stayed empty, and why native statuses still sent. I reproduced it exactly by deactivating everything except BrikPanel and WooCommerce.
Fixed in 3.2.17: the plugin now loads the email system itself before sending. Tested on your exact scenario, and the emails go out.
The update will be on wordpress.org shortly. Please update, remove the diagnostic snippet, and change one order into your custom status to confirm. Thanks a lot for your patience and testing, it made this one findable.
Thank you for testing so carefully, and for the FluentSMTP detail, that is very helpful. The 3.2.15 change fixed one real cause (a conflicting plugin blocking the email event), but since you already reduced to just BrikPanel + WooCommerce + FluentSMTP, your case is a different one.
The key clue is that nothing reaches the FluentSMTP log at all. That means my plugin is deciding not to send before it ever calls WordPress mail, so this is not a delivery problem. It happens for one of two reasons:
- The status the order actually moves into does not match the status the email is enabled for (this is common after migrating, where the underlying status slug can differ from what you see).
- There are no valid recipients for that email (the customer checkbox is off, or the test order has no customer email address, and no admin/extra recipient is set).
To pin down exactly which, could you add this small snippet (via Code Snippets, or a mu-plugin), then change an order into your custom status once:
add_action('woocommerce_order_status_changed', function($order_id, $from, $to, $order){ $emails = get_option('brikpanel_status_emails', array()); $enabled = array(); if (is_array($emails)) { foreach ($emails as $slug => $cfg) { if (!empty($cfg['enabled'])) $enabled[] = $slug; } } $to_key = sanitize_key($to); $cfg = isset($emails[$to_key]) ? $emails[$to_key] : null; wc_get_logger()->info(sprintf( 'order #%d | from=%s to=%s | enabled-email-statuses=[%s] | MATCH=%s | customer=%s admin=%s extra=%s | billing_email=%s', $order_id, sanitize_key($from), $to_key, implode(', ', $enabled), in_array($to_key, $enabled, true) ? 'YES' : 'NO', ($cfg && !empty($cfg['customer'])) ? 'on' : 'off', ($cfg && !empty($cfg['admin'])) ? 'on' : 'off', ($cfg && !empty($cfg['recipients'])) ? $cfg['recipients'] : '(none)', ($order instanceof WC_Order) ? ($order->get_billing_email() ?: '(empty)') : '?' ), array('source' => 'brikpanel-diag')); }, 999, 4);Then open WooCommerce → Status → Logs, choose the
brikpanel-diaglog, and paste me the one line it produces. That line tells us immediately whether the status matched (MATCH=YES/NO), whether a recipient was set, and whether the order had a customer email, and I can fix it from there. If no line appears at all, that itself is the answer and points somewhere else.Thanks again for sticking with this.
Thank you very much, I’ve made all the changes you requested and released the new version 3.2.15 . If you notice anything missing, please let me know here. In the meantime, you need to download and install the new version from the plugin’s wp.org page because the update notification will appear after 24 hours.
Thank you very much, I’ve made all the changes you requested and released the new version 3.2.15 . If you notice anything missing, please let me know here. In the meantime, you need to download and install the new version from the plugin’s wp.org page because the update notification will appear after 24 hours.
Hi thank you very much 🙏,
You were right, and thank you for pushing on this. I reproduced the problem and found the cause.
My plugin sent the email by listening to WooCommerce’s “order status changed” event. WooCommerce fires several status events in a row inside a single error-catching block, and that one is the last. If another plugin on your site throws an error on an earlier status event (a leftover hook from your previous custom-status plugin is a very likely source), WooCommerce silently swallows it and never reaches the event my plugin was waiting on. The status still changes, so you see the move but no email is sent and nothing reaches the mail log. Your old plugin was unaffected because it sends from its own code.
I’ve fixed this in the next version (3.2.15): the email now also fires from the order save step, which runs outside that fragile chain, so it sends even when another plugin blocks the status event. I added a guard so it still sends exactly once. I tested it manually, via bulk changes, REST and cron, on both simple and variable products.
The update will be on the wp.org repository shortly. After updating, please switch the status by hand once more and confirm the email arrives. Thanks again for your patience and the detailed reports, they made this fix possible.