BrikPanel: WooCommerce Dashboard, Abandoned Cart Recovery, Google Sheets Sync, Inventory Management & Bulk Editor

變更記錄

3.2.63 (2026-08-14)

• Fix: A phone number that already carries its country code no longer gets a second one in front of it. A shopper who typed “90 545 728 83 42” at a store based in the United States was linked to “+1 90 545 728 83 42”, a number belonging to nobody. When BrikPanel has no country on file for a shopper it used to fall back to your store’s own country and put that code in front regardless; now, if the number already begins with a country code, the number is trusted and left alone. When the shopper’s real country is known nothing changes. Reported by a store owner.
• New: Abandoned carts remember which country the phone was typed in. Checkout now records the billing country alongside the phone, so the WhatsApp link no longer has to guess one afterwards. Where a guess is still the only option, the button’s tooltip says so, and shows the exact number it will dial before you click it. Carts saved before this update keep working and simply fall back to the smarter detection above.
• Fix: The Orders and Abandoned Carts screens now build WhatsApp links the same way. The two screens each had their own copy of the number logic and could disagree: a Caribbean number gained a duplicated area code on one screen but not the other, a number already written with its country code was doubled on one screen, and one screen would happily build a link from a number too long to be real. Both now share one routine, so the same customer always gets the same link. Numbers written with “+”, with “00” or with the North American “011” dial-out prefix are all understood, and a single national leading zero is dropped without eating the rest of the number.

3.2.62 (2026-08-14)

• New: Attributes you type in the product editor can become real WooCommerce attributes, in any language. Colour and size swatches, layered navigation and attribute filters all read what WooCommerce calls global attributes, the ones listed under Products → Attributes. The editor used to convert one for you only if you happened to name it Color, Colour, Renk, Size or Beden, so a Dutch shop typing “Kleur” ended up with a product-only attribute its theme could not use, while an English shop typing “Color” got a site-wide one it never asked for. There is now one switch, “Create global attributes automatically” in WooCommerce → Settings → BrikPanel → Products, on by default and no longer tied to a list of words. An attribute that already exists is reused instead of duplicated, whatever capitalisation you type. Nothing is created while the product is still a draft, and a name WooCommerce will not accept, too long, reserved or just a number, quietly stays product-only rather than failing the save. Switching it off later leaves attributes that already exist alone; remove those in Products → Attributes. Reported by a store owner.
• Fix: A variation’s default choice no longer disappears when you save twice without reloading. When an attribute became a global one during a save, the editor kept referring to it by its old name, so the “Default Form Values” dropdown came back empty and the next save cleared the default you had picked. The editor now picks up the new attribute, its proper label and its values straight from the save, so a second save keeps everything and a variation row you add by hand offers the right options.
• Fix: The item list in an abandoned-cart WhatsApp message now puts each product on its own line. Products were strung together on one line separated by semicolons, so a cart of four or five items arrived as a crowded paragraph that was hard to read on a phone. {items} now writes one product per line, variations included. Downloading the list as CSV or Excel is unchanged, where the whole cart still belongs in a single cell. Reported by a store owner.
• New: The WhatsApp button on your orders now opens with the message already written. Clicking the WhatsApp icon on the Orders list, or the button on an order’s page, used to open an empty conversation and leave you to type everything yourself. It now opens with a draft ready to send, which you can still edit or delete before sending; nothing is ever sent on its own. Write your own in WooCommerce → Settings → BrikPanel → Orders, with {customer_first_name}, {order_number}, {order_status}, {order_total}, {order_items} and more. Clear the box to go back to opening an empty conversation.
• New: A different WhatsApp message for each order status. Say one thing while an order is being prepared and another while it is still awaiting payment. Every order status your store has is listed, including your own custom ones and any a shipping plugin adds; switch one on and write its message, and every status you leave off keeps using the general message. Simple and variable products both list correctly, with each variation’s options shown once.

3.2.61 (2026-08-14)

• New: A button another plugin adds to the top bar now follows you everywhere. BrikPanel’s own top bar steps aside on a few screens, the post and page editor, the site editor, and for staff accounts without WooCommerce permissions, and WordPress shows its own toolbar there instead. Until now a button registered for the BrikPanel bar simply disappeared on those screens. It is now placed in the WordPress toolbar automatically, so the plugin author writes one registration and the button is there on every screen. The store owner keeps the same on/off switch and per-role visibility rules over it either way. Requested by arcanetech.

