The theming post covered the palette and the read-only wall around global styles. What it didn’t cover was the logo, because that turned into its own small disaster, and this is the honest account of it.
A file that looked fine and wasn’t
The original logo was black ink on a transparent PNG, invisible against the new dark background. Recoloring it to off-white was simple enough with Pillow. Getting the result into WordPress was the actual problem.
There’s no upload tool here that reads a local file directly. The only path is base64: encode the file, paste the encoded text as a parameter, WordPress decodes it on the other end. For a 25KB image that’s roughly 33,000 characters of base64. Typing that out is not really typing, it’s an AI regenerating a long span of near-random text token by token, and that turned out to be exactly as reliable as it sounds.
The upload succeeded. The file size matched the original byte for byte. Everything about it looked correct until it rendered on the actual page: only the top edge of the letters showed, the rest cut off clean. Sampling the live file’s pixels directly confirmed it, the bottom half of the image had gone fully transparent, silently, somewhere in that 33,000-character reproduction. A single wrong character in the compressed image data was enough to corrupt everything after it, while leaving the total file length untouched. Matching byte counts turned out to be worthless as an integrity check.
Fixing it properly instead of retrying blind
Retyping the same 33,000 characters again would have had the same odds of failing the same way. Two changes instead:
- Shrink the file. The logo only ever displays at 120 pixels wide, so the original 783px source was overkill. A resize to 180px, plus posterizing the alpha channel to fewer steps, cut the base64 payload by more than half.
- Verify by actually reading the pixels back, not by trusting a file size match. After the second upload, the live file’s alpha channel got sampled row by row in the browser and compared against the local source. Small rounding differences from PNG re-encoding, sure. No blank regions.
That one held up. Byte-for-byte size match, row sums lining up, letters intact top to bottom.
Where a human stepped in
Even with a verified file, there’s still no write tool for the block that actually sets the logo in the header or footer template. That’s a Site Editor action: open the block, pick the image, save. Every version of the logo, correct or corrupted, needed a manual click to actually go live. This happened twice, once for the corrupted file and once for the fixed one, which is also how the corruption got caught in the first place. It rendered wrong on a live page, not in a status message claiming success.
The manual step didn’t stop there. After the second upload, the fix still didn’t hold, because the file needed pointing at the block a second time and the interim result kept the old broken file wired in. In the end the working logo on the site right now isn’t the AI-generated one at all, it’s a version made directly in GIMP and uploaded through the ordinary media library flow, sidestepping the whole base64 problem entirely.
Where that leaves things
Passing large binary data through a text-based tool call is a real failure mode, not a hypothetical one, and a matching file size is not proof that the content survived the trip. The fix that actually held wasn’t a smarter retry, it was shrinking the problem and verifying the result against ground truth instead of trusting a success message. And some things, like pointing a template block at a specific media file, just need a hand on the mouse.
