Autonavi.ee

The product page has a compatibility check. The customer enters their unit’s software version and the system compares it with 772 known versions and 183 that can be activated directly.

The check copes with a partially typed version, because people rarely copy a long code exactly. It knows which units only have support in hardware and need a software update too, and recommends the newest option that fits. The aim is fewer wrong orders and returns.

The most important rule: compatibility is promised by software version, not by model year. The same model from the same year can ship with three different generations of head unit (MIB2, MIB2+ or MIB3), depending on trim and market. A promise based on the year would mean refunds. So every product description says how to read the version off the screen: hold the MENU button for about 10 seconds.

Products are generated automatically from cleaned per-make tables and imported into WooCommerce. Each product carries the list of software versions it works with, and the compatibility check uses the same list. When the data is corrected, both the products and the check update from the same source.

Porsche gearbox calibration products were added later the same way. Their driving rules and prices also came from a table, and when the table had a mistake it was fixed there, not on hundreds of product pages.

Each add-on is a separate option with its own price that can be switched on or off per product, and the final price is calculated in the cart. The product stays one product instead of hundreds of variants, which would have been impossible to manage at this scale.

The product image also follows the selection: when a customer picks full-screen mode, for example, they immediately see what it looks like in their car.

What didn’t work: the add-on price was added to the product price every time WooCommerce recalculated the cart total. And WooCommerce does that often: when the address, shipping method or coupon changes. Each change could add the same add-on price again. The server also accepted add-ons that weren’t allowed on that product at all, if someone wrote them into the request.

How it works now: the price is always calculated from the product’s original price, not from the previous result, so several calculations in a row always give the same answer. The server takes the allowed add-ons and their prices from the product’s own settings. A price coming from the browser is never trusted.

What didn’t work: the product page and the server had different rules. The page allowed one thing, the server checked another, and the product setting “don’t check the VIN for this product” only worked in the browser. The server still demanded a VIN.

How it works now: the rules are the same on both sides and the server has the final say. The VIN must have the right format: 17 characters, without the letters I, O and Q, which VINs don’t use. A plate number used to be accepted too, but that option went, because the software package is tied to the VIN. A plate doesn’t tell the package which car it’s in. The check can be switched on or off per product, and that setting now applies on the server too.

The checkout template called the page header and footer itself, even though the page had already done so. The result was a page inside a page. You could hardly see it, but checkout refreshes itself in the background (when the address or shipping method changes) and the payment code expects a specific page structure. The doubled structure could break it.

Now checkout has one page frame and the checkout part is an ordinary block inside it. Other small bugs went at the same time: product page data was loaded on every page, even where it wasn’t needed, and some scripts assumed a library that hadn’t been loaded.

Each order has a “Download software” button. The server picks the right base package from the car’s software version, keeps only the features the customer bought (CarPlay and Android Auto are separate), ties the package to that car’s VIN and offers the finished file for download. Nobody has to assemble files by hand.

The base packages are large and valuable, so they’re kept where the public internet can’t reach them. Only staff with the right permissions see the button.

What didn’t work: the earlier approach deleted the package files when the VIN didn’t match. On review I found it couldn’t tell a wrong car from a failed read. If the car returned its VIN in lower case, if the read came back empty or if a file had one extra character, the check took the right car for a wrong one and deleted a valid package. One script also had a typo that meant the check could never pass: every run, right VIN or not, ended in deletion. And the deletion had no guard against reaching outside the memory card.

How it works now: the package runs in two stages. The first stage contains no software files at all, only the VIN check. Only the right VIN unlocks the second stage with the real software. A wrong VIN never sees it. A read error no longer means “wrong car”, it stops safely and deletes nothing. The new version also has a trial mode that runs the whole decision and only logs what it would do, and a second trial mode that tests the handover between stages without installing any software.

I’m also honest about what it isn’t. This protection prevents installing on the wrong car; it isn’t cryptographic copy protection. That’s also why it no longer deletes anything: deleting only ever hurt genuine customers.

What makes the check harder is that the same calculation lives in four places: locking the package in the browser and on the server, and unlocking it in two different on-car scripts. All four have to agree byte for byte. One older script had rewritten the calculation in the car shell’s own arithmetic. In a 32-bit environment that could silently overflow and give the wrong result without a single error. In another script the car’s shell didn’t understand how the file names were encoded, so the delete quietly did nothing at all. The protection only existed on paper. The server version is now byte-for-byte identical to the browser one and checked against a memory card that was really used in a car.

I went through every product spreadsheet and the shop’s export. For each product I checked whether the promised activation is technically possible on that car, against the compatibility checker’s own data, because that is what decides real orders.

What I found: one make’s spreadsheet had been wrapped in quotes a second time on export. A reader saw 336 rows of one column instead of 14 products with 41 columns, so an import would have brought in garbage or nothing at all. The shop had over 30 products with no product code. Those can’t be updated by import or linked to the compatibility checker. One product was listed twice at different prices (€200 and €100), another four times as separate products. 32 finished products had never been imported: there were no Škoda or VW activations on sale at all.

Product names also included cars that don’t exist. There’s no Audi RS1 in the new-generation A1, and Audi has never built an RS Q7. Year ranges didn’t match the head unit. The VW T-Roc was listed as 2017–2023, but from model year 2021 it has MIB3 and needs a different product. 2015 Audi TTs have MIB1, where CarPlay can’t be activated. It went the other way too: some Audi ranges stopped at 2020 although those cars kept the same unit until 2024, so sales were simply being missed. Bentley was wrongly labelled MH2P. It’s actually MIB2 High, but the full-screen product still fits it.

The biggest finding was a missing section. The compatibility checker already knew 69 MIB3 software versions, but the shop had not a single MIB3 product. That left out every VAG car from about 2020 on: Golf 8, Octavia IV, Leon, Formentor, the whole ID range. The new master file added 50 MIB3 products for 26 models.

How it works now: the CarPlay and Android Auto catalogue is built by a script from one master file: 261 products with one price ladder and the same columns. Product codes match the shop’s, so an import updates the existing 89 products and adds the rest, with no duplicates. When a price needs changing, it’s changed in one place and the script is rerun.