3.2.60 (2026-08-13)

• Fix: The Rank Math SEO score is correct again in the product editor. A product scoring 100/100 in the product list showed 0/100 on the BrikPanel editing screen. Rank Math loads its Advanced Custom Fields bridge on any product screen, and with the ACF section switched off that bridge threw an error which cancelled the entire analysis before a single test had run, so the score fell back to zero. The bridge is now left out when no ACF field is on screen, an add-on that fails while Rank Math gathers the content can no longer take the whole score down with it, and the product’s first image is handed over as the featured image so the image tests pass exactly as they do in the WordPress editor. Both screens now report the same number, on simple and on variable products.
• New: Write your own WhatsApp message for abandoned carts, in your own language. The message opened from the Abandoned Carts list was fixed text. WooCommerce → Settings → BrikPanel → Cart abandonment now has a “WhatsApp message” box with {customer_name}, {store_name}, {items}, {cart_url} and {recovery_url} placeholders. {recovery_url} rebuilds that exact cart in a single tap, with the right variations selected. Leave the box untouched and the message stays as it was, in your store’s language.
• Fix: Text in Arabic, Turkish or any other non-Latin alphabet is no longer cut in the middle of a character when a message or popup field reaches its length limit.
• New: Live Visitors shows what each visitor is browsing on. Mobile, tablet or desktop now appears as a small icon at the start of every row, worked out with the same detector as the Devices breakdown, so the two can never disagree. No raw browser information is stored and nothing extra is sent from the visitor’s browser.
• Security: A customer can no longer inject code into your dashboard through their own billing details. Details a customer types in themselves, such as a phone number, were placed in the Live Visitors row tooltip without escaping the double quote character, so a crafted phone number could run its own script the moment the store owner hovered over that row. Every row tooltip, label and link now uses attribute-safe escaping.
• Fix: Saving a variable product no longer stops after the first variation. BrikPanel asks other plugins to save their own variation fields after each variation. A plugin that ends the request outright instead of returning an error, which Woo Product Variation Gallery does when it does not recognise the form it is given, left every variation after the first one unsaved and showed no error at all. Such a plugin now loses only its own field write, your variation data is saved, and every other plugin carries on as normal. The same protection covers the plugins that run when the product itself is saved.
• Fix: Admin-only wording no longer turns up in translation plugins. Text that only ever appears on BrikPanel’s own admin screens was being prepared on every storefront page view and every background request, so front-end translation plugins such as TranslatePress collected it as store text: 112 such rows on a test store, now none. It is prepared only where it is actually shown, which also takes a slice of needless work out of every page load.

3.2.52 (2026-08-13)

• Fix: Saving a bundle, composite or booking product no longer wipes its own data. After a save, BrikPanel told other plugins to process the product, which is how their fields get saved. For a product type whose own WooCommerce panel the simplified editor cannot show, those plugins received a form that never contained their fields and read that as “the merchant cleared everything”: a WooCommerce Product Bundles product lost every bundled item and had its layout and cart settings reset. When BrikPanel saves a product type it cannot fully represent, it now holds back only the plugin that owns the missing panel, so that plugin’s data is left exactly as it was while every other plugin still saves normally, and the editor says where those settings can be changed. Reported on the support forum.
• Fix: A product whose type is added by another plugin (bundle, composite, booking, subscription) keeps that type when saved from the editor with the product type selector switched off, instead of being turned into a simple product.
• Fix: One plugin failing while WooCommerce draws its product data panels no longer hides every other plugin’s panel from the “Additional product data sections” list, or from the editor itself.

3.2.51 (2026-08-13)

• New: Find a product by your own supplier or manufacturer code. The product list search already matched the title, the description and the WooCommerce SKU, including a variation SKU, but a warehouse that scans a supplier code kept in its own custom field got nothing back. Stores can now tell BrikPanel which extra fields to search with the new brikpanel_product_search_meta_keys filter, and a code found on a variation returns its parent product, so simple and variable products both work. Nothing changes unless you use the filter: out of the box BrikPanel still searches exactly the WooCommerce SKU field. Requested on the support forum.
• Fix: A SKU containing an apostrophe is now findable. Searching the product list for a code such as OB’RIEN-9933 returned nothing, because the apostrophe was still escaped when the SKU was matched. Searching by product name was unaffected.
• Fix: A product search no longer leaves its extra search rule switched on for the rest of the page load when another plugin throws an error while the product list is being built, which could quietly widen unrelated searches on the same request.
• Fix: While a product search is running, BrikPanel’s extra search rule is no longer applied to searches another plugin happens to run at the same moment, which could quietly widen someone else’s results.

