Commit Graph
2 Commits
Author SHA1 Message Date
kristianwindandClaude Opus 5 8528b94c2d Drop WooCommerce's brand purple from the plugin icon
assets/icon.svg filled the badge, the envelope fold and the percent sign with
#7f54b3 — WooCommerce's own brand colour. Caught by the odin session during the
trademark review.

The point of taking "Woo" out of the plugin names was to stop implying an
official tie to Automattic. A mark that keeps their purple says visually
exactly what the rename stops saying, and a colour is harder to defend as
coincidence than a name. It is wrong independently of what the family palette
ends up being, so it does not wait for that decision.

#1a7a52 chosen to match the old colour's WEIGHT rather than merely to differ
from it: 5.32:1 on white against the purple's 5.50:1, so the white envelope and
badge keep the contrast the proportions were tuned for at 40px — the size
WordPress renders this at on Dashboard → Updates. Green also reads as savings.

The hex of the colour being avoided is written broken up in the comment
(7f-54-b3). A palette check across the five plugins would otherwise match this
explanation and report the icon as still carrying it — the same self-matching
trap the credential scan hit earlier today, when the rule flagged its own
documentation.

Not included, because it belongs to the rename and that is still Kristian's
decision: the aria-label still reads "WooCommerce Email Discount Manager",
which is the plugin's actual name today.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-17 10:08:13 +02:00
kristianwindandClaude Opus 5 200f791f40 An icon, a Check again that checks, and the auto-update rule written down
Three gaps found by being asked plain questions about it.

**The auto-update toggle was a promise nobody had checked.** offer_update()
answers even when the installed version is current, on the reasoning that the
answer has to land in WordPress's no_update list for the "Enable auto-updates"
link to exist at all. That was a comment and an intention; it is now an
assertion against the real WP_Plugins_List_Table, which is where the flag is
actually read:

    $plugin_data = array_merge( (array) $plugin_info->no_update[ $plugin_file ],
                               array( 'update-supported' => true ), $plugin_data );

A plugin in neither response nor no_update gets "Auto-updates are not available
for this plugin" while looking entirely healthy.

**An icon.** Without one, Dashboard → Updates shows a generic grey plug.
assets/icon.svg, handed over in the offer's icons key, served from the shop's
own copy rather than the release host — one fewer thing that must be reachable
for wp-admin to render, and it cannot go mixed content on an HTTPS shop. Drawn
as paths rather than <text>: an SVG that leans on a font renders differently on
every machine, and this one is shown at about 40px, which is the size where
that is the difference between a mark and a smudge.

**"Check again" now checks again.** The six-hour cache is right for the check
WordPress runs twice a day and wrong for a link whose whole promise is that it
looks now. Publishing a release and then clicking it showed nothing for up to
six hours, which reads exactly like a broken updater.

And docs/REUSE.md was missing all of this: it covered Update URI, where to
instantiate the updater and making the repo public, but not the one rule that
is genuinely easy to get wrong.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-16 12:23:05 +02:00