What changed in each plugin, newest first.
The changelog text is in English, as in the plugin.
wp-content/mu-plugins/egenverk-babbla-lean.php, and is off until an admin turns it on: a plugin that grants chat access through its own capability rule is not loaded for those requests either, and its users would then be refused — turn lean reads off again in that case. Deactivating Babbla removes the file (on a multisite network only a network-wide deactivation does, since the file serves every site). wp egvb lean on|off|status does the same from WP-CLI. When a Babbla update changes the file, Diagnostics offers to update it.tests/database-test.php (wp eval-file).tests/housekeeping-test.php (wp eval-file).wc-ajax call (per endpoint), admin-ajax.php call (per action, Heartbeat labelled), REST call (per route pattern, so /wp/v2/pages/3 and /4 are one row; unknown routes as no-route, and calls refused before they run, such as by a permission check, by their path with numbers as {id}) and wp-cron.php hit adds one short line to a file for that minute under uploads/egenverk-lagom/watch/. No database write and no cache on the request path: about 18 µs per call measured on dev, and files stop growing at 2 MB a minute. A WP-Cron job sums finished minutes every minute into the last hour's counts and deletes the files; the card shows the top 25 endpoints (total, peak per minute, last minute) and warns when WP-Cron has not run, the folder is not writable or a minute hit the cap.tests/watch-test.php (wp eval-file; run it as the web server user, or chown the folder afterwards).tests/scheduler-test.php passes phpcs (multi-item arrays on one line).tests/scheduler-test.php (wp eval-file).tools.php?page=lagom now reach Tools → Lagom instead of "Sorry, you are not allowed to access this page": WordPress refuses the unknown page before admin_init, where the redirect used to run.bin/package.sh gives every file and folder readable modes, so fonts copied with private modes no longer answer 403 on servers where the web server runs as another user.tests/dashboard-test.php (wp eval-file).wp-content/uploads/egenverk-babbla-signal/, which carries an .htaccess that sends Cache-Control: no-store, private (Apache with mod_headers) and an empty index.php. The directory and both files are created on activation, on the first write, and again whenever one is missing. The old file in the uploads root is deleted once the new one exists; uninstall (with purge on) removes the directory as well. A wp-admin tab left open across the update still reads the old address: it gets three 404s and falls back to asking the server on a schedule until it is reloaded.poll_interval and signal_token from GET /poll too (see 0.38.0); a busy site's egvb_poll_interval now also stretches the open chat's safety net. Without the file (uploads not writable, or three failed reads) the open chat keeps the 0.38.0 schedule unchanged.GET /unread and GET /poll return poll_interval (seconds) and signal_token (the change signal's current token, read before the answer is built). A new filter, egvb_poll_interval (default 0, clamped to 0–600 seconds), lets a busy site make every closed chat wait longer between its scheduled requests without a release.ALTER TABLE … MODIFY request_id). Existing messages and ids are kept; if the conversion fails, the plugin retries it on the next request.GET /babbla/v1/poll, answers in one request what an open conversation used to ask for in two: its new messages and, when due, the conversation list (and, on request, the unread count). Each part is exactly what its own route returns. The existing routes are unchanged.EGENVERK_LAGOM_PSI_KEY in wp-config.php; the page says only whether a key is set, the key is sent only in the server's request to Google, and it is scrubbed from any error message before that is stored or shown. The address sent is always a scanned page of this site, never one from the form. Uninstall removes the key and the results.tests/pagespeed-test.php (wp eval-file; Google is never called, the request is answered by a filter).index.php, with a trailing slash — so /Cart, /cart and /index.php/cart/ are the same page, and prefixes match whole path segments (/blog/ covers /blog/x/, not /blog-posts/). Plugin rules need pretty permalinks; with plain ones the mu-plugin does nothing and new rules are refused. A preview with the token is kept out of page caches.tests/plugin-rules-test.php (wp eval-file).bin/lagom-coverage --verify opens every page type that has rules in preview with the rules off and on, at desktop and phone size, runs the same interactions and compares console errors, failed requests, interactions that stopped working and the layout of every visible element (more than 2 % changed fails). --shots dir saves both screenshots per page. Results go to a new REST route egenverk-lagom/v1/coverage/verify.--read-only), and an empty cart fails the check. A full verification run adds a simple product from the plan to the cart first. Order-pay and order-received need a real order and never pass a run, so no rule may target them (a rule there would also hold back every rule verified together with it).@font-face or @keyframes and no matching style rule are shown as "fonts or animations only, check by eye" instead of "unused" and are never proposed: rule usage cannot tell whether a font or an animation is used.docs/coverage-runner.md): Tools → Lagom lists a plan of one page per page type (scanned pages and suggestions, own addresses can be added), creates a run key, and shows per file and page type what the last run saw: "unused here", "start-up only" or "used", with the share of the file that ran.bin/lagom-coverage (developer tool, not in the zip): a headless browser with a temporary profile that opens each planned page once, records which JS functions are called after load and which CSS rules match, runs standard non-destructive interactions, and uploads a per-file summary.egenverk-lagom/v1/coverage/plan and /results, each needing a valid run key; uploads are kept only for planned pages the scan recorded (a page that redirected is filed under the page type it landed on, if the scan saw it there), and every text is sanitised.tests/coverage-test.php (wp eval-file).docs/BRIEF-assets.md section 3): "Unload…" on a scanned CSS or JS file stops it loading on the page types you tick, front end or admin screens. Rules act on whole handles only.?egenverk_lagom_assets=preview, with a note on the page saying how many rules were applied. Preview links per page type sit next to each rule.?egenverk_lagom_assets=off turns every rule off for one request; scans ignore rules so the list stays complete. Back to preview and delete per rule; known page caches (WP Rocket, LiteSpeed, W3 Total Cache, WP Super Cache) are emptied after a change, otherwise the page asks you to.docs/decisions.md records the decisions behind the asset manager and order search; the brief now describes coverage (runner A plus PageSpeed B), the production safeguards and the PR order.tests/asset-rules-test.php (wp eval-file).docs/BRIEF-assets.md). While it is on, an administrator opens any front-end page or admin screen with ?egenverk_lagom_assets=scan and Lagom records every CSS and JS file that page printed: handle, the file actually served, whether it is minified and whether the other build (.min or source) is on disk, size, inline code, owner (plugin, theme, core or external host), and what depends on it. Uninstall removes the stored scans. Scans are kept per page type (front page, shop, product, product category, cart, checkout, order received, account, page template, post type, admin screen), at most 40 page types.tests/asset-scan-test.php (wp eval-file).{prefix}egvl_order_index holds one row per order with the normalised billing email, phone (E.164), postcode, first and last name, company and transaction id, each column indexed. Fast order search uses it once it is complete, so email, phone, postcode, transaction id and name are found fast without HPOS; until then only order numbers are, as before.tests/order-index-test.php (wp eval-file).?wc-ajax=egenverk_conversion_relay: every page view and wc-ajax request of a visitor with a WooCommerce session or a login (init priority 20, before Kustom's confirmation completes a payment at 999), a cart addition, the order review, the checkout and the moment before a payment completes. Cookiebot's CookieConsent is parsed by the plugin itself: -1 (a visitor outside a consent region, which Cookiebot's script also reports as a grant) is a grant, 0 a refusal, and otherwise only the marketing flag of the object Cookiebot writes is read, up to 4 kB; anything else is unknown. WP Consent API's wp_consent_marketing cookie is read directly, because wp_has_consent() on the server grants when no consent type is set or, in an opt-out region, when there is no cookie: deny is a refusal, allow a grant only when wp_has_consent() agrees, anything else unknown. The click comes from the pixel SDK's __oppref, which the SDK replaces on every ad landing, then from the plugin's own cookie egenverk_conversion_relay_click, and the browser reference from __obref; each is checked like the endpoint checks them, and must be valid UTF-8.items_added event when the consent cookie in that request grants, instead of requiring a record an earlier request had stored.egenverk_conversion_relay_added (host-only, not HttpOnly, SameSite=Lax, Secure on https, path /), each with the event id the server generated, the product and variation, quantity, amount and currency. Carrying every recent addition, rather than the ones the request brought back, keeps an addition whose answer the browser had not read when the next one was posted, and never sets again what the browser sent. The value is at most 1 kB encoded: product names are dropped first, then an addition too large on its own, then the oldest; when nothing fits the cookie is removed. The script reads it on added_to_cart, wc-blocks_added_to_cart and when a page loads, which covers an addition that reloads the page, measures items_added with each event id it has not measured in the last five minutes, and removes the cookie. With refused consent, the pixel off or the event not selected it removes it unmeasured; while consent is unknown, or another script owns the pixel SDK, it leaves it. A refusal the server sees removes it. A refusal also forgets the ids measured, and empties the session's additions, so a later grant does not hand earlier ones over.unknown, whatever an older record says. The session's unpaid order is re-stamped on every order review and consent change, never above what the request's cookie says. Every capture, through the payment or a paid status, now needs that stamp to be a grant as well as the record, and none happens in a request whose consent cookie refuses. A grant that reaches the server only after the payment completed no longer makes the purchase count, as it could through the payment until now: consent is taken as it was when the order was placed and paid.egenverk_conversion_relay_click as <expiry>.<click> (host-only, path /, SameSite=Lax, Secure on https, not HttpOnly), 30 days from the click, instead of in localStorage, which the server cannot read. The script writes it only with a grant and never writes the same click again, so a reload does not extend it; a click 1.3 kept in localStorage moves to the cookie with its expiry. With a grant and a click the server sets the same cookie, since Safari keeps a cookie a script writes for seven days only. The expiry it carries is kept in a new session or for a new account, a click only the pixel SDK's __oppref carries keeps the expiry the session saw before, and a cookie the browser already holds is not sent again. A refusal removes it on both sides.SameSite=Lax, Secure on https: egenverk_conversion_relay_record, HttpOnly, which names the record with a signature, and egenverk_conversion_relay_marker, which the script reads and which holds only the expiry, so no script sees a stable identifier. A refusal made on a page, which the next request WooCommerce makes would carry anyway, is sent at once as one small request (client: 4, action: refuse, with keepalive, so it survives the tab being closed) when the server may hold a grant: with a cart, a login or that marker. It is sent once per change to a refusal on that page, and on start-up for a refusal made before the script ran while the marker is there; never for a refusal the page request itself carried, and never in answer to another tab. The HttpOnly marker's signed reference to the record lets the refusal reach it after the WooCommerce session has expired, as it does two days after a guest's last visit; it is signed with a key derived from the auth salt, so rotating the salts invalidates every marker, which is then ignored and removed, and such a late refusal is dropped while the record expires by itself. The endpoint answers the refusal with an empty result, never throttles it, removes both markers, and ignores it when the request's consent cookie grants again; the script then sends a refusal made before it started at most once per marker value in a tab session. The order received, pay-for-order and account pages, where nothing is measured, carry the script in a refusal-only mode: no pixel, no page events and no cart additions, only the refusal and its cleanup.localStorage (egenverk_conversion_relay_synced, egenverk_conversion_relay_granted and their first names) is removed on the first page view. The pixel, the page events, the configuration in the page and the diagnostics are unchanged. A page cached with HTML from before 1.2.1 measures nothing until the page cache is purged.client 2 and 3) as before for one version, since pages and browser caches keep them for a while: grants, clicks, refusals, the cart preparation and the throttling. That code goes in 1.5.0.consent_lock_busy).checkout_place_order event on the checkout form, but Kustom Checkout posts the order straight to ?wc-ajax=checkout from its own script, so that event never fires and the synchronization never ran for an order placed through Kustom: a refusal made on its checkout page after an earlier grant could leave the order stamped with the grant. The checkout request itself now carries the consent cookie, and the order and the record are both written from it in that request, whichever script posts the order; the hook is gone. A refusal made after the order was placed is read on Kustom's confirmation page before that request captures the payment; if Kustom's server push captured it first, the refusal withdraws the queued purchase if it reaches the server before the purchase is sent, a few seconds after payment.woocommerce_payment_complete or Kustom's payment callback was decided by the customer's consent record alone, never by the consent recorded on the order when it was placed, so an order placed with consent unknown or refused was still exported when an older grant was on record. Only the paid-status path (1.2.0) checked the order.