3.2.50 (2026-08-13)

• Fix: Cookie consent now works with the banners people actually use. The consent gate added in 3.2.48 was tested against the eleven most-installed consent banners, and two problems turned up. Banners that report a decision without declaring which privacy law applies, which includes CookieYes and GDPR Cookie Compliance by Moove, left BrikPanel waiting forever after the visitor had already clicked Accept. And banners that announce “everything denied” on the very first page load, CookieYes among them, made BrikPanel send a pointless clean-up request on every page view before the visitor had touched anything. Both are fixed: a decision from your banner is honoured whichever way it is reported, and a refusal with nothing to clean up is now the no-op it should be.
• Tweak: The consent documentation now lists which banners work with no setup at all (Complianz, CookieYes, GDPR Cookie Compliance, WPConsent, Cookiebot, iubenda, Beautiful Cookie Consent Banner), which one needs its own Compliance mode connected (Cookie Notice), and gives a tested copy-paste bridge for the ones that do not use the WordPress Consent API at all (CookieAdmin, Real Cookie Banner, Termly).

3.2.49 (2026-08-13)

• New: Remove an expense straight from the dashboard. The Profit section’s Expenses breakdown was read-only: you could add a cost with the “+” button but there was no way to take one back out without leaving the page. Every line that comes from your own expenses now has a small remove control. Because a line is a grouped total rather than a single entry, the confirmation tells you exactly what it covers: one entry is named with its date and amount, several are summed and counted.
• New: Repeating expenses ask what you meant. Removing a line that belongs to a repeating expense offers a choice between clearing only the period you are looking at and removing the repeating expense altogether. The first entry of a series is the date the whole series is generated from, so it is kept out of the “only this period” option and the dialog says so rather than quietly deleting future occurrences.
• Fix: Deleting one occurrence of a repeating expense now sticks. Removing a single generated occurrence, from either the Operational Expenses page or the dashboard, looked like it worked but the entry came straight back the next time the figures were read: the engine that fills in a repeating expense saw a period with no entry and created it again. Removed occurrences are now remembered, so they stay removed, while the rest of the series keeps running. Editing the expense’s amount no longer brings them back either, and changing its start date or frequency correctly forgets removals that no longer apply.
• Fix: A repeating expense set to a percentage of revenue can no longer be expanded into dated money entries, which would have multiplied the rate as if it were an amount.

3.2.48 (2026-08-13)

• New: Visitor tracking can now wait for cookie consent. Until now the only way to stop BrikPanel writing a visitor cookie before a consent banner had been answered was to switch tracking off entirely, which also emptied the Visitors, Live Visitors and conversion funnel cards. A new Wait for cookie consent switch under WooCommerce → Settings → BrikPanel → Analytics keeps the statistics and holds everything back until the visitor allows analytics: no cookie, no browser storage, no request. Consent takes effect immediately without a page reload, and withdrawing it stops tracking and deletes BrikPanel’s own cookies and browser storage for that visitor. Off by default, so nothing changes unless you turn it on. Reported by silaghichris.
• New: Works with the WordPress Consent API out of the box. With the consent switch on, BrikPanel reads the statistics category, follows live consent changes from your banner, and declares every cookie and browser storage key it uses so a consent platform can list them in your cookie policy automatically.
• Developer: Consent can also be driven from any cookie banner through the brikpanel_frontend_tracking_allowed PHP filter or the brikpanel_start_tracking() / brikpanel_stop_tracking() JavaScript methods. Both are documented under WooCommerce → Settings → BrikPanel → Developers.

3.2.47 (2026-08-13)

• Fix: Pasting a comma-separated list of attribute values now works. The attribute value box only split on the pipe character WooCommerce itself uses, so pasting “Red, Blue, Green” landed as one long value. Commas now split too. A pipe still wins when the text contains one, so a WooCommerce list whose values contain commas (“Lime, Basil and Mandarin | Vanilla”) is still read correctly.
• Fix: A failed save now tells you what actually went wrong. “An error occurred” was all you got when saving a product failed, which is no help to anyone. The message now names the server’s reply — the status code and, when another plugin’s PHP error killed the request, the error and the file it came from. The full reply is also written to the browser console so it can be copied into a support message.

3.2.46 (2026-08-13)

• New: Other plugins can add their own buttons to the top bar. BrikPanel hides the WordPress toolbar, so a plugin that added a button there had nowhere to put it and the only option was the single manual shortcut in the settings. A plugin can now register a real top bar item: a live counter, a menu, a status badge, or just a label and a link. It can sit on the left or the right, next to whichever built-in control it belongs beside. Every registered item shows up in WooCommerce → Settings → BrikPanel → Dashboard with the same on/off switch and per-role visibility rules as the built-in controls, so the store owner stays in charge of it. Requested by arcanetech.

3.2.45 (2026-08-13)

• Fix: The sidebar lines up for staff accounts, not just administrators. Menu items supplied by other plugins carried a slightly wider icon than BrikPanel’s own, so their labels sat a fraction further right and their rows a pixel taller, leaving a ragged left edge. Administrators barely noticed it because most of their menu is BrikPanel’s own items; a staff account, whose menu is mostly other plugins, saw it on nearly every row. Every row now reserves the same icon slot and stands the same height, in both left-to-right and right-to-left stores. Reported by slamadeyinka.
• Fix: The stray “WooCommerce” row in a staff account’s menu is gone. BrikPanel lists Orders and Customers as menu items of their own and hides the “WooCommerce” heading above them. A role that cannot open either one was left with just the heading, which sat out of line with everything else and led to a “Cannot load woocommerce.” error page when clicked, because it is a heading rather than a real screen. It is now left out when there is nothing under it, and styled like any other item on the rare setup where it does open a page.
• Fix: Menu icons that come from another plugin as a Dashicon are no longer drawn larger than the icons beside them, and a menu item the current account cannot open no longer leaves an empty element behind in the sidebar.

3.2.44 (2026-08-10)

• Fix: Unsaved variation edits are no longer thrown away. Filling in costs, prices, stock or SKUs across the variation table and then pressing “Generate variations” wiped every one of them and restored the table to how it looked when the page loaded, because regenerating rebuilt each row from the last saved copy rather than from what was on screen. Everything you have typed is now carried into the rebuilt table. The same protection covers a save that is still running: on a big product a save takes a few seconds, and anything typed while it was in flight used to be reverted the moment the reply came back, then quietly saved as empty on the next save. Reported by connororgan94 for variation costs in particular.
• New: Add a single variation instead of generating every combination. An “Add manually” button sits next to “Generate variations”. It adds one row and lets you pick the combination yourself from a dropdown per attribute, including WooCommerce’s “Any” option, so a product with nine bundles and two inserts no longer forces all eighteen rows on you when you only sell three of them. Picking a combination another variation already uses is flagged straight away.
• New: Paste a whole list of attribute values or tags at once. The attribute value box now accepts a pipe-separated list, the same format WooCommerce’s own attribute box uses, so you can copy a list of values straight across or out of a spreadsheet and get one value per entry. Product tags do the same with a comma-separated list. A comma inside a value is left alone, so “Lime, Basil and Mandarin” stays one value.
• New: “Select all” for a global attribute. An attribute backed by a global attribute now shows a button that adds every one of its values in one click, and turns into “Clear all” once they are all on the product. Typing a value the attribute does not have yet offers to add it, so a new value can be created from the product itself instead of going to the attributes screen first.
• Fix: Deleting an attribute no longer leaves it stuck to the variations. Removing an attribute row and saving left every variation still carrying the deleted attribute in the database. It was invisible and harmless day to day, but it came back to life the moment an attribute of the same name was added again, silently pinning variations to a value nobody chose. A variation now only keeps the attributes the product actually has.
• New: Optional wide layout for big monitors. A new “Use the full screen width” setting under WooCommerce ▸ Settings ▸ BrikPanel ▸ Products lets the variations table and the two description editors spread across a wide screen instead of staying in the centre column; the short-field cards keep their normal width so the page still reads as one page. The variations table then stops needing a horizontal scrollbar on most stores, so cost, SKU and image are visible without scrolling sideways. Off by default, and it has no effect below roughly 1360 pixels. Requested by connororgan94.

3.2.42 (2026-08-09)

• Tweak: The Google Ads and Meta Ads integration is out of beta, so its “Beta” labels have been removed from the dashboard button, the Ad Platforms page, the WooCommerce menu item and the settings screen.

3.2.41 (2026-08-09)

• Fix: “Most Added to Cart” counted far more adds than really happened. Three things were being counted that no shopper did. Link preloading, the feature in browsers and speed plugins that quietly loads a page before you click it, follows the “Add to cart” links on your shop and category pages, and WooCommerce fills the cart for real when it does, so a single preloader sweeping one page produced one add for every product on it. On top of that the same person adding the same product again, and carts filled by scripts or from the admin area, all counted every single time. Adds are now counted the same way the “Add to cart” figure above them always has been, one per shopper per product per day, and preloaded requests are ignored everywhere in the analytics. Expect the numbers on this card to drop sharply and to finally line up with the rest of the dashboard.
• Fix: “Most Viewed Pages” credited category and search traffic to a random product. Views were recorded against whichever product the page happened to finish listing, so a busy category page inflated one arbitrary product and never appeared under its own name. Category, tag and shop pages are now listed as themselves, the cart and account pages are counted properly instead of being dropped, and a search results page is left out rather than pinned on a product.
• Fix: Both cards could show fewer than five rows. If one of the top entries pointed at a product or page that had since been deleted, the row was quietly removed and the card looked like there was less data than there was. The list now fills up to five with whatever still exists.

3.2.40 (2026-08-09)

• New: The dashboard remembers the date range you picked. Choosing Last 7 Days, Last 30 Days or a custom range used to last only until you refreshed or left the screen, and the dashboard snapped back to Today every time you came back. Your choice now stays, including a custom range with its exact dates. It is remembered per account, so every member of staff keeps their own view, and per store on a network install.
• Fix: A date that does not exist on the calendar no longer drags in your whole order history. A custom range like the 45th of month 13, which only a hand-edited link or a corrupted saved range could produce, slipped past the date check and was read as the beginning of time, so the dashboard and the Excel export both went off and measured every order the store has ever taken. Impossible dates are now rejected on every route in and fall back to today.

3.2.39 (2026-08-09)

• Fix: A saved product editor layout could be discarded on some stores. When the stored section layout had been written by a settings import it was ignored entirely and rebuilt from scratch, which dropped any third-party plugin panels the store had added to the editor.

3.2.38 (2026-08-09)

• Fix: The top bar icons could go blank on a single screen. On stores running a plugin that styles SVG icons across the whole page, the notification bell, the hidden-notices bell and the other top bar icons were repainted invisible on whichever screen that plugin loads its stylesheet on, most often the Orders list. The buttons still worked and still opened their panels, they just looked empty. The top bar now draws its own icons on its own terms, so no other plugin’s styling can wipe them, on any screen and in both left-to-right and right-to-left layouts. Thanks to iesayi for the report.
• Fix: A dead search box sat in the toolbar for staff who could not use it. The “Search BrikPanel” box was added to the admin bar for every account, but the scripts behind it only loaded for accounts that could manage WooCommerce, so those staff saw an unstyled box that did nothing when clicked. It is now shown only to the accounts that can actually use it.
• Fix: The WordPress menu is no longer reordered for accounts that keep it. Anyone left on the standard WordPress sidebar now also keeps its original ordering, instead of having WooCommerce quietly moved to the top by a panel they are not using.

3.2.37 (2026-08-08)

• Fix: Staff accounts saw two menus stacked on top of each other. On any account that was not an administrator, the BrikPanel sidebar could be drawn without the stylesheet that hides the WordPress menu underneath it, leaving an unstyled list of links sitting above the normal WordPress and WooCommerce menu. The sidebar and its stylesheet now always travel together, so this can no longer happen for anyone.
• Fix: BrikPanel now reaches the staff roles it was always meant to. The panel only recognised accounts holding WooCommerce’s “manage WooCommerce” permission, but WooCommerce itself shows its own menus to roles that hold order, report or product permissions instead. Custom staff roles built with a role editor were caught in that gap. Anyone WooCommerce treats as store staff, plus editors and authors, now gets the BrikPanel interface; customers and subscribers keep the standard WordPress screens as before.
• Developer: new brikpanel_interface_capabilities and brikpanel_user_can_use_interface filters to widen or narrow which accounts receive the BrikPanel interface.

Older releases are listed in changelog.txt, included with the plugin.